"Luis R. Rodriguez" <lrodriguez@atheros.com> writes:
Hi Luis,
A few comments:
Is there a reason not to renumber this whole file, making this section
2.1 and incrementing everything else further down? It just stands out
from the rest of the document by having a 2.0 section, as well as having
all of the 2.0.x subsections. It's probably fairly minor, but it does
make this chunk look very different than the rest of the
development-process document ...
The bang (!) seems unneeded.
The second sentence seems to have an overabundance of modifiers, perhaps
something like: This means there are no strict guidelines, in terms of
specific dates, for a kernel release.
I don't quite follow: In order to aid the development of Linux
maintainers subsystem have trees ...
is there a missing comma and/or some missing words?
Is the "foo-next-2.6.git" convention that widespread? It just seems
like subsystem maintainers have various ways they track things for the
next development release, but maybe I am wrong. If not, though, perhaps
toning "typically done" down some, and using it as an example of how it
*might* be done, would be better.
as a breeding and testing ground for bleeding edge patches. (sounds
better i think)
The first sentence seems to overstate the case somewhat ... new patches
are welcome most any time, not necessarily accepted ... I suspect (but
don't know for sure) that there are times when subsystem trees are
"closed" as well, but maybe not officially
"between a stable kernel release and prior to the rc1 kernel release"
sounds like "during the merge window"
to address regressions and fix bugs introduced by the new features added
during the merge window.
and, as such, it marks
That seems a little strange to say ... if they wish to target deadlines,
they can't work without consideration for inclusion into a specific
kernel, can they?
I think you are trying to suggest that they *not* target deadlines, but
that if they must ...
prior to the last rc kernel release, chances are ...
(Li Zefan had some corrections in here, that I won't repeat)
before and after the merge window closes.
These patches are targeted for the new kernel currently under
development. (or something like that, "targeted for the kernel prior to
its final release" doesn't make sense, at least to me)
This could be simplified substantially: Before the merge window closes,
Linus accepts pull requests from the subsystem maintainers; these
contain all of the queued up patches for that subsystem that are bound
for the next kernel release.
It doesn't seem like you need to keep stressing that the merge window
closes with -rc1 ... but maybe that's just me ...
I think you mean "intrusive bug fixes", but maybe not ... maybe the
distinction isn't on the intrusiveness, so much as how
critical/important the fix is ... this also seems overly concrete, in
that various maintainers have their own style which may or may not
conform to this ...
When in doubt, consult with the subsystem maintainer to determine
when the patch should be merged. A well-written, concise commit log
message will help here.
Again, seemingly too rigid based on what really happens ... but maybe
this is documenting the "ideal"
Again, maybe it's just me, but this 'non-intrusive' distinction doesn't
read quite right ... I guess the problem is that non-intrusive and
regression/security/oops fixes are not mutually exclusive but this
document sometimes reads that way ... there are critical bug fixes that
will be accepted pretty much any time, no matter how intrusive they
are. There are less critical bug fixes that will be accepted based on
how intrusive they are and where in the cycle the patch is proposed.
so, when do these non-intrusive bug fixes get accepted? only pre-merge window?
No ! needed I don't think ....
except staging drivers?
68 days I presume
jake
--
Jake Edge - jake@edge2.net - http://www.edge2.net
--
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
