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.