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

[Bryan McLellan < >]

On Fri, May 1, 2015 at 2:01 PM, Phil Dibowitz < " target="_blank"> > wrote:

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.

Our internal tools are already pretty well reduced to a single line in RFC047. I like the perspective of someone on the outside adding context like "as someone that isn't you, I like knowing thing"

https://github.com/chef/chef-rfc/blob/master/rfc047-release-process.md#chef-client-release-process-1

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

I think we just ship off master or near master like Lamont is talking about. Let's work that out. But that removes the first part of the process where we look for closed things and do anything with them. They're already merged to the place that they ship from. Ideally, we don't have to merge anything for the release because the Maintainers are doing it periodically (which also lets people use that code in the nightly builds)

* At freeze-date, releaser must:
* search for "is:open milestone:X.Y.Z" and either:
  * merge to master
  * comment that we're not pulling it in for reason Q (and add a later milestone)

* if shipping a major or minor release, repeat the previous step for any lesser milestones
* Close the aforementioned milestones
* Add milestones for the next release versions as applicable

* Build/ship RC

# Wait one week per RFC047. Watch for regressions filed.

* tag/ship final build.

I'd like to avoid the rcfix milestones. It's on the Maintainers to watch for regressions between an rc and final get that stuff fixed and merged into the release branch already. While we don't all triage issues completely, we all have our ears to the ground in different places and hear about these. I think the rcfix milestone creation is going to mostly be busywork and more likely to be skipped/forgotten/noisy than help us find an issue/pr we wouldn't find anyway.

On Fri, May 1, 2015 at 5:29 PM, Lamont Granquist < " target="_blank"> > wrote:

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.

Yeah I don't like freezing master itself. It's been annoying having our release tags out on release branches, but I think that's actually okay if our release branches are short dead ends. Which is what I think we're talking about. But I'm not sure I want a bunch of branches lying around.

git checkout -b 12-release master

git tag 12.x.y.rc.0 -a

git push origin 12.x.y.rc.0 && git push origin 12-release

# build and ship off the 12.x.y.rc.0 tag

# development can continue off master

# regression is found

git checkout 12-release

git commit -a -m "fix regression"

git tag 12.x.y.rc.1 -a

git checkout master

git cherry-pick some-sha
git push origin 12.x.y.rc.1 && git push origin 12-release && git push origin master

# ... release happens on 12-release

git checkout master

git merge 12-release

It seems like you're going to have problems with the cherry-pick on that final merge, but I'd like those branches to get merged back in so they can "go away." Am I missing something about git here? Is there a better way to do that?

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.

Releases are getting faster + easier. Eventually the talk is that the builds happen automatically and we will "promote a build" to stable when we want to. 12.3.0 happened fairly magically using manhattan. I thinking milestones are really worthwhile to anyone who isn't the person making the release. We need this even internally now since we're trying to have more teams writing client code so they can understand whats happening with their PRs.

We could have a Jenkins step before chef-release that takes the Chef Version and searches the github issues API for open issues for that version, and fails if there are any. I think that'd make more people rage than it would help though.

--

Bryan McLellan | chef | engineering lead
(c) 206.607.7108 | (t) @btmspox | (www) http://chef.io