Soll das dann so laufen: Oh, ich habe ein Bug gefunden -> Hmmm, ok, gibt ja nun nur noch einen Bug-Tracker mit Supernamen "KDE". Ist ja egal, wo der Fehler aufgetreten ist. Das können dann andere Leute für mich entscheiden. Die kümmern sich dann schon. Am besten wird Qt, der Kernel, Systemd, etc. auch noch mit in den gleichen Topf geworfen. Einmal umrühren und fertig ist der Desktop mit dem Übernamen "KDE x" und zudem perfekt getestet, weil plötzlich ja alle Unterprojekte viel besser auf einander abgestimmt sind. So stellst Du Dir das vor, weil der Benutzer nicht in der Lage ist zu erkennen, wo ein Fehler aufgetreten ist und er die einzelnen Komponenten sowieso nicht unterscheiden kann und schon gar nicht benennen kann?
Im vorigen Post hast Du geschrieben:
So, und wie ist das jetzt bei KDE? Wo beginnt Plasma, wo endet es? Gehört Akonadi/Nepomuk noch zu Plasma oder ist das schon Teil des Frameworks oder aber nur der Plattform?
Hier schreibst Du aber:
Damit hat man dann wenigstens eine Release, unter einem Namen, die auch wirklich mal getestet wurde. Jeder weiß aus welchen Komponenten diese Release besteht und man muss nicht bei einem Bugreport alle Unterversionen von jeder Subkomponente angeben.
Was nun? Ist der User nun dämlich und weiss nix oder weiss dann automatisch doch jeder, aus welchen Komponenten das Super-Release besteht? Ich kann dem nicht ganz folgen.
Jedes der Unterprojekte kann unter dem eigenen Namen machen was es will und so viele Versionen rausballern wie es Spaß macht.
Die Aufspaltung wird ja erst mit der 5er Reihe kommen. Plötzlich doch wieder Ok? Oder geht es nun nur um einen einzigen "KDE" Übernamen als Oberbegriff?
Die geplante Trennung in lauter Unterkomponenten die alle ihrem eigenen Releasezyklus folgen hatten wir in ähnlicher Weise schon mal bei frühen Versionen von Gnome.
Das mit Gnome kann ich nicht beurteilen. Ich bin auch kein KDE-Entwickler. Aber das Konzept, KDE modularer zu gestalten und Abhängigkeiten zu reduzieren ist denke ich richtig und die Vorteile werden überwiegen.
Soll das dann so laufen: Oh, ich habe ein Bug gefunden -> Hmmm, ok, gibt ja nun nur noch einen Bug-Tracker mit Supernamen "KDE". Ist ja egal, wo der Fehler aufgetreten ist.
Jetzt laber halt nicht so einen Mist. An dem Bugtracker würde sich doch bei keiner Variante was ändern.
Ist ja egal, wo der Fehler aufgetreten ist. Das können dann andere Leute für mich entscheiden. Die kümmern sich dann schon.
Ja, ist jetzt schon so, weil einfach viele User die Komponente nicht zuordnen können.
Einmal umrühren und fertig ist der Desktop mit dem Übernamen "KDE x" und zudem perfekt getestet, weil plötzlich ja alle Unterprojekte viel besser auf einander abgestimmt sind. So stellst Du Dir das vor, weil der Benutzer nicht in der Lage ist zu erkennen, wo ein Fehler aufgetreten ist und er die einzelnen Komponenten sowieso nicht unterscheiden kann und schon gar nicht benennen kann?
Und dich soll man noch ernst nehmen können? Bezeichnest andere als Troll und laberst dann so eine gequirlte Scheiße weil dir die Meinung nicht passt.
Was nun? Ist der User nun dämlich und weiss nix oder weiss dann automatisch doch jeder, aus welchen Komponenten das Super-Release besteht?
Oh man, 3 Meter weit zu denken ist wohl zuviel verlangt? Denk dir einfach das Wort "Entwickler" dazu: Jeder Entwickler weiß aus welchen Komponenten die Superrelease besteht und dadurch wird dem User das Auflisten aller Versionen und Komponenten erspart.
Die Aufspaltung wird ja erst mit der 5er Reihe kommen. Plötzlich doch wieder Ok? Oder geht es nun nur um einen einzigen "KDE" Übernamen als Oberbegriff?
Es geht darum das jemand den Scheiß auch testet! KDE ist so schon verbuggt genug. Wenn jetzt jeder nach Lust und Laune released, wie soll es denn dann eine vernünftige Beta Phase geben und wie soll das saubere Zusammenspiel der Komponenten gesichert werden? System- und Integrationstests sind nunmal wichtig für stabile Software und die wirst du dann nicht mehr haben. Was glaubst du wohl in welche Richtung die Stabilität dann geht?
Das mit Gnome kann ich nicht beurteilen. Ich bin auch kein KDE-Entwickler. Aber das Konzept, KDE modularer zu gestalten und Abhängigkeiten zu reduzieren ist denke ich richtig und die Vorteile werden überwiegen.
Nein, weil keiner seine Software mehr vernünftig testen kann. Es gibt keine Referenz mehr gegen die ich meine Tests ausführen kann und ich kann den Usern nicht mehr sagen: Nimm KDE 5.x.y, dann läuft's.
"Laber, Mist, gequirle Scheiße?" Musst Du gleich agro werden? In Deinen Aussagen geht es drunter und drüber:
So, und wie ist das jetzt bei KDE? Wo beginnt Plasma, wo endet es? Gehört Akonadi/Nepomuk noch zu Plasma oder ist das schon Teil des Frameworks oder aber nur der Plattform? Das ist alles völlig wirr und jemand der sich nicht für die KDE Architektur interessiert (vermutlich die meisten normalen Anwender), der KANN gar nicht zwischen den Komponenten unterscheiden.
Du hältst die breite Masse der Anwender für dämlich. Auf Nachfrage präsentierst Du einen Deiner Meinung nach besseren Vorschlag, als das Projekt in 3 Unterprojekte aufzuteilen:
Wie bisher wird aber alle halbe Jahr, bzw. jeden Monat (Bugfixes) eine Release zusammengebaut (und getestet !), aus Komponenten die auch wirklich zusammen funktionieren. ... Damit hat man dann wenigstens eine Release, unter einem Namen, die auch wirklich mal getestet wurde. Jeder weiß aus welchen Komponenten diese Release besteht und man muss nicht bei einem Bugreport alle Unterversionen von jeder Subkomponente angeben
Nun weiß also jeder doch wieder aus welchen Komponenten KDE aufgebaut ist? Du möchstest also eine KDE Überversion mit einer Versionsnummer haben, die alle paar Monate released wird. Das zweite Standbein Deiner Argumentation ist eine generelle Zunahme der Fehleranfälligkeit, wenn das System in drei Bereiche aufgeteilt wird. Deine Begründung dazu:
Es geht darum das jemand den Scheiß auch testet! KDE ist so schon verbuggt genug. Wenn jetzt jeder nach Lust und Laune released, wie soll es denn dann eine vernünftige Beta Phase geben und wie soll das saubere Zusammenspiel der Komponenten gesichert werden? ... Es gibt keine Referenz mehr gegen die ich meine Tests ausführen kann und ich kann den Usern nicht mehr sagen: Nimm KDE 5.x.y, dann läuft's.
Warum kannst Du dann eine Anwendung künftig nicht mehr vernünftig testen? Die Anwendung setzt eine bestimmte Frameworks-Version vorraus, ggf. eine bestimmte Plasma-Version. Ist doch bei Qt-Anwendungen genauso. Sag Deinen Anwendern dann, installiere bitte Frameworks x.y. Nenn mir bitte technische Gründe, die dagegen sprechen. Ich kenne die Details nicht, aber es ist hier die Rede davon, KDE in 3 Bereiche aufzuteilen: Basis, Desktop und Anwendungen. Du tust so, als würde davon die Welt untergehen. Und das KDE ja ach so verbuggt ist. Na dann nutze es doch nicht mehr. Ich kann damit sehr gut umgehen. Natürlich ärgere ich mich über dieses und jenes. Bugs in KMail werden z.B. immer gerne generell KDE allgemein zugeordnet, dass liest man in Diskussionen immer wieder. Für mich sind das aber Bugs, die ich nicht zu KDE rechne. Wenn Outlook bei mir crasht, dann ist das meistens auch kein Windows-Bug. Deswegen meine ich für mich, dass ich schon ganz gut mit dem ach so verbuggten KDE, wie Du es nennst, leben kann und ich auch keine Befürchtung habe, dass es durch eine Aufsplittung schlimmer wird. Im Gegenteil, KDE wird deswegen schlanker und besser werden.
Ich könnte mir sogar vorstellen, dass durch die neue Aufteilung neue DE's entstehen werden. Eine Art lightweight KDE ist mit KLyDE z.B. in Entwicklung und wird in Zukunft von der Modularisierung von KDE bestimmt auch profitieren.
Soll das dann so laufen: Oh, ich habe ein Bug gefunden -> Hmmm, ok, gibt ja nun nur noch einen Bug-Tracker mit Supernamen "KDE". Ist ja egal, wo der Fehler aufgetreten ist. Das können dann andere Leute für mich entscheiden. Die kümmern sich dann schon. Am besten wird Qt, der Kernel, Systemd, etc. auch noch mit in den gleichen Topf geworfen. Einmal umrühren und fertig ist der Desktop mit dem Übernamen "KDE x" und zudem perfekt getestet, weil plötzlich ja alle Unterprojekte viel besser auf einander abgestimmt sind. So stellst Du Dir das vor, weil der Benutzer nicht in der Lage ist zu erkennen, wo ein Fehler aufgetreten ist und er die einzelnen Komponenten sowieso nicht unterscheiden kann und schon gar nicht benennen kann?
Im vorigen Post hast Du geschrieben:
Hier schreibst Du aber:Was nun? Ist der User nun dämlich und weiss nix oder weiss dann automatisch doch jeder, aus welchen Komponenten das Super-Release besteht? Ich kann dem nicht ganz folgen.Die Aufspaltung wird ja erst mit der 5er Reihe kommen. Plötzlich doch wieder Ok? Oder geht es nun nur um einen einzigen "KDE" Übernamen als Oberbegriff?Das mit Gnome kann ich nicht beurteilen. Ich bin auch kein KDE-Entwickler. Aber das Konzept, KDE modularer zu gestalten und Abhängigkeiten zu reduzieren ist denke ich richtig und die Vorteile werden überwiegen.Jetzt laber halt nicht so einen Mist. An dem Bugtracker würde sich doch bei keiner Variante was ändern.
Ja, ist jetzt schon so, weil einfach viele User die Komponente nicht zuordnen können.
Und dich soll man noch ernst nehmen können? Bezeichnest andere als Troll und laberst dann so eine gequirlte Scheiße weil dir die Meinung nicht passt.
Oh man, 3 Meter weit zu denken ist wohl zuviel verlangt? Denk dir einfach das Wort "Entwickler" dazu: Jeder Entwickler weiß aus welchen Komponenten die Superrelease besteht und dadurch wird dem User das Auflisten aller Versionen und Komponenten erspart.
Es geht darum das jemand den Scheiß auch testet! KDE ist so schon verbuggt genug. Wenn jetzt jeder nach Lust und Laune released, wie soll es denn dann eine vernünftige Beta Phase geben und wie soll das saubere Zusammenspiel der Komponenten gesichert werden? System- und Integrationstests sind nunmal wichtig für stabile Software und die wirst du dann nicht mehr haben. Was glaubst du wohl in welche Richtung die Stabilität dann geht?
Nein, weil keiner seine Software mehr vernünftig testen kann. Es gibt keine Referenz mehr gegen die ich meine Tests ausführen kann und ich kann den Usern nicht mehr sagen: Nimm KDE 5.x.y, dann läuft's.
"Laber, Mist, gequirle Scheiße?" Musst Du gleich agro werden? In Deinen Aussagen geht es drunter und drüber:
Du hältst die breite Masse der Anwender für dämlich. Auf Nachfrage präsentierst Du einen Deiner Meinung nach besseren Vorschlag, als das Projekt in 3 Unterprojekte aufzuteilen:Nun weiß also jeder doch wieder aus welchen Komponenten KDE aufgebaut ist? Du möchstest also eine KDE Überversion mit einer Versionsnummer haben, die alle paar Monate released wird. Das zweite Standbein Deiner Argumentation ist eine generelle Zunahme der Fehleranfälligkeit, wenn das System in drei Bereiche aufgeteilt wird. Deine Begründung dazu:Warum kannst Du dann eine Anwendung künftig nicht mehr vernünftig testen? Die Anwendung setzt eine bestimmte Frameworks-Version vorraus, ggf. eine bestimmte Plasma-Version. Ist doch bei Qt-Anwendungen genauso. Sag Deinen Anwendern dann, installiere bitte Frameworks x.y. Nenn mir bitte technische Gründe, die dagegen sprechen. Ich kenne die Details nicht, aber es ist hier die Rede davon, KDE in 3 Bereiche aufzuteilen: Basis, Desktop und Anwendungen. Du tust so, als würde davon die Welt untergehen. Und das KDE ja ach so verbuggt ist. Na dann nutze es doch nicht mehr. Ich kann damit sehr gut umgehen. Natürlich ärgere ich mich über dieses und jenes. Bugs in KMail werden z.B. immer gerne generell KDE allgemein zugeordnet, dass liest man in Diskussionen immer wieder. Für mich sind das aber Bugs, die ich nicht zu KDE rechne. Wenn Outlook bei mir crasht, dann ist das meistens auch kein Windows-Bug. Deswegen meine ich für mich, dass ich schon ganz gut mit dem ach so verbuggten KDE, wie Du es nennst, leben kann und ich auch keine Befürchtung habe, dass es durch eine Aufsplittung schlimmer wird. Im Gegenteil, KDE wird deswegen schlanker und besser werden.Ich könnte mir sogar vorstellen, dass durch die neue Aufteilung neue DE's entstehen werden. Eine Art lightweight KDE ist mit KLyDE z.B. in Entwicklung und wird in Zukunft von der Modularisierung von KDE bestimmt auch profitieren.