Raphael Hertzog wrote on 30/08/2020: > On Sat, 29 Aug 2020, Richard Laager wrote: >> 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. > > Your approach is perfectly valid but I don't really believe that it should > be the recommended approach. It doesn't seem to match the most common > workflow. > > Most package maintainers are not actively working on two different > development branches, instead the single development branch keeps moving > between: > - ready for unstable/upload to unstable > - work in progress on a new upstream release > - possible upload to experimental to gather feedback (buildd, users) > - back to ready for upload to unstable > > In some rare cases, we will have to do some intermediary upload to > unstable because some RC bug popped up and we don't want to wait until > we're ready with the next upload. In that case, we will create a > debian/unstable branch starting from the last tag in debian/unstable.
Hi Raphael and thanks for this thread. I think I can see your point here, however I still don't think that having debian/latest (or debian/devel as I'd prefer, see my other email) beats the straightforwardness of cutting releases from a branch named after the release the package is uploaded to (the d/changelog codename). What I propose is to require for dep14 compliance that uploads to <codename> are to be cut from debian/<codename> branches, unless <codename> is experimental. This allows to checkout the "maintainer view" of a given (nonexperimental) version of a package by knowing only: - the repository location - the relevant d/changelog entry. This automatically allows: - The simplest workflow where packaging is done in debian/unstable, and that's it. Good for simple, stable packages. In this case debian/unstable has to be the default branch or declared in Vcs-Git. - Uploading to experimental, right from debian/unstable or by branching it off to debian/experimental, committing experimental stuff and uploading from there. The debian/experimental branch is allowed to be ephemeral (as the packages are) or force-pushed. - If debian/latest (~ debian/devel) is desired it can just be used. Maintenance can continue in the debian/unstable branch e.g. to fix RC bugs, as in your example. When a new version is ready is can be merged to debian/unstable and uploaded. The debian/unstable branch is treated just like a stable release branch. Good for more complex packages. - The maintainer must declare if debian/latest is being used by setting it as the repo default branch, or by specifying it in Vcs-Git. - Same if development mainly happens in debian/experimental: make it the default branch or declare it in Vcs-Git. In this case debian/latest is not allowed. - Uploads to experimental can cut from debian/latest, but the branch is not ephemeral. Cons: may require extra merges from debian/latest to debian/unstable. In exchange we gain the flexibility of debian/latest, branch name predictability (but for experimental, by design), and good compatibility with existing workflows. Paride