Re: Inquiry: NGINX branch to track in "Interim" Non-LTS Releases

[Thomas Ward]

Hi, all.


On 08/08/2018 10:00 AM, Thomas Ward wrote:
>
>
>
> On 08/08/2018 01:22 AM, Christian Ehrhardt wrote:
>>
>>
>> On Tue, Aug 7, 2018 at 7:14 PM Thomas Ward > > wrote:
>>
>> 
>>
>> Hi Thomas,
>> yeah I'd prefer to track Mainline in non-LTS releases as well.
>>
>> To the sole exception of being very careful toward the next LTS to
>> not being forced to decide to "go back" or "stay on mainline" for the
>> next Ubuntu LTS.
>> For example if NGINX 1.17 mainline would be in Ubuntu 19.10 (as we
>> track mainline in non-LTS releases), but then there would not be a
>> NGINX 1.18 stable available in time for Ubuntu 20.04 to pick up.
>> I don't know about the NGINX release schedule too much (is it regular
>> and reliable?), maybe this is not an issue at all, but I have seen
>> similar issues for other packages so I wanted to mention it.
>>
>
> We do have that type of issue though.  We need not look further than
> the 16.04 cycle for an example of this.  NGINX Stable was cut from
> NGINX Mainline the same day as we released 16.04, but we had tracked
> mainline right up to that point so there was a version strong only
> change SRU'd in the day after release.
>
> For 18.04, NGINX Stable was cut from mainline the same day as final
> freeze, but I managed to get that uploaded right before FinalFreeze
> went into effect.
>
> NGINX stable versions tend to be cut from mainline right about the
> time we are either releasing or are entering final freeze, based on
> the past experiences of their release cycles.  Generally speaking
> however, even if they cut stable from mainline right after we release,
> the changes between Mainline and stable at that point are typically
> just version string changes as we saw in the 16.04 cycle.  Maybe a
> bugfix or two but usually not new features.
>
> NGINX however doesn't follow a fixed-date release cycle
> unfortunately.  Which has contributed to things like the 16.04 cycle
> had or a last minute upload before freeze like 18.04 had.  They do,
> however, tend to cut the releases within 1 week of our release date
> (Ubuntu Release Week +/- 1 week), and by that point the likelihood
> they add any new features to the release prior to cutting Stable from
> that mainline branch is very very low based on the historical trends
> (based on watching upstream changelogs since 2014).
>
> While I can't say with *certainty* there won't be a case where they
> release Stable maybe a week after our release, it's so far only been a
> version-string-only change, and there's precedent already in place
> from 16.04 where we can put a version-string-only change into -updates
> without disrupting anything.  Consistently, the 'release' of Stable
> has been in April around the time we release an LTS version.  And so
> far, the only case we've had where NGINX releases Stable when we're in
> a final frozen state for LTS when Stable comes out has been the 16.04
> cycle and it was a version-string-only change, of which that
> version-string change was able to be done as a post-release SRU as it
> doesn't change any features and just updates the version string. 
> (Otherwise it's been in the FeatureFreeze states, and we've been able
> to get it approved, or *right* before FinalFreeze where the Release
> team said "Upload it now before we freeze" and it got in).
>
>
>>
>> ---
>> Thomas Ward
>> Ubuntu Server Team Member
>>
>> -- 
>> ubuntu-server mailing list
>> ubuntu-server@lists.ubuntu.com
>> 
>> https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
>> More info: https://wiki.ubuntu.com/ServerTeam
>>
>>
>>
>> -- 
>> Christian Ehrhardt
>> Software Engineer, Ubuntu Server
>> Canonical Ltd
>
> --
> Thomas Ward
> Ubuntu Server Team Member

In follow up to my response to Christian, I ended up discussing this
briefly with Seth Arnold over IRC yesterday.

I agree that up to LTS we need to make sure we don't have to have any
type of version reverts, so I have come up with the following
idea/proposal: For 18.10 and 19.04, both interim releases, we can track
Mainline.  This way we can at least get the 'newer features' read for
19.04 or 19.10 getting NGINX 1.16.x as its stable version, and as we
approach 20.04 LTS we can determine if we should focus on getting the
next Stable into an LTS.

This way we don't have to worry between now and the next LTS about the
version reverts.

This also gets my want of newer features to be tested in the interim
releases (at least the next two), without impinging upon LTS.

Thoughts?


--
Thomas Ward
Ubuntu Server Team Member
-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Inquiry: NGINX branch to track in "Interim" Non-LTS Releases

[Thomas Ward]

On 08/08/2018 01:22 AM, Christian Ehrhardt wrote:
>
>
> On Tue, Aug 7, 2018 at 7:14 PM Thomas Ward  > wrote:
>
> 
>
> Hi Thomas,
> yeah I'd prefer to track Mainline in non-LTS releases as well.
>
> To the sole exception of being very careful toward the next LTS to not
> being forced to decide to "go back" or "stay on mainline" for the next
> Ubuntu LTS.
> For example if NGINX 1.17 mainline would be in Ubuntu 19.10 (as we
> track mainline in non-LTS releases), but then there would not be a
> NGINX 1.18 stable available in time for Ubuntu 20.04 to pick up.
> I don't know about the NGINX release schedule too much (is it regular
> and reliable?), maybe this is not an issue at all, but I have seen
> similar issues for other packages so I wanted to mention it.
>

We do have that type of issue though.  We need not look further than the
16.04 cycle for an example of this.  NGINX Stable was cut from NGINX
Mainline the same day as we released 16.04, but we had tracked mainline
right up to that point so there was a version strong only change SRU'd
in the day after release.

