[chef-dev] Re: Re: Re: releases, github milestones, etc.

[Peter Fern < >]

On 05/01/2015 05:54, Phil Dibowitz wrote:
> On Thu, Apr 30, 2015 at 05:49:55PM +0100, Thom May wrote:
>> I don't think that's realistic though; that hypothetical contributor can't
>> make a good judgement on whether their contribution is gonna go into a
>> patch release or has to be held until the next major version.
>> That said, I think it is reasonable to have a tag that allows the
>> contributor to nominate regressions.
> Many contributors won't... but if you're not even looking at milestones, how
> are you even sure you're merging in the things *you* want to merge to a 
> given
> release. We need a consistent way to tag stuff for a release so that Chef 
> can
> do a search, ensure everything is merged.
>
> Let's say there was a regression in the RC and I sent a PR, merge it, and 
> tag
> it for release, but you don't merge it. Oops, now we just released a
> regression we didn't have to. The argument of "oh, but we'll know about the
> regression so we'll cherry pick it ourselves" isn't acceptable. The whole
> point of having maintainers and open development system is so there's
> transparency and consistency. EIther we're using milestones in GH or we're
> not, but we need a system that's consistent.

I don't think it's sane to for every contributor to be allowed to decide
- based on their own value judgment, that may or may not be sound - when
their PR should get merged.  This is likely to result in at best noise,
and at worst chaos, since everyone wants their stuff to go in as soon as
possible, and often only the project maintainers have any broad sense of
the state of the projects, and the impact of other items in the merge queue.

I do agree that milestones add useful visibility for all involved
though.  Contributor settable tags for enhancement, bugfix and
regression do make sense - the review team can use them to prioritize
regressions and then /they/ should bin issues into a milestone.