On 8/29/20 5:16 PM, Simon McVittie wrote: > On Sat, 29 Aug 2020 at 15:07:07 -0500, Richard Laager wrote: >> 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. > > The way I think of it phrases this a bit differently: whether or not you > have a version targeting experimental right now, if you *were* uploading > to experimental, what would you do? I think that's a perfectly reasonable way to look at the issue. I don't think that's what the DEP-14 language says, though. > I think the workflow used in packaging dbus (with the newly proposed > naming: debian/unstable as default, and a debian/experimental branch > that runs ahead of it) is fine. This is good if you want to draw most > attention to the version in unstable, with experimental being for early > adopters and not recommended for general use. > > I think the workflow used in packaging gnome-shell (with the newly > proposed naming: debian/latest as default, and a debian/unstable branch > that lags behind it) is *also* fine. This is good if you want to draw > most attention to the version in experimental (when there is one). In both cases, I would have debian/unstable and debian/experimental branches. I would draw attention to the main line of development by making that as the default branch on the server: debian/unstable in the first case and debian/experimental in the second. That way, someone who doesn't know the package's branch style gets a hint on clone; someone who does already knows which branch they want and can pick it explicitly. Of course, the same server-side HEAD setting also works (and should be used) if debian/latest is in use. -- Richard
Attachment:
signature.asc
Description: OpenPGP digital signature