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

Paul Gortmaker paul.gortmaker at windriver.com
Fri Jun 22 17:23:30 UTC 2012

On 12-06-20 09:13 AM, Takashi Iwai wrote:
> At Wed, 20 Jun 2012 09:02:32 -0400,
> Josh Boyer wrote:
>> On Wed, Jun 20, 2012 at 02:33:32PM +0200, Takashi Iwai wrote:
>>> Hi,
>>> I'd like to join this year's kernel summit.  I can bring expertise
>>> from the sound subsystem maintenance and raise issues learned from the
>>> Linux laptop / desktop preload experiences.
>>> Like many people have already commented on stable kernel process, I'm
>>> also interested in it.  Especially whether it makes sense to allow
>>> maintainers to send pull requests to Greg and others.
>>> Currently, we receive patch bombs from Greg when patches are queued or
>>> in the review phase before the stable release.  But it's hard to
>>> follow whether all necessary patches are merged only from these
>>> individual patch mails.  I often loose some overview.
>>> After all, it's the subsystem maintainer who knows well about the
>>> commits they did, what should be applied to which kernel and how.
>>> I'm willing to do the backport or merge to the stable kernel for my
>>> own commits at the same time I commit to the for-linus branch, then
>>> give Greg to pull.
>> Dave Miller does this for the net tree already, though I don't think it
>> is a pull request.  I believe he queues the patches he feels are
>> necessary and then sends them in one large patch.
> OK, that's good to know.
>> That sounds like something any maintainer could ask Greg to work from.
> Yeah, but a general guideline would be good to have, IMO.
>>> This also helps in some cases where the patch is not trivial to
>>> backport.  So far, I prepare an extra patch and send to stable after
>>> merge to Linus tree, but I forget often due to this delay.
>>> 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
> :)

People can spend their time creating whatever they want, but I do have
to wonder if it is worthwhile for something like this.  Since all the
commits are format-patch output, one does not even need to rely on
the quiltimport feature.  Doing what you describe above is trivial,
and can be done with "git am" directly:

stable$git checkout -b scratch v3.4.3
Switched to a new branch 'scratch'
stable$rm -f /tmp/mbox; for i in `cat ../stable-queue/queue-3.4/series` ; do cat ../stable-queue/queue-3.4/$i >> /tmp/mbox ; done
stable$git am /tmp/mbox
Applying: ARM i.MX53: Fix PLL4 base address
Applying: ARM: imx6: exit coherency when shutting down a cpu
Applying: ARM i.MX imx21ads: Fix overlapping static i/o mappings
Applying: Revert "drm/i915/dp: Use auxch precharge value of 5 everywhere"
Applying: drm/radeon: add some additional 6xx/7xx/EG register init
Applying: drm via: initialize object_idr
Applying: drm/udl: only bind to the video devices on the hub.

Tip: Using "git am" on a single mbox with hundreds of patches is _way_
faster than calling "git am" hundreds of times.  It also will magically
resume if/when you stall on an apply failure and manually have to fixup.

Also, "git am" is more strict when it comes to sanity checking what
it applies (i.e. it expects proper header etc), whereas a quilt series
can contain things like raw patches w/o commit headers etc.


> Takashi
> _______________________________________________
> Ksummit-2012-discuss mailing list
> Ksummit-2012-discuss at lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/ksummit-2012-discuss

More information about the Ksummit-2012-discuss mailing list