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

Takashi Iwai tiwai at suse.de
Wed Jun 20 16:32:15 UTC 2012


At Wed, 20 Jun 2012 09:24:03 -0700,
Greg KH wrote:
> 
> On Wed, Jun 20, 2012 at 06:04:22PM +0200, Takashi Iwai wrote:
> > At Wed, 20 Jun 2012 08:54:01 -0700,
> > Greg KH wrote:
> > > 
> > > On Wed, Jun 20, 2012 at 03:13:17PM +0200, Takashi Iwai wrote:
> > > > > > Or, at least, if we can have the expanded to-be-released-as-stable
> > > > > > git tree, it'd help the review for me...
> > > > > 
> > > > > Greg keeps the unreleased patches in a quilt series in the stable-queue
> > > > > git tree.  Is that not sufficient?  If not, why?
> > > > 
> > > > Well, it's no expanded tree.  I'm just too lazy to do "get the latest
> > > > linux-stable.git, update stable-queue.git, apply series" at each time
> > > > :)
> > > 
> > > And would someone really be willing to pull that git tree?
> > 
> > I would, at least.
> > 
> > > Problem is, it would be constantly rebased, which I don't want to do,
> > > and it would be thrown away after each stable release as well, when I do
> > > a real release, which would take a whole lot of explaining to users as
> > > to how to handle it.
> > 
> > It'd just look like linux-next, no?
> 
> Not that I can determine.
> 
> > 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.

OK.

> > If a patch has to be removed, it can be a simple git-revert.  The
> > revert is also a good information so that someone won't stumble on the
> > same commit.
> 
> That's why I keep the patches in a quilt tree, not a git tree, as
> accumulating the reverts and other fixes can be a pain in the long-run.
> quilt works much better for this.

Yeah, I do understand why it's in quilt.  But, I also wonder whether
this could be kept in git tree as well.  For the overview, git tree is
much better to handle in general.

> > Abandoning the pre-release branch after each release is no big
> > problem, I think.  They could be kept by tags, if any.
> > 
> > > But if someone is willing to create the tree from my quilt series
> > > automagically, feel free to do so.
> > 
> > I'll check it but I guess other guys manage it much much better than
> > me...
> 
> I'm a bit worried here, you often tag patches for stable trees, and are
> doing so much better than lots of other subsystem maintainers.  Do you
> feel there are more patches you could be marking or sending to me?  If
> that's true, I hate to wonder about the other subsystems that aren't
> sending me any...

Oh no, it doesn't mean that suddenly patches from me would double.
My request for a git tree is rather to make sure that I don't miss
anything important.  It's often easier to look from the complete form
than a pile of pieces.

Also, the question about git pull came from a similar situation.  It'd
be good if I myself can take a look through the tree to be merged to
stable kernels beforehand when I send a pull request to Linus.

In addition, there is a case of forgotten tags.
I tag to stable kernel, but also I forget and notice later when I look
through the tree before passing to Linus.  What should I do?  Amend
commit is no preferred option for a published repo.
So, if I can manage the stable branch, I can just cherry-pick the
forgotten one on the top.  That was one motivation.


Takashi


More information about the Ksummit-2012-discuss mailing list