Kurt Jansson schrieb:
"Linux, wie auch eine Vielzahl anderer Projekte,
sind fast
ausschließlich öffentlich entwickelt worden. Bedingt durch die große
Anzahl der Entwickler, die nicht selten einen kompletten Zugriff auf die
Quellen der Applikation haben, ergeben sich daraus allerdings auch
Probleme. Die vorteilhafte öffentliche Entwicklung könnte allerdings,
wie es SCO zu suggerieren versucht, auch Nachteile haben: Ungeprüfter
Quellcode, sei es rechtlicher oder sicherheitsrelevanter Natur, kann
unbemerkt in das System einfließen und zu späteren Problemen führen.
Durch ein gezieltes Management kann allerdings auch dieses Risiko auf
ein Minimum reduziert werden."
http://www.pro-linux.de/news/2004/6841.html
Ich bin mir nicht sicher, ob die pro-linux-Leute die Intention und das
Verfahren, das Linus einführen will, wirklich verstanden haben. Es geht
nämlich noch nichtmal darum, den Patch und seine Auswirkungen zu prüfen,
sondern nur darum, festzuhalten, von wo nach wo das Ding gemailt wurde,
bevor er in irgendeinem Kernel-Tree auftaucht. Jeder setzt einfach
seinen Friedrich Wilhelm darunter... Mit Prüfung hat das nur sehr
mittelbar was zu tun.
Natürlich wird die Kernel-Entwicklung anders gemanaged
als ein Wiki,
aber einem "subsystem maintainer" entsprächen in unserem Sifter-Projekt
im Prinzip ein paar handverlesene Reviewer. Aber klar, wer verliest und
nach welchen Kriterien, das sind die immer noch offenen Fragen.
Das Wiki-Prinzip impliziert leider, dass wir nur mehr oder weniger
planlos die Artikel in Wiki gegenlesen können, weil wir aus
verständlichen Gründen keine wirklichen "Subsystem-Maintainer" haben,
sondern nur Leute, denen ein bestimmter Themenbereich am Herzen liegt.
Und von denen zu verlangen, dass sie in jedem Fall mit
schlafwandlerischer Sicherheit Sinn von Unsinn unterscheiden und vor
allem jede Ungenauigkeit und alle Fehler erkennen, ist meiner Meinung
nach zu hoch gegriffen. Aber bevor wir es nicht ausprobiert haben,
möchte ich einen Review-Prozess gleich welcher Art auch nicht totreden...
Alwin