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

[Ted Ts'o]

On Tue, Jun 19, 2012 at 09:56:06AM -0400, Steven Rostedt wrote:
> > The bottom line is that adding more tags and process to changelogs
> > doesn't solve the fundamental problem which is that a lot of people
> > can't write good changelogs in the first place.
> 
> I agree that is an issue. Maybe we need to push maintainers to push back
> on change logs. Not to pull if a change log is not up to stuff. Or have
> Linus or Greg start being more vocal when they see crappy change logs.

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.

> 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.

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.

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.

	      	     	     	   - Ted