[Ksummit-2012-discuss] [ATTEND] stable-kernel git management?

Greg KH greg at kroah.com
Wed Jun 20 19:40:06 UTC 2012

On Wed, Jun 20, 2012 at 09:27:15PM +0200, Jiri Kosina wrote:
> On Wed, 20 Jun 2012, Greg KH wrote:
> > > And I don't know why it must be so often rebased.  Aren't stable
> > > patches rather accumulative?
> > 
> > I often (i.e. at least once a release), need to pull a patch out of the
> > middle of the series and throw it away.
> Just an idea ... how about stable tree starting to use git topic branches?
> There are many options how this could actually be done -- per subsystem, 
> per bug, per "categorization" :), etc. The final -stable release would be 
> just a merge of all v3.0.x-stable/topic...  branches into 
> v3.0.x-stable-final.
> This will allow for
> - just simply you deciding not to merge the topic branches with patches 
>   you decide to revert for the final stable release, without any need for 
>   rebase
> - easy cherry-picking (actually proper git merging) from stable for all 
>   the "stable customers"

So pretty much one branch per patch?  Really?  How am I going to keep
track of all of that?

Ok, even with a few "topic" branches if we can group them by subsystem
is going to be really tough, let's look at the 3.4.4-rc1 kernel as an
example.  At first guess, that looks like it would have at least 25
different branches.  I'm all for "octopus" merges, but isn't that a bit
too much?

> This should be trivially scriptable.

Please write the scripts to do so then, right now, the work it takes me
to do the stable releases is not much at all, as I've scripted it pretty
well.  For me to change how that works would require a bunch of rework
of both my scripts, and my workflow, for almost no-gain that I can see.
Actually, it looks like more work, as I'm sure I will get those topic
branches confused.

greg k-h

More information about the Ksummit-2012-discuss mailing list