[Ksummit-2012-discuss] [ATTEND] stable kernel stuff and grumpy maintainers [bisection/rebase/-next]

Jason Wessel jason.wessel at windriver.com
Tue Jun 19 17:08:10 UTC 2012

On 06/19/2012 10:06 AM, Steven Rostedt wrote:
> On Tue, 2012-06-19 at 10:46 -0400, Ted Ts'o wrote:
>>> This is another argument to have a linux-devel repo that people can have
>>> development code go into, and become a single repository for work. Lots
>>> of people may push their 'here's what I'm doing' to their own repos, but
>>> few people will see it. If we have a single "development" repo, it will
>>> get a lot more viewers and vet out bugs before they even hit linux-next.
>>> This may not solve the bad change logs, but we can encourage people to
>>> review changes that go into this repo, and complain about change logs,
>>> to get developers to write better ones.
>> Well, that's an argument for using a rewinding head for a development
>> branch.  What I do for ext4 is I keep an "origin" pointer which points
>> at the upstream commit where I've branched off of (generally 3.x-rc3
>> or so), a "master" pointer for which points at the commits which are
>> cast into stone, and a "dev" pointer which is where patches that are
>> in development (and hence the commit descriptions are may changed, as
>> I add tested-by headers, or if I need to fix out-and-out bugs in the
>> commits).  The "dev" head is rewinding, and it's also what feeds into
>> linux-next.
> We avoid that mainly because that would screw up my (and others) work
> flow. There's lots of patches I send to Ingo, I have various branches
> too. Sometimes I need to figure out what needs to go to Ingo by checking
> the status between my branch and tip's. If tip were to rebase, that
> would make it very difficult for me to know what is there and what
> isn't.

Comments in code and such that don't get caught and get fixed later
are one thing but... as long as we are on the grump topic, I sure get
annoyed with the number of completely impossible to bisect problems in
the kernel like in an rc-0 window.  I would guess if you asked for a
show of hands of how many people in the last year had to bisect
something and had a compile fail you would see more than one hand up.

This becomes particular acute at times with certain non-x86 trees.

While there are plenty of arguments for not rebasing things in
development etc..., I always do a final re-base and test before
putting something into linux-next to make sure it bisects properly.  I
also understand the risks you might break something to make it bisect
correctly if you have to piddle with code, but this can be avoided
completely by diffing the original result with the end result.  On at
least one occasion this led me to even re-factor some code.

I don't know how many cycles are available in linux-next builds, but I
wonder if about the collaboration aspect with the guy who said he
could do 25,000 kernel compiles a day.  Of interest to me is some
reporting and encouragement to fixing bisection quality in the
kernel as a whole.


More information about the Ksummit-2012-discuss mailing list