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 stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html