xmltooling_1.6.0-1 upload to experimental

[Russ Allbery]

wferi at niif.hu (Ferenc Wágner) writes:

> Actually, I was able to do the Alioth approval myself, because you had
> granted wferi-guest admin rights before.  However, there is a question
> for you about the xml-security-c packaging in <87y445hr01.fsf at lant.ki.iif.hu>
> http://lists.alioth.debian.org/pipermail/pkg-shibboleth-devel/2016-August/003781.html:

> | I think the jessie branch should have been merged back into master
> | before the release of 1.7.2-2.  It was created to hold high urgency
> | security uploads to unstable while 1.7 was already in experimental, if
> | I read the Git history correctly.  Russ, can you provide any input on
> | this?  I'd merge it now to salvage the changelog entries of 1.6.1-6
> | and 1.6.1-7 and tie off its history, freeing the branch name for
> | potential stable uploads.

> Both some historical context and you opinion on the above action plan
> would be much appreciated in that thread.

The short answer is that this is up to you, since it depends on your
mental model for how Git branches should be thought of, and on that score
I'm happy to defer to the folks who are doing all the current work.

I think of Git branches for separate Debian releases as diverging lines of
development, similar to the old "release branch" model of version control.
So, when there's some reason to produce an update to a version that has
diverged from the master line of development, I branch from the version
that was last in common and then apply patches and do uploads from that
branch and tag that branch with the versions of the upload.  I don't
normally ever merge that branch back into mainline unless the exact same
change applied to mainline and I uploaded the same package to both
distributions.

In this particular case, this was a bit weird since the line of
development that's currently represented in the jessie branch was
abandoned before the actual release of jessie.  (It was security patches
for a version targeted for testing while the main line of development was
in experimental.)  Usually this comes up for stable releases; this was a
bit of a special case.  But the line of development is still conceptually
separate for me, so I'm not sure it would make sense to merge the jessie
branch back into debian/master.  The master branch doesn't need or want
the changes that were made on the jessie branch, since it picked up the
same changes via upstream releases.

This means that the package's changelog currently doesn't have entries for
the uploads that were made from the jessie branch.  But I would argue
that's a feature, rather than a bug, since those uploads were not
conceptually part of the line of development that culminated in the
current version of the package, so they're not, strictly speaking, part of
the development history of what's on debian/master now.

The remaining problem is that the branch is currently called jessie, which
implies that it's a maintenance branch for the current stable release, but
it's a line of development that was abandoned before jessie was released.
So if we do keep the branch separate, it should definitely be renamed to
something that makes that clearer.

Personally, I'd keep the branch and rename it.  I can see the argument for
merging it back in as a way of "closing" it, but it feels conceptually
weird to me to merge in changes and commits that aren't really part of the
development history of what's currently in debian/master.

-- 
Russ Allbery (rra at debian.org)               <http://www.eyrie.org/~eagle/>