[pytest-dev] on abolishing the feature branch concept

[Bruno Oliveira]

On Mon, Jan 25, 2016 at 9:49 AM Florian Bruhin <me at the-compiler.org> wrote:

> * Bruno Oliveira <nicoddemus at gmail.com> [2016-01-25 11:43:27 +0000]:
> > 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.
>

One benefit I see is that we would have a an answer for the common question
"when will be the next bug fix release", which we always respond "as soon
as we have some other get bugs fixed"... having a schedule for that also
would allow people to prepare and plan themselves.



> > > 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?
>

I understood that Ronny's plan was to make regendoc run for every PR. I'm
just commenting on what I had in mind to enrich the discussion with an
alternate point of view. :)

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.
>

Certainly, I agree!

Cheers,
Bruno.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20160125/e6034588/attachment.html>