On Fri, Jun 19, 2009 at 8:00 AM, Pavel Machek<pavel@xxxxxx> wrote: > On Tue 2009-06-16 11:17:05, Luis R. Rodriguez wrote: >> On Tue, Jun 16, 2009 at 02:34:01AM -0700, Jouni Malinen wrote: >> > 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.. >> >> Thanks, fixed. >> >> > 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. >> >> The rc-series rules this patch adds are a summary, so they do indeed appear to be >> stricter but I do think new vendor/device ids should be welcomed as well AFAICT, >> for instance. >> >> What may be best is to merge these two somehow and refer to the common rules for >> both and try to differentiate between them in their respective documentation >> section. >> >> But I also think good judgement can be applied, good judgement being defined as >> that of a subsystem maintainer, which allows us to simply tell developers to >> focus on development and send patches up and the respective maintainer routes >> the fixes accordingly. >> >> The spirit of writig this summary is to be clear that rules do exist and that >> we cannot simply suggest to read stable_kernel_rules.txt as there are items there >> which do not apply. >> >> Reason for trying to add more documentation for this is today there are a lot >> companies are working upstream and a better sense of what can get into specific >> kernel releases becomes more important and you also have more responsible >> developers looking out to ensure their fixes get propagated to the right trees. >> So leaving some of these things undocumented, implied or in the dark can turn >> out to not be as healthy and IMHO is what lead to the original issue from which >> I extracted information to create this summary. >> >> > 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. >> >> Agreed. >> >> > "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). >> >> I believe it makes sense to send fixes for new hardware on an old >> driver if it is known the fix cannot regress as it does not affect older >> hardware. >> >> > 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). >> >> Agreed. But I think that would fall under the new driver category. >> >> > 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. >> >> Agreed. In the end it seems to come down to the specifics of the patch and >> only the maintainer can really be a good judge of whether it should go in >> or not. Of course properly documenting each patch helps, and I believe that >> in itself may be good enough to address the grey areas. >> >> Here's a new patch with the fix you noted. Also added a little stub about >> maintainers judgement, etc. >> >> From: Luis R. Rodriguez <lrodriguez@xxxxxxxxxxx> >> Subject: [PATCH] Documentation: add documentation summary for rc-series and merge window >> >> This is losely based on previous discussions on linux-kernel [1][2]. >> Lets also refer people reading the stable rules to >> Documentation/development-process/. >> >> Also add the number of days it has taken between releases, >> and provide the average for the last 10 releases: 86.0 days. >> >> [1] http://marc.info/?l=linux-kernel&m=122048427801324&w=2 >> [2] http://marc.info/?l=linux-netdev&m=122048757705315&w=2 >> >> Signed-off-by: Luis R. Rodriguez <lrodriguez@xxxxxxxxxxx> >> --- >> Documentation/development-process/2.Process | 96 ++++++++++++++++++++++++--- >> Documentation/stable_kernel_rules.txt | 5 ++ >> 2 files changed, 91 insertions(+), 10 deletions(-) >> >> diff --git a/Documentation/development-process/2.Process b/Documentation/development-process/2.Process >> index d750321..c220646 100644 >> --- a/Documentation/development-process/2.Process >> +++ b/Documentation/development-process/2.Process >> @@ -7,20 +7,96 @@ 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 >> + - it must fix a reported security hole >> + - it must fix a reported oops/kernel hang > > - it must fix a bug. Well that's for certain, but there is a difference between a general notion of a bug and the type of bug fixes that should go in during the rc-series. This documentation patch highlights the difference. > I do not think the 'reported' requirement is there in -rc, Well if its not reported how else would you find out about it during the rc-series? And if its something easily triggerable that should have been fixed earlier, not late in the rc-series. > and yes, > compile-fixes etc are welcome. Sure, but what are these doing so late in the rc-series? > Non-intrusive bugfixes too, afaict. It really depends on what you mean but generally no, and this is why I think this clarification is important. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
