Richard Laager <rlaa...@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 (r...@debian.org) <https://www.eyrie.org/~eagle/>