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