[pytest-dev] on abolishing the feature branch concept

[Florian Bruhin]

* Bruno Oliveira <nicoddemus at gmail.com> [2016-01-25 11:43:27 +0000]:
> On Mon, Jan 25, 2016 at 9:06 AM Ronny Pfannschmidt <
> opensource at ronnypfannschmidt.de> wrote:
> 
> > I agree on the link article as well and like the model,
> > i propose a time-frame of either 3 or 4 months for the feature releases.
> >
> > My personal preference is 3 months.
> >
> 
> I think that sounds good for the feature releases. For bug fix releases I
> think a shorter time frame makes more sense, how about every 2 weeks? We
> could prepare the release PR Thursday and release on Friday.

I don't think it makes sense to do time-based *bugfix* releases.
GitLab does those as appropriate (i.e. whenever important enough fixes
pile up), and I think it makes more sense to keep the flexibility
there.

> > I'd like to discuss a new approach at a later point in time.
> > the idea is to have a deploy handler, which will "deploy" a pull request
> > to maser/feature
> > whenever it notices differences after a regen run.
> >
> 
> Sure, count me in for this discussion.
> 
> I was thinking of having a manual trigger, where one would make changes to
> a "regendoc-pytest" repository  (like in my devpi-pytest experiment) and
> push it. This would trigger a regendoc run and PR, which could then be
> merged as usual. Running this job would then be part of the release
> process. It is still does require manual intervention, but is less error
> prone and does not require the person to have everything configured in
> their local workstation.

I think that's what ronny proposed too, no?

Doing a regendoc PR from Travis sounds like a good idea IMHO. First
maybe it should be more deterministic though, i.e. produce no changes
if there was nothing changing the output.

Florian

-- 
http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
         I love long mails! | http://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20160125/7b28c20d/attachment.sig>