packaging branches (was: xmltooling_1.6.0-1 upload to experimental)

[Ferenc Wágner]

Russ Allbery <rra at debian.org> writes:

> wferi at niif.hu (Ferenc Wágner) writes:
>
>> 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.

I mostly agree with these general principles.  I'm torn here because I'd
like to send the message that there are no changes on the jessie branch
which are missing from master (except for the changelog entries) and
that both branches ended up releasing into the same distribution
(although it's already too late for that).  All these mean that there's
no point doing further development on the jessie branch, thus there's no
point keeping it as a separate head, because these two lines of
development converged in the end (in the sense of releasing into the
same distribution).

Coming back to the changelog: a linear text file is always at a
disadvantage representing nonlinear development history.  I've had to
reconcile this a couple of times releasing backports.  For the moment
I've settled for keeping old backports entries and adding new ones after
merging in master (with its new changelog entries), describing new
backporting changes (if any) and the rebuild line.  Using this as a
template, I get that maybe we should merge master (which should have
been named experimental) into jessie (which should be called master).
I'm not sure how far this analogy can go, maybe it's wrong from the
start.  With backports, we have parallel (not diverging, nor converging)
lines of development, with regular merges in one direction.  Stable
(maintenance and security) branches are mostly diverging.  Finally,
experimental branches should eventually merge (converge) into master,
like topic or feature branches, though can receive merges beforehand.

> 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.

Well, maybe it's already too late to do anything better.  Can you
suggest a good name for it?  I ponder about ones like jessie-prep,
jessie-testing or jessie-fasttrack.

> 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.

Sure, they aren't part of the history, but part of the content.  Maybe a
bit like merging the upstream release tag into our upstream branch
during the import of the tarball (while ignoring its content using the
"ours" strategy).  Wandering far from the original question here, but
I'm interested in discussing this on the theoretical level as well.
-- 
Regards,
Feri