[Ksummit-2012-discuss] [ATTEND] Process issues, device model, stable

[Steven Rostedt]

On Tue, 2012-06-19 at 19:29 +0000, Luck, Tony wrote:
> > The problem is, we do not enforce any of this. It's all been more of a
> > "please do it this way". The only one that could possible enforce it is
> > Linus himself. He could say, "I'm not accepting this unless it was in
> > linux-next for a full release".
> 
> A full release seems rather extreme ... but there might be more support
> for "a couple of weeks".

Yeah, I actually changed my attitude in the middle of my email. I later
ended with:

"You can get your own branch that is automatically updated and it has to
sit there unmodified for a given amount of time, and then Linus can pull
from it there."

I changed from full release to "given amount of time".


> 
> E.g. code going into linux-next up until "-rc5"[*] is announced is a candidate
> for inclusion in the 3.x merge window.  People can (and should) keep supplying
> linux-next with new things beyond that point ... but they will be candidates for
> 3.(x+1).
> 
> This could also be the rebase deadline ... trees feeding linux-next should
> be *encouraged* to rebase (to add more "Tested-by", fix speeling mistales,
> squeeze out superfluous commits, combine pointlessly split commits, improve
> commit message text, add Cc: stable) ... all the stuff that will make the
> history of mainline more readable and useful ... but leaving enough time
> that Linus will feel that the patches have had testing in the form and
> environment that he is being asked to pull.
> 
> Possible upside of having a defined point would be more people focusing
> testing on the next-YYYYMMDD release that comes out at -rc5 - so we will
> find and fix problems that would otherwise show up in the merge window.

I actually like this idea.

But I'm still not giving up on the linux-devel. I wouldn't push that new
changes must first go into linux-devel before it goes into next. But
have it like the way -mm was. Have it be the place to put the 'release
early, release often' code. The current approach has been more of push
out a lot of patches and have people bitch about them, rewrite, push out
again, bitch, rewrite, push, bitch, rewrite and push until they are
finally acceptable. But in the mean time, no one is testing that code.

This could have been where the uprobes code could have lived. It would
have needed to be rebased each time, but people could have started
getting their feet wet with them.

-- Steve