Re: [asterisk-dev] Proposal for New Major Version Process Change

[Joshua C. Colp]

On Wed, Jul 8, 2020 at 6:34 PM Matthew Fredrickson 
wrote:

> On Wed, Jul 8, 2020 at 8:29 AM Joshua C. Colp  wrote:
> >
> > On Wed, Jul 8, 2020 at 10:24 AM Dan Jenkins  wrote:
> >>
> >> YES YES YES.
> >
> >
> > I'm sorry, I didn't quite hear you. Did you say "no"? :D
> >
> >>
> >> I never really got why it was done like it was...
> >
> >
> > Yeah, I don't really recall why either. I think it originates from a
> time where we were still early to testing and didn't have confidence in
> things as much, still finding our footing.
> >
> >>
> >> I agree, 4-6 weeks is good. If someone's going to take the time to
> upgrade to an 18 RC then they'll be looking to test it and give feedback
> etc etc so you don't need a huge amount of time... just enough to actually
> action bug fixes and then release new RCs with those bug fixes
> >
> >
> > Indeed. Even before cutting the RC we'll be testing it and such too.
>
> This sounds like a good idea and definitely removes some of the
> complications around keeping branches in sync at that time.
>
> I'd be a fan of the 6 weeks side of things for major releases.
>

It sounds like everyone is on board with this proposal so I see no qualm
with giving it a try this time. Unless any concerns come up before
Wednesday then on Wednesday the Asterisk 18 branch will be cut, but the
18.0 branch will not. Changes will continue to flow into the Asterisk 18
branch as appropriate. Since this is the first time we're trying this I see
no reason we can't do 6 weeks for finalizing things, so 6 weeks before
release time the release candidates will be cut and made available.

Thanks everyone for your feedback!

-- 
Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Proposal for New Major Version Process Change

[Matthew Fredrickson]

On Wed, Jul 8, 2020 at 8:29 AM Joshua C. Colp  wrote:
>
> On Wed, Jul 8, 2020 at 10:24 AM Dan Jenkins  wrote:
>>
>> YES YES YES.
>
>
> I'm sorry, I didn't quite hear you. Did you say "no"? :D
>
>>
>> I never really got why it was done like it was...
>
>
> Yeah, I don't really recall why either. I think it originates from a time 
> where we were still early to testing and didn't have confidence in things as 
> much, still finding our footing.
>
>>
>> I agree, 4-6 weeks is good. If someone's going to take the time to upgrade 
>> to an 18 RC then they'll be looking to test it and give feedback etc etc so 
>> you don't need a huge amount of time... just enough to actually action bug 
>> fixes and then release new RCs with those bug fixes
>
>
> Indeed. Even before cutting the RC we'll be testing it and such too.

This sounds like a good idea and definitely removes some of the
complications around keeping branches in sync at that time.

I'd be a fan of the 6 weeks side of things for major releases.

Just my .02.
Matthew Fredrickson

>
> --
> Joshua C. Colp
> Asterisk Technical Lead
> Sangoma Technologies
> Check us out at www.sangoma.com and www.asterisk.org
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev



--
Matthew Fredrickson
Digium - A Sangoma Company | Director of Open Source Software Development
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Proposal for New Major Version Process Change

[Sylvain Boily]

Hello,

On 2020-07-08 8:20 a.m., Joshua C. Colp wrote:


What do people think? Do we believe that a month out is ample enough? 
The 18 branch itself will exist, so that can be used for early testing 
(and likely will be). If a month isn't enough it could be moved out 
further. Really I think thanks to the testing that happens and the 
code review I don't think we need as long of a stabilization period as 
has been needed in the past, so this helps shrink it.



Thank you for your proposal, looks like very cool, like the other 
probably 6 weeks will be better.


Sylvain

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Proposal for New Major Version Process Change

[James Finstrom]

Well if it got Dan Jenkins excited :)

I dig it.

