> And I think it could work for the kernel too, especially the stable
> releases and for the process of getting there. I just don't really know
> how to set it up well.
A start might be
1. Ack large patches you don't want with "Not for 2.6" instead
of ignoring them. I'm bored of seeing the 18th resend of
this and that wildly bogus patch.
Then people know the status
2. Apply patches only after they have been approved by the maintainer
of that code area.
Where it is core code run it past Andrew, Al and other people
with extremely good taste.
3. Anything which changes core stuff and needs new tools, setup
etc please just say NO to for now. Modules was a mistake (hindsight
I grant is a great thing), but its done. We don't want any more
4. Violate 1-3 when appropriate as always, but preferably not to
often and after consulting the good taste department 8)
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Dec 23 2002 - 22:00:20 EST