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

[Phil Dibowitz < >]

On 05/01/2015 09:38 AM, Bryan McLellan wrote:
> Anyway, this conversation should absolutely result in PRs against RFCs.
> 
> It's probably "as easy as" writing in process for using milestones. In the
> Github Workflow Process the next unreleased milestone gets set to something
> when it's merged to track that it'll be in that release. In the RFC047 
> release
> process, we basically say that we search for something like "is:open
> milestone:12.2.1" if that's the release we want to make and we have to have 
> a
> discussion/resolve anything that's still open (e.g. this is too big, has to 
> be
> in the next release, this release is just about getting a regression fixed).
> The hard part is probably convincing everyone who has to do it's that it is
> worth the time so we don't lose any potential release cadence (like it's 
> hard
> convincing people that keeping a clean git history is worth the effort :] ).

Thanks Bryan! Yes I was probably assuming more widespread knowledge of some of
that context then was reasonable, I'm glad you laid that out.

I LOVE the idea of living on master, but I realize we've got work to do before
we get there.

While I'm always happy to write RFCs (or PRs against RFCs), I don't think it
makes any sense for a non-Chef-employee to write one around
release-engineering since (a) only Chef-employees will be doing it
(justifiably) for the forseeable future and (b) it has to fit into your guys'
workflow and tools.

But I'm happy to help figure out a process. How about something like this -
please feel free to modify/hackup/etc.:

* At freeze-date, releaser must:
 * search for "is:closed milestone:X.Y.Z" and either:
   * cherry-pick to release branch OR
   * comment that we're not pulling it in for reason Q (and add a later 
milestone)
 * search for "is:open milestone:X.Y.Z" and either:
   * merge to master & merge to to release branch *IF* it was ready already OR
   * change the milestone
 * _IF_ the release is X.Y.0 then repeat the above 2 steps for
"milestone:X.Y-1.Z+1"... i.e if the last release was 12.3.1 and we're
releasing 12.4, we should check for anything tagged for 12.3.2.
 * Close the aforementioned milestones
 * Add milestones for the next anticipated minor and bugfix release (assuming
a release of, say 12.3.1, he or she would add 12.3.2 and 12.4.0).
 * Add a milestone for <release>-rcfix
 * Do build

Then..

* At final-release time (or additional-RC time), the releaser must do the same
thing for <release>-rcfix - not everything has to be cherry-picked, but it
must EITHER be cherry-picked *OR* moved to a later milestone

The goals here being:

* When an RC is built, everything LEFT with that milestone is included (not
everything that *had* that milestone)
* When a final is built, anything with RC-fix was either picked or explicitly
denied.

Thoughts?


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