On 8/28/20 6:01 PM, Raphael Hertzog wrote:
> following the recent discussions of June and of the last days, I'm
> proposing the changes below to DEP-14. Basically it replaces debian/master
> with debian/latest for all the reasons already discussed earlier. And
> it says that debian/unstable is preferred over debian/sid.
I think this is a change in the right direction.
However, this is still saying that one should prefer debian/latest over
debian/unstable, and that debian/unstable is (sort of) only for use when
you're also uploading to experimental.
I think this is backwards. I think the default should be
debian/unstable. If you want to use experimental, then also use a
debian/experimental branch.
The big advantage of this approach is that the branch names are always
consistent with changelog names. This works well when you need a
debian/buster for a stable update and/or a debian/buster-backports for a
backport. Aside from being helpful to humans, this consistency then
makes for a reasonable default in the tools (e.g. git-buildpackage). It
also extends perfectly to use with downstream distributions, with things
like ubuntu/bionic, ubuntu/focal, etc. FWIW, I have a package using all
of debian/{buster,buster-backports,unstable} and ubuntu/bionic right now
and it works great.
When I last brought this up [1], Russ Allbery said that debian/latest
was desirable (to him, at least) because, "My normal use of experimental
does not involve maintaining unstable and experimental branches
simultaneously. I essentially never do that; instead, I maintain one
development branch, which I upload to either experimental or to unstable
based on things like where we are in the release cycle or whether I need
to stage some change." [2]
I believe that "git branches are cheap", so I don't really see the
problem in switching back and forth between debian/unstable and
debian/experimental in that case. Given that he further said, "If I'm
uploading to experimental, I don't fix bugs in unstable until the
experimental release is ready for upload to unstable.", the merges would
be fast-forward merges anyway, so they wouldn't take any actual hand
merge work. Using separate branches would inherently allow for proper
handling of the "exception" he described of needing to upload a fix to
unstable while debian/latest is the upload to experimental.
That said, I do understand we give a lot of deference to developers'
workflows. So I have no objection to DEP-14 supporting this workflow
with debian/latest. But I would like to see it (debian/latest)
recharacterized as the alternate approach rather than the recommended
method.
Previously, my proposal would have required a fair amount of branch
renaming--from debian/master to debian/unstable. However, with the
change from debian/master to debian/latest, branch renaming would "have
to" occur anyway, so renaming debian/master to debian/unstable is no
more trouble.
[1] https://lists.debian.org/debian-devel/2019/11/msg00084.html
[2] https://lists.debian.org/debian-devel/2019/11/msg00085.html
--
Richard
Attachment:
signature.asc
Description: OpenPGP digital signature