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
signature.asc
Description: OpenPGP digital signature