zum Thema: ich finde das sollte eher der Bugtracker irgendwie benutzerfreundlicher gestalltet/besser organisiert werden. mich, der sich eigentlich wenig mit dem Kernel ausseinandersetzt, schreckt bugzilla irgendwie ab. mit trac oder launchpad komm ich besser zurecht...
Hmm, ich meine mich zu erinnern, dass sogar Bugzilla von den Kernelentwicklern als NoGo bezeichnet wurde. Linus Torvalds vertritt doch den Standpunkt, dass alles was sich nicht komfortabel über Mail regeln läßt, nicht in Frage kommt. Da bereits Bugzilla beim Webfrontend schwächelt, dürfte ein Wiki von der Zielgruppe Kernelentwickler nahezu ignoriert werden, oder hat sich an dieser (verständlichen) Einstellung etwas getan?
Ich frag mich, was haben die gegen Webseiten?? Was haben Email Proggis was gute Webfrontends nicht haben?? das is ne ernst gemeinte frage, ich hab das mit den mailinglisten noch immer nicht ganz durchblickt.
Eine Mail kommt rein und wird einem Bug zugeordnet. Dies geschieht im Idealfall bereits automatisch durch entsprechende Tags, die das Bugtrackingsystem setzt. Danach wird einfach hin- und hergeantwortet bis das Thema durch ist. Will man noch Entwicklerkollegen oder Betatester einbeziehen, kommen sie als CC in die Empfängerliste und alle bleiben immer fein auf dem aktuellen Stand. Dazu hat man schön alle Mails lokal vorliegen und kann nach Herzenslust darin operieren.
Webasierende Systeme verliert man dagegen schonmal aus dem Augenmerk und wenn einer der Beteiligten eine Änderung verschläft, führt das zu Verzögerungen. Außerdem sind die relevanten Informationen leicht über mehrere Webseiten verstreut, womöglich noch mit unterschiedlichen Frontends und man bekommt kaum einen Gesamtüberblick. Ein Wiki ist dagegen sicherlich die Hölle, man muss sich die Informationen aus einem Medium zusammensuchen, das überhaupt nicht fürs Bugtracking gedacht ist und daran ändern auch Zusammenfassungen an die Mailingliste nicht viel, dann kramt man eben in einer riesigen Mail herum.
Habe ich was vergessen oder falsch interpretiert? Macht mich schlau, ich würde gern von einem Praktiker hören, wo beispielsweise das Webinterface von Bugzilla und Co schwächeln.
Man übersieht, dass selbst Bugzilla alle neuen Posts per Mail rumschickt. So kann man sehr leicht auf dem laufenden bleiben. Ich sehe die stärke von Bugzilla v.a. in der Nachverfolgbarkeit von Fehlern.
>Ich frag mich, was haben die gegen Webseiten?? Was haben Email Proggis was gute Webfrontends nicht haben??
Ich mag mich täuschen, aber viele alte Unix/Linux Haudegen, und zu denen gehören viele der Kernelentwickler, sind unterbewusst gegen alles was irgendwie mit grafischer Benutzeroberfläche und rumklicken zusammenhängt, und dazu gehören auch Weboberflächen. Und komme jetzt keiner mit lynx:)
Ich z. B. benutze X fast nur zum surfen mit Firefox und ansonsten finde ich X praktisch weil ich da so viele xterms aufmachen kann in denen ich Konsolenprogramme laufen lasse. Ich habe es irgendwie bis heute nicht gelernt eine GUI effektiv zu bedienen und komme mit Konsolenprogrammen meist viel besser zurecht.
Das ist halt der alte Glaubenskrieg zwischen CLI und GUI Benutzern.
Mails werden Stapelweise genau dann gelesen/beantwortet wenn man Zeit hat - egal wo. Sobald man wieder Netz hat, gehen die dann automatisch raus in die Welt. Und nen Mailclient kann man auch viel eleganter und effizienter benutzen, grade wenn man hunderte Mails zu bearbeiten hat. Man muss auch nicht immer nach jeder Aktion nen paar (Milli-)Sekunden warten (je nach Leitungsqualität), sondern der "interaktive" Teil ist quasi in Echtzeit. Wie schnell oder langsam die Mails ankommen oder rausgehen, interessiert mich dann nicht mehr.
Und um in einem Web-basierten Frontend immer auf dem neuesten Stand zu sein, muss ich entweder regelmässig vorbeigucken, nen Feed dazu abbonnieren oder eben doch wieder per Mail informieren lassen. Macht mans gleich per Mail, hat man keinen solchen Medienbruch.
Was natürlich nicht heisst, ein duales System hätte Nachteile - grade bei nicht regelmässiger Nutzung ist ein Webfrontend natürlich viel einfacher zu bedienen.
Genau das macht Bugzilla ja, nur halt nicht gerade mit modernen Methoden. Hier ist sicher mal ein bischen Arbeit fällig, um das wieder attraktiv zu bekommen.
mag ja sein, daß das gegenwärtige Bugtrackersystem etwas abschreckend auf DAUs wie mich wirkt - ich hab mich vor 5 Monaten trotzdem durchgerungen, mein Ärgernis mit meiner seit Kernel 2.6.13 nicht mehr funktionierenden PCMCIA Karte nach bestem Wissen und Gewissen dort kund zu tun (Bug 7706) - Ergebnis bis heute: Null Da frag ich mich doch: hängts wirklich am Bugtrackersystem? Oder sind die Kernelentwickler ganz einfach überlastet und kommen nicht nach mit der Bearbeitung der eingereichten Bugs?
Bugs bleiben aus diversen Gründen manchmal lange liegen. Wenn's dir so pressiert, versuch es doch mit einer Email an die Mailingliste oder direkt an den Maintainer der Komponente.
Bugtracking-Systeme haben durchaus enorme Vorteile. Als User kann man sie wesentlich leichter durchsuchen als in Mailinglisten und somit vielleicht schon die Lösung für sein Problem finden ohne den Maintainer damit zu nerven.
Weiterhin hat man als Entwickler eine super Übersicht darüber was noch zu erledigen ist, man kann Verwandtschaftsbeziehungen und Abhängigkeiten zwischen Unterschiedlichen Aufgaben/Bugs definieren und das alles auch als jemand der solche Systeme noch nie zuvor genutzt hat. Für ein 2 Semester langes Projekt für unsere Uni haben wir "Mantis" erfolgreich einsetzen können. Das Projekt ist nocht recht jung und hat enige wenige Macken aber dafür is es in PHP/MySQL geschrieben und somit auf üblichen Webservern leichter einzurichten als Bugzilla. Ich kann solche Tools jedem Entwickler nur wärmstens empfehlen. Nach ein wenig Einarbeitungszeit alles easy. Wie gesagt muss man dazu natürlich auch den Webserver erreichen können, d.h. offline geht nichts.
Aber selbst das könnte man beheben durch Client Software, die sich mit ner Datenbank synchronisiert. Man antwortet auf ein Problem und mit der nächsten Verbindung zum Netz wirds dann hochgeschickt. Bleibt die Nutzung einer GUI aber das ist dann wirklich nur noch Glaubensfrage und nicht mehr in jedem Falle zu rechtfertigen.
Also ich schwöre auf TRAC. Wer mit Bugtracking (und evtl. parallel mit Versionskontrolle) anfängt dem kann ich nur zu TRAC raten. Der Vorteil neben dem üblichen Buggetracke ist ein eingebautes WIKI und ein sehr komfortables Interface zu Subversion. Mit quasi Nullaufwand hat damit SVN-Commits mit Bugs und Wiki-Einträgen so verknüpft, dass sie komfortable absurfbar sind, wenn einen Informationsbedürfnisse plagen.
Muss sich jeder Entwickler seine Bugs selbst abholen, oder bekommt der Entwickler eine Mail mit der Bitte "Schau dir das einmal an"?
Ich glaube genau das ist es, was sich Linus wünschen würde: Ein System, dass möglichst zielgenau den zuständigen Personen eine Mail schickt. Denn eine ständige Berieselung mit Mails die einen nichts angehen führt zur Abstumpfung und diese Mails werden dann ignoriert (Mailingliste).
Und eine Holschuld, die jedes Wiki oder daraus generiertes Riesenmail bedeuten würde, würde sowieso ignoriert werden. Kein Programmierer geht gerne Bugs jagen, wenn er das nächste tolle Feature im Kopf hat.
Wenn TRAC sowas kann, solltest du es Linus vorschlagen, vielleicht greift er es ja auf.
Warte, ich helf Dir auf die Sprünge: Sie hatte wissen wollen, ob die Kernel-Entwickler evtl überlastet sind und es vielleicht zu Unrecht auf die Technik abwälzen.
Ich habe mir gestern Zeit genommen, Dein Bug-Posting (ganz) zu lesen und ich fürchte, Du hast wenig verwertbare Informationen hinterlassen, mit denen die Kernel-Maintainer den Fehler, der mit Deiner Hardware auftritt, beheben oder wenigstens erstmal identifizieren könnten. Da der Bug aber andersrum auch nicht als "nicht reproduzierbar" gekennzeichnet ist, muss man tatsächlich anzweifeln, ob sich schon jemand (außer jetzt grad mir - das hilft leider nicht viel) die Zeit genommen hat, ihn mal durchzulesen. Das Problem mit Deinem Posting ist, dass es dort *so* nicht hingehört. Dir ist da nichts vorzuwerfen, schließlich hat Dich ja der Kernel selbst aufgefordert, Dich da zu melden aber im Grunde gehört ein Bug, der (vom Posting ausgegangen) nur mit einem SuSE-Kernel (der ist alles andere als vanilla) bestätigt, auf genau einer Maschine aufgetreten ist, auf den SuSE Bugtracker. Wenn man ihn dort klar reproduzieren und als Fehler in einem Kernel-Subsystem ausmachen kann, gehört er dann (von Fachpersonal - alles andere ist leider recht wertlos) bei den Kernel-Entwicklern selber gemeldet. Man darf von freien Entwicklern einfach nicht verlangen, dass sie Informationen hinterherlaufen. Genausowenig darf man aber von Usern verlangen, sich für jedes Problem die passende Bildung zuzulegen und eben da kommen die Distributoren ins Spiel. Sie agieren als Vermittler zwischen Entwicklern und Benutzern der Software. Ich würde es also eher bei SuSE versuchen, als mich selber auf die Kernel-Mailinglist zu setzen. Viel Glück bei der Lösung deines Problems.
zum Thema: ich finde das sollte eher der Bugtracker irgendwie benutzerfreundlicher gestalltet/besser organisiert werden.
mich, der sich eigentlich wenig mit dem Kernel ausseinandersetzt, schreckt bugzilla irgendwie ab.
mit trac oder launchpad komm ich besser zurecht...
Linus "liebt" bugzilla
Da bereits Bugzilla beim Webfrontend schwächelt, dürfte ein Wiki von der Zielgruppe Kernelentwickler nahezu ignoriert werden, oder hat sich an dieser (verständlichen) Einstellung etwas getan?
das is ne ernst gemeinte frage, ich hab das mit den mailinglisten noch immer nicht ganz durchblickt.
Eine Mail kommt rein und wird einem Bug zugeordnet. Dies geschieht im Idealfall bereits automatisch durch entsprechende Tags, die das Bugtrackingsystem setzt. Danach wird einfach hin- und hergeantwortet bis das Thema durch ist. Will man noch Entwicklerkollegen oder Betatester einbeziehen, kommen sie als CC in die Empfängerliste und alle bleiben immer fein auf dem aktuellen Stand. Dazu hat man schön alle Mails lokal vorliegen und kann nach Herzenslust darin operieren.
Webasierende Systeme verliert man dagegen schonmal aus dem Augenmerk und wenn einer der Beteiligten eine Änderung verschläft, führt das zu Verzögerungen. Außerdem sind die relevanten Informationen leicht über mehrere Webseiten verstreut, womöglich noch mit unterschiedlichen Frontends und man bekommt kaum einen Gesamtüberblick. Ein Wiki ist dagegen sicherlich die Hölle, man muss sich die Informationen aus einem Medium zusammensuchen, das überhaupt nicht fürs Bugtracking gedacht ist und daran ändern auch Zusammenfassungen an die Mailingliste nicht viel, dann kramt man eben in einer riesigen Mail herum.
Habe ich was vergessen oder falsch interpretiert? Macht mich schlau, ich würde gern von einem Praktiker hören, wo beispielsweise das Webinterface von Bugzilla und Co schwächeln.
Ich mag mich täuschen, aber viele alte Unix/Linux Haudegen, und zu denen gehören viele der Kernelentwickler, sind unterbewusst gegen alles was irgendwie mit grafischer Benutzeroberfläche und rumklicken zusammenhängt, und dazu gehören auch Weboberflächen. Und komme jetzt keiner mit lynx:)
Ich z. B. benutze X fast nur zum surfen mit Firefox und ansonsten finde ich X praktisch weil ich da so viele xterms aufmachen kann in denen ich Konsolenprogramme laufen lasse. Ich habe es irgendwie bis heute nicht gelernt eine GUI effektiv zu bedienen und komme mit Konsolenprogrammen meist viel besser zurecht.
Das ist halt der alte Glaubenskrieg zwischen CLI und GUI Benutzern.
Mails werden Stapelweise genau dann gelesen/beantwortet wenn man Zeit hat - egal wo. Sobald man wieder Netz hat, gehen die dann automatisch raus in die Welt.
Und nen Mailclient kann man auch viel eleganter und effizienter benutzen, grade wenn man hunderte Mails zu bearbeiten hat. Man muss auch nicht immer nach jeder Aktion nen paar (Milli-)Sekunden warten (je nach Leitungsqualität), sondern der "interaktive" Teil ist quasi in Echtzeit. Wie schnell oder langsam die Mails ankommen oder rausgehen, interessiert mich dann nicht mehr.
Und um in einem Web-basierten Frontend immer auf dem neuesten Stand zu sein, muss ich entweder regelmässig vorbeigucken, nen Feed dazu abbonnieren oder eben doch wieder per Mail informieren lassen. Macht mans gleich per Mail, hat man keinen solchen Medienbruch.
Genau das macht Bugzilla ja, nur halt nicht gerade mit modernen Methoden. Hier ist sicher mal ein bischen Arbeit fällig, um das wieder attraktiv zu bekommen.
deshalb also die diskussion über einen mail basierenden bugtracker in der lkml..
Da frag ich mich doch: hängts wirklich am Bugtrackersystem? Oder sind die Kernelentwickler ganz einfach überlastet und kommen nicht nach mit der Bearbeitung der eingereichten Bugs?
Weiterhin hat man als Entwickler eine super Übersicht darüber was noch zu erledigen ist, man kann Verwandtschaftsbeziehungen und Abhängigkeiten zwischen Unterschiedlichen Aufgaben/Bugs definieren und das alles auch als jemand der solche Systeme noch nie zuvor genutzt hat. Für ein 2 Semester langes Projekt für unsere Uni haben wir "Mantis" erfolgreich einsetzen können. Das Projekt ist nocht recht jung und hat enige wenige Macken aber dafür is es in PHP/MySQL geschrieben und somit auf üblichen Webservern leichter einzurichten als Bugzilla.
Ich kann solche Tools jedem Entwickler nur wärmstens empfehlen. Nach ein wenig Einarbeitungszeit alles easy. Wie gesagt muss man dazu natürlich auch den Webserver erreichen können, d.h. offline geht nichts.
Aber selbst das könnte man beheben durch Client Software, die sich mit ner Datenbank synchronisiert. Man antwortet auf ein Problem und mit der nächsten Verbindung zum Netz wirds dann hochgeschickt. Bleibt die Nutzung einer GUI aber das ist dann wirklich nur noch Glaubensfrage und nicht mehr in jedem Falle zu rechtfertigen.
Ich glaube genau das ist es, was sich Linus wünschen würde: Ein System, dass möglichst zielgenau den zuständigen Personen eine Mail schickt. Denn eine ständige Berieselung mit Mails die einen nichts angehen führt zur Abstumpfung und diese Mails werden dann ignoriert (Mailingliste).
Und eine Holschuld, die jedes Wiki oder daraus generiertes Riesenmail bedeuten würde, würde sowieso ignoriert werden. Kein Programmierer geht gerne Bugs jagen, wenn er das nächste tolle Feature im Kopf hat.
Wenn TRAC sowas kann, solltest du es Linus vorschlagen, vielleicht greift er es ja auf.
Da der Bug aber andersrum auch nicht als "nicht reproduzierbar" gekennzeichnet ist, muss man tatsächlich anzweifeln, ob sich schon jemand (außer jetzt grad mir - das hilft leider nicht viel) die Zeit genommen hat, ihn mal durchzulesen.
Das Problem mit Deinem Posting ist, dass es dort *so* nicht hingehört.
Dir ist da nichts vorzuwerfen, schließlich hat Dich ja der Kernel selbst aufgefordert, Dich da zu melden
Wenn man ihn dort klar reproduzieren und als Fehler in einem Kernel-Subsystem ausmachen kann, gehört er dann (von Fachpersonal - alles andere ist leider recht wertlos) bei den Kernel-Entwicklern selber gemeldet.
Man darf von freien Entwicklern einfach nicht verlangen, dass sie Informationen hinterherlaufen.
Genausowenig darf man aber von Usern verlangen, sich für jedes Problem die passende Bildung zuzulegen und eben da kommen die Distributoren ins Spiel. Sie agieren als Vermittler zwischen Entwicklern und Benutzern der Software.
Ich würde es also eher bei SuSE versuchen, als mich selber auf die Kernel-Mailinglist zu setzen.
Viel Glück bei der Lösung deines Problems.