On 8/31/20 8:53 AM, Raphael Hertzog wrote: > I already agreed that we can tweak the wording to document that it's I don't think the people on the list saw that message, as it had an attachment. It's below (unabridged). > 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. On 8/30/20 4:27 PM, Raphael Hertzog wrote: > Hello, > > On Sun, 30 Aug 2020, Richard Laager wrote: >> You could use debian/experimental all the time and then merge down to >> debian/unstable only when you're ready to upload and have chosen >> unstable. But I suspect your objection would be: that's unnecessary >> busywork. And I see that point. I would probably make the same >> objection, which means I think I agree with the debian/latest concept in >> your situation. > > You perfectly understood my reasoning. Thank you for making that effort. > >> I'm not sure if most package maintainers are doing this or not. I've >> always assumed that most people are targetting only unstable most of the >> time and that use of experimental is relatively rare. I could easily be >> wrong on that. > > 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? > But most packages also never need to maintain two development branches > in parallel. Only very big packages, linux or django for example, will > maintain different upstream versions in two parralel branches. > > Another thing that's quite certain is that you never know what the future > will bring you. And while you never had to use experimental, you might > have to at some point. > > In that sense, I find debian/latest more future-proof but I also > agree that for the few cases where we would have to use experimental, > it's not a big deal to have to create debian/experimental. > > 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? 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. > Thus <vendor>/latest is a better default for tools like git-buildpackage > and it makes sense for DEP-14 to endorse such a default branch as the > recommended name. > >> That is, I'm generally always targetting unstable and _not_ regularly >> using multiple releases, so the DEP-14 language "prohibits" me from >> using debian/unstable. This is what feels backwards to me. If I'm always >> targetting unstable, debian/latest (and previously debian/master) is >> less clear than debian/unstable. >> >> At a minimum, can we rework this in some way so the language does not >> require me to be regularly using multiple releases to use >> debian/unstable as a branch name? > > That seems entirely reasonable, yes. Can you try to make a proposal ? > > I attach the current markdown file with my not-yet pushed change that I > submitted for review here. > > Cheers, 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. 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/ Proposal "A": My original position was that we limit that exception to using "unstable" and "experimental" instead of "sid" and what (I later learned) may or may not be "rc-buggy". This has the advantages that there is only one recommended default (instead of two or three) and the branch name (sans vendor) _always_ matches the changelog. Proposal "B": Raphael Hertzog, Russ Allbery, et al. upload to unstable or experimental depending on various factors, which notably may not be known a priori. In this case, it would be annoying busywork to have to switch from debian/unstable to debian/experimental when the decision is made to upload to experimental. Paride Legovini proposed that we could just relax the restriction on uploading to experimental: "What I propose is to require for dep14 compliance that uploads to <codename> are to be cut from debian/<codename> branches, unless <codename> is experimental." Here, I'm going to tighten that to say that uploads from debian/unstable are allowed to experimental. I assume this is not objectionable, as I don't think anyone was suggesting uploading from e.g. debian/buster to experimental. This keeps the advantage of only one recommended default. In this case, the branch name matches the changelog in all cases except for these occasional uploads to experimental. Proposal "C": This allows e.g. `debian/unstable` as co-equal (albeit second-listed) choice to e.g. `debian/latest`. It does not expressly prohibit uploading to `experimental` from `debian/unstable` but does nudge by saying that `debian/latest` is advantageous in that case. This is most in line with what Raphael Hertzog asked me to prepare. Proposal "D": This is "C" but with <vendor>/<suite> listed first. This is a subtle nudge towards that option. It also makes the text flow better, as the options are discussed in the order listed. My personal view is now: B > A > D > C Effects on developers of my preferred option, "B": In my case, I'm already using debian/unstable, so under proposal B, I'm already good. I can intermittently upload to experimental from that branch if I need and that would be DEP-14 compliant. In your (Raphael and also Russ) case, you're using debian/master, so under proposal B, you'd have to rename to debian/unstable. But you were going to have to rename to debian/latest anyway, so that's no more work. You can then continue your practice of alternating uploads between unstable and experimental. Anyone who has separate debian/unstable and debian/experimental branches was and is compliant with no changes. -- Richard
Attachment:
signature.asc
Description: OpenPGP digital signature