> 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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/a8868548708f26ab17b0f2eda6b61ade.squir...@isengard.geekcommandos.com