You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficcontrol.apache.org by "Fieck, Brennan" <Br...@comcast.com> on 2019/03/04 21:50:34 UTC
Re: [EXTERNAL] Re: Release Milestones
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 <ra...@gmail.com>
Sent: Monday, March 4, 2019 2:21 PM
To: dev@trafficcontrol.apache.org
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
<Br...@comcast.com> 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.
Re: [EXTERNAL] Re: Release Milestones
Posted by Hank Beatty <hb...@apache.org>.
I created the 3.0.1 milestone and added a couple of PRs to it.
-Hank
On 3/7/19 10:18 AM, Jeremy Mitchell wrote:
> 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 <De...@comcast.com>
> wrote:
>
>> +1
>>
>> On 3/7/19, 8:14 AM, "Steve Malenfant" <sm...@gmail.com> 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 <mi...@gmail.com>
>> 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 <
>> Brennan_Fieck@comcast.com>
>> > 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 <ra...@gmail.com>
>> > > Sent: Monday, March 4, 2019 4:36 PM
>> > > To: dev@trafficcontrol.apache.org
>> > > 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 <
>> mitchell852@gmail.com>
>> > > 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 <
>> > Brennan_Fieck@comcast.com
>> > > >
>> > > > 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 <ra...@gmail.com>
>> > > > > Sent: Monday, March 4, 2019 2:21 PM
>> > > > > To: dev@trafficcontrol.apache.org
>> > > > > 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
>> > > > > <Br...@comcast.com> 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.
>> > > > >
>> > >
>> >
>>
>>
>>
>
Re: [EXTERNAL] Re: Release Milestones
Posted by Jeremy Mitchell <mi...@gmail.com>.
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 <De...@comcast.com>
wrote:
> +1
>
> On 3/7/19, 8:14 AM, "Steve Malenfant" <sm...@gmail.com> 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 <mi...@gmail.com>
> 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 <
> Brennan_Fieck@comcast.com>
> > 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 <ra...@gmail.com>
> > > Sent: Monday, March 4, 2019 4:36 PM
> > > To: dev@trafficcontrol.apache.org
> > > 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 <
> mitchell852@gmail.com>
> > > 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 <
> > Brennan_Fieck@comcast.com
> > > >
> > > > 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 <ra...@gmail.com>
> > > > > Sent: Monday, March 4, 2019 2:21 PM
> > > > > To: dev@trafficcontrol.apache.org
> > > > > 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
> > > > > <Br...@comcast.com> 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.
> > > > >
> > >
> >
>
>
>
Re: [EXTERNAL] Re: Release Milestones
Posted by "Gelinas, Derek" <De...@comcast.com>.
+1
On 3/7/19, 8:14 AM, "Steve Malenfant" <sm...@gmail.com> 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 <mi...@gmail.com>
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 <Br...@comcast.com>
> 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 <ra...@gmail.com>
> > Sent: Monday, March 4, 2019 4:36 PM
> > To: dev@trafficcontrol.apache.org
> > 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 <mi...@gmail.com>
> > 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 <
> Brennan_Fieck@comcast.com
> > >
> > > 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 <ra...@gmail.com>
> > > > Sent: Monday, March 4, 2019 2:21 PM
> > > > To: dev@trafficcontrol.apache.org
> > > > 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
> > > > <Br...@comcast.com> 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.
> > > >
> >
>
Re: [EXTERNAL] Re: Release Milestones
Posted by Steve Malenfant <sm...@gmail.com>.
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 <mi...@gmail.com>
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 <Br...@comcast.com>
> 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 <ra...@gmail.com>
> > Sent: Monday, March 4, 2019 4:36 PM
> > To: dev@trafficcontrol.apache.org
> > 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 <mi...@gmail.com>
> > 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 <
> Brennan_Fieck@comcast.com
> > >
> > > 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 <ra...@gmail.com>
> > > > Sent: Monday, March 4, 2019 2:21 PM
> > > > To: dev@trafficcontrol.apache.org
> > > > 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
> > > > <Br...@comcast.com> 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.
> > > >
> >
>
Re: [EXTERNAL] Re: Release Milestones
Posted by Jeremy Mitchell <mi...@gmail.com>.
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 <Br...@comcast.com>
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 <ra...@gmail.com>
> Sent: Monday, March 4, 2019 4:36 PM
> To: dev@trafficcontrol.apache.org
> 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 <mi...@gmail.com>
> 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 <Brennan_Fieck@comcast.com
> >
> > 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 <ra...@gmail.com>
> > > Sent: Monday, March 4, 2019 2:21 PM
> > > To: dev@trafficcontrol.apache.org
> > > 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
> > > <Br...@comcast.com> 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.
> > >
>
Re: [EXTERNAL] Re: Release Milestones
Posted by "Fieck, Brennan" <Br...@comcast.com>.
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 <ra...@gmail.com>
Sent: Monday, March 4, 2019 4:36 PM
To: dev@trafficcontrol.apache.org
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 <mi...@gmail.com> 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 <Br...@comcast.com>
> 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 <ra...@gmail.com>
> > Sent: Monday, March 4, 2019 2:21 PM
> > To: dev@trafficcontrol.apache.org
> > 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
> > <Br...@comcast.com> 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.
> >
Re: [EXTERNAL] Re: Release Milestones
Posted by Rawlin Peters <ra...@gmail.com>.
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 <mi...@gmail.com> 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 <Br...@comcast.com>
> 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 <ra...@gmail.com>
> > Sent: Monday, March 4, 2019 2:21 PM
> > To: dev@trafficcontrol.apache.org
> > 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
> > <Br...@comcast.com> 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.
> >
Re: [EXTERNAL] Re: Release Milestones
Posted by Jeremy Mitchell <mi...@gmail.com>.
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 <Br...@comcast.com>
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 <ra...@gmail.com>
> Sent: Monday, March 4, 2019 2:21 PM
> To: dev@trafficcontrol.apache.org
> 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
> <Br...@comcast.com> 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.
>