On 05.03.06 17:23:45, Enrico Weigelt wrote: > * Andreas Pakulat <[EMAIL PROTECTED]> schrieb: > > Ein Teil davon duerfte auf der miserablen Arbeit der Paketmaintainer > > diverser Mainstream-Distri's beruhen, denn schliesslich wollen die > > Projektentwickler dass man auch auf diesen Distri's das Programm > > kompilieren kann. > > Ich denke, beide Parteien tragen Ihren Teil dazu bei. > Aber gerade die Distro-Maintainer sollten da etwas konsequenter > und radikaler in ihren QS-Anforderungen sein.
Genau, damit keiner mehr die Distro benutzt/kauft, da das alle Distro-Maintainer machen, kauft/benutzt niemand mehr Linux. Ist ja nicht so schlimm, Alternativen existieren ja. > + Vollautomatischer, nicht-interaktiver build. KDE kann man prinzipiell ausm svn vollautomatisch inter-aktiv bauen lassen. Auch bei Debian's buildd's klappt das sehr gut. Sofern eben keine Fehler beim Paketieren gemacht wurden, bzw. bei KDE keine Fehler im aktuellen Code existieren. > + Libraries -> 100% abwärtskompatibel (zumindest auf Quell-Ebene) Soll ich jetzt mal ROFL schreiben? Spaetestens bei Major-Versions werden i.A. die Source-Interfaces geaendert. Nicht wegen schlechtem Design, sondern weil sich die Anforderungen/Wuensche weiterentwickelt und veraendert haben. Genau dafuer gibts ja Major-Versions. Innerhalb von Minor/Bugfix Versionen muss natuerlich Quellkompatibilitaet oder besser sogar Binaerkompatibilitaet gewaehrleistet sein. Das haben leider nicht alle Library-Entwickler so verinnerlicht... 100% Abwaehrtskompatibilitaet ist das was Windows bis WinME "versucht" hat, selbst M$ hat es aufgegeben und mit Win2K/WinXP diese Kompatibilitaet zugunsten von Wartbarkeit, Stabilitaet usw. eingeschraenkt. Beim naechsten Windows wirds wohl noch "extremer" aussehen. > > > Wenn sich in einer Library von einer Version zur nächsten die > > > Interfaces inkompatibel werden, dann ist das ein Designfehler, > > > > Das kommt auf den Versionssprung an... Von 3.4.X auf 4.X.X darf sowas > > sein (um mal beim KDE-Beispiel zu bleiben, Zahlen sind aber beliebig > > austauschbar). > > Nein, auch dann nicht. Man muß ein neues Paket / eine neue Library > bauen, also zB. libfoo1, libfoo2, ... diese Libs müssen natürlich > auch problemlos koexistieren können. ?? Um sowas anzuzeigen gibts den Soname bei Libraries (im Sinne von nativen Linux-Libs). Bei Python loest man das ganze wohl mit sog. eggs oder eben neuen Namen mit der neuen Major-Revision drin. > > > unabhängig vom individuellen Gefühl der jeweiligen Autoren. > > > Solche Libs (-Versionen) sollte man einfach nicht benutzen, sondern > > > ggf. reparieren. > > > > In der Praxis gibts leider Faelle wo sich die Autoren nicht sonderlich > > darum kuemmern ihre ABI kompatibel zu halten und man leider keine > > vernuenftigen Alternativen hat. > > Dann muß man eben mal in den sauren Apfel beißen und sich selbst > der Sache annehmen, notfalls eine neue Branche aufmachen. Genau, ich schreib mal eben schnell ne SSL library, so in 2 Stunden oder so? Ich kenn mich zwar mit dem Thema nur rudimentaer aus aber das wird schon werden... > Übrigends kann ich mit ABI-Inkompatiblitäten zwischen major-Releases > grade so noch leben (evtl. sollte man aber eine ABI-Revision mitpflegen), > aber zumindest auf source-Ebene *muß* es passen - sonst ist das für > mich Schlamperei. So nu muss ich aber wirklich: ROFL. Wie willst du denn deine Library and neue Anforderungen anpassen? Oder kennst du alle jemals auftretenden Anforderungen im vorneherein? Achso du ueberlegst dir einfach nen neuen Namen und startest von vorne. Major Releases werden genau deswegen gemacht, weil man die ABI und die API brechen muss um neue Dinge einfliessen zu lassen. > > Gerade bei OSS ist es auch so, dass die Entwickler nicht unbedingt Lust > > haben kaputten Code von anderen zu reparieren sondern sie moechten halt > > lieber ihre eigenen Dinge weiterentwickeln. > > Durchaus verständlich, aber auf Dauer kontraproduktiv. > Ich habe selbst meine Erfahrungen damit machen müssen, wie schwierig > es ist, kleine aber wichtige Fixes in die official branches zu kriegen > (zB. DESTDIR-fix für expat) > > Deshalb hab ich mir angewöhnt, meine eigenen Fixes zu pflegen. Hmm, ist das nicht auch unguenstig? Ich meine dann muessen die Nutzer deiner App immer deine expat-Version benutzen. Und der Support fuer die die das nicht "kapieren" oder sowas wie README's und aehnliches nicht lesen duerfte einiges an Zeit kosten. > > > Wenn die Namen mir jetzt noch was sagen würden ... > > > > fam == file alteration monitor > > > > Leider total buggy und nicht mehr gepflegt. > > Wenn Du es benutzt, warum pflegst Du es nicht ? 1. Ich bin noch immer Student und hab leider andere Dinge zu tun 2. Ich brauche fam nicht 3. Ich hab von der Materie keine Ahnung (das Teil basiert auf irgendwelchen notify-Funktionen vom Kernel) Das reicht mir aus. Ich leiste meinen Teil zu OSS so gut ich kann und eigentlich beansprucht das jetzt schon mehr Zeit als gut fuer mich ist... > > Ok, jetzt kann man denen sagen: "Ihr koennt mich mal, CVS ist nur > > fuer Freaks". > > CVS ist für Entwickler, nicht Anwender. (Jemand der in seine > Software eine gewisse Lib einbaut, ist auch Anwender dieser) Da kommen wir wohl nicht ueberein. Naja, lassen wir das Thema. > Evtl. sollte man bei gewissen Libs über kürzere Release-Zeiträume > nachdenken Oh, hast du ne Klon-Maschine um gute Entwickler zu klonen und allen Projekten so mit unendlich viel Manpower dabei zu helfen? Ich weiss nicht wie das bei anderen Projekten aussieht und entschuldige bitte dass ich immer auf das von dir so verhasste KDE zurueckkomme. KDE hat beschlossen nur noch Bugfix-Releases von KDE3 zu veroeffentlichen damit moeglichst viel Manpower in KDE4 fliessen kann, dennoch ist der aktuell anvisierte Release in 1.5-2 Jahren. Anderen OSS Projekten duerfte es aehnlich gehen. > und erstmal eine Sache zuende bringen, bevor man eine andere anfängt. > Manchmal sollte man auch kleinere Brötchen backen und Libs > aufsplitten. Aufsplitten loest das Manpower Problem auch nicht. > > > Okay, die Qualität der Geschwindigkeit opfern. In der kommerzwelt > > > ist das leider allzu oft die Praxis (manchmal sogar legitim, wenn sich > > > der Mehraufwand fürs Gepfusche und nachträgliche Reparaturen durch > > > zeitige Fertigstellung rechnet - bei Inhouse-Anwendungen durchaus > > > sinnvoll, bei Standardsoftware aber tödlich). > > > > > > Mein Buildsystem ist aber für saubere und robuste OSS gedacht. > > > > Auch bei OSS gibts sowas, klaro ist da eher "Es ist fertig wenn es > > fertig ist" das Motto. Dennoch denke ich werden vielfach Libraries und > > Anwendungen mit CVS-Versionen von Bibliotheken entwickelt um moeglichst > > frueh die neuen Features testen zu koennen... > > Das ist aber wieder Pfusch. Nicht die Anwendungsentwickelr sind zum > Testen einer Lib da, sondern das QM-Team der Lib. Also hast du doch ne Klon-Maschine zumindest fuers QM. Im Moment machen das zu einem guten Teil die Anwender, die muessen dafuer aber CVS-Versionen benutzen... Wir drehen uns irgendwie im Kreis. Lassen wir das. > Jaja, Projektmanagement in OSS ist nicht ganz trivial, weil es da > ja keine Kommandostrukturen gibt ;-) Ich denke in groesseren Projekten gibts schon Kommandostrukturen, allerdings gibts meistens zu wenig QM-Leute, zu wenig Entwickler, zu wenig Software-Designer, zu wenig UI-Designer, zu wenig Uebersetzer (hab ich was vergessen?). > > > Qt halte ich für den klassischen Kommerz-Pfusch. Überladene, > > > überzüchtete eierlegende Wollmilchsau, die nichtmal ein paar > > > Grundlegende moderne Konzepte wie garbage collection brauchbar > > > verwendet. > > > > GC? Bei C++? Der war gut. Da musste schon selbst GCen. > > boehm-gc ? Naja, modern find ich den ja nicht ;-) (Nein ich kenne ihn nicht, nur anhand der Paper-Daten). Ansonsten ziehe ich mich jetzt lieber aus dem Thema zurueck, denn mit MM hab ich bisher nicht sooo viel am Hut gehabt (ausser aufzupassen meine Objekte nicht zu frueh zu deleten). Achja: Ich habs auch lieber mich nicht drum kuemmern zu muessen, das geb ich schon zu. > > Und das machen die recht ordentlich (stichwort RefCounting und > > Implicit Sharing) IMHO. > > Ungenügender Ansatz. Funktioniert nicht bei Ringstrukturen. Ist klar. > Eines der wesentlichen Konzeptionsfehler von Qt ist, daß es zu > viel auf einmal will. > > BTW: kann man mittlerweile auch eine Qt-Anwendung ohne grafisches > Display (Xserver, etc) starten ? Ja, mit Qt4. > Mein letzter Versuch bei qt3 > schlug da fehl. Korrekt. qt3 braucht eine Gui. AFAIK startete Qt ja wohl auch als GUI-Framework und hat zumindestens bis Qt3 sein Hauptaugenmerk darauf. Dinge wie SQL-DB-Anbindung, XML und Netzwerk-Connectivity sollten dem Anwendungsentwickler einfach nur die Arbeit erleichtern, bzw. dafuer sorgen dass er nicht noch 4 andere Libs und deren Strukturen verstehen muss. > Deshalb mußte ich bei einer Anwendung, die ich > eigentlich nur GUI-frei machen wollte, sämtliche Qt-Abhängigkeiten > entfernen. Sowas war ich eigentlich nur aus der Teletubbi-Welt > gewohnt ... aber der Kommerz-Stumpfsinn hat eben schon längst > auch in der OSS-Welt einzug gehalten :( Wenn ich zu Qt3 Zeiten eine Applikation ohne GUI haben haette wollen haette ich sowieso auf Qt verzichtet, von vorneherein. Soo umwerfend sind die restlichen Spaesse in der Lib naemlich auch nicht. Da kann man ruhig ueber ne Alternative nachdenken. > Psychische Defizite der breiten Masse dürften wohl die Hauptursache > darstellen ... ACK. Das merkt man auch immer mal wieder in dieser ML, Lernresistenz und Faulheit kriegt man halt nicht so leicht weg. Duerfte aber auch nicht nur durch Software gepraegt werden, auch durch alle andalle anderen Lebensbereiche. Andreas -- You will be married within a year, and divorced within two. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
