Re: RFC: Final update of DEP-14 on naming of git packaging branches
Richard Laager <rlaager@wiktel.com> writes:
> 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.
I think I understand your argument here. The point that Git branches are
cheap is valid.
I think the primary thing that bothers me about this workflow is that
experimental becomes an ephemeral branch, which appears and disappears
based on the vagaries of the release cycle. This is unlike every other
packaging branch I use, which are stable release branches. They may not
receive any further activity, but debian/etch, for instance, is still a
meaningful branch (it was the last thing uploaded to etch), it has meant
the same thing since I first created it, and there's no reason to ever
delete it.
debian/experimental, on the other hand, is essentially an ephemeral
development branch off of debian/unstable with little continuity. If one
uses Git in a way that emphasizes ephemeral development branches that are
pushed publicly but then disappear randomly, that may not feel like much
of a problem, and I know that's a common GitHub workflow. But to me it
feels very strange to delete the branch on which uploads to the archive
were based (and even stranger to leave it around when it's older than
unstable).
Perhaps this is my problem, and I should embrace the fact that the history
is reachable from the tag and can be merged back into the unstable branch
and stop worrying about it.
That said, one way in which this becomes concrete is the Vcs-Git control
field. What do you put in the branch field for your experimental upload?
Naming debian/experimental is clearly wrong; that branch is highly likely
to not exist when someone later checks. Naming debian/unstable is also
clearly wrong; the package is not based on that branch.
Maybe that doesn't matter. Indeed, this is part of the argument against
having Vcs-* fields in source packages, I realize. But it makes this
convention feel odd to me.
It's valid to say that it's okay for me to feel odd and I can cope with
feeling odd and follow the convention anyway.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: