Carrying security branches in the main git repository

[Ben Collins]

On Thu, 2008-11-20 at 15:42 +0000, Andy Whitcroft wrote:
> On Thu, Nov 20, 2008 at 07:51:38AM -0700, Tim Gardner wrote:
> > Andy (aka git wizard),
> > 
> > I've been struggling with rebasing the security branch back into master
> > and am finding that it doesn't really work all that well. Of course, the
> > code patches rebase just fine, but where I'm having some real conflicts
> > is with some of the generated administrative files such as those in
> > debian/abi (and to some extent debian/changelog).
> > 
> > What I'm considering is to just name the security branch with its
> > release version (such as security-2.6.27-9.18), cherry-pick the security
> > branch code commits back into master, and push the whole mess up to
> > zinc. The one thing I want is the ability to reliably reproduce the
> > security kernel. This method seems to satisfy that criteria, as well has
> > making sure master contains all of the security kernel code patches.
> 
> I was envisaging you would merge the security branch into master, as in
> a real git merge.  The changes since the 'split' are only the security
> patches anyhow.  There is a version tag on the tip which represented the
> security version, so you can always re-check that out and recreate the
> kernel right?
> 
> > Another advantage is that with this method I don't have to arbitrarily
> > fix the changelog. The content of changelog for the kernel in a
> > particular pocket accurately reflects the changes that went into that
> > kernel. Whereas, in the past I was hacking security changelog sections
> > into an arbitrary location in the master changelog, the results of which
> > Stefan and I have not always agreed.
> 
> When I simulated the above I could simply ignore the changelog
> modifications from the security branch, as subsequent to the merge the
> 'full list' produced by debian/rules printchanges included the security
> commits also.

Problem is that kills history. Since -proposed will eventually end up in
-updates, which will eventually be used as the base for another security
upload, it would be nice if the previous security uploads showed up as
such.

Honestly, from my past experience, this is all being made more complex
than it needs to be. I don't see a way to logically and reliably map our
archive pockets with git branches in a way that will make it easier to
maintain than what we are doing now.

But I will rely on Stefan's judgment, since he is the one having to
maintain it right now.