On Wed, Jul 8, 2020 at 6:25 AM Dan Jenkins  wrote:
>
> YES YES YES.
>
> I never really got why it was done like it was...
>
> I agree, 4-6 weeks is good. If someone's going to take the time to upgrade to 
> an 18 RC then they'll be looking to test it and give feedback etc etc so you 
> don't need a huge amount of time... just enough to actually action bug fixes 
> and then release new RCs with those bug fixes
>
> Dan
>
>
>
> On Wed, Jul 8, 2020 at 2:14 PM Joshua C. Colp  wrote:
>>
>> On Wed, Jul 8, 2020 at 9:56 AM Jared Smith  wrote:
>>>
>>> On Wed, Jul 8, 2020 at 8:21 AM Joshua C. Colp  wrote:

 1. It leaves a confusing area for developers where we have to ask "should 
 this go into 18.0?"
 2. It confuses users because if they upgrade to 18.0.0 then it is likely 
 the other current releases have bug fixes they don't have, which has 
 caused issues for users in the past.
>>>
>>>
>>> I agree with these two points of confusion.
>>>
 What do people think? Do we believe that a month out is ample enough?
>>>
>>>
>>> I think somewhere between four and six weeks is more than adequate, given 
>>> the maturity of the project.
>>
>>
>> That's my thinking too. I also think despite not creating actual tarballs we 
>> could still reach out on the asterisk-users list and the Discourse early to 
>> inform people that the branch has been created and while a release candidate 
>> has not yet been created that it can still be retrieved from Git or Github 
>> and used/tested.
>>
>> --
>> Joshua C. Colp
>> Asterisk Technical Lead
>> Sangoma Technologies
>> Check us out at www.sangoma.com and www.asterisk.org
>> --
>> _
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> asterisk-dev mailing list
>> To UNSUBSCRIBE or update options visit:
>>http://lists.digium.com/mailman/listinfo/asterisk-dev
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev



-- 
James Finstrom
Guy who does stuff that is sometimes cool

gpg: https://github.com/jfinstrom.gpg

This email was sent from a personal email account. The content of this
email is not endorsed by my employer or any project I may be a part
of. The contents of this email should be considered my opinion and not
taken as any form of official response. Please keep your hands and
feet in the ride while in motion. Please be sure to tip the wait
staff.

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Proposal for New Major Version Process Change

[Joshua C. Colp]

On Wed, Jul 8, 2020 at 12:57 PM Corey Farrell  wrote:

> With the current process new features can be added with tests can target
> 18 as soon as the branch is cut but would not go into 18.0.  What would
> happen with new features in this scheme, would they just get held open in
> gerrit until 18.0 is branched or be accepted as normal since 18.0.0 release
> process is not yet started?  I agree a month is plenty of time for the
> release candidate cycle but think it would be good to decide how new
> features will be dealt with before 18 is branched.
>
The policies of a normal release branch would apply to the 18 branch once
cut. That means you would not be able to just throw new features in on a
whim, but they would be held to the same requirements/restrictions we place
on the other branches (13, 16, and 17) and would be merged in before 18.0.0
is cut if they fall within that. They would also, like normal, go into the
other release branches as appropriate (and I expect that would be the case).

-- 
Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Proposal for New Major Version Process Change

[Corey Farrell]

With the current process new features can be added with tests can target 
18 as soon as the branch is cut but would not go into 18.0.  What would 
happen with new features in this scheme, would they just get held open 
in gerrit until 18.0 is branched or be accepted as normal since 18.0.0 
release process is not yet started?  I agree a month is plenty of time 
for the release candidate cycle but think it would be good to decide how 
new features will be dealt with before 18 is branched.


On 7/8/20 8:20 AM, Joshua C. Colp wrote:

Greetings all,

I've given this some thought in the past and thought with the 
impending branching of Asterisk 18 I'd get some input on a change to 
the process. The new major version process has evolved over time but 
hasn't really been changed lately. Let's look at what it is like in 
practice today:


On July 15th under current process both the 18 branch and 18.0 
branches will be cut. The 18 branch will continue to receive all bug 
fixes, but the 18.0 branch will only receive changes as a result of 
issues found through testing 18.0 or through big fixes to new 
functionality in it. This means that when 18.0.0 is actually released 
it is generally a few months behind. In the past this was to give it 
time to stabilize as it were. This presents the following issues:


1. It leaves a confusing area for developers where we have to ask 
"should this go into 18.0?"
2. It confuses users because if they upgrade to 18.0.0 then it is 
likely the other current releases have bug fixes they don't have, 
which has caused issues for users in the past.


I don't think this is the best situation for either.

I'd like to propose that instead of cutting the 18.0 branch on July 
15th we simply cut the 18 branch, and that it continues to receive all 
bug fixes. Approximately a month before a target release of 18.0.0 we 
create the first release candidate, 18.0.0-rc1. At this time we also 
create release candidates of the other branches. All release 
candidates will then be left available for a prolonged period of time 
to give people ample time to test. On the release date all will be 
released, ensuring that all branches including 18 have the same set of 
bug fixes as appropriate to their version.


This removes the confusion for developers over whether to include a 
fix, since the 18.0 branch won't exist until rc1 at which point normal 
cherry pick rules apply. This also eliminates the confusion 
experienced by users since all releases will be on the same page at 
the same time at release.


What do people think? Do we believe that a month out is ample enough? 
The 18 branch itself will exist, so that can be used for early testing 
(and likely will be). If a month isn't enough it could be moved out 
further. Really I think thanks to the testing that happens and the 
code review I don't think we need as long of a stabilization period as 
has been needed in the past, so this helps shrink it.


Cheers,

--
Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at www.sangoma.com  and 
www.asterisk.org 


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Proposal for New Major Version Process Change

[Michael L. Young]

- On Jul 8, 2020, at 8:20 AM, Joshua C. Colp  wrote: 

| I'd like to propose that instead of cutting the 18.0 branch on July 15th we
| simply cut the 18 branch, and that it continues to receive all bug fixes.
| Approximately a month before a target release of 18.0.0 we create the first
| release candidate, 18.0.0-rc1. At this time we also create release candidates
| of the other branches. All release candidates will then be left available for 
a
| prolonged period of time to give people ample time to test. On the release 
date
| all will be released, ensuring that all branches including 18 have the same 
set
| of bug fixes as appropriate to their version.

| This removes the confusion for developers over whether to include a fix, since
| the 18.0 branch won't exist until rc1 at which point normal cherry pick rules
| apply. This also eliminates the confusion experienced by users since all
| releases will be on the same page at the same time at release.

| What do people think? Do we believe that a month out is ample enough? The 18
| branch itself will exist, so that can be used for early testing (and likely
| will be). If a month isn't enough it could be moved out further. Really I 
think
| thanks to the testing that happens and the code review I don't think we need 
as
| long of a stabilization period as has been needed in the past, so this helps
| shrink it.

The proposal sounds very reasonable. Yes, with all the testing that is in the 
project now, a month should be good enough. 

-- 
Michael L. Young 
(elguero) 
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Proposal for New Major Version Process Change

[Kevin Harwell]

+1

I would also would approve of other potential changes to releases and the
release process but will save that for another time :-D

On Wed, Jul 8, 2020 at 7:21 AM Joshua C. Colp  wrote:

