> Patches get lost. Patches get dropped. Patches get missed. This is
> bad and wasteful in itself, but it has a secondary effect that is
> worse -- it degrades the feedback loop that makes the whole process
> work.
What about a patch robot, much like the LSM Robot,
that forces submitters into a minimum of discipline,
and helps Linus manage patches?
It could also be used to offer both Linus and submitters
a nice interface as to patch status.
Submitters could also replace patches with newer ones, etc.
Integration into Linus' environment (aka easy apply/unapply)
would be good, too.
All in all, it looks like a lot of the work needs to be done
in tight collaboration with Linus.
NB: once the basic infrastructure is setup, there are lots
of possibilities for extension:
assuming the bot is well interfaced to the web,
and has a mirror/whatever running on a server near Linus
with lots of CPU available,
it could be complemented with nice source analysis and/or
invalidation mechanisms, as to what patched or unpatched
parts of the kernel are likely to be outdated
by what change in the kernel design.
There could also be a version of the bot just for handling
source layout and/or fixes in comments/typos...
The bot could be moderated (or not), with some official maintainer
doing grunt work, and semi-automatically filtering things to keep
abusers out.
## Faré | VN: Уng-Vû Bân | Join the TUNES project! http://www.tunes.org/ ##
## FR: François-René Rideau | TUNES is a Useful, Not Expedient System ##
## Reflection&Cybernethics | Project for a Free Reflective Computing System ##
An apple every eight hours will keep three doctors away.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/