Carrying security branches in the main git repository

[Stefan Bader]

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.
> 
> 
With hardy I am currently at the point where I merged the security branch with 
the proposed. So I have

-23.46 -proposed(to come)
-22.45 -security(new)
-22.44 -proposed(old)
-21.43 -security (old)

Next is to get the -22.45 up to be able to get the abi files from it to make 
-23.46, then merge that into master and go on from there...




-- 

When all other means of communication fail, try words!