[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
