... ist halt Broken by Design ... Nie im Multiuser Umfeld getestet (Server $HOME vieler User)
Auf NFS Homes ist das Zeug komplett unbrauchbar und einfach nur Müll...
Nach einem KDE PPA Update (um endlich diese Bugs loszuwerden) hatte Das Home vieler user Größen jenseits von 200GB für jeden.
Der reinste interne DDOS auf die Server.
Einzige Abhilfe war $XDG_DATA_HOME und $XDG_CONFIG_HOME auf lokales /var/tmp/$USER umzuleiten. In /etc/X11/Xsessiond./ zu machen.
So schön und toll das KDE auch ist, den Schuß ins Knie mit AKONADI und NEPUMUK hätte man sich besser erspart.
Oder man hätte vielleicht auch mal die Critical Bugreports ernst nehmen sollen und die Fehler im Design beheben müssen. Das wäre ja sinnvolle Arbeit gewesen und ist unterblieben.
Lieber noch eine Versionsnummer mit nichtsagenden bunten Plamsoids rauf pushen als die grundlegenenden Probleme Lösen!
Also was bringt es Bugreports zuschreiben, die immer wieder sofort als "incomplete", "irrelevant" oder "nicht reproduceable" abgekanzelt werden?
Es tut mir Leid, dass du mit KDE Software schlechte Erfahrungen gemacht hast.
Nun aber ein paar Dinge, die du falsch verstanden hast und die dann doch sehr wichtig sind:
1.
Oder man hätte vielleicht auch mal die Critical Bugreports ernst nehmen sollen und die Fehler im Design beheben müssen.
Wer definiert critical bugs? Du als Nutzer oder die Entwickler? Leider ist ein Bug den du als Nutzer als kritisch empfindest nicht unbedingt für die Entwickler ein kritischer. Entwickler müssen andere Abwägungen treffen, die für Anwender nicht immer nachvollziehbar sind und entsprechend priorisieren. Lieber behebe ich einen kleinen Bug der Millionen von Nutzern betrifft als einen besonderen Spezialfall für eine Handvoll Nutzer abzudecken.
ich persönlich bin immer sehr verärgert wenn mir ein Anwender einen Bug als "kritisch" aufmacht. Dies wird sofort von mir geändert und meistens führt es dann auch dazu, dass der Bug wenn er wirklich unwichtig ist, erst mal ans Ende der Liste wandert. Je stärker der Nutzer schreit, desto weiter nach Hinten in der Liste. Mich störts nicht und dann arbeite ich doch lieber an was wo man danach ein "Thank you" vom Nutzer bekommt.
2.
Lieber noch eine Versionsnummer mit nichtsagenden bunten Plamsoids rauf pushen als die grundlegenenden Probleme Lösen!
Seufz, was soll man dazu sagen. Ist dir bewusst, dass die Schnittmenge der Akonadi Entwickler und derer die nichtssagende bunte Plasmoide entwickeln die leere Menge ist? Wie soll denn ein Desktop Shell Entwickler Probleme bei einem E-Mail Framework beheben?
3.
die immer wieder sofort als "incomplete", "irrelevant" oder "nicht reproduceable" abgekanzelt werden?
Niemand kanzelt bugreports ab. Wenn ein Bug nicht reproduzierbar ist, dann ist er eben nicht reproduzierbar. Einen Bug den ich nicht reproduzieren kann, kann ich leider auch nicht beheben und wird dann auf NEEDSINFO WAITINGFORINFO gesetzt. Ein Bugreport der incomplete ist, scheint wohl wichtige Informationen zu fehlen. Auch da kann ein Entwickler leider nichts machen. Wenn du einen Crash Report einsendest ohne Debugging Informationen, dann sieht man zwar das es abgeraucht ist aber leider nicht wo. Sowas endet halt als NEEDSINFO BACKTRACE.
Und nunja irrelevant als status gibt es nicht. Du meinst wohl RESOLVED INVALID. Und ja nicht jede Software muss deinen Anforderungen entsprechen. Sowas ist dann halt auch mal INVALID.
Übrigens morgen gibt es einen Bug Day für KDEPIM, vllt. möchtest du ja mithelfen um es besser zu machen. Dann verstehst du auch besser was einen guten Bugreport ausmacht
Wer definiert critical bugs? Du als Nutzer oder die Entwickler?
Da muss ich dem OP zustimmen, denn ich als Benutzer definiere was kritisch ist, nicht du der Entwickler. Wem nützt eine Software, die niemand benutzt?
Natürlich in einem freien Open Source Projekt steht es dir frei was du entwickelst. Aber wenn du willst dass deine Software Benutzer hat, dann solltest du die Beschwerden deiner Nutzer auch ernst nehmen.
Z.B. Chrome hat Tabs an der Seite entfernt (Side Tabs). Für mich ist es ein Must-Have-Feature, da sie es entfernt haben wohl weil sie annehmen dass dies kein wichtiges Feature ist, werde ich kein Chrome mehr benutzen.
ich persönlich bin immer sehr verärgert wenn mir ein Anwender einen Bug als "kritisch" aufmacht.
Weil es für diesen Benutzer ein kritischer Bug ist? Wenn du den nicht behebst, dann geht der Benutzer eben zu einem anderen Projekt und irgendwann hast du keine Benutzer mehr. Kann ja sein, dass es dir nichts ausmacht.
Da muss ich dem OP zustimmen, denn ich als Benutzer definiere was kritisch ist, nicht du der Entwickler.
Mir als Entwickler ist doch bewusst, dass es für den Benutzer kritisch ist. Sonst hätte er sich ja nicht die Mühe gemacht den Bug zu melden.
Die Einschätzung ob ein Bug nun kritisch ist oder nicht kann ein Benutzer gar nicht vornehmen. Dazu fehlt ihm nämlich das Verständnis der internals der Software und wieviele Nutzer es betrifft.
Weil es für diesen Benutzer ein kritischer Bug ist?
Nein weil er meint, dass sein Problem wichtiger ist als das anderer Nutzer. Ich behebe Bugs nach dem Prinzip was am wichtigsten für die meisten Nutzer ist, nicht nach wer am lautesten schreit.
Wenn du den nicht behebst, dann geht der Benutzer eben zu einem anderen Projekt und irgendwann hast du keine Benutzer mehr. Kann ja sein, dass es dir nichts ausmacht.
ich liebe ganz besonders die Drohungen von Nutzern, dass sie nach Windows wechseln, wenn man ihren Bug nicht behebt (ja sowas kommt vor). Muss ich ganz ehrlich sagen: ist mir sch*** egal. Reisende soll man nicht aufhalten.
Es gibt immer mehr Bugs zu beheben als verfügbare Zeit. Die Priorisierung was ich in meiner verfügbaren Zeit behebe, nehme ich selber vor. Wer das beeinflussen will, muss dann halt in den Geldbeutel greifen und eine Firma beauftragen.
Die Einschätzung ob ein Bug nun kritisch ist oder nicht kann ein Benutzer gar nicht vornehmen. Dazu fehlt ihm nämlich das Verständnis der internals der Software und wieviele Nutzer es betrifft.
Sehr richtig! Nehmmen wir z.B. folgenden Bug auf bugs.kde.org:
All sub folders in "Kmail folders" deleted after creating a new folder in "Kmail folders".
Dem Nutzer fehlt ganz einfach das Verständnis der internals der Software und wieviele Nutzer es betrifft. Was hat der Nutzer auch da rumzuspielen und neue Ordner anzulegen? Tausende Nutzer sind glücklich ohne neue Ordner!
es scheint wohl um Bug 299061 zu gehen. Ohne jetzt die Situation in irgendeine Richtung bewerten zu wollen, werde ich jetzt mal eine Analyse des Bug Reports vornehmen. Würde ein Bug in der Art gegen KWin aufgemacht, würden wir den Nutzer vermutlich erst mal nach forum.kde.org schicken um User Support zu bekommen, denn das ist was der Nutzer will und braucht.
Schauen wir uns den Bug mal an:
Bisher noch von keinem Entwickler betrachtet. Das ist schlecht, aber KMail 2 hat aktuell 692 offene Bugs.
Bug Report ist von einem Gentoo Nutzer. Eigene Erfahrung ist, dass Gentoo Nutzer meinen ihr System zu optimieren und kaputt konfigurieren. Es ist für einen Entwickler schwierig einzuschätzen wie die Software tatsächlich aussah - Distributionspakete sind da genauer
Bug ist für eine veraltete Version gemeldet. Urpsrünglich 4.7, geändert auf 4.8.1, zu einem Zeitpunkt wo 4.8.2 aktuell war
Bug ist sehr emotional, z.B. "*all*", "were deleted!!!", "it is important for me to get the old emails back!"
Nutzer braucht dringend User Support: "Please can you help me recover my email to the state it was in a few hours ago."
Nutzer bringt mehrere Probleme in den Report: "Also, I can no longer delete any email in my IMAP folder."
Der Bugreport hat ein großes Problem: Emotionalität
Es ist verständlich, dass der Nutzer aufgebracht ist, aber es hilft leider nicht bei der Problembehebung. Wenn ich mich richtig erinnere, hab ich einen der früheren KMail Maintainer über diese Situation sprechen hören, dass dies für Entwickler sehr schwierig ist und einen an den Rand von Depressionen bringen kann. Und das kann ich gut nachvollziehen.
Für einen Entwickler gibt es hier nichts zu machen. Der Nutzer wird niemals die Informationen bereitstellen um den Bug korrekt zu reproduzieren ("I don't want to break my email any more"), womit die Entwickler leider nichts machen können. Die Wahrscheinlichkeit, dass der Bug eskalieren würde, wenn ein Entwickler nüchtern antworten würde (und alles andere geht nicht), ist sehr hoch. Ich musste auch schon mehrmals die Community Working Group um Hilfe bitten in Bugreports.
Das Ergebnis ist nun, dass der Nutzer vermutlich noch mehr verärgert ist, dass ihm nicht geholfen wurde. Aber er hat dazu das falsche Medium gewählt.
Meine Wunschbehandlung von solchen Probleme wäre:
First level support nimmt den Fehler auf und hilft dem Nutzer die Daten wiederherzustellen - alles andere ist irrelevant
First level support leitet Problem an Second level support weiter. Dieser versucht das Problem mit Testdaten zu reproduzieren.
Second Level Support öffnet Bugreport mit allen relevanten Daten inklusive einem Testfall
Entwickler (Third Level Support) behebt den Fehler
Nun noch abschließend: war der Bug kritisch? Für den Nutzer sicherlich nicht, für ihn ist nur kritisch die Daten zurückzubekommen. Für die Entwickler? Kann ich nicht beurteilen, denn die Analyse des Bugs steht noch aus. Persönlich würde ich Datenverlust als kritisch einstufen, aber aus der Datenlage in dem Bugreport kann ich nicht schließen ob es tatsächlich Datenverlust gab.
Von Softwareversteher am Sa, 18. August 2012 um 22:14 #
Tja, wenn ich das so lese, frage ich mich ob es bei jedem Bug auch wirklich der Schuldige zu ermitteln ist. Habe ich eine überhitzte Komponente im Rechner kann der Benutzer nur sehen das die Software versagt hat. Ist er versiert genug konnte er es herausfinden. Aber dazu muss er auch fähig sein, einen Fehler einer Analytisch und reproduzierbar einzukreisen. Das können selbst wenige Fachleute so genau, das ein Softwareentwickler erahnen kann ob seine Software die alleinige Schuld trägt. Ich für mein Teil habe 40% Daten durch eigenverschulden verloren . Und 50% weil ich keine Redundanz oder Backups hatte . Und 10% war schuld weil die neue Version die alten Daten nicht akzeptierte. Also 90% ist man selber Schuld .
Ganz ehrlich: Bei 692 offenen Bugs verhält sich das eher nicht so. Es gibt bestimmt Software, die zu Deiner Darstellung passt, Kmail2 gehört aber nicht dazu. Bei Kmail2 fehlt zu oft einfach der deutliche Hinweis, um was für eine Softwarequalität es sich handelt: alpha, beta oder final. Ein Normalnutzer wird bei einem Emailprogramm niemals Alpha- oder Beta-Software anfassen, wenn er im vorhinein darüber informiert wird.
Ist Kmail2 momentan wirklich als Emailprogramm für Otto Normalnutzer geeignet? Das ist doch eigentlich die allerwichtigste Frage.
Von Softwareversteher am So, 19. August 2012 um 12:10 #
Dazu muss ich sagen, was hat Kmail2 für einen Anreiz,dass man es benutzen will? Ich nutze Thunderbird. Aauch sehe ich kein zwang bei anderer KDE Software, es gibt genug alternativen die auch ihre macken haben, aber Systemübergreifend nutzbar sind. Bei Mac oder Windows hat man mit Kmail mehr Probleme etwas zu übernehmen. Wenn man lang genug mit der Software unter Linux sich beschäftigt hat,als User mein ich. Merkt man halt das vielen Projekten die nötige Strucktur fehlt um wirklich "fertig" zu werden. Das ist leider bei Desktopanwendungen ganz extrem. So lange kein komerzieller Erfolg hinter den Entwicklungen steht, werden Softwareentwickler aufgeben. Selbst in der Politik gibt es keinen der lange genug durchhält, nur weil er die Welt verbessern will. Und wenn emotionale Bugreports oft genug kommen, stirbt die Lust am Entwickeln. In einer Firma wird der Projektleiter einfach einen Ersatz suchen und weiter entwickeln lassen. Es darf beim Entwickler gar kein Bug direkt vom User mit emotionalem Inhalt ankommen, dazu müsste es leute geben, die die information Filtern und nur das wesentliche als Report weiterleiten. Die Entwickler unter Linux sind zu nah am "Kunden" und da gibt es zu weni rational denkende. Und wenn ein Bugreport nur ein Shitstorm auslösen soll, dann kann man ihn auch einfach löschen. Schade eigentlich, das gerade im Desktopbereich nur die Kommerziellen Firmen den Kunden vorgauckeln können, das alles funktioniert. Das einzige was da funktioniert, ist den Kunden klar zu machen , das er selber Schuld ist bzw. das es ja nur eine winziges Problem ist und nur bei ihm. Wer kennt die Zahl der Bugreports bei Windows oder Mac??? Richtig, nur die Verantwortlichen. Bei der offenen Komunikation unter Linux sehen alle User wie schnell sich um "ihr" Bug gekümmert wird. Und da sehen viele sich zu wichtig und wollen es sofort behoben haben.Und wenn Bugs zu lange offen bleiben und das publik wird/ist, ist das Bild einer nicht funktionierenden Softwareentwicklung perfekt.Und das lässt viele lieber bei Windows und Mac bleiben. Dort ist es nicht besser,aber wird vorgegaukelt das es besser ist.Und das perfekt.
Von Verzweifelter KMail User am So, 19. August 2012 um 15:49 #
Dazu muss ich sagen, was hat Kmail2 für einen Anreiz,dass man es benutzen will?
Groupware-Support! Was für so ziemlich jeden wichtig ist, der in einer größeren Firma arbeitet. Selbst zu Hause kann ich darauf nicht verzichten, denn da will ich ja auch Zugriff auf meine Firmenmails und Termine haben.
Schade eigentlich, das gerade im Desktopbereich nur die Kommerziellen Firmen den Kunden vorgauckeln können, das alles funktioniert. Das einzige was da funktioniert, ist den Kunden klar zu machen , das er selber Schuld ist bzw. das es ja nur eine winziges Problem ist und nur bei ihm.
Sorry, das ist mit Verlaub großer Stuss den du da erzählst. Der Grund warum kommerzielle Software meist stabiler ist, nennt sich TESTEN. Ein großer Teil der OpenSource Projekte hat wenige oder keinerlei Unit-Tests vorzuweisen. Von Sanity-, Integration- oder Systemtests wollen wir gar nicht erst anfangen. Da wird nix groß getestet, sondern einfach nur zusammengeschnürt und veröffentlicht. Wenn man Glück hat gibt es vorher wenigstens noch ne Beta-Phase.
Die OpenSource Projekte, die zumindest umfangreiche Unit-Tests vorweisen können, die laufen auch stabil. Davon gibt es einige, doch in der Gesamtheit gehen sie unter. Fakt ist, dass unterm Strich sehr viele Open Source Entwickler lieber neue Features entwickeln, anstatt den vorhanden Code zu stabilisieren. Klar, Unit Tests sind langweiliger zu entwickeln als neue Features, wer will es ihnen da verdenken. Trotzdem zeigt das, dass offenbar wenig Interesse an Stabilität besteht.
Und das lässt viele lieber bei Windows und Mac bleiben. Dort ist es nicht besser,aber wird vorgegaukelt das es besser ist.
Auch das halte ich für ausgemachten Stuss. Das kannst du ganz einfach selber testen: Arbeite mal 3 Monate mit Outlook und dann 3 Monate mit Kontact. Nach 3 Monaten vergleichen wir dann mal die Buglisten von den Bugs, die dir in der Zeit aufgefallen sind. Ich arbeite täglich sowohl mit Outlook als auch mit Kontact. Bei Outlook fällt mir aus dem Stegreif kein einziger Bug ein, bei Kontact hingegen kann ich eine ganze Latte auflisten.
Das gleiche gilt für beliebige andere Komponenten.
Von Softwareversteher am So, 19. August 2012 um 16:04 #
Wenn deine Erfahrungen sich nur auf deine genannten Programme beschränkt ist alles Stuss was du kommentierst. Und wenn du mal Windows Software die teuer war gekauft hast und gegen eine Support-Wand rennst, dann kannst du mitreden.
Wenn deine Erfahrungen sich nur auf deine genannten Programme beschränkt ist alles Stuss was du kommentierst. Und wenn du mal Windows Software die teuer war gekauft hast und gegen eine Support-Wand rennst, dann kannst du mitreden.
Wie wär's mal mit ein paar Beispielen anstatt hier gross rumzutönen? Welche Anwendungen machen denn ach so viele Probleme unter Windows?
Die Stabilität der Standardanwendungen ist auf jeden Fall um Welten besser als unter Linux.
wir konnten schon ein paar Mal einem Nutzer den Tipp geben, dass sein RAM dann wohl doch einen Schaden hat oder dass die Festplatte defekt ist. Kommt sogar vergleichsweise oft vor.
> Muss ich ganz ehrlich sagen: ist mir sch*** egal. Reisende soll man nicht aufhalten.
Na dann ist ja gut zu wissen, daß Open Source Projekte nicht von Geld- & Zeitspenden leben müssen.
> Es gibt immer mehr Bugs zu beheben als verfügbare Zeit. Die Priorisierung was ich in meiner verfügbaren Zeit behebe, nehme ich selber vor.
Du bist nicht der einzige Entwickler eines Projekts, daher steht es dir nicht zu, die Statustags für die jeweiligen Bugs einzustufen und dann Bugs ganz hinten auf die Liste zu setzen, die andere Entwickler gerne beheben würden, wenn sie davon Kenntnis erhalten würden.
Du bist nicht der einzige Entwickler eines Projekts, daher steht es dir nicht zu, die Statustags für die jeweiligen Bugs einzustufen und dann Bugs ganz hinten auf die Liste zu setzen, die andere Entwickler gerne beheben würden, wenn sie davon Kenntnis erhalten würden.
Bei KWin arbeiten genau zwei Entwickler mit den Bugreports und einer davon ist der Maintainer. Ich denke schon, dass es zu den Aufgaben des Maintainers gehört die Priorität korrekt zu setzen. Im Endeffekt entscheidet nämlich der Maintainer ob ein Patch aufgenommen wird oder nicht.
Muss ich ganz ehrlich sagen: ist mir sch*** egal. Reisende soll man nicht aufhalten. Es gibt immer mehr Bugs zu beheben als verfügbare Zeit. Die Priorisierung was ich in meiner verfügbaren Zeit behebe, nehme ich selber vor. Wer das beeinflussen will, muss dann halt in den Geldbeutel greifen und eine Firma beauftragen.
Das ist doch mal eine Ansage mit der man was anfangen kann!
Warum steht das so übrigens nicht auf kde.org? Dann wüsste wenigstens jeder Bescheid?
"ich liebe ganz besonders die Drohungen von Nutzern, dass sie nach Windows wechseln, wenn man ihren Bug nicht behebt (ja sowas kommt vor). Muss ich ganz ehrlich sagen: ist mir sch*** egal. Reisende soll man nicht aufhalten."
Die haben Windows sowieso noch installiert und sind mit ihren Dual-Boot-Maschinen in Wirklichkeit nie wirklich gewechselt. Das ist Euer Zielpublikum.
Da könnte ja jeder Benutzter alle seine Bugs als kritisch einstufen. Wie wichtig ein Bug ist muss von einem Entwickler beurteilt werden. Eventuell ist der Fehler nur auf dem System des Benutzers und tritt sonst überhaupt nicht auf.
> Wer definiert critical bugs? Du als Nutzer oder die Entwickler?
Natürlich der Nutzer.
Der Entwickler besitzt keine ausreichende Distanz zu seinem Projekt und ist daher in seinem Urteilsvermögen innerlich befangen, daher kann nur der Nutzer eine objektive und neutrale Bewertung zu der Schwere des Bugs abgeben.
Im kommerziellen Umfeld ist das auch der Fall, da werden kritische Bugs nämlich schnell vom Nutzer abgestraft.
> ich persönlich bin immer sehr verärgert wenn mir ein Anwender einen Bug als "kritisch" aufmacht. Dies wird sofort von mir geändert und meistens führt es dann auch dazu, dass der Bug wenn er wirklich unwichtig ist, erst mal ans Ende der Liste wandert.
Wenn das so ist, dann können WIR User uns das schreiben von Bug Reports ja in Zukunft sparen.
> Je stärker der Nutzer schreit, desto weiter nach Hinten in der Liste.
Siehste, genau das meine ich mit innerliche Befangenheit. Kritikunfähigkeit kommt auch dazu.
Da wundert es mich nicht, daß die schlimmsten Bugs, die natürlich völlig zu Recht von den Usern als Critical eingestuft wurden, über Jahre nicht behoben wurden.
> Niemand kanzelt bugreports ab.
Du hast es gerade eben zugegeben, daß du als Entwickler genau das machst.
ach das mit dem kritisch und am lautesten Schreien kann man ganz anschaulich erklären.
Ich lebe in Baden-Württemberg und bei uns im Ländle wird da so ein kleines Bahnhofsprojekt gemacht. Ich selbst lebe im Badischen bin also nicht direkt betroffen und habe auch nur mitbekommen was man so aus den Medien hörte und dergleichen.
Auf jeden Fall gab es letztes Jahr dann einen Volksentscheid zu dem Bahnhof. Ich hatte damit gerechnet nach all den Demonstrationen und dergleichen die selbst im entfernten Baden zu spüren waren, dass der Bahnhof abgelehnt wird oder dass das Quorum nicht erreicht wird.
Stattdessen wurde das Quorum erreicht und eine Mehrheit selbst im betroffenen Stuttgart hat dafür gestimmt.
Nicht immer sind die, die am lautesten schreien auch in der Mehrheit. Deshalb lasse ich mich in meiner Wahl welche Bugs ich bearbeite nicht vom laut schreien beeinflussen, sondern analysiere ganz objektiv den Bugreport.
Ach ja und dann ist da noch so ein kleines Problem namens Motivation. Natürlich bin ich nicht motiviert einen Bug zu bearbeiten, bei dem die Entwickler beleidigt werden oder elendig lang herumdiskutiert wird.
Das ganze hat überhaupt nichts mit Befangenheit oder Kritikunfähigkeit zu tun. Zu sagen, dass ein Bug nicht so wichtig ist, wie der Nutzer meint, bedeutet nicht, dass man nicht in der Lage ist Kritik anzunehmen. Genaugenommen ist der Nutzer nicht kritikfähig, denn er kann nicht das große und ganze erkennen (Bug betrifft nur ihn im Vergleich zu anderem Bug der tausende von Nutzern betrifft).
Ach Martin, ich kann Dich nur für Deine Geduld bewundern, die Du bei solchen Kommentaren an den Tag legst. Wer ernsthaft kommerzielle Software und Bug Reports in den Mund nimmt, der ist per se imho schon nicht ernst zu nehmen. Und dass man sich nicht von irgend jemanden vorschreiben lässt, was man in seiner Freizeit zu tun hat, sollte eigentlich auch selbstverständlich sein. Wenn es danach ginge würde ich dem Kommentator vorschreiben, dass er das Posten hier unterlassen soll - ihm fehlt ja offensichtlich die Distanz zu seinen Kommentaren
@All: Leute denkt doch mal erst nach, bevor ihr solchen Unsinn verzapft! Wie kann man ernsthaft annehmen, dass man als Benutzer über Dinge an einer OS Software bestimmen kann? Ich kann Vorschläge machen oder daran mitarbeiten oder einen Fork erstellen - den Entwicklern kann ich doch keine Befehle erteilen! Mann mann mann... habt ihr so ein Anspruchsdenken auch in eurem übrigen Leben?
> Wer ernsthaft kommerzielle Software und Bug Reports in den Mund nimmt, der ist per se imho schon nicht ernst zu nehmen.
Nicht jeder spielt nur Computerspiele, daher wäre es sinnvoll wenn du mal aus deiner Welt herausbrichst und dir professionelle Software z.B. für Supercomputer oder der Anlagenindustrie anschaust, dann wirst du auch (hoffentlich) erkennen, wo dein Fehler in deiner Argumentation liegt.
Wir reden hier aber nicht von Spezialsoftware o.ä. sondern von Desktop Software. Kann ich bei MS einen Bug Report für MS Office einreichen? Und diesen dann ggf. noch als kritisch einstufen? Oder bei Apple, wenn mein iDings spinnt? Werden die reagieren, wenn ich damit "drohe" keine Apple-Produkte mehr zu kaufen?
Aber ich gehe dennoch auch gerne auf Deine These ein, dass das im B2B-Bereich anders abläuft. Denn selbst bei B2B-Software stuft nicht der Supportnehmer die Wichtigkeit eines Fehlers ein, sondern darüber entscheidet ein Kompetenzträger der jeweiligen Fachabteilung des Software Anbieters. Zumindest habe ich das in der Berufswelt bisher nicht anders erlebt - aber ich lasse mich da gerne belehren. Du kannst mir gerne ein Beispiel nennen, wo das so wie von Dir postuliert der Fall wäre!
Also muss nicht ich meine Argumentation überdenken, sondern Du nicht mit Haarspalterei daher kommen.
Von Softwareversteher am So, 19. August 2012 um 14:08 #
Man was war das früher schön, als niemand Software als Gott gegeben wahrnahm. Es gibt viel mehr Menschen die Software kaufen und mit den Fehlern leben als Menschen die Meckern und drohen und kein Cent gegeben haben. Ich finde es immer lustig, wenn Bugs in Macsoftware nach Updates nur von vereinzelten in Foren angeprangert werden, aber das Zeug doch gekauft wird. Vielleicht sollten OS Entwickler Geld fürs angemeckert werden bekommen. Dann hätten die in kurzer Zeit mehr Geld als M$ un Aplle zusammen. Es müsste wirklich mal festgehalten werden, wieviel Zeit in einem Projekt zur Entwicklung und wieviel zu Fehlerbehebung verbraucht werden. Und jeder Bug sollte durch ein Spenden oder Bezahlsystem in seiner Wertigkeit steigen. Einfach bei jedem Bug eine Spendemöglichkeit einrichten und sehen wem es etwas Wert ist zur Behebung bei zu tragen. Wenn ich nicht Programmieren kann um es selber zu beheben, dann Zahle ich um genau den Bug interessanter für Programmierer zu machen. Die dann Ihr Geld damit verdienen können.Dazu muss nur sicher sein, das das Geld nicht in ein Bugtopf kommt, sondern das gezahlte genau dem Bug hilft wofür es gezahlt wurde. Ich denke, das so viel geziehlter ein wirklicher Bug behoben wird und wenn ich sehe das niemand für den Bug bezahlt, dann kann er auch nicht so wichtig sein. Selbst wenn jeder nur 50 Cent Zahlt, hängt es nur noch an der Zahl der Betroffenen, um viel Geld zusammen zu bekommen.
Das würde nur dazu führen, dass keine Bugs mehr reportet würden. Langfristig gesehen, könnten die Entwickler dann Ihre Software für sich alleine benutzen.
Wenn ein Projekt einen Bug aus irgendwelchen Gründen nicht fixen kann oder will, dann schreibt man nach ein paar Wochen eben "WONTFIX" hin und schließt das Ganze. Zumindest weiß der Nutzer dann, woran er ist.
Und jeder Bug sollte durch ein Spenden oder Bezahlsystem in seiner Wertigkeit steigen. Einfach bei jedem Bug eine Spendemöglichkeit einrichten und sehen wem es etwas Wert ist zur Behebung bei zu tragen
Deine sicher nett gemeinte Idee hat leider einen Fehler in der Umsetzung.
Wenn man so ne Open Source Seite für das Fixen von Bugs erstellen würde, so wie z.B. bei Frage_einen_Anwalt.de, wo dann jeder user einen Bug melden und nen Preis ausschreiben kann, dann werden viele Entwickler sich auf den gleichen Bug stürzen und da ein Bug nicht gleich, so wie ein Anwaltsschreiben fertig ist, werden viele Entwickler im privaten Kämmerlein ihre Zeit am gleichen Bug verschwenden und die Arbeit somit doppelt und dreifach erledigen und nur einer, in der Regel der schnellste, seinen möglicherweise dahingerotzen Bugfix online stellen, während die anderen nicht nur lehr ausgehen, sondern auch ihre Zeit verschwendet haben. Denn wenn jeder am gleichen Problem arbeitet, hilft das niemand und zu allem Übel kommt dann noch hinzu, daß höchstwahrscheinlich der am schnellsten fertige Bugfix in die Software aufgenommen wird und nicht der qualitativ eleganteste Bugfix.
So ein System kann also nur nach Auftragsarbeit funktionieren, bei dem dann ein Bugs einem bestimmten Entwickler der sich dafür meldet zugewiesen wird und der dann genug Zeit bekommt in aller Ruhe das Problem alleine zu lösen. Solange steht dann das Geld auf halde. Damit sich aber ein Entwickler nicht alle Bugs für sich alleine reserviert oder gar den Bugfix auf die lange Bank schiebt, so daß der Bug über Monate ungelöst bleibt, währen hier unter Umständen entweder eine Frist in der der Bug zu lösen ist notwendig, was auch nicht optimal ist, da dadurch der Bugfix in Verzug gerät, wenn dann 5 inkompetente Entwickler der Reihe nach daran werkeln, oder man führt Vertragsstrafen ein, so wie es bei Auftragsarbeiten üblich ist, aber dann wird man auch weder Entwickler haben die sich darauf einlassen wollen.
Im großen und ganzen wäre das größte Problem von diesem Konzept aber, daß die klassischen Entwickler, die neue Features in die Software einbauen oder die Software zu einem besseren Grunddesign komplett umbauen und damit in der Regel leer ausgehen, sich verarscht fühlen müssen.
Und da es schon bezahlte Entwickler z.B. bei Debian gab, was zu erheblichem Neid und Streitigkeiten führte, ist klar, daß so ein Konzept bei OS Software nicht wirklich funktionieren kann, bzw. der Open Source Software eher schadet.
die Idee ist gut und auch nicht neu, nur leider würde sie auch nicht funktionieren.
Als erstes und größtes Problem sehe ich, dass Anwender zu den Schlüssen kommen würden, dass die Entwickler absichtlich Bugs einbauen um sie danach beheben zu können. Und ganz ehrlich würde ich das für denkbar halten, falls Entwickler davon leben wollen können.
Ein anderes Problem ist, dass bei gut funktionierender Entwicklungsmodelle mehrere Entwickler an einem Bugfix beteiligt sein sollten. Wie ist der Reviewer zu beurteilen und der Maintainer, der es absegnet.
Dann ist die Frage wie damit umgegangen wird, wenn der Bugfix schlechte Qualität hat oder sogar Regressions verursacht? Muss der Entwickler das dann beheben oder soll sich die Community darum kümmern?
Ein weiteres schwerwiegendes Problem sind die Gehaltsgefälle. Das was für einen indischen Entwickler viel Geld ist, dafür würde ein deutscher Entwickler nicht mal die Tastatur berühren - ein ernsthaftes Problem auch bei GSoC.
Ich denke, dass solch ein Modell nicht funktionieren kann, da es das Potential hat eine Community zu zerstören. Es führt zu einer zwei Klassen Gesellschaft von deren die Geld mit der Software verdienen und derer die es freiwillig machen.
Wir reden hier aber nicht von Spezialsoftware o.ä. sondern von Desktop Software.
Auch da findest du qualitativ hochwertigen Code.
Von Software nach Maß bis zu Mathematika und NI Multisim findest du dort überall kommerzielle Software mit qualitativ hochwertigem Code und das ist alles Desktop Software.
Kann ich bei MS einen Bug Report für MS Office einreichen?
Als Firma hat man mit MS in der Regel einen Supportvertrag und da kann man das durchaus weiterreichen.
Denn selbst bei B2B-Software stuft nicht der Supportnehmer die Wichtigkeit eines Fehlers ein, sondern darüber entscheidet ein Kompetenzträger der jeweiligen Fachabteilung des Software Anbieters.
Wenn deine Firma groß genug und dein Supportvertrag finanziell bedeutend genug ist, dann wird die Softwarefirma sogar unwichtige Features schnellstmöglich einbauen, wenn du es forderst.
Es gibt auch Firmen, die dir Supportverträge für OpenSource Software anbieten. Was hier anscheinend immer wieder vergessen wird, ist dass es bei OpenSource darum geht, dass der Quellcode offen ist und nicht darum, dass die Produkte kostenlos sind.
Von Open Source Software das zu erwarten im Support Bereich was kommerzielle Anbieter leisten ist nun ja naiv. Aber Open Source macht es möglich, dass es Firmen gibt, die kommerziellen Support anbieten und auch noch darum konkurrieren können anstatt dass du eine einzige Firma hast, die Preise diktieren.
Im Umfeld des KDE Umfelds kenne ich mehrere Firmen, die dir auch Fehler in KDE Software beheben. Ich selbst biete das kommerziell auch an (wobei ich es nicht bewerbe und es nicht gerade viel einbringt).
Also wer will, kann seinen kommerziellen Support bekommen und dann sieht das genauso aus wie bei normaler unfreier Software.
"Im Umfeld des KDE Umfelds kenne ich mehrere Firmen, die dir auch Fehler in KDE Software beheben. "
Als Privatnutzer lohnt sich das im Hinblick auf Kmail2 bestimmt nicht, da es hierfür zur Zeit andere, bugfreiere Emailsoftwareangebote gibt. Falls ich Kmail2 jemals benutzt und solche Probleme, wie sie hier anscheinend augetaucht sind, damit gehabt hätte, dann wäre mir nur die Option geblieben, möglichst viele Emails zu "retten" und eine andere Software zu benutzen. Gnome2-Evolution funktioniert ganz gut, für Privatnutzer reicht Thunderbird ganz bestimmt meist aus, für KDE-Fans bieten der OBS genauso wie open SUSE 12.1 Main noch KMail1 an.
Und Firmen sollten vor einer Umstellung auf Kmail2 entsprechende Tests gemacht haben. Von daher glaube ich kaum, dass hier überhaupt irgendwelche "Schäden" aufgetreten sind.
Verbiege doch nicht alles in Deinem Sinne! Es ging um die Tatsache, dass man als 0815 User bei kommerzieller Massenware idR. eben keinen Bug direkt melden und schon gar nicht diesen priorisieren kann. Das war der Knackpunkt. Von Qualität war da gar nicht die Rede.
Und auch beim letzten Punkt stimmst DU mir ja zu: Ich kann einen Bug als Großkunde sicher melden und monieren, aber ich kann ihn nicht *direkt* priorisieren. Indirekt mag das über meinen Supportvertrag und dessen Lukrativität für die Anbieterfirma natürlich eine große Rolle spielen, direkt beeinflussen kann ich es nicht. Und nun zeige mir doch mal den Unterschied zu einem OS Projekt auf? Neben monetären Anreizen - wie es Martin ja schon aufzeigte - kann man da den Entwickler eben eher durch Stichhaltigkeit und Nutzen seines Reports motivieren. Wo ist hier also noch ein Problem? Unterm Strich hast Du hier sogar *mehr* Möglichkeiten!
Jedem vernüftigem Menschen sollte es völlig klar sein, daß die Entwickler nicht zwei Dinge gleichzeitig tun können. Entweder Akonadi/Nepumuk/Kmail Bugreports lesen, oder aufregende neue Plugins für Mars- und Venuskarten oder Mondfinsternisse entwickeln.
Von C++ Entwickler am Sa, 18. August 2012 um 23:30 #
Stimmt, denn die Akonadi Entwickler können nur in C++ Programmieren, während die KStars/Marble Benutzer nur Bildchen malen könenn.
Wer nicht in C++ programmieren kann, der sollte vielleicht besser gar nicht am KDE Projekt mitarbeiten. Im kommerziellen Umfeld kann ich jedenfalls jeden guten C++ Programmierer an JEDEN C++ Code heranlassen. Vielleicht braucht er dann etwas einarbeitungszeit, aber den Code wird er verstehen und dann ist es auch völlig egal, ob das Programm des Codes Akademika oder Sternchen heißt.
Fast alle KDE Software ist in C++ geschrieben. Neuerdings kommt im GUI Bereich auch QtQuick hinzu - da war übrigens KMail einer der ersten Anwendungsfälle. Marble und KStars sind auch beide in C++ geschrieben
Ich frage mich daher was deine Aussage soll. Ich als Entwickler eines in C++ geschriebenen Fenstermanagers kann nicht an dem in C++ geschriebenen E-Mail Frameworks arbeiten, da mir schlicht die Kompetenz dazu fehlt. Genauso haben halt E-Mail Framework Entwickler keine Ahnung von Fenstermanagement (das könnte ich nun mit Quellen beweisen).
Von C++ Entwickler am So, 19. August 2012 um 01:12 #
> Ich als Entwickler eines in C++ geschriebenen Fenstermanagers kann nicht an dem in C++ geschriebenen E-Mail Frameworks arbeiten, da mir schlicht die Kompetenz dazu fehlt.
Dann bist du unflexibel.
Also ich kann, ich arbeite mich in den zusätzlichen Stoff, sofern vorhanden, einfach ein und gut ist.
Zumal eigentlich jeder Informatiker ein Grundgerüst in Sachen E-Mails und der dazu entsprechenden RFC haben sollte, der Rest ist trivial. Insbesondere wenn es nur darum geht Bugs zu beheben und nicht neue Features einzubauen.
Ja nee ist klar. Wenn Du Herzprobleme hast, kannst Du ja auch zu einem Zahnarzt gehen, der ist ja auch Mediziner. Was solls, kann er sich doch bei Deiner Bypass-OP erst einmal einarbeiten...
Die Sprache ist doch nicht das Problem, sondern die Problem Domäne - wer das nicht verstanden hat ist eben kein guter Informatiker! Natürlich kann man sich in diese einarbeiten, aber das verlangt eben Zeit und Motivation. Und wenn man für etwas nicht bezahlt wird, dann ist ersteres meist knapp und letzteres rein intrinsisch. Insofern ist die Annahme, dass KDE Entwickler einfach mal so universell Bugs fixen ziemlich naiv und weltfremd.
Von C++ Entwickler am So, 19. August 2012 um 02:40 #
Wenn du nen Unfall hast, dann operiert dich ein Arzt des Krankenhaus am Herz, der Niere oder sonst wo.
Im übrigen hinkt dein Vergleich, denn wie ich bereits sagte, gehört Rechnernetze zum Grundstudium eines Informatikstudiums. Das ist also keine Schwerpunktwahl wie bei einem Arzt der seinen Schwerpunkt auf Zahnarzt setzt.
> Insofern ist die Annahme, dass KDE Entwickler einfach mal so universell Bugs fixen ziemlich naiv und weltfremd.
Nö, denn wie ich bereits sagte, müssen keine neuen Features eingeführt werden, sondern Bugs gefixt werden. Das ist also C++ Code, bei dem der Großteil des Codes schon existiert und bei den Grundbausteinen von der Schleife bis zur IF Bedingung oder typischen bekannten Algorithmen unterschiedet sich kein Code.
Das was du sagst, ist in etwa so, als könnte ein Kind, welches nur Lego Burgen baut, keine Schiffe aus Lego Bausteinen bauen.
Die Software besteht aus Millionen Code-Zeilen. Da kann man sich nicht einfach so einarbeiten. Jedes Projekt hat eine andere Struktur und andere Schwierigkeiten. Das sollte man in Grundstudium gelernt haben.
Falls du meinst, dass es so einfach ist behebe den Bug doch selbst!
Von C++ Entwickler am So, 19. August 2012 um 06:14 #
Offenbar ist nicht jeder talentiert, das sehe ich an deiner Antwort.
Der erste Schritt ist ein Debugger, damit findet man schon die Stelle, wo das Programm aussteigt, sofern der Bug reproduzierbar ist. Und OO Code ist eine große Hilfe, wenn er denn gut designed wurde, so daß ein guter Progger sich hier eigentlich gut zurecht finden sollte.
So manche Cracker haben es da schwerer, denn denen steht kein Original C++ Code zur Verfügung.
Mit einem Debugger findest du crashes, super, das ist aber nur ein mögliches Problem. Um den Crash zu finden brauch ich keinen Debugger, da reicht auch der Crash Report der Users. Und was hat man wenn man die Stelle gefunden hat? Richtig die Stelle Code an der es abraucht. Das hilft bei der Problemlösung ziemlich wenig wenn man die Materie nicht kennt - und das ist genau was hier ausgesagt wurde.
Ich gib dir jetzt mal einen Crash Fix als Beispiel. Ein Crash bei dem wir etwa zwei Jahre lang nicht wussten wie man ihn auslösen kann. Wir wussten die Zeile wo es abraucht, aber nicht warum. Zuletzt nach einigen Code-Änderung hätte dir ein Debugger nicht mal mehr den Crash gezeigt, da es ein vom Timing abhängiges Problem war - upps Debugger verändern ja das Verhalten von Anwendungen. Ohne tiefes Verständnis des internen Aufbaus der Anwendung wäre dieser Crash nicht behebbar gewesen und den Ansatz den ich gewählt hatte, war ein Schuss ins Blaue basierend auf Annahmen, die ich ableiten konnte aus meinem Wissen über den internen Aufbau der Anwendung und das Verhalten im fraglichen Zeitraum.
Ich wage sehr zu bezweifeln, dass ein nicht Domain Experte dieses Problem hätte identifizieren können (den Weg das Problem zu reproduzieren hatte ich auch selbst aus Wissen über die Anwendung abgeleitet), noch dass er auf den Lösungsansatz gekommen wäre, noch dass er ihn hätte umsetzen können. Immerhin wir als Experten der Anwendungen haben Monate gebraucht einen Weg zu finden den Crash zu reproduzieren.
Von C++ Entwickler am So, 19. August 2012 um 16:34 #
Immerhin wir als Experten der Anwendungen haben Monate gebraucht einen Weg zu finden den Crash zu reproduzieren.
Erkennst du hier deinen Denkfehler nicht?
Du schreibst "Experten der Anwendung". Eben, ein Experte der Anwendung ist nicht zwangsläufig auch ein Experte der RFCs, Gesetzesvorschriften und Normen in diesem Bereich, etwas, was du ja zu Beginn hier angeführt hast, daß man das brauchen würde, um den C++ Code zu fixen. Siehe deine Worte:
Ich als Entwickler eines in C++ geschriebenen Fenstermanagers kann nicht an dem in C++ geschriebenen E-Mail Frameworks arbeiten, da mir schlicht die Kompetenz dazu fehlt.
Es ist also ein Code wie jeder andere, der eine bestimmte Anwendung bildet. Für die Anwendung arbeitet man sich kurz ein, bei gegebenen UML Diagramm sollte das recht effizient möglich sein, ansonsten nimmt man eben den Code und dann kann ein guter C++ Entwickler auch das Problem fixen.
Denn das Problem hat nichts mit RFCs, Gesetzevorschriften oder Normen oder speziellen Softwarebereichen zu tun, sondern es ist schlichtweg nur C++ Code.
Die Grundlagen die einem Programm zugrunde liegen sind überall gleich, die Spezialisierung fängt erst da an, wo du Experten in umzusetzenden Gestezesvorschriften, RFCs oder Normen benötigst und das braucht man nicht zum Bug fixen, sondern für nur neue Features.
nun ok du hast vollkommen Recht ich bin ein absoluter Idiot. Ich verstehe gar nicht warum ich mehr als ein Jahr gebraucht habe bis ich KWin intern verstanden habe und ich verstehe noch viel weniger warum ich nach all den Jahren und sogar mittlerweile als Maintainer immer noch Bereiche gibt von denen ich keine Ahnung habe.
Ich hätte mich wohl besser mal kurz in den Quellcode einarbeiten müssen oder ich bin einfach ein zu schlechter Programmierer.
Nun zu der RFC Geschichte. Klar wenn ich bei KWin Bugs behebe brauche ich dafür keine RFC, trotzdem hab ich hier einen kompletten Stapel mit ausgedruckten Spezifikationen, die ich immer mal wieder zur Rate ziehe. Muss manchmal schon sein, wenn sich die GTK Anwendungen anders verhalten als die Qt Anwendungen. Da muss man halt schon mal die Specs lesen. Aber klar braucht man ja nicht, der C++ Code ist natürlich völlig ausreichend.
Schon mal gesehen, dass ein RFC buggy ist oder von Servern falsch umgesetzt wird? Die Software, die ich während meiner Masterthesis geschrieben habe, ist am Ende daran gescheitert, dass die GoogleMail Server einen RFC falsch bzw. gar nicht implementiert hatten. Aber klar das Lesen des Quellcodes hätte das Problem sicherlich behoben.
"Die Software, die ich während meiner Masterthesis geschrieben habe, ist am Ende daran gescheitert, dass die GoogleMail Server einen RFC falsch bzw. gar nicht implementiert hatten."
Und jetzt? Musst Du die "Diplomarbeit" noch einmal schreiben?
Es ist schon lustig, was Du als "C++ Entwickler" so für wage Thesen vertrittst. Ich habe in meinem Informatikstudium niemals ein RFC in einer VL durchgekaut oder mich sonst wie näher mit Mail-Protokollen befasst. War das also dann kein "richtiges" Informatikstudium? Das solltest Du meiner Uni mal schreiben
Zu dem Finden von Bugs hatte Martin ja schon einiges geschrieben. Ich will aber noch mal herausstellen, dass *speziell* das Fixen von Bugs tiefgreifende Kenntnis des Codes und Erfahrung in der Domäne voraussetzt. Das Coden von neuen Funktionalitäten ist da fast einfacher, sofern Du Dich auf vorhandenes stützen kannst. Das "nur" Bug fixen ist also kein "nur", sondern geht mit der von mir dargestellten Kausalkette (Coden in der Freizeit, intrinsische Motivation) einher. Und daher bleibst Deine Ansicht weltfremd.
Im übrigen kannst Du meine These gerne ignorieren - in der Realität indes zeigt es sich doch, dass der Status quo genau so ist, wie ich ihn ableite. Und den kannst Du nicht wegdiskutieren...
Zudem verunglimpfst Du meine Beispiele. Bei der Technologie "Lego" ist es eben künstlich anzunehmen, dass es dort spezielle Domänen gäbe, bei denen jemand keine universelle Kompetenz haben kann. Im Bereich "Technic" ist es aber in der Tat so, dass Du sicherlich Probleme hast, gewisse Funktionalität zu implementieren, wenn Du damit noch keine Erfahrung hast. Denn auch bei Lego gibt es gewisse "Design Pattern" und zudem musst Du von der Existenz von Teilen wissen, wenn von diesen die Machbarkeit abhängt - das geht ohne Erfahrung einfach nicht. Davon abgesehen ist das aber auch kein Bug fixen, denn so stark kann man bei Lego wohl kaum Tätigkeiten abstrahieren
Mein Arzt Gleichnis ist einfach gut - Du kannst aber auch gerne einen Elektriker nehmen. Der eine kann ein Haus verkabeln, der andere mein TV Gerät oder meine Waschmaschine reparieren. Es ist schon weltfremd anzunehmen, dass beide so mir nichts dir nichts austauschbar wären. Fachkompetenz erwirbt man sich durch Zeit, die man in einer Domäne tätig ist; das kann man nicht mit Pauschalaussagen a la "C++ ist das wichtige, wer das kann, kann alles" wegfegen.
Deine Aussagen zu Bugs und Deiner Unfähigkeit Bildnisse zu interpretieren lassen mich aber auch daran zweifeln, ob Du wirklich Ahnung von der Materie des Softwareentwicklung hast. Einen coolen Nickname kann sich hier ja jeder zulegen
Von C++ Entwickler am So, 19. August 2012 um 16:50 #
Ich habe in meinem Informatikstudium niemals ein RFC in einer VL durchgekaut oder mich sonst wie näher mit Mail-Protokollen befasst.
Tja, ein Studium umfaßt nunmal auch Eigenarbeit zu Hause.
Ich habe mir die RFCs zum HTTP und FTP Protokoll, sowie zu denen eines E-Mail Programms alle durchgelesen, unser Prof hat uns das sogar auch empfohlen und stell dir vor, in meiner Studierzeit habe ich auch die RFCs zu VoIP durchgelesen.
Wenn du das nicht gemacht hast, dann ist das schlecht, weil es aussagt, daß du während deinem Studium dich nicht besonders tief in die Materie eingearbeitet hast, sondern gerademal das allernötigste gemacht hast nur um Scheine zu bestehen.
dass *speziell* das Fixen von Bugs tiefgreifende Kenntnis des Codes
Siehe mein erstes Posting, man arbeitet sich kurz ein und verschafft sich einen Überblick, die meisten Bugs kann man damit erschlagen.
und Erfahrung in der Domäne voraussetzt.
Nö, das eben nicht, Siehe oben.
Wenn ich an einem Programm für z.B. Elektroniklayout einen Bug fixen möchte, dann muß ich weder die VDE Vorschriften noch die Pin-Abstände von diversen ICs wissen, möglicherweise brauche ich nichtmal ein tieferes Verständnis in der Elektrotechnik, denn dieses Wissen brauche ich nur dann, wenn ich neue Features in die Software einarbeiten will und nicht zum Fixen eines Bugs.
Das fixen von Bugs ist in 99 % der Fälle nur das Fixen von Programmierfehlern, also der Programmierung an sich und alles was damit zu tun hat. Im prinzip also die Grundlagen, die Grundbausteine und Algorithmen.
Das Coden von neuen Funktionalitäten ist da fast einfacher, sofern Du Dich auf vorhandenes stützen kannst.
Ne, eben nicht. Wenn ich an einer Schaltungssimulation für Elektronik neue Features einbauen will, dann brauche ich in den meisten Fällen ein tieferes Verständnis in der Elektrotechnik.
Bei Programmen für die Medizin wird das nicht anders sein, was meinst denn du, warum es in der Informatik extra Studiengänge wie Wirtschafts-, Medizin- oder Bioinformatik gibt?
Das erschaffen von völlig neuen Features erfordert also wesentlich mehr Hintergrundwissen, als für das reine fixen von Bugs. Für das fixen von Bugs reicht reines Programmiererwissen.
Du kannst aber auch gerne einen Elektriker nehmen. Der eine kann ein Haus verkabeln, der andere mein TV Gerät oder meine Waschmaschine reparieren.
Offenbar kennst du den Unterschied zwischen einem Elektriker und einem Elektroniker nicht.
Deine Hausverkabelung ist Elektrik. Das TV Gerät ist reine Elektronik. Und die Waschmaschine wohl so ein Zwischending zwischen Elektronik und Mechatronic.
Das fixen von Bugs ist in 99 % der Fälle nur das Fixen von Programmierfehlern, also der Programmierung an sich und alles was damit zu tun hat. Im prinzip also die Grundlagen, die Grundbausteine und Algorithmen.
Glaubst du allen Ernstes, dass zum Beispiel die Probleme bei Akonadi oder Nepomuk (worüber dieser Thread ja ist) simple Programmierfehler sind? Ach wäre das schön wenn dem so wäre...
Glaubst du den Fehler den ich weiter oben beschrieb, war ein simpler Progammierfehler? Glaubst du allen Ernstes, dass man Fehler in Nepomuk beheben kann ohne Wissen von RDF? Oder Fehler in KWin ohne Wissen von Fenstermanagement und Compositing?
Wenn ja, dann bitte ich dich doch in die freie Software Entwicklung einzusteigen. Du scheinst ein Genie zu sein, wie ich es so noch nicht gesehen habe. Freue mich schon in Zukunft weniger Bugs zu haben
Und nun gehe ich erst mal einen Unit Test schreiben für einen Fehler den ich noch nicht ganz verstehe.
Tja, ein Studium umfaßt nunmal auch Eigenarbeit zu Hause.
Ich habe mir die RFCs zum HTTP und FTP Protokoll, sowie zu denen eines E-Mail Programms alle durchgelesen, unser Prof hat uns das sogar auch empfohlen und stell dir vor, in meiner Studierzeit habe ich auch die RFCs zu VoIP durchgelesen.
Wenn du das nicht gemacht hast, dann ist das schlecht, weil es aussagt, daß du während deinem Studium dich nicht besonders tief in die Materie eingearbeitet hast, sondern gerademal das allernötigste gemacht hast nur um Scheine zu bestehen.
LOL! Schon mal daran gedacht, dass es nicht jeden Informatiker nach solchen Dingen gelüstet? HTTP nehme ich gerne als gegeben hin, ebenso POP3 usw. Ich kenne natürlich einige Grundlagen, aber das *stumpfe* Durchlesen von RFCs bringt genauso viel wie das eines Lexikons - außer, man hat ein eidetisches Gedächtnis.
Hast Du Dich mal mit semantischen Technologien auseinander gesetzt? Ontologien, OWL, SPARQL? Es ließen sich sicherlich genügend Themenfelder finden, von denen Du keine oder wenig fundierte Ahnung hast - deswegen abzuleiten, dass jemand zu wenig Interesse an der Gesamtmaterie hat und nur das "nötigste" für seine Scheine getan hat, ist sagenhaft dümmlich! Als dermaßen vor Selbstwusstsein strotzendem Informatik-Gott , der gerne ex catedra redet und seine Meinung als Naturgesetz darstellt, hätte ich ein wenig mehr Intelligenz erwartet...
Ad "Elektroniker vs Elektriker": Du hast Recht, ich war da zu unpräzise. Offenbar ist der Oberbegriff der des Elektronikers - Elektriker ist da wohl eher Volksmund. Allerdings ändert das nichts an meinem Bild, denn offensichtlich bezeichnet man eben doch beide *Spezialisierungen* mit einem Begriff. Zudem bleibt das Ärzte Gleichnis immer noch so stehen, ohne dass Du es auch nur ansatzweise entkräften konntest (Wie auch!?! Es stimmt eben )
Deine Weltsicht auf Bugs ist dermaßen eingeschränkt, dass ich immer noch denke, dass Du eher noch ein Student bist, der nur kleinere und kürzere Projekte realisiert hast. Bugs umfassen so viel mehr als simple Programmierfehler! Und genau das sind einfach diejenigen, deren Ursache sich nur *schwer* aufspüren und ggf. auch beheben lässt. Wer das auf "Man muss nur C++ kennen" reduziert, ist einfach nicht ernst zu nehmen.
Und nein, neue Features können sehr viel einfacher sein, als einen Bug zu fixen. Oftmals sind es Kompositionen von vorhandenen Komponenten; was muss ich da für ein tiefgreifendes Verständnis für die Software im Kern haben? Ich habe mir auch schon mal kleine Erweiterungen für Gimp geschrieben - meinst Du ernsthaft, dass ich mir dafür Wissen um den Code von Gimp oder Grafikverarbeitung i.A. hätte aneignen müssen? Gleiches gilt für Scribus, dort sogar *direkt* im Code, den ich um eine Funktion in der Python-API erweitert habe. Dank Doku zur API muss man sich nur die Funktionen zusammenstellen, die man benötigt... alles viel trivialer, als einen Programmfehler auszumerzen.
Natürlich können neue Funktionen auch sehr schwierig zu implementieren sein! Aber im Gegensatz zu Bugs besteht hierbei die *Möglichkeit*, dass das einfach funktioniert.
Dieses Urteil fällst Du allein auf Basis der Anzahl der Bugmeldungen? Wieviele davon mehrfach Meldungen sind, sich auf alte KDE-Versionen beziehen, nur bestimmte Distributionen oder gar nur einzelne Benutzer betreffen - alles egal. Einfach draufhauen.
Das sich die KDE-Entwickler mit diesem Kindergarten überhaupt noch abgeben, verdient Respekt.
Also ich fasse das nochmal zusammen. Deiner Meinung nach ist es also am wichtigsten, dass die Entwickler auf die Bugs antworten statt Bugs zu beheben. Fair enough.
Ich finde das aber eine schlechte Idee. Ich weiß, dass den Entwicklern die zeit fehlt sich um die Reports zu kümmern und dass sie viele Bugs beheben kannst du in jedem Changelog von einer neuen sc Version lesen.
Du könntest übrigens mithelfen den Entwicklern das leben einfacher zu machen und mithelfen die Bugs zu organisieren. Aus eigener Erfahrung kann ich sagen, dass dass schon einiges an Arbeit ist und wenn der Bugtracker nicht aufgeräumt ist, dann kann man ihn zum beheben von Bugs garnicht verwenden.
Also los mithelfen und hier nicht die Entwickler Beschuldigen. Es bringt wenig auf die auch noch drauf zu hauen, die deine Bus beheben.
Du sprachst doch vorher von kritischen Bugs, dann ist das diese Liste: https://bugs.kde.org/buglist.cgi?bug_severity=critical&query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=Akonadi&product=nepomuk
Das sind dann nur 14 und schließt auch nicht irgendwelche Feature Requests ein.
Meiner Erfahrung nach sagt die Anzahl aber nicht viel aus, wenn die Entwickler nicht den Bugtracker stark einsetzen. KDEPIM fehlen leider die Ressourcen um mit bugs.kde.org zu arbeiten.
... ist halt Broken by Design ...
Nie im Multiuser Umfeld getestet (Server $HOME vieler User)
Auf NFS Homes ist das Zeug komplett unbrauchbar und einfach nur Müll...
Nach einem KDE PPA Update (um endlich diese Bugs loszuwerden) hatte Das Home vieler user Größen jenseits von 200GB für jeden.
Der reinste interne DDOS auf die Server.
Einzige Abhilfe war $XDG_DATA_HOME und $XDG_CONFIG_HOME auf lokales /var/tmp/$USER umzuleiten. In /etc/X11/Xsessiond./ zu machen.
So schön und toll das KDE auch ist, den Schuß ins Knie mit AKONADI und NEPUMUK hätte man sich besser erspart.
Oder man hätte vielleicht auch mal die Critical Bugreports ernst nehmen sollen und die Fehler im Design beheben müssen. Das wäre ja sinnvolle Arbeit gewesen und ist unterblieben.
Lieber noch eine Versionsnummer mit nichtsagenden bunten Plamsoids rauf pushen als die grundlegenenden Probleme Lösen!
Also was bringt es Bugreports zuschreiben, die immer wieder sofort als "incomplete", "irrelevant" oder "nicht reproduceable" abgekanzelt werden?
Eben, Gar Nichts!
Es tut mir Leid, dass du mit KDE Software schlechte Erfahrungen gemacht hast.
Nun aber ein paar Dinge, die du falsch verstanden hast und die dann doch sehr wichtig sind:
1.
Wer definiert critical bugs? Du als Nutzer oder die Entwickler? Leider ist ein Bug den du als Nutzer als kritisch empfindest nicht unbedingt für die Entwickler ein kritischer. Entwickler müssen andere Abwägungen treffen, die für Anwender nicht immer nachvollziehbar sind und entsprechend priorisieren. Lieber behebe ich einen kleinen Bug der Millionen von Nutzern betrifft als einen besonderen Spezialfall für eine Handvoll Nutzer abzudecken.ich persönlich bin immer sehr verärgert wenn mir ein Anwender einen Bug als "kritisch" aufmacht. Dies wird sofort von mir geändert und meistens führt es dann auch dazu, dass der Bug wenn er wirklich unwichtig ist, erst mal ans Ende der Liste wandert. Je stärker der Nutzer schreit, desto weiter nach Hinten in der Liste. Mich störts nicht und dann arbeite ich doch lieber an was wo man danach ein "Thank you" vom Nutzer bekommt.
2.
Seufz, was soll man dazu sagen. Ist dir bewusst, dass die Schnittmenge der Akonadi Entwickler und derer die nichtssagende bunte Plasmoide entwickeln die leere Menge ist? Wie soll denn ein Desktop Shell Entwickler Probleme bei einem E-Mail Framework beheben?3.
Niemand kanzelt bugreports ab. Wenn ein Bug nicht reproduzierbar ist, dann ist er eben nicht reproduzierbar. Einen Bug den ich nicht reproduzieren kann, kann ich leider auch nicht beheben und wird dann auf NEEDSINFO WAITINGFORINFO gesetzt. Ein Bugreport der incomplete ist, scheint wohl wichtige Informationen zu fehlen. Auch da kann ein Entwickler leider nichts machen. Wenn du einen Crash Report einsendest ohne Debugging Informationen, dann sieht man zwar das es abgeraucht ist aber leider nicht wo. Sowas endet halt als NEEDSINFO BACKTRACE.Und nunja irrelevant als status gibt es nicht. Du meinst wohl RESOLVED INVALID. Und ja nicht jede Software muss deinen Anforderungen entsprechen. Sowas ist dann halt auch mal INVALID.
Übrigens morgen gibt es einen Bug Day für KDEPIM, vllt. möchtest du ja mithelfen um es besser zu machen. Dann verstehst du auch besser was einen guten Bugreport ausmacht
Da muss ich dem OP zustimmen, denn ich als Benutzer definiere was kritisch ist, nicht du der Entwickler. Wem nützt eine Software, die niemand benutzt?
Natürlich in einem freien Open Source Projekt steht es dir frei was du entwickelst. Aber wenn du willst dass deine Software Benutzer hat, dann solltest du die Beschwerden deiner Nutzer auch ernst nehmen.
Z.B. Chrome hat Tabs an der Seite entfernt (Side Tabs). Für mich ist es ein Must-Have-Feature, da sie es entfernt haben wohl weil sie annehmen dass dies kein wichtiges Feature ist, werde ich kein Chrome mehr benutzen.
Weil es für diesen Benutzer ein kritischer Bug ist? Wenn du den nicht behebst, dann geht der Benutzer eben zu einem anderen Projekt und irgendwann hast du keine Benutzer mehr. Kann ja sein, dass es dir nichts ausmacht.
Die Einschätzung ob ein Bug nun kritisch ist oder nicht kann ein Benutzer gar nicht vornehmen. Dazu fehlt ihm nämlich das Verständnis der internals der Software und wieviele Nutzer es betrifft.
Nein weil er meint, dass sein Problem wichtiger ist als das anderer Nutzer. Ich behebe Bugs nach dem Prinzip was am wichtigsten für die meisten Nutzer ist, nicht nach wer am lautesten schreit.ich liebe ganz besonders die Drohungen von Nutzern, dass sie nach Windows wechseln, wenn man ihren Bug nicht behebt (ja sowas kommt vor). Muss ich ganz ehrlich sagen: ist mir sch*** egal. Reisende soll man nicht aufhalten.Es gibt immer mehr Bugs zu beheben als verfügbare Zeit. Die Priorisierung was ich in meiner verfügbaren Zeit behebe, nehme ich selber vor. Wer das beeinflussen will, muss dann halt in den Geldbeutel greifen und eine Firma beauftragen.
Sehr richtig! Nehmmen wir z.B. folgenden Bug auf bugs.kde.org:
Dem Nutzer fehlt ganz einfach das Verständnis der internals der Software und wieviele Nutzer es betrifft. Was hat der Nutzer auch da rumzuspielen und neue Ordner anzulegen? Tausende Nutzer sind glücklich ohne neue Ordner!
es scheint wohl um Bug 299061 zu gehen. Ohne jetzt die Situation in irgendeine Richtung bewerten zu wollen, werde ich jetzt mal eine Analyse des Bug Reports vornehmen. Würde ein Bug in der Art gegen KWin aufgemacht, würden wir den Nutzer vermutlich erst mal nach forum.kde.org schicken um User Support zu bekommen, denn das ist was der Nutzer will und braucht.
Schauen wir uns den Bug mal an:
Der Bugreport hat ein großes Problem: Emotionalität
Es ist verständlich, dass der Nutzer aufgebracht ist, aber es hilft leider nicht bei der Problembehebung. Wenn ich mich richtig erinnere, hab ich einen der früheren KMail Maintainer über diese Situation sprechen hören, dass dies für Entwickler sehr schwierig ist und einen an den Rand von Depressionen bringen kann. Und das kann ich gut nachvollziehen.
Für einen Entwickler gibt es hier nichts zu machen. Der Nutzer wird niemals die Informationen bereitstellen um den Bug korrekt zu reproduzieren ("I don't want to break my email any more"), womit die Entwickler leider nichts machen können. Die Wahrscheinlichkeit, dass der Bug eskalieren würde, wenn ein Entwickler nüchtern antworten würde (und alles andere geht nicht), ist sehr hoch. Ich musste auch schon mehrmals die Community Working Group um Hilfe bitten in Bugreports.
Das Ergebnis ist nun, dass der Nutzer vermutlich noch mehr verärgert ist, dass ihm nicht geholfen wurde. Aber er hat dazu das falsche Medium gewählt.
Meine Wunschbehandlung von solchen Probleme wäre:
Nun noch abschließend: war der Bug kritisch? Für den Nutzer sicherlich nicht, für ihn ist nur kritisch die Daten zurückzubekommen. Für die Entwickler? Kann ich nicht beurteilen, denn die Analyse des Bugs steht noch aus. Persönlich würde ich Datenverlust als kritisch einstufen, aber aus der Datenlage in dem Bugreport kann ich nicht schließen ob es tatsächlich Datenverlust gab.
Tja, wenn ich das so lese, frage ich mich ob es bei jedem Bug auch wirklich der Schuldige zu ermitteln ist.
Habe ich eine überhitzte Komponente im Rechner kann der Benutzer nur sehen das die Software versagt hat. Ist er versiert genug konnte er es herausfinden. Aber dazu muss er auch fähig sein, einen Fehler einer Analytisch und reproduzierbar einzukreisen. Das können selbst wenige Fachleute so genau, das ein Softwareentwickler erahnen kann ob seine Software die alleinige Schuld trägt.
Ich für mein Teil habe 40% Daten durch eigenverschulden verloren . Und 50% weil ich keine Redundanz oder Backups hatte . Und 10% war schuld weil die neue Version die alten Daten nicht akzeptierte. Also 90% ist man selber Schuld .
Ganz ehrlich: Bei 692 offenen Bugs verhält sich das eher nicht so. Es gibt bestimmt Software, die zu Deiner Darstellung passt, Kmail2 gehört aber nicht dazu. Bei Kmail2 fehlt zu oft einfach der deutliche Hinweis, um was für eine Softwarequalität es sich handelt: alpha, beta oder final. Ein Normalnutzer wird bei einem Emailprogramm niemals Alpha- oder Beta-Software anfassen, wenn er im vorhinein darüber informiert wird.
Ist Kmail2 momentan wirklich als Emailprogramm für Otto Normalnutzer geeignet?
Das ist doch eigentlich die allerwichtigste Frage.
Dazu muss ich sagen, was hat Kmail2 für einen Anreiz,dass man es benutzen will? Ich nutze Thunderbird. Aauch sehe ich kein zwang bei anderer KDE Software, es gibt genug alternativen die auch ihre macken haben, aber Systemübergreifend nutzbar sind. Bei Mac oder Windows hat man mit Kmail mehr Probleme etwas zu übernehmen.
Wenn man lang genug mit der Software unter Linux sich beschäftigt hat,als User mein ich. Merkt man halt das vielen Projekten die nötige Strucktur fehlt um wirklich "fertig" zu werden. Das ist leider bei Desktopanwendungen ganz extrem.
So lange kein komerzieller Erfolg hinter den Entwicklungen steht, werden Softwareentwickler aufgeben. Selbst in der Politik gibt es keinen der lange genug durchhält, nur weil er die Welt verbessern will. Und wenn emotionale Bugreports oft genug kommen, stirbt die Lust am Entwickeln.
In einer Firma wird der Projektleiter einfach einen Ersatz suchen und weiter entwickeln lassen.
Es darf beim Entwickler gar kein Bug direkt vom User mit emotionalem Inhalt ankommen, dazu müsste es leute geben, die die information Filtern und nur das wesentliche als Report weiterleiten. Die Entwickler unter Linux sind zu nah am "Kunden" und da gibt es zu weni rational denkende.
Und wenn ein Bugreport nur ein Shitstorm auslösen soll, dann kann man ihn auch einfach löschen.
Schade eigentlich, das gerade im Desktopbereich nur die Kommerziellen Firmen den Kunden vorgauckeln können, das alles funktioniert. Das einzige was da funktioniert, ist den Kunden klar zu machen , das er selber Schuld ist bzw. das es ja nur eine winziges Problem ist und nur bei ihm.
Wer kennt die Zahl der Bugreports bei Windows oder Mac??? Richtig, nur die Verantwortlichen. Bei der offenen Komunikation unter Linux sehen alle User wie schnell sich um "ihr" Bug gekümmert wird. Und da sehen viele sich zu wichtig und wollen es sofort behoben haben.Und wenn Bugs zu lange offen bleiben und das publik wird/ist, ist das Bild einer nicht funktionierenden Softwareentwicklung perfekt.Und das lässt viele lieber bei Windows und Mac bleiben. Dort ist es nicht besser,aber wird vorgegaukelt das es besser ist.Und das perfekt.
Groupware-Support! Was für so ziemlich jeden wichtig ist, der in einer größeren Firma arbeitet. Selbst zu Hause kann ich darauf nicht verzichten, denn da will ich ja auch Zugriff auf meine Firmenmails und Termine haben.
Sorry, das ist mit Verlaub großer Stuss den du da erzählst. Der Grund warum kommerzielle Software meist stabiler ist, nennt sich TESTEN. Ein großer Teil der OpenSource Projekte hat wenige oder keinerlei Unit-Tests vorzuweisen. Von Sanity-, Integration- oder Systemtests wollen wir gar nicht erst anfangen. Da wird nix groß getestet, sondern einfach nur zusammengeschnürt und veröffentlicht. Wenn man Glück hat gibt es vorher wenigstens noch ne Beta-Phase.
Die OpenSource Projekte, die zumindest umfangreiche Unit-Tests vorweisen können, die laufen auch stabil. Davon gibt es einige, doch in der Gesamtheit gehen sie unter. Fakt ist, dass unterm Strich sehr viele Open Source Entwickler lieber neue Features entwickeln, anstatt den vorhanden Code zu stabilisieren. Klar, Unit Tests sind langweiliger zu entwickeln als neue Features, wer will es ihnen da verdenken. Trotzdem zeigt das, dass offenbar wenig Interesse an Stabilität besteht.
Auch das halte ich für ausgemachten Stuss. Das kannst du ganz einfach selber testen: Arbeite mal 3 Monate mit Outlook und dann 3 Monate mit Kontact. Nach 3 Monaten vergleichen wir dann mal die Buglisten von den Bugs, die dir in der Zeit aufgefallen sind. Ich arbeite täglich sowohl mit Outlook als auch mit Kontact. Bei Outlook fällt mir aus dem Stegreif kein einziger Bug ein, bei Kontact hingegen kann ich eine ganze Latte auflisten.
Das gleiche gilt für beliebige andere Komponenten.
Wenn deine Erfahrungen sich nur auf deine genannten Programme beschränkt ist alles Stuss was du kommentierst. Und wenn du mal Windows Software die teuer war gekauft hast und gegen eine Support-Wand rennst, dann kannst du mitreden.
Wie wär's mal mit ein paar Beispielen anstatt hier gross rumzutönen? Welche Anwendungen machen denn ach so viele Probleme unter Windows?
Die Stabilität der Standardanwendungen ist auf jeden Fall um Welten besser als unter Linux.
wir konnten schon ein paar Mal einem Nutzer den Tipp geben, dass sein RAM dann wohl doch einen Schaden hat oder dass die Festplatte defekt ist. Kommt sogar vergleichsweise oft vor.
Die Rechtfertigungen der Kontact/Kmail Entwickler (oder deren Unterstützer) werden immer lächerlicher.
Wie kommt's übrigens, dass zwischen Version 1.x und ca. 4.6 keine "Komponenten überhitzten"? Na?
> Muss ich ganz ehrlich sagen: ist mir sch*** egal. Reisende soll man nicht aufhalten.
Na dann ist ja gut zu wissen, daß Open Source Projekte nicht von Geld- & Zeitspenden leben müssen.
> Es gibt immer mehr Bugs zu beheben als verfügbare Zeit. Die Priorisierung was ich in meiner verfügbaren Zeit behebe, nehme ich selber vor.
Du bist nicht der einzige Entwickler eines Projekts, daher steht es dir nicht zu, die Statustags für die jeweiligen Bugs einzustufen und dann Bugs ganz hinten auf die Liste zu setzen, die andere Entwickler gerne beheben würden, wenn sie davon Kenntnis erhalten würden.
Das ist doch mal eine Ansage mit der man was anfangen kann!
Warum steht das so übrigens nicht auf kde.org? Dann wüsste wenigstens jeder Bescheid?
Der hat mir gefallen!
"ich liebe ganz besonders die Drohungen von Nutzern, dass sie nach Windows wechseln, wenn man ihren Bug nicht behebt (ja sowas kommt vor). Muss ich ganz ehrlich sagen: ist mir sch*** egal. Reisende soll man nicht aufhalten."
Die haben Windows sowieso noch installiert und sind mit ihren Dual-Boot-Maschinen in Wirklichkeit nie wirklich gewechselt.
Das ist Euer Zielpublikum.
Da könnte ja jeder Benutzter alle seine Bugs als kritisch einstufen. Wie wichtig ein Bug ist muss von einem Entwickler beurteilt werden. Eventuell ist der Fehler nur auf dem System des Benutzers und tritt sonst überhaupt nicht auf.
+1
"Es tut mir Leid, dass du mit KDE Software schlechte Erfahrungen gemacht hast."
Ups, Call-Center-Jargon.
> Wer definiert critical bugs? Du als Nutzer oder die Entwickler?
Natürlich der Nutzer.
Der Entwickler besitzt keine ausreichende Distanz zu seinem Projekt und ist daher in seinem Urteilsvermögen innerlich befangen,
daher kann nur der Nutzer eine objektive und neutrale Bewertung zu der Schwere des Bugs abgeben.
Im kommerziellen Umfeld ist das auch der Fall, da werden kritische Bugs nämlich schnell vom Nutzer abgestraft.
> ich persönlich bin immer sehr verärgert wenn mir ein Anwender einen Bug als "kritisch" aufmacht. Dies wird sofort von mir geändert und meistens führt es dann auch dazu, dass der Bug wenn er wirklich unwichtig ist, erst mal ans Ende der Liste wandert.
Wenn das so ist, dann können WIR User uns das schreiben von Bug Reports ja in Zukunft sparen.
> Je stärker der Nutzer schreit, desto weiter nach Hinten in der Liste.
Siehste, genau das meine ich mit innerliche Befangenheit.
Kritikunfähigkeit kommt auch dazu.
Da wundert es mich nicht, daß die schlimmsten Bugs, die natürlich völlig zu Recht von den Usern als Critical eingestuft wurden, über Jahre nicht behoben wurden.
> Niemand kanzelt bugreports ab.
Du hast es gerade eben zugegeben, daß du als Entwickler genau das machst.
ach das mit dem kritisch und am lautesten Schreien kann man ganz anschaulich erklären.
Ich lebe in Baden-Württemberg und bei uns im Ländle wird da so ein kleines Bahnhofsprojekt gemacht. Ich selbst lebe im Badischen bin also nicht direkt betroffen und habe auch nur mitbekommen was man so aus den Medien hörte und dergleichen.
Auf jeden Fall gab es letztes Jahr dann einen Volksentscheid zu dem Bahnhof. Ich hatte damit gerechnet nach all den Demonstrationen und dergleichen die selbst im entfernten Baden zu spüren waren, dass der Bahnhof abgelehnt wird oder dass das Quorum nicht erreicht wird.
Stattdessen wurde das Quorum erreicht und eine Mehrheit selbst im betroffenen Stuttgart hat dafür gestimmt.
Nicht immer sind die, die am lautesten schreien auch in der Mehrheit. Deshalb lasse ich mich in meiner Wahl welche Bugs ich bearbeite nicht vom laut schreien beeinflussen, sondern analysiere ganz objektiv den Bugreport.
Ach ja und dann ist da noch so ein kleines Problem namens Motivation. Natürlich bin ich nicht motiviert einen Bug zu bearbeiten, bei dem die Entwickler beleidigt werden oder elendig lang herumdiskutiert wird.
Das ganze hat überhaupt nichts mit Befangenheit oder Kritikunfähigkeit zu tun. Zu sagen, dass ein Bug nicht so wichtig ist, wie der Nutzer meint, bedeutet nicht, dass man nicht in der Lage ist Kritik anzunehmen. Genaugenommen ist der Nutzer nicht kritikfähig, denn er kann nicht das große und ganze erkennen (Bug betrifft nur ihn im Vergleich zu anderem Bug der tausende von Nutzern betrifft).
Ach Martin, ich kann Dich nur für Deine Geduld bewundern, die Du bei solchen Kommentaren an den Tag legst. Wer ernsthaft kommerzielle Software und Bug Reports in den Mund nimmt, der ist per se imho schon nicht ernst zu nehmen. Und dass man sich nicht von irgend jemanden vorschreiben lässt, was man in seiner Freizeit zu tun hat, sollte eigentlich auch selbstverständlich sein. Wenn es danach ginge würde ich dem Kommentator vorschreiben, dass er das Posten hier unterlassen soll - ihm fehlt ja offensichtlich die Distanz zu seinen Kommentaren
@All: Leute denkt doch mal erst nach, bevor ihr solchen Unsinn verzapft! Wie kann man ernsthaft annehmen, dass man als Benutzer über Dinge an einer OS Software bestimmen kann? Ich kann Vorschläge machen oder daran mitarbeiten oder einen Fork erstellen - den Entwicklern kann ich doch keine Befehle erteilen! Mann mann mann... habt ihr so ein Anspruchsdenken auch in eurem übrigen Leben?
> Wer ernsthaft kommerzielle Software und Bug Reports in den Mund nimmt, der ist per se imho schon nicht ernst zu nehmen.
Nicht jeder spielt nur Computerspiele, daher wäre es sinnvoll wenn du mal aus deiner Welt herausbrichst und dir professionelle Software z.B. für Supercomputer oder der Anlagenindustrie anschaust, dann wirst du auch (hoffentlich) erkennen, wo dein Fehler in deiner Argumentation liegt.
Wir reden hier aber nicht von Spezialsoftware o.ä. sondern von Desktop Software. Kann ich bei MS einen Bug Report für MS Office einreichen? Und diesen dann ggf. noch als kritisch einstufen? Oder bei Apple, wenn mein iDings spinnt? Werden die reagieren, wenn ich damit "drohe" keine Apple-Produkte mehr zu kaufen?
Aber ich gehe dennoch auch gerne auf Deine These ein, dass das im B2B-Bereich anders abläuft. Denn selbst bei B2B-Software stuft nicht der Supportnehmer die Wichtigkeit eines Fehlers ein, sondern darüber entscheidet ein Kompetenzträger der jeweiligen Fachabteilung des Software Anbieters. Zumindest habe ich das in der Berufswelt bisher nicht anders erlebt - aber ich lasse mich da gerne belehren. Du kannst mir gerne ein Beispiel nennen, wo das so wie von Dir postuliert der Fall wäre!
Also muss nicht ich meine Argumentation überdenken, sondern Du nicht mit Haarspalterei daher kommen.
Man was war das früher schön, als niemand Software als Gott gegeben wahrnahm. Es gibt viel mehr Menschen die Software kaufen und mit den Fehlern leben als Menschen die Meckern und drohen und kein Cent gegeben haben.
Ich finde es immer lustig, wenn Bugs in Macsoftware nach Updates nur von vereinzelten in Foren angeprangert werden, aber das Zeug doch gekauft wird. Vielleicht sollten OS Entwickler Geld fürs angemeckert werden bekommen. Dann hätten die in kurzer Zeit mehr Geld als M$ un Aplle zusammen.
Es müsste wirklich mal festgehalten werden, wieviel Zeit in einem Projekt zur Entwicklung und wieviel zu Fehlerbehebung verbraucht werden. Und jeder Bug sollte durch ein Spenden oder Bezahlsystem in seiner Wertigkeit steigen.
Einfach bei jedem Bug eine Spendemöglichkeit einrichten und sehen wem es etwas Wert ist zur Behebung bei zu tragen. Wenn ich nicht Programmieren kann um es selber zu beheben, dann Zahle ich um genau den Bug interessanter für Programmierer zu machen. Die dann Ihr Geld damit verdienen können.Dazu muss nur sicher sein, das das Geld nicht in ein Bugtopf kommt, sondern das gezahlte genau dem Bug hilft wofür es gezahlt wurde.
Ich denke, das so viel geziehlter ein wirklicher Bug behoben wird und wenn ich sehe das niemand für den Bug bezahlt, dann kann er auch nicht so wichtig sein.
Selbst wenn jeder nur 50 Cent Zahlt, hängt es nur noch an der Zahl der Betroffenen, um viel Geld zusammen zu bekommen.
Das würde nur dazu führen, dass keine Bugs mehr reportet würden. Langfristig gesehen, könnten die Entwickler dann Ihre Software für sich alleine benutzen.
Wenn ein Projekt einen Bug aus irgendwelchen Gründen nicht fixen kann oder will, dann schreibt man nach ein paar Wochen eben "WONTFIX" hin und schließt das Ganze. Zumindest weiß der Nutzer dann, woran er ist.
Deine sicher nett gemeinte Idee hat leider einen Fehler in der Umsetzung.
Wenn man so ne Open Source Seite für das Fixen von Bugs erstellen würde, so wie z.B. bei Frage_einen_Anwalt.de, wo dann jeder user einen Bug melden und nen Preis ausschreiben kann, dann werden viele Entwickler sich auf den gleichen Bug stürzen und da ein Bug nicht gleich, so wie ein Anwaltsschreiben fertig ist, werden viele Entwickler im privaten Kämmerlein ihre Zeit am gleichen Bug verschwenden und die Arbeit somit doppelt und dreifach erledigen und nur einer, in der Regel der schnellste, seinen möglicherweise dahingerotzen Bugfix online stellen, während die anderen nicht nur lehr ausgehen, sondern auch ihre Zeit verschwendet haben.
Denn wenn jeder am gleichen Problem arbeitet, hilft das niemand und zu allem Übel kommt dann noch hinzu, daß höchstwahrscheinlich der am schnellsten fertige Bugfix in die Software aufgenommen wird und nicht der qualitativ eleganteste Bugfix.
So ein System kann also nur nach Auftragsarbeit funktionieren, bei dem dann ein Bugs einem bestimmten Entwickler der sich dafür meldet zugewiesen wird und der dann genug Zeit bekommt in aller Ruhe das Problem alleine zu lösen.
Solange steht dann das Geld auf halde.
Damit sich aber ein Entwickler nicht alle Bugs für sich alleine reserviert oder gar den Bugfix auf die lange Bank schiebt, so daß der Bug über Monate ungelöst bleibt, währen hier unter Umständen entweder eine Frist in der der Bug zu lösen ist notwendig, was auch nicht optimal ist, da dadurch der Bugfix in Verzug gerät, wenn dann 5 inkompetente Entwickler der Reihe nach daran werkeln, oder man führt Vertragsstrafen ein, so wie es bei Auftragsarbeiten üblich ist, aber dann wird man auch weder Entwickler haben die sich darauf einlassen wollen.
Im großen und ganzen wäre das größte Problem von diesem Konzept aber, daß die klassischen Entwickler, die neue Features in die Software einbauen oder die Software zu einem besseren Grunddesign komplett umbauen und damit in der Regel leer ausgehen, sich verarscht fühlen müssen.
Und da es schon bezahlte Entwickler z.B. bei Debian gab, was zu erheblichem Neid und Streitigkeiten führte, ist klar, daß so ein Konzept bei OS Software nicht wirklich funktionieren kann, bzw. der Open Source Software eher schadet.
die Idee ist gut und auch nicht neu, nur leider würde sie auch nicht funktionieren.
Als erstes und größtes Problem sehe ich, dass Anwender zu den Schlüssen kommen würden, dass die Entwickler absichtlich Bugs einbauen um sie danach beheben zu können. Und ganz ehrlich würde ich das für denkbar halten, falls Entwickler davon leben wollen können.
Ein anderes Problem ist, dass bei gut funktionierender Entwicklungsmodelle mehrere Entwickler an einem Bugfix beteiligt sein sollten. Wie ist der Reviewer zu beurteilen und der Maintainer, der es absegnet.
Dann ist die Frage wie damit umgegangen wird, wenn der Bugfix schlechte Qualität hat oder sogar Regressions verursacht? Muss der Entwickler das dann beheben oder soll sich die Community darum kümmern?
Ein weiteres schwerwiegendes Problem sind die Gehaltsgefälle. Das was für einen indischen Entwickler viel Geld ist, dafür würde ein deutscher Entwickler nicht mal die Tastatur berühren - ein ernsthaftes Problem auch bei GSoC.
Ich denke, dass solch ein Modell nicht funktionieren kann, da es das Potential hat eine Community zu zerstören. Es führt zu einer zwei Klassen Gesellschaft von deren die Geld mit der Software verdienen und derer die es freiwillig machen.
Auch da findest du qualitativ hochwertigen Code.
Von Software nach Maß bis zu Mathematika und NI Multisim findest du dort überall kommerzielle Software mit qualitativ hochwertigem Code und das ist alles Desktop Software.
Als Firma hat man mit MS in der Regel einen Supportvertrag und da kann man das durchaus weiterreichen.
Wenn deine Firma groß genug und dein Supportvertrag finanziell bedeutend genug ist, dann wird die Softwarefirma sogar unwichtige Features schnellstmöglich einbauen, wenn du es forderst.
Es gibt auch Firmen, die dir Supportverträge für OpenSource Software anbieten. Was hier anscheinend immer wieder vergessen wird, ist dass es bei OpenSource darum geht, dass der Quellcode offen ist und nicht darum, dass die Produkte kostenlos sind.
Von Open Source Software das zu erwarten im Support Bereich was kommerzielle Anbieter leisten ist nun ja naiv. Aber Open Source macht es möglich, dass es Firmen gibt, die kommerziellen Support anbieten und auch noch darum konkurrieren können anstatt dass du eine einzige Firma hast, die Preise diktieren.
Im Umfeld des KDE Umfelds kenne ich mehrere Firmen, die dir auch Fehler in KDE Software beheben. Ich selbst biete das kommerziell auch an (wobei ich es nicht bewerbe und es nicht gerade viel einbringt).
Also wer will, kann seinen kommerziellen Support bekommen und dann sieht das genauso aus wie bei normaler unfreier Software.
"Im Umfeld des KDE Umfelds kenne ich mehrere Firmen, die dir auch Fehler in KDE Software beheben. "
Als Privatnutzer lohnt sich das im Hinblick auf Kmail2 bestimmt nicht, da es hierfür zur Zeit andere, bugfreiere Emailsoftwareangebote gibt.
Falls ich Kmail2 jemals benutzt und solche Probleme, wie sie hier anscheinend augetaucht sind, damit gehabt hätte, dann wäre mir nur die Option geblieben, möglichst viele Emails zu "retten" und eine andere Software zu benutzen. Gnome2-Evolution funktioniert ganz gut, für Privatnutzer reicht Thunderbird ganz bestimmt meist aus, für KDE-Fans bieten der OBS genauso wie open SUSE 12.1 Main noch KMail1 an.
Und Firmen sollten vor einer Umstellung auf Kmail2 entsprechende Tests gemacht haben. Von daher glaube ich kaum, dass hier überhaupt irgendwelche "Schäden" aufgetreten sind.
Verbiege doch nicht alles in Deinem Sinne! Es ging um die Tatsache, dass man als 0815 User bei kommerzieller Massenware idR. eben keinen Bug direkt melden und schon gar nicht diesen priorisieren kann. Das war der Knackpunkt. Von Qualität war da gar nicht die Rede.
Und auch beim letzten Punkt stimmst DU mir ja zu: Ich kann einen Bug als Großkunde sicher melden und monieren, aber ich kann ihn nicht *direkt* priorisieren. Indirekt mag das über meinen Supportvertrag und dessen Lukrativität für die Anbieterfirma natürlich eine große Rolle spielen, direkt beeinflussen kann ich es nicht. Und nun zeige mir doch mal den Unterschied zu einem OS Projekt auf? Neben monetären Anreizen - wie es Martin ja schon aufzeigte - kann man da den Entwickler eben eher durch Stichhaltigkeit und Nutzen seines Reports motivieren. Wo ist hier also noch ein Problem? Unterm Strich hast Du hier sogar *mehr* Möglichkeiten!
In naher Zukunft wird es nun auch KDE-Plugins für Mars- und Venuskarten oder die Darstellung von Mond- und Sonnenfinsternissen geben.
Jedem vernüftigem Menschen sollte es völlig klar sein, daß die Entwickler nicht zwei Dinge gleichzeitig tun können. Entweder Akonadi/Nepumuk/Kmail Bugreports lesen, oder aufregende neue Plugins für Mars- und Venuskarten oder Mondfinsternisse entwickeln.
und auch die Schnittmenge der Akonadi Entwickler und KStars/Marble Entwickler ist die leere Menge. Aber das hatte ich ja schon hier erklärt.
Scheint aber doch etwas zu kompliziert zu sein das zu verstehen. Schade.
Stimmt, denn die Akonadi Entwickler können nur in C++ Programmieren, während die KStars/Marble Benutzer nur Bildchen malen könenn.
Wer nicht in C++ programmieren kann, der sollte vielleicht besser gar nicht am KDE Projekt mitarbeiten.
Im kommerziellen Umfeld kann ich jedenfalls jeden guten C++ Programmierer an JEDEN C++ Code heranlassen.
Vielleicht braucht er dann etwas einarbeitungszeit, aber den Code wird er verstehen und dann ist es auch völlig egal, ob das Programm des Codes Akademika oder Sternchen heißt.
Fast alle KDE Software ist in C++ geschrieben. Neuerdings kommt im GUI Bereich auch QtQuick hinzu - da war übrigens KMail einer der ersten Anwendungsfälle. Marble und KStars sind auch beide in C++ geschrieben
Ich frage mich daher was deine Aussage soll. Ich als Entwickler eines in C++ geschriebenen Fenstermanagers kann nicht an dem in C++ geschriebenen E-Mail Frameworks arbeiten, da mir schlicht die Kompetenz dazu fehlt. Genauso haben halt E-Mail Framework Entwickler keine Ahnung von Fenstermanagement (das könnte ich nun mit Quellen beweisen).
> Ich als Entwickler eines in C++ geschriebenen Fenstermanagers kann nicht an dem in C++ geschriebenen E-Mail Frameworks arbeiten, da mir schlicht die Kompetenz dazu fehlt.
Dann bist du unflexibel.
Also ich kann, ich arbeite mich in den zusätzlichen Stoff, sofern vorhanden, einfach ein und gut ist.
Zumal eigentlich jeder Informatiker ein Grundgerüst in Sachen E-Mails und der dazu entsprechenden RFC haben sollte, der Rest ist trivial. Insbesondere wenn es nur darum geht Bugs zu beheben und nicht neue Features einzubauen.
Ja nee ist klar. Wenn Du Herzprobleme hast, kannst Du ja auch zu einem Zahnarzt gehen, der ist ja auch Mediziner. Was solls, kann er sich doch bei Deiner Bypass-OP erst einmal einarbeiten...
Die Sprache ist doch nicht das Problem, sondern die Problem Domäne - wer das nicht verstanden hat ist eben kein guter Informatiker! Natürlich kann man sich in diese einarbeiten, aber das verlangt eben Zeit und Motivation. Und wenn man für etwas nicht bezahlt wird, dann ist ersteres meist knapp und letzteres rein intrinsisch. Insofern ist die Annahme, dass KDE Entwickler einfach mal so universell Bugs fixen ziemlich naiv und weltfremd.
Wenn du nen Unfall hast, dann operiert dich ein Arzt des Krankenhaus am Herz, der Niere oder sonst wo.
Im übrigen hinkt dein Vergleich, denn wie ich bereits sagte, gehört Rechnernetze zum Grundstudium eines Informatikstudiums.
Das ist also keine Schwerpunktwahl wie bei einem Arzt der seinen Schwerpunkt auf Zahnarzt setzt.
> Insofern ist die Annahme, dass KDE Entwickler einfach mal so universell Bugs fixen ziemlich naiv und weltfremd.
Nö, denn wie ich bereits sagte, müssen keine neuen Features eingeführt werden, sondern Bugs gefixt werden.
Das ist also C++ Code, bei dem der Großteil des Codes schon existiert und bei den Grundbausteinen von der Schleife bis zur IF Bedingung oder typischen bekannten Algorithmen unterschiedet sich kein Code.
Das was du sagst, ist in etwa so, als könnte ein Kind, welches nur Lego Burgen baut, keine Schiffe aus Lego Bausteinen bauen.
Die Software besteht aus Millionen Code-Zeilen. Da kann man sich nicht einfach so einarbeiten. Jedes Projekt hat eine andere Struktur und andere Schwierigkeiten. Das sollte man in Grundstudium gelernt haben.
Falls du meinst, dass es so einfach ist behebe den Bug doch selbst!
Offenbar ist nicht jeder talentiert, das sehe ich an deiner Antwort.
Der erste Schritt ist ein Debugger, damit findet man schon die Stelle, wo das Programm aussteigt, sofern der Bug reproduzierbar ist.
Und OO Code ist eine große Hilfe, wenn er denn gut designed wurde, so daß ein guter Progger sich hier eigentlich gut zurecht finden sollte.
So manche Cracker haben es da schwerer, denn denen steht kein Original C++ Code zur Verfügung.
Sorry, aber was du schreibst ist ziemlich naiv.
Mit einem Debugger findest du crashes, super, das ist aber nur ein mögliches Problem. Um den Crash zu finden brauch ich keinen Debugger, da reicht auch der Crash Report der Users. Und was hat man wenn man die Stelle gefunden hat? Richtig die Stelle Code an der es abraucht. Das hilft bei der Problemlösung ziemlich wenig wenn man die Materie nicht kennt - und das ist genau was hier ausgesagt wurde.
Ich gib dir jetzt mal einen Crash Fix als Beispiel. Ein Crash bei dem wir etwa zwei Jahre lang nicht wussten wie man ihn auslösen kann. Wir wussten die Zeile wo es abraucht, aber nicht warum. Zuletzt nach einigen Code-Änderung hätte dir ein Debugger nicht mal mehr den Crash gezeigt, da es ein vom Timing abhängiges Problem war - upps Debugger verändern ja das Verhalten von Anwendungen. Ohne tiefes Verständnis des internen Aufbaus der Anwendung wäre dieser Crash nicht behebbar gewesen und den Ansatz den ich gewählt hatte, war ein Schuss ins Blaue basierend auf Annahmen, die ich ableiten konnte aus meinem Wissen über den internen Aufbau der Anwendung und das Verhalten im fraglichen Zeitraum.
Ich wage sehr zu bezweifeln, dass ein nicht Domain Experte dieses Problem hätte identifizieren können (den Weg das Problem zu reproduzieren hatte ich auch selbst aus Wissen über die Anwendung abgeleitet), noch dass er auf den Lösungsansatz gekommen wäre, noch dass er ihn hätte umsetzen können. Immerhin wir als Experten der Anwendungen haben Monate gebraucht einen Weg zu finden den Crash zu reproduzieren.
Erkennst du hier deinen Denkfehler nicht?
Du schreibst "Experten der Anwendung".
Eben, ein Experte der Anwendung ist nicht zwangsläufig auch ein Experte der RFCs, Gesetzesvorschriften und Normen in diesem Bereich, etwas, was du ja zu Beginn hier angeführt hast, daß man das brauchen würde, um den C++ Code zu fixen.
Siehe deine Worte:
Es ist also ein Code wie jeder andere, der eine bestimmte Anwendung bildet.
Für die Anwendung arbeitet man sich kurz ein, bei gegebenen UML Diagramm sollte das recht effizient möglich sein, ansonsten nimmt man eben den Code und dann kann ein guter C++ Entwickler auch das Problem fixen.
Denn das Problem hat nichts mit RFCs, Gesetzevorschriften oder Normen oder speziellen Softwarebereichen zu tun, sondern es ist schlichtweg nur C++ Code.
Die Grundlagen die einem Programm zugrunde liegen sind überall gleich, die Spezialisierung fängt erst da an, wo du Experten in umzusetzenden Gestezesvorschriften, RFCs oder Normen benötigst und das braucht man nicht zum Bug fixen, sondern für nur neue Features.
nun ok du hast vollkommen Recht ich bin ein absoluter Idiot. Ich verstehe gar nicht warum ich mehr als ein Jahr gebraucht habe bis ich KWin intern verstanden habe und ich verstehe noch viel weniger warum ich nach all den Jahren und sogar mittlerweile als Maintainer immer noch Bereiche gibt von denen ich keine Ahnung habe.
Ich hätte mich wohl besser mal kurz in den Quellcode einarbeiten müssen oder ich bin einfach ein zu schlechter Programmierer.
Nun zu der RFC Geschichte. Klar wenn ich bei KWin Bugs behebe brauche ich dafür keine RFC, trotzdem hab ich hier einen kompletten Stapel mit ausgedruckten Spezifikationen, die ich immer mal wieder zur Rate ziehe. Muss manchmal schon sein, wenn sich die GTK Anwendungen anders verhalten als die Qt Anwendungen. Da muss man halt schon mal die Specs lesen. Aber klar braucht man ja nicht, der C++ Code ist natürlich völlig ausreichend.
Schon mal gesehen, dass ein RFC buggy ist oder von Servern falsch umgesetzt wird? Die Software, die ich während meiner Masterthesis geschrieben habe, ist am Ende daran gescheitert, dass die GoogleMail Server einen RFC falsch bzw. gar nicht implementiert hatten. Aber klar das Lesen des Quellcodes hätte das Problem sicherlich behoben.
"Die Software, die ich während meiner Masterthesis geschrieben habe, ist am Ende daran gescheitert, dass die GoogleMail Server einen RFC falsch bzw. gar nicht implementiert hatten."
Und jetzt?
Musst Du die "Diplomarbeit" noch einmal schreiben?
Nein, natürlich nicht. Ich hab das ganze mal im Blog zusammengefasst. Ausführlich auch hier.
68 Euro? Da finde ich die Nutzung des openSUSE Buldservice aber wesentlich origineller.
Aber klar doch! Der Unfallarzt operiert alles! Wenn Du ihn nett bittest, saugt er Dir vielleicht auch noch Fett ab und korrigiert die Nase.
Schon lange nicht mehr in der Notaufnahme gewesen, oder? Selbst die Autoren von "Emergency Room" hatten mehr Ahnung als Du.
Es ist schon lustig, was Du als "C++ Entwickler" so für wage Thesen vertrittst. Ich habe in meinem Informatikstudium niemals ein RFC in einer VL durchgekaut oder mich sonst wie näher mit Mail-Protokollen befasst. War das also dann kein "richtiges" Informatikstudium? Das solltest Du meiner Uni mal schreiben
Zu dem Finden von Bugs hatte Martin ja schon einiges geschrieben. Ich will aber noch mal herausstellen, dass *speziell* das Fixen von Bugs tiefgreifende Kenntnis des Codes und Erfahrung in der Domäne voraussetzt. Das Coden von neuen Funktionalitäten ist da fast einfacher, sofern Du Dich auf vorhandenes stützen kannst. Das "nur" Bug fixen ist also kein "nur", sondern geht mit der von mir dargestellten Kausalkette (Coden in der Freizeit, intrinsische Motivation) einher. Und daher bleibst Deine Ansicht weltfremd.
Im übrigen kannst Du meine These gerne ignorieren - in der Realität indes zeigt es sich doch, dass der Status quo genau so ist, wie ich ihn ableite. Und den kannst Du nicht wegdiskutieren...
Zudem verunglimpfst Du meine Beispiele. Bei der Technologie "Lego" ist es eben künstlich anzunehmen, dass es dort spezielle Domänen gäbe, bei denen jemand keine universelle Kompetenz haben kann. Im Bereich "Technic" ist es aber in der Tat so, dass Du sicherlich Probleme hast, gewisse Funktionalität zu implementieren, wenn Du damit noch keine Erfahrung hast. Denn auch bei Lego gibt es gewisse "Design Pattern" und zudem musst Du von der Existenz von Teilen wissen, wenn von diesen die Machbarkeit abhängt - das geht ohne Erfahrung einfach nicht. Davon abgesehen ist das aber auch kein Bug fixen, denn so stark kann man bei Lego wohl kaum Tätigkeiten abstrahieren
Mein Arzt Gleichnis ist einfach gut - Du kannst aber auch gerne einen Elektriker nehmen. Der eine kann ein Haus verkabeln, der andere mein TV Gerät oder meine Waschmaschine reparieren. Es ist schon weltfremd anzunehmen, dass beide so mir nichts dir nichts austauschbar wären. Fachkompetenz erwirbt man sich durch Zeit, die man in einer Domäne tätig ist; das kann man nicht mit Pauschalaussagen a la "C++ ist das wichtige, wer das kann, kann alles" wegfegen.
Deine Aussagen zu Bugs und Deiner Unfähigkeit Bildnisse zu interpretieren lassen mich aber auch daran zweifeln, ob Du wirklich Ahnung von der Materie des Softwareentwicklung hast. Einen coolen Nickname kann sich hier ja jeder zulegen
Tja, ein Studium umfaßt nunmal auch Eigenarbeit zu Hause.
Ich habe mir die RFCs zum HTTP und FTP Protokoll, sowie zu denen eines E-Mail Programms alle durchgelesen, unser Prof hat uns das sogar auch empfohlen und stell dir vor, in meiner Studierzeit habe ich auch die RFCs zu VoIP durchgelesen.
Wenn du das nicht gemacht hast, dann ist das schlecht, weil es aussagt, daß du während deinem Studium dich nicht besonders tief in die Materie eingearbeitet hast, sondern gerademal das allernötigste gemacht hast nur um Scheine zu bestehen.
Siehe mein erstes Posting, man arbeitet sich kurz ein und verschafft sich einen Überblick, die meisten Bugs kann man damit erschlagen.
Nö, das eben nicht, Siehe oben.
Wenn ich an einem Programm für z.B. Elektroniklayout einen Bug fixen möchte, dann muß ich weder die VDE Vorschriften noch die Pin-Abstände von diversen ICs wissen, möglicherweise brauche ich nichtmal ein tieferes Verständnis in der Elektrotechnik, denn dieses Wissen brauche ich nur dann, wenn ich neue Features in die Software einarbeiten will und nicht zum Fixen eines Bugs.
Das fixen von Bugs ist in 99 % der Fälle nur das Fixen von Programmierfehlern, also der Programmierung an sich und alles was damit zu tun hat. Im prinzip also die Grundlagen, die Grundbausteine und Algorithmen.
Ne, eben nicht.
Wenn ich an einer Schaltungssimulation für Elektronik neue Features einbauen will, dann brauche ich in den meisten Fällen ein tieferes Verständnis in der Elektrotechnik.
Bei Programmen für die Medizin wird das nicht anders sein, was meinst denn du, warum es in der Informatik extra Studiengänge wie Wirtschafts-, Medizin- oder Bioinformatik gibt?
Das erschaffen von völlig neuen Features erfordert also wesentlich mehr Hintergrundwissen, als für das reine fixen von Bugs.
Für das fixen von Bugs reicht reines Programmiererwissen.
Offenbar kennst du den Unterschied zwischen einem Elektriker und einem Elektroniker nicht.
Deine Hausverkabelung ist Elektrik.
Das TV Gerät ist reine Elektronik.
Und die Waschmaschine wohl so ein Zwischending zwischen Elektronik und Mechatronic.
Glaubst du allen Ernstes, dass zum Beispiel die Probleme bei Akonadi oder Nepomuk (worüber dieser Thread ja ist) simple Programmierfehler sind? Ach wäre das schön wenn dem so wäre...
Glaubst du den Fehler den ich weiter oben beschrieb, war ein simpler Progammierfehler? Glaubst du allen Ernstes, dass man Fehler in Nepomuk beheben kann ohne Wissen von RDF? Oder Fehler in KWin ohne Wissen von Fenstermanagement und Compositing?
Wenn ja, dann bitte ich dich doch in die freie Software Entwicklung einzusteigen. Du scheinst ein Genie zu sein, wie ich es so noch nicht gesehen habe. Freue mich schon in Zukunft weniger Bugs zu haben
Und nun gehe ich erst mal einen Unit Test schreiben für einen Fehler den ich noch nicht ganz verstehe.
Hast Du Dich mal mit semantischen Technologien auseinander gesetzt? Ontologien, OWL, SPARQL? Es ließen sich sicherlich genügend Themenfelder finden, von denen Du keine oder wenig fundierte Ahnung hast - deswegen abzuleiten, dass jemand zu wenig Interesse an der Gesamtmaterie hat und nur das "nötigste" für seine Scheine getan hat, ist sagenhaft dümmlich! Als dermaßen vor Selbstwusstsein strotzendem Informatik-Gott , der gerne ex catedra redet und seine Meinung als Naturgesetz darstellt, hätte ich ein wenig mehr Intelligenz erwartet...
Ad "Elektroniker vs Elektriker": Du hast Recht, ich war da zu unpräzise. Offenbar ist der Oberbegriff der des Elektronikers - Elektriker ist da wohl eher Volksmund. Allerdings ändert das nichts an meinem Bild, denn offensichtlich bezeichnet man eben doch beide *Spezialisierungen* mit einem Begriff. Zudem bleibt das Ärzte Gleichnis immer noch so stehen, ohne dass Du es auch nur ansatzweise entkräften konntest
(Wie auch!?! Es stimmt eben 
)
Deine Weltsicht auf Bugs ist dermaßen eingeschränkt, dass ich immer noch denke, dass Du eher noch ein Student bist, der nur kleinere und kürzere Projekte realisiert hast. Bugs umfassen so viel mehr als simple Programmierfehler! Und genau das sind einfach diejenigen, deren Ursache sich nur *schwer* aufspüren und ggf. auch beheben lässt. Wer das auf "Man muss nur C++ kennen" reduziert, ist einfach nicht ernst zu nehmen.
Und nein, neue Features können sehr viel einfacher sein, als einen Bug zu fixen. Oftmals sind es Kompositionen von vorhandenen Komponenten; was muss ich da für ein tiefgreifendes Verständnis für die Software im Kern haben? Ich habe mir auch schon mal kleine Erweiterungen für Gimp geschrieben - meinst Du ernsthaft, dass ich mir dafür Wissen um den Code von Gimp oder Grafikverarbeitung i.A. hätte aneignen müssen? Gleiches gilt für Scribus, dort sogar *direkt* im Code, den ich um eine Funktion in der Python-API erweitert habe. Dank Doku zur API muss man sich nur die Funktionen zusammenstellen, die man benötigt... alles viel trivialer, als einen Programmfehler auszumerzen.
Natürlich können neue Funktionen auch sehr schwierig zu implementieren sein! Aber im Gegensatz zu Bugs besteht hierbei die *Möglichkeit*, dass das einfach funktioniert.
Nachtrag
Die Liste der Schande:
https://bugs.kde.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDSINFO&bug_status=VERIFIED&product=Akonadi&product=nepomuk&query_format=advanced&order=changeddate%20DESC%2Cpriority%2Cbug_severity&query_based_on=
Ich glaube daher nicht, daß ich der einzige entäuschte Anwender bin.
Leider kappt bugs.kde.org die liste nach dem 500. Eintrag.
Demnach bleibe ich bei meiner Aussage!
J. Sauer
Dieses Urteil fällst Du allein auf Basis der Anzahl der Bugmeldungen? Wieviele davon mehrfach Meldungen sind, sich auf alte KDE-Versionen beziehen, nur bestimmte Distributionen oder gar nur einzelne Benutzer betreffen - alles egal. Einfach draufhauen.
Das sich die KDE-Entwickler mit diesem Kindergarten überhaupt noch abgeben, verdient Respekt.
Nein, das Urteil fälle ich nicht aus der Anzahl.
Vielmehr aus der Anzahl der Offenen/NICHT Bearbeiteten.
Die Anzahl der nicht bearbeiteten ist schlichtweg eine Zumutung.
Auch wenn die sich auf alte Versionen beziehen mögen, heisst der Zustand des Bug Reporting Systems für mich im Klartext:
LMAA User!
Damit bleibt meine ursprüngliche Aussage nach wie vor gültig und kann als Faktum gelten. Q.E.D!
J. Sauer
Also ich fasse das nochmal zusammen. Deiner Meinung nach ist es also am wichtigsten, dass die Entwickler auf die Bugs antworten statt Bugs zu beheben. Fair enough.
Ich finde das aber eine schlechte Idee. Ich weiß, dass den Entwicklern die zeit fehlt sich um die Reports zu kümmern und dass sie viele Bugs beheben kannst du in jedem Changelog von einer neuen sc Version lesen.
Du könntest übrigens mithelfen den Entwicklern das leben einfacher zu machen und mithelfen die Bugs zu organisieren. Aus eigener Erfahrung kann ich sagen, dass dass schon einiges an Arbeit ist und wenn der Bugtracker nicht aufgeräumt ist, dann kann man ihn zum beheben von Bugs garnicht verwenden.
Also los mithelfen und hier nicht die Entwickler Beschuldigen. Es bringt wenig auf die auch noch drauf zu hauen, die deine Bus beheben.
Du sprachst doch vorher von kritischen Bugs, dann ist das diese Liste: https://bugs.kde.org/buglist.cgi?bug_severity=critical&query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=Akonadi&product=nepomuk
Das sind dann nur 14 und schließt auch nicht irgendwelche Feature Requests ein.
Meiner Erfahrung nach sagt die Anzahl aber nicht viel aus, wenn die Entwickler nicht den Bugtracker stark einsetzen. KDEPIM fehlen leider die Ressourcen um mit bugs.kde.org zu arbeiten.