nginx exception request

Thomas Ward teward at trekweb.org
Mon Jul 6 01:45:30 UTC 2015


Hello!

I've made on-line comments, links, responses, questions, concerns, etc.
below.  Apologies for the delay in my response, but as July 4th was a
holiday in the US, and I was out of town away from my email.

On 07/03/2015 04:41 AM, Dave Walker wrote:
> On 30 June 2015 at 15:55, Thomas Ward <teward at trekweb.org> wrote:
>> On 06/30/2015 06:08 AM, Robie Basak wrote:
>>> On Tue, Jun 23, 2015 at 10:50:05AM +0100, Robie Basak wrote:
>>>> Please can we agree on feature freeze and SRU policy exceptions so that
>>>> we can execute option A, or otherwise discuss alternatives?
>>> Any thoughts please? Although we'd not execute on any exception until
>>> 2016, Thomas needs to know now whether to merge 1.9 from Debian or
>>> diverge on 1.8 for Wily.
>> There is also another option that is likely less desirable than the
>> other aforementioned options in the previous emails in this chain by
>> Robie: We (or rather, I) could do absolutely nothing for Wily, and we
>> can ultimately just deal with this closer to 16.04, such that we can
>> have this discussion for a longer period of time.
>>
>> By doing nothing, 1.6.x will remain in Ubuntu for the duration of Wily.
>> Features from 1.7.x which are now present in 1.8.x (nginx stable) will
>> not exist in Ubuntu Wily, and even newer features (and to my chagrin,
>> the "Disable SSLv3 By Default" change at the source code level) from
>> 1.9.x will not exist in Ubuntu Wily either.  This option allows us on
>> the Server Team, and myself, to not have to immediately worry about
>> merging, while users who want the newer features in 1.8.x and 1.9.x can
>> simply use the already-existing NGINX PPAs that I maintain which package
>> both NGINX versions for all supported Ubuntu releases.
>>
>> While input from the Release team is sought for Wily, so we can try and
>> have less of a merge delta by 16.04, we can theoretically do nothing now
>> for Wily, and then go with 1.9.x in 16.04, and then focus on the one-off
>> policy exceptions or potential other alternatives then, rather than
>> require the release team's input immediately.  However, I believe it is
>> a better option to consider 1.8.x or 1.9.x now for Wily rather than do
>> nothing.
>>
> Hi,
>
> Considering there is effort to plan ahead for future releases and
> potential SRU/MRE extraordinary updates, I quite think this requires
> input from the technical-board.  Rather than cross-posting this thread
> to there, might I suggest a parallel thread is started there?
>
> My thought is that Nginx previously hasn't received as much love in
> Ubuntu as Apache, so doing as much as possible to align with Debian
> support is probably preferential.  Although, teward seems to have been
> doing a sustained effort at pushing it in Ubuntu.
>
> Perhaps it would be useful to look at the Nginx PPA statistics, to try
> and gauge how many people are using it outside of the primary
> archives?  - teward, could you do an analysis on this?  This produces
> some nice charts - http://wpitchoune.net/blog/ppastats/
Well, I think we'll have a problem here.  Launchpad and that tool don't
get along, since the tool pulls *all* the data at once, which causes
some issues to the API, in that it tries to get everything in one hit. 
That tool also doesn't appear very customizable to pull smaller chunks,
and I know for a fact that wgrant was commenting "you'll want to tweak
the code that you're using" (to quote him) when I was asking about the
errors I'm seeing from Launchpad (in the #launchpad channel on
freenode).  I'm not fluent enough with pure C code to tweak this to
achieve that goal of tweaking it, though.

Do you have another tool on-hand that does the same general thing,
Dave?  I'm a little bit too busy with work the next few months to write
a custom Python script myself with smaller data chunks to do this...
> Nginx seems to have a pretty reliable upstream reputation, mixed with
> how near the scheduled release is to the next LTS and common for the
> prior LTS to be used until the next point - I would be confident in
> putting weight behind this idea, providing that:
>  - LTS releases with the latest snapshot from hg upstream, and plan to
> minimal SRU to tagged release (which there is prior art of)
Unless I'm misunderstanding you here, I'm hesitant to pull the latest hg
snapshot (at that time) in this case.  The reason being there may be
incomplete features there in the hg snapshot, with even more bugs than
it may already have due to it being an in-development branch.  I'd be
more comfortable with LTS having the latest-tagged-release prior to
1.10.x from the hg repository (or nginx.org tarballs) rather than
pulling incomplete-features code from the hg repository.

If it is however preferable to pull that snapshot, I'll do it, but only
if the TB and/or a substantial amount of this opinion being held by the
Release Team stand by that opinion.  Provided that we pull the latest
changes in the packaging (to account for potential FTBFS issues and
conflicting-configuration issues) from Debian while we do this - the
tricky part about pulling nginx mainline is that they make substantial
backend/api changes which do break the third-party modules in the
packages built for Universe from the same source package).
>  - Config files do not change
I think this will be the trickiest part of the merge, here, although
likely not as tricky as diverging from Debian completely, or pulling
from the upstream repository.  Nginx upstream doesn't change their
config files, to my knowledge, as much as Debian does when making tweaks
to it, as Debian has some "out of the box" configurations specific to
the packaging variances that make it diverge from the upstream
tarball-default install (one such example of this is the default-disable
of SSLv3 in the default nginx.conf file).  This'll need me to nitpick
packaging changes necessary for building (likely to happen!) while
making sure the Debian-packaged configuration files won't change.  It's
tricky, but it can be done, and I'd be willing to do that.
>  - Upgrade is well tested (old LTS->new LTS, old Nginx LTS -> new
> Nginx LTS & Wily->New LTS)
>
> If this plan is done, then it makes sense to track 1.9.x series for
> Wily and 1.10 for next LTS.  However, this really does require input
> from the TB and commitment from teward and/or the server team to
> follow through.
I was the one that brought the discussion up at the Server Team meeting,
especially since Wily needs nginx merged from Debian.  With Debian
having the odd habit of switching from stable to mainline and then back
to stable later, I thought it prudent to reach out to the Server Team
(and other teams whom are relevant, such as the Release Team and the
Tech Board) to try and decide the course of action, as myself and the
server team are the primary drive for nginx-core in Main.

Providing the TB (and Release Team) give the OK on 1.9.x for Wily and
1.10.x for the next LTS with ample exceptions put in place for version
bumps, etc., I'd be glad to follow through with the changes as laid out
here.

If not, I'm content with leaving Wily alone, or merging 1.9.x for Wily
and then another 1.9.x merge for X.

> --
> Kind Regards,
> Dave Walker





More information about the ubuntu-server mailing list