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