Re: RFC: Final update of DEP-14 on naming of git packaging branches
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
Reply to: