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

[Lamont Granquist < >]

On 5/1/15 11:01 AM, Phil Dibowitz wrote:
> 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?
I'm more in favor of the rc being cut off of master and that's the 
freeze.  Anything that was in the minor milestone that wasn't merged to 
master gets bumped to the next milestone.  The only thing that gets 
cherry-picked to the rc branch after that is bugfixes.

Releases take so much time that I don't think any more burden should be 
placed on the person shepherding the release.  I also think that any 
more process than this simply won't get followed correctly and that 
people doing the release will just continually make mistakes. We need to 
make it easy on that person to get their job done because the release 
job already sucks hard enough as it is.

I think this also is by far the safest approach for anyone trying to get 
a patch in.  Whatever process we come up with, I'm quite certain that if 
you've gotten your patch into master before the dot-0 rc is forked off 
that it'll make it into the release.

There's also the issue that the rc is supposed to reflect the stable 
code that is going to get shipped.  Any code which is cherry-picked from 
master after the rc goes is code which got no testing in the rc.  To 
make the rc process produce a more stable shipped release we shouldn't 
be cherry-picking anything other than regressions we find in the rc.