Re: RFC: DEP-14: Recommended layout for Git packaging repositories
> On Tue, 11 Nov 2014, Raphael Hertzog wrote:
First, I'm a fan of trying to ease the workflow for all by having some
standardisation / best-practice recommendation/documentation.
Kudos to the initiattors!
>> QUESTION: some people have argued to use debian/master as the latest
>> packaging targets sometimes sid and sometimes experimental. Should we
>> standardize on this? Or should we explicitly allow this as an alternative?
>
> Given the feedback received, and the case of derivatives that don't have a
> stable name for their development releases, I propose to update the
> "Packaging branches and tags" section with the content below. Does
> that sound like an improvement?
>
> Packaging branches and tags
> ===========================
>
> In general, packaging branches should be named according to the codename
> of the target distribution. We differentiate however the case of development
> releases from other releases.
>
> For development releases
> ------------------------
>
> Packages uploaded to the current development release should be prepared
> in a `<vendor>/master` branch.
>
> However, when multiple development releases are regularly used (for
> example `unstable` and `experimental` in Debian), it is also accepted to
> name the branches according to the codename or the suite name of the
> target distribution (aka `debian/sid` or `debian/unstable`, and
> `debian/experimental`). Those branches can be short-lived (i.e. they exist
> only until they are merged into `<vendor>/master` or until the version in
> the associated repository is replaced by the version in `<vendor>/master`)
> or they can be permanent (in which case `<vendor>/master` should not
> exist).
>
> NOTE: The Git repository listed in debian/control's `Vcs-Git` field should
> have its HEAD point to the branch where new upstream versions are being
> packaged (that is one of the branches associated to a development release).
> The helper tools that do create those repositories should use a command
> like `git symbolic-ref HEAD refs/heads/debian/master` to update HEAD
> to point to the desired branch.
>
> For stable releases
> -------------------
>
> When a package targets any release that is not one of the usual
> development releases (i.e. stable releases or a frozen development
> release), it should be prepared in a branch named with the codename of the
> target distribution. In the case of Debian, that means for example
> `debian/jessie`, `debian/wheezy`, `debian/wheezy-backports`, etc. We
> specifically avoid "suite" names because those tend to evolve over time
> ("stable" becomes "oldstable" and so on).
>
> Security updates and stable updates are expected to be handled on
> the branch of the associated distribution. For example, in the case of
> Debian, uploads to `wheezy-security` or `wheezy-proposed-updates`
> are prepared on the `debian/wheezy` branch. Shall there be a need to
> manage different versions of the packages in both repositories, then
> the branches `debian/wheezy-security` and `debian/wheezy-updates`
> can be used.
>
> Tagging package releases
> ------------------------
>
> When releasing a Debian package, the packager should create and push
> a signed tag named `<vendor>/<version>`. For example, a Debian maintainer
> releasing a package with version 2:1.2~rc1-1 would create a tag named
> `debian/2%1.2_rc1-1` whereas an Ubuntu packager releasing a package with
> version 1.3-0ubuntu1 would use `ubuntu/1.3-0ubuntu1`. The tags should
> point to the exact commit that was used to build the corresponding upload.
>
One point came to my mind: NMUs
Can we maybe add some words what would be best practice to handle NMUs?
I think just applying them to debian/sid (or whatever we call it) won't work
in every case, as the packaging repository might have already
(not-for-NMUs-suitableable) commits. I saw even new upstream releases sitting
there, with an maintainer (pseudo)MIA*.
So it is not guaranteed that NMUs can be directly applied to debian/sid and
worst case lots of stuff needs to be reverted before one can start on the NMU
and maybe restored later, rinse-repeat on a later NMU. And if the NMU is
cancelled, there will be lots of noise in the commit log for non-existing
releases.
For the maintainer ack'ing the NMU could be then simple as an merge.
So may I propose to have some procedure recommended for NMUs? (or at least for
such case where it is not easy possible to work directly with debian/sid)
Maybe add the intended NMU-version to it. This branch could also be
short-lived.
* responsive in email, but still non acting >>6months
Reply to: