I do think we should settle on some "minimum quality standards" for a release. I.e. No more than
- 0 critical bugs ( https://github.com/apache/trafficcontrol/issues?q=is%3Aopen+is%3Aissue+label%3Abug+label%3Acritical ) - 0 blocker bugs ( https://github.com/apache/trafficcontrol/issues?q=is%3Aopen+is%3Aissue+label%3Abug+label%3Ablocker ) - X major bugs ( https://github.com/apache/trafficcontrol/issues?q=is%3Aopen+is%3Aissue+label%3Amajor+label%3Abug ) although those labels are very subjective. one person's "critical" is another person's "trivial". if we can agree on the "minimum quality standards", it should be added to the release process ( https://cwiki.apache.org/confluence/display/TC/Release+Management+Process) imo and be enforced by the release manager. however, i'm not sure how you enforce it... jeremy On Tue, Mar 5, 2019 at 11:39 AM Fieck, Brennan <[email protected]> wrote: > I could get behind a 4.0 milestone if that's just where we are. > > > ... who would determine what goes into a minor release... > > That'd have to be done by voting for issues/PRs to include. But again, > the timebox approach is fine IMO, but if there are outstanding bugs to > be fixed or features that absolutely must be included in 4.0 (dropping Py2 > support!) those can be easily tracked using a milestone. > > > if we create a 4.0 milestone and put 40 issues in it, does that mean we > don't > > cut the 4.0 branch until those 40 things are done? > > Yeah that'd be the idea. But you're right, that almost certainly would > slow us > down so going back to Rawlin's suggestion, if we cut a new release today > (I'd volunteer to manage if I could) then the milestone should only track > things > that *must* go into 4.0 and be back-ported into the candidate branch. That > shouldn't be 40 things, it should probably be closer to 5. > ________________________________________ > From: Rawlin Peters <[email protected]> > Sent: Monday, March 4, 2019 4:36 PM > To: [email protected] > Subject: Re: [EXTERNAL] Re: Release Milestones > > Yeah, I agree with not doing a backport release for 3.1. I think the > 3.0.x branch was cut in early 09/18, which means master has advanced > nearly 6 months ahead now. I think unless there is a major bugfix > required for a 3.0.1 release, our next release should probably be 4.0. > That said, I don't know of anything that would prevent us from cutting > the 4.0.x branch off master right now, and given the cadence of the > last 3 major releases (3.0, 2.2, and 2.1) I think it would take about > 4-6 months to get the release out the door once the release branch is > cut off master. So, I don't think it will take a full year for the > next release. > > Are there any committers out there itching to be the next release manager? > > - Rawlin > > On Mon, Mar 4, 2019 at 3:39 PM Jeremy Mitchell <[email protected]> > wrote: > > > > I believe master is waaaaay ahead of the 3.0.x branch so doing a cherry > > pick (backport) of a feature for 3.1.0 might not be a safe operation. > plus, > > we don't typically do minor releases (not that we can't but who would > > determine what goes into a minor release). > > > > Because we don't have dedicated resources to properly plan and scope > > releases, we've always just followed the time-box approach. i.e. every X > > months, cut a release branch from master. at one point, i think we agreed > > to 2 or 3 major releases a year. IMO we should commit to 2 major > releases a > > year and on Jan 1 and July 1 of every year cut a release branch from > > master. whatever is in master at that point makes the release. > > > > milestones seem like a great idea and we tried them in the past but at > the > > end of the day who is responsible for doing the work in the milestone. if > > we create a 4.0 milestone and put 40 issues in it, does that mean we > don't > > cut the 4.0 branch until those 40 things are done? we might actually slow > > our cadence down if we do that. > > > > jeremy > > > > On Mon, Mar 4, 2019 at 2:50 PM Fieck, Brennan <[email protected] > > > > wrote: > > > > > There's a v1.5 API for doing consistent hashing using path regexes for > > > HTTP-routed delivery services, there have been Go client updates that > > > weren't in 3.0.0RC6 that would be required to get CiaB running on that > > > branch, and there have been numerous documentation updates and > > > bug fixes. At our current release cadence, these things will not reach > > > an official release for another year or so. I think we could easily > come up > > > with a list of changes to include in 3.0.1 and 3.1.0 releases, if not > any > > > planned future changes. > > > ________________________________________ > > > From: Rawlin Peters <[email protected]> > > > Sent: Monday, March 4, 2019 2:21 PM > > > To: [email protected] > > > Subject: [EXTERNAL] Re: Release Milestones > > > > > > I think master is mostly slated for 4.0 at this point, so any 3.1 > > > and/or 3.0.1 releases would probably have to be backports unless we're > > > willing to consider 3.1 a "next major release" for things like > > > removing the legacy Traffic Ops Perl UI. I think that was at least one > > > thing that was basically committed to 4.0, but there might be other > > > stuff too. > > > > > > That said, it's hard to justify doing a release without considering > > > what we'd like to get into the potential release. For example, is > > > there a major bugfix that warrants a 3.0.1 and/or a new feature in > > > master that should be backported into a 3.1 release rather than > > > waiting until we cut master into 4.0? > > > > > > - Rawlin > > > > > > On Mon, Mar 4, 2019 at 11:26 AM Fieck, Brennan > > > <[email protected]> wrote: > > > > > > > > To perhaps help us push out releases in a more timely fashion, maybe > we > > > should start making release Milestones? > > > > We've had them in the past: > > > https://github.com/apache/trafficcontrol/milestones I don't think > > > deciding on what we > > > > > > > > want in 4.0.0 is realistic right now, but we could certainly start > > > planning for 3.0.1 and even 3.1.0. Adding issues to fix > > > > > > > > or Pull Requests to include would probably be a voting process (a > > > cursory reading of the ASF release candidate > > > > > > > > process suggests that the votes for merely planning a release need > not > > > be "binding", though I could very well be > > > > > > > > wrong about that). Honestly, for a patch version we should probably > only > > > look at things that are actually done, > > > > > > > > whereas for a minor version release we'd want to plan on including > fixes > > > for extant problems and including functionality > > > > > > > > that may not be written today. > > > > > > > > > > > > Making sure everything that goes into a release is tracked by a > > > milestone as progress is made will also simplify > > > > > > > > checking the changelog for everything that should be there/maybe even > > > generating the changelog from the milestone. > > > > > > > > > > > > I don't have the authority to create milestones, which suggests that > > > even doing that requires a vote from the community > > > > > > > > before any committers feel obligated to do anything. I'm +1 on > creating > > > milestones for 3.1.0 and 3.0.1, and if and > > > > > > > > when voting on those commences I have some candidates for inclusion > in > > > each to propose. > > > >
