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

[Phil Dibowitz < >]

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.

-- 
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: OpenPGP digital signature