> Greetings all,
>
> I've given this some thought in the past and thought with the impending
> branching of Asterisk 18 I'd get some input on a change to the process. The
> new major version process has evolved over time but hasn't really been
> changed lately. Let's look at what it is like in practice today:
>
> On July 15th under current process both the 18 branch and 18.0 branches
> will be cut. The 18 branch will continue to receive all bug fixes, but the
> 18.0 branch will only receive changes as a result of issues found through
> testing 18.0 or through big fixes to new functionality in it. This means
> that when 18.0.0 is actually released it is generally a few months behind.
> In the past this was to give it time to stabilize as it were. This presents
> the following issues:
>
> 1. It leaves a confusing area for developers where we have to ask "should
> this go into 18.0?"
> 2. It confuses users because if they upgrade to 18.0.0 then it is likely
> the other current releases have bug fixes they don't have, which has caused
> issues for users in the past.
>
> I don't think this is the best situation for either.
>
> I'd like to propose that instead of cutting the 18.0 branch on July 15th
> we simply cut the 18 branch, and that it continues to receive all bug
> fixes. Approximately a month before a target release of 18.0.0 we create
> the first release candidate, 18.0.0-rc1. At this time we also create
> release candidates of the other branches. All release candidates will then
> be left available for a prolonged period of time to give people ample time
> to test. On the release date all will be released, ensuring that all
> branches including 18 have the same set of bug fixes as appropriate to
> their version.
>
> This removes the confusion for developers over whether to include a fix,
> since the 18.0 branch won't exist until rc1 at which point normal cherry
> pick rules apply. This also eliminates the confusion experienced by users
> since all releases will be on the same page at the same time at release.
>
> What do people think? Do we believe that a month out is ample enough? The
> 18 branch itself will exist, so that can be used for early testing (and
> likely will be). If a month isn't enough it could be moved out further.
> Really I think thanks to the testing that happens and the code review I
> don't think we need as long of a stabilization period as has been needed in
> the past, so this helps shrink it.
>
> Cheers,
>
> --
> Joshua C. Colp
> Asterisk Technical Lead
> Sangoma Technologies
> Check us out at www.sangoma.com and www.asterisk.org
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev



-- 
Kevin Harwell
Software Developer
Sangoma Technologies
Check us out at: https://sangoma.com & https://asterisk.org
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Proposal for New Major Version Process Change

[Joshua C. Colp]

On Wed, Jul 8, 2020 at 10:24 AM Dan Jenkins  wrote:

> YES YES YES.
>

I'm sorry, I didn't quite hear you. Did you say "no"? :D


> I never really got why it was done like it was...
>

Yeah, I don't really recall why either. I think it originates from a time
where we were still early to testing and didn't have confidence in things
as much, still finding our footing.


> I agree, 4-6 weeks is good. If someone's going to take the time to upgrade
> to an 18 RC then they'll be looking to test it and give feedback etc etc so
> you don't need a huge amount of time... just enough to actually action bug
> fixes and then release new RCs with those bug fixes
>

Indeed. Even before cutting the RC we'll be testing it and such too.

-- 
Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Proposal for New Major Version Process Change

[Dan Jenkins]

YES YES YES.

I never really got why it was done like it was...

I agree, 4-6 weeks is good. If someone's going to take the time to upgrade
to an 18 RC then they'll be looking to test it and give feedback etc etc so
you don't need a huge amount of time... just enough to actually action bug
fixes and then release new RCs with those bug fixes

Dan



On Wed, Jul 8, 2020 at 2:14 PM Joshua C. Colp  wrote:

> On Wed, Jul 8, 2020 at 9:56 AM Jared Smith 
> wrote:
>
>> On Wed, Jul 8, 2020 at 8:21 AM Joshua C. Colp  wrote:
>>
>>> 1. It leaves a confusing area for developers where we have to ask
>>> "should this go into 18.0?"
>>> 2. It confuses users because if they upgrade to 18.0.0 then it is likely
>>> the other current releases have bug fixes they don't have, which has caused
>>> issues for users in the past.
>>>
>>
>> I agree with these two points of confusion.
>>
>> What do people think? Do we believe that a month out is ample enough?
>>> 
>>
>>
>> I think somewhere between four and six weeks is more than adequate, given
>> the maturity of the project.
>>
>
> That's my thinking too. I also think despite not creating actual tarballs
> we could still reach out on the asterisk-users list and the Discourse early
> to inform people that the branch has been created and while a release
> candidate has not yet been created that it can still be retrieved from Git
> or Github and used/tested.
>
> --
> Joshua C. Colp
> Asterisk Technical Lead
> Sangoma Technologies
> Check us out at www.sangoma.com and www.asterisk.org
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Proposal for New Major Version Process Change

[Joshua C. Colp]

On Wed, Jul 8, 2020 at 9:56 AM Jared Smith 
wrote:

> On Wed, Jul 8, 2020 at 8:21 AM Joshua C. Colp  wrote:
>
>> 1. It leaves a confusing area for developers where we have to ask "should
>> this go into 18.0?"
>> 2. It confuses users because if they upgrade to 18.0.0 then it is likely
>> the other current releases have bug fixes they don't have, which has caused
>> issues for users in the past.
>>
>
> I agree with these two points of confusion.
>
> What do people think? Do we believe that a month out is ample enough?
>> 
>
>
> I think somewhere between four and six weeks is more than adequate, given
> the maturity of the project.
>

That's my thinking too. I also think despite not creating actual tarballs
we could still reach out on the asterisk-users list and the Discourse early
to inform people that the branch has been created and while a release
candidate has not yet been created that it can still be retrieved from Git
or Github and used/tested.

-- 
Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Proposal for New Major Version Process Change

[Jared Smith]

On Wed, Jul 8, 2020 at 8:21 AM Joshua C. Colp  wrote:

> 1. It leaves a confusing area for developers where we have to ask "should
> this go into 18.0?"
> 2. It confuses users because if they upgrade to 18.0.0 then it is likely
> the other current releases have bug fixes they don't have, which has caused
> issues for users in the past.
>

I agree with these two points of confusion.

What do people think? Do we believe that a month out is ample enough?
> 


I think somewhere between four and six weeks is more than adequate, given
the maturity of the project.

--
Jared Smith
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Proposal for New Major Version Process Change

[George Joseph]

On Wed, Jul 8, 2020 at 6:21 AM Joshua C. Colp  wrote:

> Greetings all,
>
> I've given this some thought in the past and thought with the impending
> branching of Asterisk 18 I'd get some input on a change to the process. The
> new major version process has evolved over time but hasn't really been
> changed lately. Let's look at what it is like in practice today:
>
> On July 15th under current process both the 18 branch and 18.0 branches
> will be cut. The 18 branch will continue to receive all bug fixes, but the
> 18.0 branch will only receive changes as a result of issues found through
> testing 18.0 or through big fixes to new functionality in it. This means
> that when 18.0.0 is actually released it is generally a few months behind.
> In the past this was to give it time to stabilize as it were. This presents
> the following issues:
>
> 1. It leaves a confusing area for developers where we have to ask "should
> this go into 18.0?"
> 2. It confuses users because if they upgrade to 18.0.0 then it is likely
> the other current releases have bug fixes they don't have, which has caused
> issues for users in the past.
>
> I don't think this is the best situation for either.
>

Agreed.


>
> I'd like to propose that instead of cutting the 18.0 branch on July 15th
> we simply cut the 18 branch, and that it continues to receive all bug
> fixes. Approximately a month before a target release of 18.0.0 we create
> the first release candidate, 18.0.0-rc1. At this time we also create
> release candidates of the other branches. All release candidates will then
> be left available for a prolonged period of time to give people ample time
> to test. On the release date all will be released, ensuring that all
> branches including 18 have the same set of bug fixes as appropriate to
> their version.
>

Sounds like a good plan.


>
> This removes the confusion for developers over whether to include a fix,
> since the 18.0 branch won't exist until rc1 at which point normal cherry
> pick rules apply. This also eliminates the confusion experienced by users
> since all releases will be on the same page at the same time at release.
>
> What do people think? Do we believe that a month out is ample enough? The
> 18 branch itself will exist, so that can be used for early testing (and
> likely will be). If a month isn't enough it could be moved out further.
> Really I think thanks to the testing that happens and the code review I
> don't think we need as long of a stabilization period as has been needed in
> the past, so this helps shrink it.
>

+1


>
> Cheers,
>
> --
> Joshua C. Colp
> Asterisk Technical Lead
> Sangoma Technologies
> Check us out at www.sangoma.com and www.asterisk.org
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev



-- 
George Joseph
Asterisk Software Developer
direct/fax +1 256 428 6012
Check us out at www.sangoma.com and www.asterisk.org
[image: image.png]
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev