Derek, you want to make a 3.0.1 milestone and take a stab at throwing some issues in it with steve's help?
On Thu, Mar 7, 2019 at 6:16 AM Gelinas, Derek <[email protected]> wrote: > +1 > > On 3/7/19, 8:14 AM, "Steve Malenfant" <[email protected]> wrote: > > I think a milestone need to be created for 3.0.1 for bug fixes. I > believe > we have enough bugs to fix that should be ported back to 3.0. At least > we > can build from 3.0.x with latest fixes. We ended up in production with > 4-5 > different build number for numerous components. > > I know users won't be able to install Traffic Ops 3.0 for example on a > Centos 7.6 server (which was released in December). This stuff should > be > ported back and documented in the change log. > > Steve > > On Wed, Mar 6, 2019 at 4:38 PM Jeremy Mitchell <[email protected]> > wrote: > > > 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. > > > > > > > > > > > > >
