packaging branches

[Russ Allbery]

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

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

Right, agreed here.  The only reason to keep the branch around at all is
because there are tags based off of it that were past Debian uploads.
(You could also make an argument for just deleting the branch entirely,
since the tags do anchor the history and keep it from being garbage
collected.)

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

Yeah, agreed on what the branches should have been at the time.  I didn't
think through this very well.  And yeah, that would have worked.
Unfortunately it's a bit too late now to go back and merge the branches at
the points at which they conceptually should have been merged.

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

Indeed.  Probably the foundational error here was that I didn't branch an
experimental branch for the work that stayed on master, which would have
made it more obvious that I should just merge that branch back into the
mainline.

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

I'd probably call it something like jessie-201306 or
jessie-201306-obsolete to keep it around, since that makes it clearer that
it was used at a particular point in time but isn't interesting any more.

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

Yes, point, although the main benefit of that is to be able to do git log
and git history on upstream files with a meaningful result, and we don't
get that sort of benefit here.

I think strong arguments could be made for pretty much any approach here.
The root realization, I think, is that I made a mistake in doing
development for experimental on debian/master (well, master at the time)
because of the possibility of testing-specific security fixes, and should
have branched an experimental branch that could have been merged back in
later.

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