Carrying security branches in the main git repository

[Ben Collins]

On Thu, 2008-11-20 at 16:24 +0000, Andy Whitcroft wrote:
> 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.

Right, that's exactly the part that needs to be retained. Our changelog
should match up with what launchpad history shows.