Carrying security branches in the main git repository

[Andy Whitcroft]

On Thu, Nov 20, 2008 at 10:58:11AM -0500, Ben Collins wrote:
> 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.

Well a security kernel is really only temporary in a lot of senses, it
is an offshoot of our linear progression:
	     
	R1 -> R2 -> R3 -> R4
	       \    /      \
                S2-1       S4-1

So when we were building R3 some important security fix arrived, we made
S2 off R2, and release that.  We also merge that into what becomes R3.
The changelog for R3 shows that change as a security change within the
general list of changes.  So no change is missing, what is missing is
that there ever was a version S2-1, is it that we are not happy about
loosing?  If so I guess that is something we could maintain by simply
keeping the changelog entry from the branch in the spot it occurs in the
history.

-apw