Messages in this thread | | | Date | Thu, 2 Dec 2004 10:27:16 -0800 | From | Grant Grundler <> | Subject | Re: page fault scalability patch V12 [0/7]: Overview and performance tests |
| |
On Wed, Dec 01, 2004 at 10:34:41PM -0800, Andrew Morton wrote: > Of course, nobody will test -rc3 and a zillion people will test final > 2.6.10, which is when we get lots of useful bug reports. If this keeps on > happening then we'll need to get more serious about the 2.6.10.n process. > > Or start alternating between stable and flakey releases, so 2.6.11 will be > a feature release with a 2-month development period and 2.6.12 will be a > bugfix-only release, with perhaps a 2-week development period, so people > know that the even-numbered releases are better stabilised.
No matter what scheme you adopt, I (and others) will adapt as well. When working on a new feature or bug fix, I don't chase -bk releases since I don't want to find new, unrelated issues that interfere with the issue I was originally chasing. I roll to a new release when the issue I care about is "cooked". Anything that takes longer than a month or so is just hopeless since I fall too far behind.
(e.g. IRQ handling in parisc-linux needs to be completely rewritten to pickup irq_affinity support - I just don't have enough time to get it done in < 2 monthes. We started on this last year and gave up.)
I see "2.6.10.n process" as the right way to handle bug fix only releases. I'm happy to work on 2.6.10.0 and understand the initial release was a "best effort".
2.6.odd/.even release described above is a variant of 2.6.10.n releases where n = {0, 1}. The question is how many parallel releases do people (you and linus) want us keep "alive" at the same time? odd/even implies only one vs several if 2.6.X.n scheme is continued beyond 2.6.8.1.
Also need to think about how well any scheme align's with what distro's need to support releases. Like the "Adopt-a-Highway" program in California to pickup trash along highways, I'm wondering if distros would be willing/interested in adopting a particular release and maintain it in bk. e.g. SuSE clearly has interest in some sort of 2.6.5.n series for SLES9. ditto for RHEL4 (but for 2.6.9.n). The question of *who* (at respective distro) would be the release maintainer is a titanic sized rathole. But there is a release manager today at each distro and perhaps it's easier if s/he remains invisible to us.
hth, grant - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |