Re: [PATCH v3.1415] Documentation: add documentation summary for rc-series and merge window

Jake Edge <jake@xxxxxxx> writes:

+After the merge window the kernel is worked on through the rc-series of the
+kernel release. The rc-series focus is to address regressions. The merge window
+closes upon the first rc-series release, rc1.

to address regressions and fix bugs introduced by the new features added
during the merge window.

I would say, to address regressions and fix bugs. Not only those added
recently, though obviously older bugs should have already been fixed.

+After a subsystem maintainer has sent his pull request to Linus during the merge
+window no further new development will be accepted for that
+foo-next-2.6.git

This is IMHO uncertain. Typical, but uncertain. I guess the maintainer
would already know what to do so I'm not sure there is a point to write
it down in this file.

It doesn't seem like you need to keep stressing that the merge window
closes with -rc1 ... but maybe that's just me ...

Me2 :-)

+Non-intrusive bug fixes fixes will very likely not be accepted.
^^^^^^^^^^^
I guess it depends on many factors, such as importance of the bug vs the
risk at the given point. Intrusive bug fixes are sometimes unavoidable
and there may be simply no better option than applying them at once.

Again, maybe it's just me, but this 'non-intrusive' distinction doesn't
read quite right ...

Me2 :-)

I guess the problem is that non-intrusive and
regression/security/oops fixes are not mutually exclusive

Precisely. This is about risk vs gain.

so, when do these non-intrusive bug fixes get accepted? only
pre-merge window?

Doesn't make sense. Merge window = new features. Fixes can be accepted
anytime (this obviously includes merge window).

+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 for it
+cannot regress as no previous kernels exists with it.

Given that fixes are accepted anytime (well, almost, depending on risk
vs gain), then obviously fixes for new driver aren't worse.


Perhaps it's just me :-) but I think we're trying to codify the rules
way too much. The general rules (merge window = new features etc) are
obviously ok but why do we need strict details like intrusive vs
non-intrusive etc? People should just use a common sense and good
judgement and, if in doubt in some particular case, ask. We are unable
to describe all situations in a single text file.
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [GIT]: Networking
    ... actually regressions due to _other_ patches you had much too happily sent ... me after the merge window had already closed). ... Regressions and bugs are fixed, and things are not getting worse ...
    (Linux-Kernel)
  • Re: [git pull] x86 changes for v2.6.27
    ... Please pull the latest x86 git tree from: ... There is also a _ton_ of build fixes which could have been easily ... window to squash patches is small in an append-only setup. ...
    (Linux-Kernel)
  • XFS status update for October 2009
    ... In October we saw the Linux 2.6.32 merge window with a major XFS update. ... and of course various smaller fixes. ... On the userspace side there has been a healthy activity on xfsprogs: ... make the source package generation simpler and shared for different package ...
    (Linux-Kernel)
  • Re: The Great Geometry Muddle
    ... can be restored after a window manager restart; ... one might choose which fixes were enabled; ... Simply fading away without even the option for proper self-support is far ... even if people aren't willing to pay for proper ...
    (comp.unix.cde)
  • Re: Slow DOWN, please!!!
    ... The code merged during a merge window is somewhat opaque from the tester's ... The suspicion is that the number of regressions introduced during merge ... Perhaps if they introduced fewer bugs, all of that would be less frustrating to ... But that need not include obviously broken patches. ...
    (Linux-Kernel)
Loading