Re: [ 00/19] 3.10.1-stable review

[Steven Rostedt]

On Thu, 2013-07-11 at 15:44 -0700, Greg Kroah-Hartman wrote:

> > For .10 I had to start making a list of "shit that's broken that there's
> > an outstanding patch for" and nagging people to send them week after week.
> > Every time I reported a new bug I'd hit, I'd have to explain I wasn't running
> > Linus' tree because there was so much other crap I had to carry just to
> > get things to a baseline of stability before starting tests.
> > 
> > By rc7 things got a lot better, but if we have fixes sitting around in
> > git trees for weeks on end with no progress, that kinda sucks.
> 
> We have patches with assigned CVE numbers sitting in subsystem trees
> that didn't hit Linus's tree until this merge window.  Now granted, I
> don't necessarily agree that they were worth CVEs, but really, holding
> them off from being merged for 2 months or so is really bad, and means
> that something seems a bit broken with our development process.
> 
> And thanks for nagging people, I really appreciate it, sad it's
> necessary.

What I try to do is, get all "stable" patches in before -rc4 is out.
Once -rc4 is out, then I get a bit more picky with what to push to
Linus. If it's not a regression (something that's been broken for a
while) I don't push it. -rc5, I get even pickier, and by -rc6 and
beyond, I only push things that may crash the kernel. If things just
give bad output (for tracing), I tag it with stable and wait for the
merge window.

3.10 was actually really bad for me. I had some major changes done to
ftrace, and there were a lot of patches sent to me after -rc4 came out.
A lot of them were nits and didn't crash the kernel, thus I only tagged
them with stable. Some of them, we didn't get correct until Linus opened
the merge window.

Maybe this would be a good KS topic. What exactly is appropriate to push
during the -rc's. Perhaps have criteria for the -rc levels.

-rc1-3, take all bug fixes.

-rc4,5, regressions, and more substantial bugs

-rc6-..  get your act together. Only critical bug fixes.

??

-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/