[Resent as debian-devel doesn't allow attachments.] Hello,I tried to do a synthesis of past August/September thread on the finalization of DEP-14 [1], see:
https://salsa.debian.org/dep-team/deps/-/merge_requests/1/diffs
I took Raphaël's proposal [1] and integrated the following changes:
(1) DEP-14 is declared CANDIDATE instead of ACCEPTED, addressing
Jonathan Dowland's concern [1], and that I agree with.
(2) Added default branch policy for native packages using Raphaël's
proposed text [3], unchanged.
(3) Implemented Richard Laager's "Option C" [4], with a slightly
different wording, more similar to Raphaël's initial proposal.
The change aims at allowing the use of debian/unstable as the
devel branch even if debian/experimental is not regularly used.
I think there was consensus over this [5]. I tried to first
express this in vendor-agnostic terms, then giving an example
of what it means in Debian, in a separate paragraph.
(4) Minor changes (typos, removed trailing spaces, updated the
final "changelog").
I tried to stick to what I believe we had consensus on, however I think
that point (3) has a shortcoming: it allows <vendor>/<suite> branches,
but doesn't cover cases where <vendor> has no development _suite_. For
example it wouldn't allow the kali/kali-dev branch, as Kali doesn't have
suites (IIUC). This case could be covered by adding:
However, when `<vendor>` has no concept of suite for the development release but has a fixed codename for it, the use of the `<vendor>/<codename>` scheme is accepted.I'd like to include this, but I left it out as it wasn't discussed before. Let me know what you think.
Cheers, Paride [1] https://lists.debian.org/debian-devel/2020/08/msg00239.html [2] https://lists.debian.org/debian-devel/2020/09/msg00305.html [3] https://lists.debian.org/debian-devel/2020/09/msg00068.html [4] https://lists.debian.org/debian-devel/2020/09/msg00075.html [5] https://lists.debian.org/debian-devel/2020/09/msg00094.html