[Pkg-nginx-maintainers] Repository Changes

[Christos Trochalakis]

Hello all,

On Mon, Jan 23, 2017 at 03:11:45PM -0600, Michael Lustfield wrote:
>Now that we have the pkg-nginx group created and have users set up, I've copied
>our existing archive from collab-maint/ to pkg-nginx/.
>
>This will make the repository available via:
>
>    https://anonscm.debian.org/git/pkg-nginx/nginx.git
>    git://anonscm.debian.org/pkg-nginx/nginx.git
>    ssh://git.debian.org/git/pkg-nginx/nginx.git
>

That's great, I have been using the new remote and the symlink also
seems to work. We also need to change the relevant fields in d/control!

>I'm working on some patches that I plan to push to ~exp sooner than later. When
>I make that push, I plan to also update the packaging to point at this new
>location. (and planning to push those changes to our testing branch soon after)
>
>If I hear no objections, when I make this update I would also like to drop the
>old repository underneath collab-maint.
>

I believe we can keep the symlink for a cycle or so, and then replace it
with a forced-pushed README file that points to the new location. How
does that sound?

>I've noticed some packaging repos that seem to be people toying around with
>building nginx modules outside of pkg-nginx. We can expect this will happen,
>but our original goal was to have a cohesive packaging team where we can have
>collaboration within the group (user foo takes over libnginx-mod-<bar>, but
>others can step up if foo goes MIA).
>

Yes I believe that's the plan, pkg-nginx can also be a home for lua related
libraries, like lua-nginx-* (redis, kafka, dns, etc). We could invite
the maintainers to migrate their packages if they wish.

Regarding the dynamic modules, I believe we have to solve some issues
first, but I will describe the situation later on. Out of curiosity,
could you share some links for 3rd-party dyn-module packaging?

>Anyway... if that's our plan, then we really need to get some documentation
>together on the wiki to help people start packaging nginx modules. I would very
>much prefer we get documentation and procedures figured out *NOW* so that we're
>ready for what we can expect will be a large influx of new modules once we
>start a new development cycle. If we can prep now, we should be able to prevent
>a lot of frustration for anyone interested.
>
>Additionally, I plan to start rolling some of my other changes such as apps.d
>into ~exp and intend on sharing those to our testing branch.
>

Traditionally we use experimental for packaging nginx-mainline releases
(the -somehow complicated- git process is described in
debian/Readme.packaging).  So those releases are basically the same
stable packaging setup but on mainline versions.

Those branches/releases are used by 3rd-parties that want to track
nginx-mainline but use a sane debian package, I know for a fact that
wikimedia (Wikipedia) rebuilds based on our packaging + a few custom
patches. So I am bit reluctant that we can use experimental for actual
packaging experiments. What I propose:

Soon, when 1.12 is out, we can safely switch master to 1.13. This is
probably safe since nginx uses a yearly release cycle, so we can assume
that Buster will ship with nginx 1.14 (= 1.13 last release).

That will leave use with a clean experimental branch that we can use
for experimentation.

Until then we can use a `pu` (proposed-updates) branch to push
experimental changes.

>
>Christos,
>
>  Since you've been doing all of the work with splitting nginx into modules, do
>  you think you could write up some initial documentation for prospective users
>  looking to package an nginx module? No need to worry about quality of English
>  if that's of any concern. I'm more than happy to massage it into some pretty
>  form. I'd also be happy to pilot that set of instructions...
>
>
>If possible, I'd really like to start discussing our buster plans in detail!
>

Unfortunately the nginx build system does not yet support building modules
out-of-tree so:

 o We cannot split each module in a different packaging repo.
 o We cannot package a new nginx module as a seperate package.

There might be some workarounds but they are far from pretty. Until
nginx enables out-of-tree building there are not much we can do.