SÃrgio Basto <sergio <at> serjux.com> writes: > > Here it go my opinion, > Many people ask for beginning of 2.7 kernel series which will end on > 2.8, by old numeration. > Kernel 2.8 will mainly a major clean up, of support of the very old > hardware, like "math co-processor" at only exist in 386 and before > Pentium. If some one want put Linux on this very old hardware should use > kernel 2.2. On the contrary, I hope this never happens. Whatever the next 'step' will be, it should just keep going into the right direction, as usual, no revolution please :) Release early, release often and no 'numerology' or 'walling off'... As per Linus' own words, the release schedule is not about features and it wasn't about features [since] forever... [at least since this workflow was adopted - 2.6.8 and the introduction of git ? ;) ] I like the d.r[.s][.lt] scheme (decade, release, stable, long-term), so basically, to convert 2.6 to 3 and leave the rest as is - no big shock to existing infrastructure ;) But I also like the yy.mm[.ss][.lt] (year, month, stable, long-term) Or maybe a hybrid of these ? ly.mm[.ss][.lt] (linux_year, month, stable, long term, where linux_year = linux_decade + year-2000 and month in both of these = month_in_year of release So that : the 2.6.39-rcX process continues for now, and in time to cut off, it gets renamed to 3.0 or 3.1 and then stable and lt adds their part, or 11.07 (provided the release happened in July) (and then stable, lt parts add) or 14.07 (11+3).(july)[.stable][.longterm] but in all 3 cases there is a merge window ending with 3.0-rc1 or 11.07-rc1 or 14.07-rc1 and in case of months used in here, say next cycle has 7 weeks, so the next major release will be 11.09 or 14.09 and so on; Because the release cycle probably never had less than 4 weeks, using the month is imho reasonable. > However a new numeration of kernel is independent of this, and I agree > with new numeration of kernel on drop a number. > Last but not least, I would like to see marked a hiper stable kernel , > which will be used by Debian guys. Debian guys tend to stop in a kernel > which is not the best one, so let we choose for them what is the stable > of stables . That as well is probably never gonna happen ;) the kernel is more stable with each release anyway, _because_ of the 'no thresholds' approach. And Debian probably have their own reasons for ending up with old kernels, like out-of-tree patches that don't get merged but need to be ported which is no easy job... and so on. > > Best regards, u 2, Kind Regards, L. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
