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 <teward at ubuntu.com
>> <mailto:teward at ubuntu.com>> wrote:
>>
>>     <snip>
>>
>> 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 at lists.ubuntu.com
>>     <mailto:ubuntu-server at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-server/attachments/20180810/9e4c5c20/attachment.html>