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-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
