| Message ID | 20090616042113.GA5680@tesla |
|---|---|
| State | RFC, archived |
| Delegated to: | David Miller |
| Headers | show |
On Mon, Jun 15, 2009 at 09:21:14PM -0700, Luis Rodriguez wrote: > On Mon, Jun 15, 2009 at 08:20:34PM -0700, Greg KH wrote: > > On Mon, Jun 15, 2009 at 10:10:11PM -0400, Luis R. Rodriguez wrote: > > > + 2.6.30 June 10, 2009 - 79 days > > > + 2.6.29 March 23, 2009 - 84 days > > > + 2.6.28 December 29, 2008 - 82 days > > > + 2.6.27 October 8, 2008 - 87 days > > > + 2.6.26 July 13, 2008 - 88 days > > > + 2.6.25 April 16, 2008 - 83 days > > > + 2.6.24 January 24, 2008 - 107 days > > > + 2.6.23 October 9, 2007 - 93 days > > > + 2.6.22 July 8, 2007 - 74 days > > > + 2.6.21 April 25, 2007 - 80 days > > > 2.6.20 February 4, 2007 > > > > Are you sure about those dates and the count of number of days? > > I used this cheesy web app: > > http://www.timeanddate.com/date/duration.html > > So it could have told 42 for all answers I suppose and I wouldn't have known > the difference. BTW does your list count the ending date? That is from say > 01-01-2009 to 01-02-2009 does it count 2 or 1? I set it to not count it. > > > According to my "big spreadsheet of kernel releases", your day count is > > wrong... > > > > I have: > > > > release: v2.6.20 v2.6.21 v2.6.22 v2.6.23 v2.6.24 v2.6.25 v2.6.26 v2.6.27 v2.6.28 v2.6.29 v2.6.30 > > date: 02/04/07 04/25/07 07/08/07 10/09/07 01/24/08 04/16/08 07/13/08 10/09/08 12/24/08 03/23/09 06/09/09 > > # Days: 68 81 75 94 108 83 88 88 76 89 78 > > I'll trust your big spreadsheet more and with it you actually get a nice > even 86.0 average. FWIW using the same cheesy web app, if we do go about the 10 kernel release average of 86.0 days the next 2.6.31 release should be September 4, 2009. Luis -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Jun 15, 2009 at 09:21:14PM -0700, Luis R. Rodriguez wrote: > So it could have told 42 for all answers I suppose and I wouldn't have known > the difference. BTW does your list count the ending date? That is from say > 01-01-2009 to 01-02-2009 does it count 2 or 1? I set it to not count it. I don't know, but at least it is consistant :) It is whatever openoffice uses when calculating dates subtracted from each other. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Jun 15, 2009 at 09:21:14PM -0700, Luis R. Rodriguez wrote: > +2.0.2: RC-SERIES RULES > + > +Rules on what kind of patches are accepted after the merge window closes. > +These are patches targeted for the kernel rc-series of a kernel prior > +to its release. > + > + - it must fix a reported regression > + - if must fix a reported security hole > + - if must fix a reported oops/kernel hang s/if/it/ twice.. Is there a good reason for documenting different rules for rc-series and -stable releases? These three rules look stricter than the ones described in stable_kernel_rules.txt: - It must fix a problem that causes a build error (but not for things marked CONFIG_BROKEN), an oops, a hang, data corruption, a real security issue, or some "oh, that's not good" issue. In short, something critical. For example, a fix for data corruption that users can hit relatively easily sounds like a good example of something that should really be accepted during the rc-phase even if it is not really a regression or does not cause a kernel oops/hang. "oh, that's not good" issue is somewhat more difficult to comment on, but I would expect that there could be some critical issues that really would benefit from an exception. What exactly would qualify is something that may be not be easily described in a sentence or two, though. The main problem I see with having a very hard line on not allowing critical fixes (however that would be defined) during the rc-phase is that it will take quite a long time to get the fix eventually out. As an example, a driver could have a bug that prevents it from working with certain subset of devices, but this is noticed only couple of kernel releases after the initial driver merge (e.g., for hardware that was not yet available for end users at the time the driver was initially submitted). In other words, the issue would not be a regression, not a security hole, and not an oops/kernel hang. However, it could make the driver unusable to large number of users (once the affected hardware model becomes available; say in a new laptop). If an issue is fixed just before a start of the next merge window the patch may not have had enough time to go through the maintainers and end up in linux-2.6.git in time before the merge window closes. If it weren't now allowed in during the rc-phase, it may not go into a stable release either (assuming the rc/stable rules are more or less the same) and we would be looking something like five month time until the fix would actually be released in a proper kernel release. Sure, users/distros could take in some additional patches to fix issues they care about, but worst case scenarios of close to half a year to fix an issue in a kernel release does not sound quite ideal.
Jouni Malinen wrote: > If it > weren't now allowed in during the rc-phase, it may not go into a stable > release either (assuming the rc/stable rules are more or less the same) They aren't. Just compare shortlogs between -RCs with shortlogs between .Ys and everything becomes almost obvious. :-)
diff --git a/Documentation/development-process/2.Process b/Documentation/development-process/2.Process index d750321..668eb8f 100644 --- a/Documentation/development-process/2.Process +++ b/Documentation/development-process/2.Process @@ -7,20 +7,92 @@ course of one year, the kernel has since had to evolve a number of processes to keep development happening smoothly. A solid understanding of how the process works is required in order to be an effective part of it. +2.0:SUMMARY + +This section provides a brief summary of the kernel release rules. + +2.0.0: KERNEL RELEASE RULES + +Stable kernels are released when they are ready! This means there are +absolutely no strict guidelines for sticking to specific dates for a +kernel release. + +2.0.1: MERGE WINDOW + +The merge window opens up after the next stable kernel is released. +The merge window is when maintainers of different subsystem send pull +requests to Linus for code they have been queuing up for the next +stable kernel. This is typically now done through respective +foo-next-2.6.git trees where foo is your subsystem. Each maintainer +queues up patches for the next kernel cycle in this foo-next-2.6.git +tree. After the merge window the kernel is worked on through the +rc-series of the kernel release. The merge window closes at the first +rc-series release. + +After a maintainer has sent his pull request to Linus during the merge +window no further new development will be accepted for that tree and +as such it marks the closure of development for that subsystem for that +kernel cycle. Developers wishing to target deadlines should simply work +on their development without regards or consideration for inclusion to +a specific kernel release. Once development is done it should simply be +posted. If you insist on targeting a kernel release for deadlines you can +try to be aware of the current rc cycle development and how soon it seems +the next stable kernel release will be made. When Linus notes the last rc +cycle released may be the last -- that is a good sign you should already +have all your development done and merged in the respective development +tree. If your code is not ready and merged into the respective maintainers +tree prior to the announced last potential rc kernel release chances are +you missed getting your code in for the next kernel merge window. +Exemptions here are new drivers, covered below. + +2.0.2: RC-SERIES RULES + +Rules on what kind of patches are accepted after the merge window closes. +These are patches targeted for the kernel rc-series of a kernel prior +to its release. + + - it must fix a reported regression + - if must fix a reported security hole + - if must fix a reported oops/kernel hang + +This means any small-non-fix code changes, although they might fix an issue, +will not be accepted. If the patch in question is for a driver that has been +around for more than a kernel release, then "small fixes" really can't be +worth all that much. And "small fixes" may be small and "obvious" they +definitely can regress. + +2.0.3 RC-SERIES NEW DRIVER EXEMPTION RULE + +The very first release a new driver (or filesystem) is special. New drivers +are accepted during the rc series. Patches for the same driver then are +also accepted during the same rc series of a kernel as well as fixes as it +cannot regress as no previous kernels exists with it. + +Once drivers are upstream for one kernel release (say on 2.6.29) the target +*goal* after the merge window of the next kernel (respectively this would be +the 2.6.30 rc-series) is to address regressions. Kernel oops/hangs and security +issues are obviously accepted but the point is these should have also been +caught earlier as a general development goal. The rc-series focus should really +be to address regressions. 2.1: THE BIG PICTURE The kernel developers use a loosely time-based release process, with a new -major kernel release happening every two or three months. The recent -release history looks like this: - - 2.6.26 July 13, 2008 - 2.6.25 April 16, 2008 - 2.6.24 January 24, 2008 - 2.6.23 October 9, 2007 - 2.6.22 July 8, 2007 - 2.6.21 April 25, 2007 - 2.6.20 February 4, 2007 +major kernel release happening about every two or three months. The current +average time based on the last 10 releases is 86.0 days. The recent release +history along with the number of days between each release looks like this: + + 2.6.30 June 10, 2009 - 78 days + 2.6.29 March 23, 2009 - 89 days + 2.6.28 December 29, 2008 - 76 days + 2.6.27 October 8, 2008 - 88 days + 2.6.26 July 13, 2008 - 88 days + 2.6.25 April 16, 2008 - 83 days + 2.6.24 January 24, 2008 - 108 days + 2.6.23 October 9, 2007 - 94 days + 2.6.22 July 8, 2007 - 75 days + 2.6.21 April 25, 2007 - 81 days + 2.6.20 February 4, 2007 - 68 Every 2.6.x release is a major kernel release with new features, internal API changes, and more. A typical 2.6 release can contain over 10,000 diff --git a/Documentation/stable_kernel_rules.txt b/Documentation/stable_kernel_rules.txt index a452227..113e8c8 100644 --- a/Documentation/stable_kernel_rules.txt +++ b/Documentation/stable_kernel_rules.txt @@ -1,5 +1,10 @@ Everything you ever wanted to know about Linux 2.6 -stable releases. +For further details, such as stable kernel release schedules, rc-series +policies and process of development please refer to: + +Documentation/development-process/ + Rules on what kind of patches are accepted, and which ones are not, into the "-stable" tree: