On Sat, 05 Sep 2020, Richard Laager wrote: > > OK to use debian/unstable as default branch even if you are not a > > complex package that require multiple branches, provided that you will > > not use debian/unstable when you decide to push something to > > experimental. > > I do not see why we have to prohibit occasional uploads to experimental > from debian/unstable. If this is permitted, then that also avoids the > busywork of creating debian/experimental in that scenario. To me it feels awkward to allow this. You can't really get it both ways IMO. If you decide to use codename-based branches, then you should use debian/experimental for an experimental upload. What do other people think? > > I don't think that you are wrong. Most packages definitely only target > > unstable and never use experimental. > > Then why give up the simplicity of only one choice and the clarity (and > tooling advantages) of debian/unstable as the typical case, in favor of > debian/latest? It's not clear to me that debian/latest has major disadvantages over debian/unstable. It's a single choice too. The "clarity" of debian/unstable is limited to Debian developers, upstream developers might not know that unstable is the development branch. Random outsiders neither. And using codename by default for the development branch means that you don't have uniformitiy across multiple vendors, which I find desirable for the purpose of letting git packaging helper tools having a sane cross-vendor default. > > Another thing to take into account is that DEP-14 has been drafted > > as a vendor-neutral recommendation. I use it in the context of Kali > > and there's no "unstable" release in Kali. We have "kali-dev". Ubuntu > > only has codenames even for their development release. > > What's wrong with kali/kali-dev? We have kali twice in the name. We used to have "kali/stable" and "kali/dev" at some point and we switched to "kali/master" when we switched to a rolling-release model to standardize on DEP-14. But what I meant is that "unstable" is only applicable to Debian and that derivatives have different models and that we should not impose too much to make sure we cater to the needs of derivatives too. > I'd love to hear someone from Ubuntu weigh in on why ubuntu/latest would > be better there. From my point of view (as someone who occasionally SRUs > something in Ubuntu), having ubuntu/<codename> is the right choice. When > a new development release opens up, you would branch e.g. ubuntu/focal > into ubuntu/groovy. Then ubuntu/focal continues to exist for SRUs > (stable release updates). To me, my proposed branching model feels like > it matches the Ubuntu development model 1:1. Sure, if you put yourself in the feet of someone doing stable release uploads, it's convenient to have a branch ready to use. But if you put yourself in the shoes of someone doing Debian syncs, then maybe ubuntu/latest would save you some hurdle. In any case, Ubuntu has no "suite" name and it's to be expected that they would use only "codename" even for their development releases. That doesn't mean that it's the right choice for everybody nor that it should be the default. > DEP-14 starts this section with a broad, "In general, packaging branches > should be named according to the codename of the target distribution." > On that, I think we all agree. Then it continues, "We differentiate > however the case of development releases from other releases." > Fundamentally, the scope of that exception is what we are discussing. Yes. (Though I would have hoped that it would not require so much discussion at this point :-)) > Diffs available here (since this list refuses attachments and I can't > figure out how to disable line wrapping in Thunderbird): > https://paste.debian.net/1162793/ Bah 503 service unavailable right now. > My personal view is now: B > A > D > C Without having read your precise diff, I would believe my personal view would be: C > D > B > A Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog <hertzog@debian.org> ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋ The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄⠀⠀⠀⠀ Debian Long Term Support: https://deb.li/LTS
Attachment:
signature.asc
Description: PGP signature