For 18.04, NGINX Stable was cut from mainline the same day as final
freeze, but I managed to get that uploaded right before FinalFreeze went
into effect.

NGINX stable versions tend to be cut from mainline right about the time
we are either releasing or are entering final freeze, based on the past
experiences of their release cycles.  Generally speaking however, even
if they cut stable from mainline right after we release, the changes
between Mainline and stable at that point are typically just version
string changes as we saw in the 16.04 cycle.  Maybe a bugfix or two but
usually not new features.

NGINX however doesn't follow a fixed-date release cycle unfortunately. 
Which has contributed to things like the 16.04 cycle had or a last
minute upload before freeze like 18.04 had.  They do, however, tend to
cut the releases within 1 week of our release date (Ubuntu Release Week
+/- 1 week), and by that point the likelihood they add any new features
to the release prior to cutting Stable from that mainline branch is very
very low based on the historical trends (based on watching upstream
changelogs since 2014).

While I can't say with *certainty* there won't be a case where they
release Stable maybe a week after our release, it's so far only been a
version-string-only change, and there's precedent already in place from
16.04 where we can put a version-string-only change into -updates
without disrupting anything.  Consistently, the 'release' of Stable has
been in April around the time we release an LTS version.  And so far,
the only case we've had where NGINX releases Stable when we're in a
final frozen state for LTS when Stable comes out has been the 16.04
cycle and it was a version-string-only change, of which that
version-string change was able to be done as a post-release SRU as it
doesn't change any features and just updates the version string. 
(Otherwise it's been in the FeatureFreeze states, and we've been able to
get it approved, or *right* before FinalFreeze where the Release team
said "Upload it now before we freeze" and it got in).


>
> ---
> Thomas Ward
> Ubuntu Server Team Member
>
> -- 
> ubuntu-server mailing list
> ubuntu-server@lists.ubuntu.com 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
> More info: https://wiki.ubuntu.com/ServerTeam
>
>
>
> -- 
> Christian Ehrhardt
> Software Engineer, Ubuntu Server
> Canonical Ltd

--
Thomas Ward
Ubuntu Server Team Member
-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Inquiry: NGINX branch to track in "Interim" Non-LTS Releases

[Christian Ehrhardt]

On Tue, Aug 7, 2018 at 7:14 PM Thomas Ward  wrote:

> Currently, all LTS versions of Ubuntu that are currently supported have a
> version of the NGINX Stable branch in the repositories.  This was done
> initially so that we can provide a 'stable' and 'released without new
> features' type of branch we would be able to track.  In the cycle before
> release, we kept it in line with NGINX Mainline because once NGINX Stable
> was cut from that Mainline branch, they'd have newer features that would
> otherwise have been unavailable if we had tracked Stable.
>
> My assumption is we want to still do this type of behavior (that is, track
> Mainline branch) in interim releases.  This lets the interim releases of
> Ubuntu work with newer features that NGINX introduces, allowing us to file
> bugs upstream as necessary with the Mainline builds or to debug issues as
> they arise in the packaging.  However, because I am not sure if this is
> what we wish to do, I thought I'd reach out to the rest of the Server Team
> for your input.
>
> What do you think would be best, tracking NGINX Stable, or tracking NGINX
> Mainline, for the interim non-LTS releases?  I'm leaning towards tracking
> Mainline in the interim releases, if there's no objection - it'll let users
> who want more cutting edge NGINX features to use those in the interim
> releases without having to force them to use the PPAs.
>
Hi Thomas,
yeah I'd prefer to track Mainline in non-LTS releases as well.

To the sole exception of being very careful toward the next LTS to not
being forced to decide to "go back" or "stay on mainline" for the next
Ubuntu LTS.
For example if NGINX 1.17 mainline would be in Ubuntu 19.10 (as we track
mainline in non-LTS releases), but then there would not be a NGINX 1.18
stable available in time for Ubuntu 20.04 to pick up.
I don't know about the NGINX release schedule too much (is it regular and
reliable?), maybe this is not an issue at all, but I have seen similar
issues for other packages so I wanted to mention it.


> ---
> Thomas Ward
> Ubuntu Server Team Member
> --
> ubuntu-server mailing list
> ubuntu-server@lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
> More info: https://wiki.ubuntu.com/ServerTeam



-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Inquiry: NGINX branch to track in "Interim" Non-LTS Releases

[Thomas Ward]

Currently, all LTS versions of Ubuntu that are currently supported have
a version of the NGINX Stable branch in the repositories.  This was done
initially so that we can provide a 'stable' and 'released without new
features' type of branch we would be able to track.  In the cycle before
release, we kept it in line with NGINX Mainline because once NGINX
Stable was cut from that Mainline branch, they'd have newer features
that would otherwise have been unavailable if we had tracked Stable.

My assumption is we want to still do this type of behavior (that is,
track Mainline branch) in interim releases.  This lets the interim
releases of Ubuntu work with newer features that NGINX introduces,
allowing us to file bugs upstream as necessary with the Mainline builds
or to debug issues as they arise in the packaging.  However, because I
am not sure if this is what we wish to do, I thought I'd reach out to
the rest of the Server Team for your input.

What do you think would be best, tracking NGINX Stable, or tracking
NGINX Mainline, for the interim non-LTS releases?  I'm leaning towards
tracking Mainline in the interim releases, if there's no objection -
it'll let users who want more cutting edge NGINX features to use those
in the interim releases without having to force them to use the PPAs.


---
Thomas Ward
Ubuntu Server Team Member

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam