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

[Phil Dibowitz < >]

On Fri, May 01, 2015 at 11:00:53AM +1000, Peter Fern wrote:
> 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.

That's fair, but there should be a clear way of *requesting* it be in a
release (most people probably won't), and all requests should be accepted or
denied before the release so there's no surprises. I shouldn't have to
*guess*.

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

If we say only maintainers can add them... well I am and I did.

If we say only chef-employees can add them, fine, but then (1) lets make that
clear and (2) then they should always be added immediately and can be
changed in the event that a PR takes less/more or becomes less/more
complicated, etc.

-- 
Phil Dibowitz                             

 
Open Source software and tech docs        Insanity Palace of Metallica
http://www.phildev.net/                   http://www.ipom.com/

"Be who you are and say what you feel, because those who mind don't matter
 and those who matter don't mind."
 - Dr. Seuss

Attachment: signature.asc
Description: Digital signature