On Wed, Jan 17, 2018 at 11:24:31AM -0500, Daniel Kahn Gillmor wrote:
> Package: e2fsprogs
> Version: 1.43.8-2
> Severity: wishlist
> Tags: patch
> 
> Adding Vcs-* fields to debian packaging makes it easier for other
> contributors to find the work and contribute.
> 
> The attached patch assumes that you're doing the packaging in the
> "debian-packaging" branch, though i note that you've also got a branch
> named "debian-branch".  please amend the location in both Vcs-Browser
> and Vcs-Git if you prefer "debian-branch" over "debian-packaging" for
> whatever reason.

Well.... I'm a bit hesitant to set up the automated fields because it
may very well mislead people.

First of all, the preferred git repository is at git.kernel.org (both
for web browsing and git cloning):

        https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git

The next issue is the branch in which the development takes place.  In
fact, most of the packging work is done in the primary "upstream"
branches.  Which is to say, at the moment the "maint" branch for
1.43.x, and the "master" and "next" branches for the
soon-to-be-released 1.44.x.

The debian-packaging branch is only really used just before I do the
next debian release, and there have been times when I haven't bothered
with the debian-packaging branch at all --- I'll just release straight
from the "master" or the "maint" branch.

The reason why I'll use debian-packaging is when I need to diverge
from the primary git branches; for example, if I need to cherry-pick a
fix that has landed in master or maint, but for whatever reason I
don't want to push out a new upstream release.  At the moment, the
primary reason why debian-packaging exists because I have enabled
metadata checksums by default even though it isn't enabled that way
for upstream.

So that's the problem --- if the goal is allow other poeple to
contribute, they should just send patches against the maint branch
(for 1.43.x).  In a month or two, I'll have released 1.44, and for a
while the master branch be 1.44, but after a stablization release or
two, oldmaint will track 1.43.x (and I may or may not publish it),
maint will then track 1.44.x, and the master/next branches will be
tracking new development work that will be in the 1.45.x release.

If they want download exactly what was used for a particular release,
they can either grab the sources from a tag such as debian-1.43.8-2,
or debian-packaging will point at the most recently released debian
package.

So the question of which branch to use is complicated, and it's hard
to compress it into a simple Vcs-git: tag.  In fact, packaging is
present in *all* of the branches (for example, I build packages for
the not-yet-released 1.44 branch for gce-xfstests[1] from the next
branch fairly regularly).

[1] https://thunk.org/gce-xfstests

Cheers,

                                                - Ted

Reply via email to