Carrying security branches in the main git repository

[Tim Gardner]

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

Lets think about what it means to merge a security release back into
master. There are some files that simply don't make sense, i.e., the
semantics of the merge are meaningless. All of the ABI files fall into
that category, as does IMHO the changelog. In fact, I could argue that
any generated file falls into the 'does not make sense' category.

The changelog file is supposed to catalog the changes that went into
that particular package. I'll admit that I didn't handle this correctly
with a couple of the Hardy security-->master merges. Copying the
security kernel changelog entry into the master branch doesn't make
sense because that entry describes changes that simply didn't happen to
master. Because we've cherry-picked the security kernel code commits,
the next time we create a master branch changelog entry using
'debian/rules insertchanges', they'll get correctly noted in the master
branch changelog for that release. That changelog entry will then
accurately represent the changes that went into that particular package.

I do agree with you that a security kernel is a temporary thing. The
branch need only exist as long as that kernel is in the archive. Once an
-updates kernel is copied into -security, we are free to drop the
corresponding security branch.

rtg
-- 
Tim Gardner tim.gardner at canonical.com