1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
|
Debian Packaging
================
We use git-buildpackage for packaging. Our repository can be found at
git.debian.org:/git/collab-maint/nginx.git.
Workflow for Unstable
=====================
We use the standard git-buildpackage workflow.
Dynamic Modules
===============
Since v1.9.11 Nginx added dynamic module support. This will sanitize the
nginx packaging flow in the long term, but there is a lot work to be done
in order to get there. We will gradually convert all modules to dynamic
as they add support for it.
Currently nginx modules need to be build together with nginx, but this
will be fixed upstream [0]. Since we already ship 3rd party modules under
debian/modules/ we will start shipping module packages (libnginx-mod) from
the same source. Once upstream implements separated building we will
split each module to a separate source.
[0] https://www.nginx.com/blog/dynamic-modules-nginx-1-9-11/
Workflow for Experimental
=========================
Nginx mainline releases (1.11.x series) are been packaged for experimental,
as they lack security support.
The workflow we use is based on the assumption that packaging work happens on
origin/master and experimental builds are a trivial patch away from that.
The direct consequense of treating experimental as a patchset for origin/master
is that the relevant branches are forced-pushed whenever we release a new
1.11.x version. In other words, **it is not safe to base your work on the
experimental branch**.
This is a brief description of our experimental branches and how we are using
them.
* experimental-base
Force-pushed when origin/master changes.
experimental-base tracks the changes needed for building the 1.11.x branch,
such as new configure parameters, etc. On new 1.11.x releases, it is rebased
on origin/master so it is always up-to-date with our latest packaging work.
* experimental
Force-pushed on every 1.11.x release.
This branch points to the latest 1.11.x release.
Before release this branch is reset to experimental-base, and then merged
with the new upstream-1.11 branch. Finally all the release specific changes
are commited (changelog entry etc) and the build is made.
* upstream-1.11
Pushed on every 1.11.x release.
Before a new 1.11.x release origin/upstream is dummy merged (-s ours) into
ustream-1.11. This is a technicallity so we can avoid resolving conflicts
when a new 1.10.x release happens between two experimental releases.
Older 1.11.x releases are not referenced by any branch, but they can be found
by the relevant debian/* tag.
3rd party experimental workflow
===============================
As we described, it is better not base you work on our forced-pushed
experimental branch. A better approach would be to maintain a custom-build
branch that is rebased to our latest experimental branch (basically git rebase
--onto the relevant commits should work).
|
