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

[Daniel DeLeo < >]

On Friday, May 1, 2015 at 9:38 AM, Bryan McLellan wrote:

> On Tue, Apr 28, 2015 at 5:13 AM, Phil Dibowitz 
> <
 
>  
> (mailto:
 )>
>  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?
IMO we have to use feature flags for this stuff for the rest of time. Even if 
we have to copy and paste a bunch of functionality to keep the old thing 
working, it’s not that bad because the old thing shouldn’t change much once 
we decide we want to get rid of it at some future time. Then major version 
bumps are where we change the default feature flag and/or remove the old 
thing.

This is also what we should do for code we think is “too scary to merge right 
before a release.” For example, if we want to merge a thing, we’re a little 
unsure of it because it’s a big change or whatever, and we plan to ship a 
minor release in 2 days, then we should rework the patch to be able to toggle 
it off. In that case, we’d change the toggle (or remove it) after the release.
  
> 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 :] ).

I hate “digital paperwork” more than anyone I know, but it’s a necessary 
evil. Of course the best thing to do is automate it as much as possible.  
>  
> Bryan

I broadly agree with the general points here, especially with what Phil said 
“in RFC terms."  

--  
Daniel DeLeo