Carrying security branches in the main git repository

[Stefan Bader]

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.
> 
> 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.
> 
> Thoughts?
> 

I am in the process of getting more experience there. The hardy security upload 
also will be a good example of complicated versioning. Currently I don't see 
the big pitfalls but I might change my mind later. Or have some good insight.

Stefan
  (Actually I currently believe it to be possible to get exactly what we want 
in the changelog without placing the sections at unusual locations)
> rtg


-- 

When all other means of communication fail, try words!