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

[Daniel DeLeo < >]

On Tuesday, April 28, 2015 at 2:13 AM, Phil Dibowitz wrote:
> On 04/28/2015 01:06 AM, Thom May wrote:
> > Hey Phil,
> > that one didn't make it to 12.3.0 because we'd already cut the RC last 
> > week.
> > I've not had a chance to look at it fully yet, but if it's urgent we'll 
> > either
> > pick it up in 12.3.1 or 12.4 in a couple of weeks.
>  
>  
>  
> Well - it's a breakage, so it's important in that sense, even though it's a
> relatively new feature not many people are using yet.
>  
> But I'm trying to discuss the more general problem here, not this specific 
> PR.
> And to be clear I'm not blaming anyone here. I think we have a process 
> problem.
>  
> > In general, we're using the issue milestones "Accepted Minor" for work 
> > that we
> > think aren't breaking changes, "Accepted Major", for things that we think 
> > will
> > be breaking changes or major work, and "Help Wanted", for issues that we'd
> > like help from the community with. We've been publishing the list of Help
> > Wanted issues to the chef-dev list as we assign things to that bucket.
> > Hope this helps,
>  
>  
>  
> I'm assuming your using Issue here interchangably with PR and not expecting
> contributors to have to make an issue for every PR? (that would seem
> unnecessarily onerous for contributors).
>  
> https://github.com/chef/chef-rfc/pull/36 doesn't actually mention how to 
> get a
> PR into a release, but since Chef doesn't actually release from HEAD 
> (*cough*
> delivery-keynote *couch*), which is totally fine, we need a defined way to
> denote stuff is desired for the next major/minor/bugfix release. Upon 
> previous
> discussions with btm, serdar, and others, I was lead to believe milestones 
> on
> PRs was that way... but that doesn't actually seem to be the case.
>  
> "Accepted Major" and "Accepted Minor" are not - afaict - sufficient. They
> don't tell me what release my thing is going to be in.
>  
> To put it in RFC terms:
>  
> As a contributor I should be able to say "I believe this belongs in 12.3"
>  
> As a maintainer I should be able to say "I'm sorry, but we're not going to 
> put
> it in 12.3 because it's big and scary"
>  
> As a contributor I should get the chance to know that and not suddenly see a
> release without the thing that I added the milestone to.
>  
> As a contributor I don't expect to be able to add a Milestone to a PR that 
> is
> already past the freeze date.
>  
> As a contributor I don't expect a release to go out the door with any 
> pending
> PRs tagged for it (either the Milestone should have been changed or I should
> have been unable to add it).
>  
>  
> It's not about this particular PR, this isn't an uncommon occurance. In 
> quite
> a few cases the only reason I've gotten my PR into a specific release is
> because I'm badgering Lamont, Adam, Serdar or someone else via 
> email/phonecall
> or whatever (or it's not that important to me and it falls into a release
> eventually) enough to make sure someone sees it.
>  
> As a maintainer I understand there is a time we cut an RC and want to get a
> release out the door, but from the perspective of both an end-user and a
> contributor, we're making a bad experience for people waiting on their
> fix/feature/whatever. We need to have a very clear way of a contributor to
> (optionally) specify what release they are expecting it to get in and a very
> clear way for us to let them know if that's going to happen.

Absolutely agree. In the past we announced RC freezes on the dev list (at 
least) with some advance notice, usually a week or so. If we just started 
doing that again (at least until we’re shipping from master), would that be 
enough?
  
>  
> --  
> Phil Dibowitz 
> 
 
>  
> (mailto:
 )
> 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



--  
Daniel DeLeo