[Ksummit-2012-discuss] [ATTEND] stable kernel stuff and grumpy maintainers

Steven Rostedt rostedt at goodmis.org
Tue Jun 19 15:06:34 UTC 2012


On Tue, 2012-06-19 at 10:46 -0400, Ted Ts'o wrote:

> Part of the problem is that for some of the contributors, English
> isn't their first language.  I've very often had to rewrite the change
> log for that reason; in some cases, it was so mangled that even though
> it was a paragraph full of text, I couldn't parse it at all, and I had
> to send back a "huh?  Is this what you meant?" message.

There has been many times that I have had issues with language and had
to fully rewrite change logs myself. That, I believe is the maintainer's
responsibility, and this is not what I'm really talking about. Although,
a maintainer needs to push back and get a better change log, even if
they need to be the one to rewrite it.

Note, usually I don't need to ask "is this what you meant" because as
the expert in the code being submitted to me, I can deduce from the
patch itself what is going on. This is how I determine if I am willing
to take the patch or not. If I know the person submitting the patch has
issues with the language, I look at the patch, it becomes obvious what
the change is for, and then I rewrite the change log to explain in
detail what the patch was about. So far no one has complained about me
doing this. I do not, however, modify the patch itself, except for very
small changes, and if I do that, I add to the change log explaining the
change I made, no matter how little the change was.

> 
> > It really comes down to reviewing patches. We do not have enough
> > reviewers, or at least we do not have a good process for reviewing. I
> > myself have been trying to send out RFC patch sets before I start
> > posting pull requests. Because, when I post a pull request for Ingo, if
> > Ingo pulls it in and then someone notices a bug, that bug will stay in
> > the repo, because Ingo follows the 'do not rebase' rule. The bug fix
> > will go on top. That's if it is noticed then.
> > 
> > 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.

> 
> It's basically a simplified version of the git repository, which has a
> master, next, and pu branch, where the pu branch is rewinding.  You
> might complain that if everyone did this, it might destablize
> linux-next, but in reality, if you want a shared "work" repository to
> be used, it has to be mostly stable.  So if someone pushes something
> which breaks either linux-next or your proposed linux-devel repo, they
> need to be flamed.

Right. And ideally, the linux-devel can allow rebases, and then perhaps
make linux-next seldom rebase. Do your development in linux-devel, and
when things look good to go to mainline, push it to linux-next where it
should be at a higher level of stability. I'm not saying that linux-next
can never rebase, but it should be the exception and not the norm.


> 
> Personally, I run a regression test before I push out something in my
> dev repository; that way I know there are no obvious bugs, even if I
> still need to clean up the commit in some minor ways.

I do that too, but there's always that case where the bug gets out. I
recently had an embarrassing bug get out but this is because to test it
you had to modify the code (tracing_off()). I had tested it, but a small
fix I had made during the test didn't get put into the git repo. When I
was done testing, I reverted the changes I made to test the code and
accidentally reverted the fix too. If this was sitting in a devel repo,
it could have been caught before making it to linux-next and even 3.4.

Of course, my code is not as widely used, (some of it requires modifying
the code, like tracing_off() and trace_printk()). Which is more reason I
would like to get my code into the hands of more developers before it
gets mainlined.

-- Steve




More information about the Ksummit-2012-discuss mailing list