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.
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.