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

[Bryan McLellan < >]

On Tue, Apr 28, 2015 at 5:13 AM, Phil Dibowitz < " target="_blank"> > wrote:

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.

<3. Ticketing process, so dear to me.

All emotions are my own, as corporations aren't people and can't have emotions. ;)

 

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

Historically, how this works has varied over the years. Of course, it ends up being "whatever is in the branch the release is cut from" which I'll get back to. When we had JIRA and ticket workflows (*btm swoons*), committers were "forced" to set Fixed Version when they marked a ticket as merged. That at least told you what went into the release. You could also set Fix Version for things you wanted to go into the release. It wasn't a guarantee, but we used it when we need that functionality.

"Accepted Major" and "Accepted Minor" are not - afaict - sufficient. They
don't tell me what release my thing is going to be in.

I'm super sad I have to go use git to figure out what release something is in . I want to be able to ask people "are you using at least 12.x.y? because it was fixed there" rather than "you should always be upgrading to the latest release, because we fixed that at some point." I think "Accepted ..." is more for triaging work that we think should be done than tracking what you're looking for.

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

+600,203,123.02, you've been awarded Process Hero.

So, I want to dump some context here for visibility for those outside of Chef Software.

For the "next while", Chef Software is going to keep being responsible for the releases because it requires a build system that's internal. We've always wanted to expose that in some way, and we're working towards doing so. The client just moved to a "new" build cluster that's completely Chef [the software] managed. We've been running that cluster for a while for other projects, but the client has the most platforms to support so getting things like Solaris and FreeBSD going took some work. 12.3.0 was the first release done on it. One huge thing is that this cluster is more way reliable. For instance, the guests run on EC2 rather than your typical outdated openstack skunkworks project. Really soon (month? I hope) we're going to be getting this cluster to the point where it produces an "integration" build at least daily, if not for every merge to master. This means that non-Chef Software maintainers can merge code and get resulting builds. 

In the long, long ago, we had months between releases. They were really hard and not our priority. At various points in time it was my job to care about that, all other times I just care about it anyway. We're definitely continuing to improve on that. At Chef Software we've moved toward "functional teams" this year in Chef Engineering (oh names). Which means there isn't a "client team" anymore, and part of that effort is ensuring that any of the teams can make a release. My team has been doing the releases since then (H/T Jay), but Community Engineering just did the 12.3.0 release. Which is AWESOME, and a milestone in getting to that place internally. Part of this goal is having a more frequent cadence of smaller releases with less risk in each of them. 

If we "release all the time," the parts of the process that aren't the build become the heavy parts and there's going to be a tendency to skip out on those. (Sidebar: Kind of like how cloud computing drove configuration management). I think you bring up the exact points we need to focus on to make sure we don't lose the ticketing parts of that process that expose value to contributors, maintainers, and users in telling whats in a release and what will be in a release without having to muster to gusto to ask all the time.

We've been using "x-stable" branches for releases for a while and the "master" branch for the next major version development, loosely. I think most of us want to get away from that and just use master. In particular it caused some regressions in the last few releases because we had some commits on the 12-stable branch that weren't in master, and then we created a separate branch for 12.3 and it was as hairy as would be expected. Just using master does kick the can down the road in terms of what we do when we want to start working on breaking changes for the next release. Maybe those go in a branch, which we have to regularly rebase against master? If we get rid of release branches, then we basically ship everything that's in master for a minor release, every time. Maintainers who merge stuff to master get it shipped. I think that solves your concern about merging stuff as a Maintainer but not having it shipped. If we have to do a patch release off a previous release to fix a regression, we can checkout the last release tag and do that, and it is that persons responsibility to ensure master gets it too. This should be written up.

I'm waiting on a copyright comment from Serdar before merging chef-rfc#36 (Github Workflow Process). I think the "RFC terms" above split between that process and the RFC047 release process.There's also chef#3205, which is a medium hurdle to getting integration builds of the client easily, and has some forward looking thoughts on future versioning that need to keep this kind of discussion in mind.

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

https://github.com/chef/chef/issues/3205

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 :] ).

Bryan