On 06.03.06 14:49:04, Enrico Weigelt wrote: > * Andreas Pakulat <[EMAIL PROTECTED]> schrieb: > > > 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. > > Nein, damit sich die Qualität erhöht, und mehr Menschen die > Distro mit geringerem Aufwand für eigene Anpassungen nutzen können. > > Harte QM-Anforderungen bedeuten nicht zwangsläufig, daß diese > von weniger Paketen erfüllt werden, sondern allenfalls daß es etwas > länger dauert - für eine stabile Distro nicht unbedingt so schlimm.
Das wuerde bedeuten alle Maintainer muessen QM betreiben... Das klappt eventuell noch bei den freien Distro's wenn du wirklich ein Distro-uebergreifendes QM-Projekt schaffst (weil dann wieder genug Leute da sind die sich ums QM kuemmern koennen). Wie das aber bei den kommerziellen aussieht kann ich ueberhaupt nicht einschaetzen. > Ich gehe mal davon aus, daß der Paket-Maintainer dem Entwickler-Team > gleich mitteilt, wenn er einen Fehler findet, und vielleicht ist er ja > selbst im Team und kümmert sich gleich drum. Zumindestens in Debian ist es so, wenn festgestellt wird (meist durch den DM) dass ein Debian-Bugreport eigentlich ein Upstream-Problem ist und Upstream sich als kooperativ erwiesen hat macht er ein followup-to-upstream oder bittet (wegen z.B. Nicht-Reproduzierbarkeit) den bug-reportenden User Upstream einen Bugreport einzureichen. Oftmals klappt das, aber AFAIK manchmal auch nicht. Es duerfte durchaus eine Reihe von Bugreports geben wo sich der Reporter nach der initialen Mail nicht mehr meldet... > > > + 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. > > Ich kenne viele Pakete, zT. grundlegende Pakete, die sich nicht so > einfach bauen lassen. Ich nicht (aka, ich hab noch keine Zeit fuer LFS auf x Architekturen gehabt). Ich "hoere" aber immer mal wieder das alles abseits von i386, PPC und ia64/amd64 richtige Probleme machen kann... > Möglicherweise pflegen da einzelne Distros ihre eigenen Branchen > bzw. Patches, mit denen das geht (so wie ich das ja auch tue), aber > es scheint nicht rechtzeitig in den Mainstream zurückzufließen. Debian-Pakete haben dafuer einen recht guten Mechanismus, die Patches werden innerhalb des Debian-Source-Pakets gehalten (dazu gehoert der upstream-source, eine Beschreibungsdatei und ein diff.gz mit den diversen Debian-spezifischen Aenderungen). > Ich denke, daß solch ein Projekt für alle Distros nützlich > sein dürfte, da diese dann nicht mehr ihre eigenen Patches pflegen > müssen. Demzufolge sollten dann auch aus den einzelnen Distros > hinreichend viele Leute mitmachen. Dann solltest du mal ein entsprechenden Proposal auf die Distro-devel-Listen setzen und schauen wie die Resonanz ist. > > > + 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. > > Das ist aber schlecht. Stattdessen sollte es eine *neue* library geben > (aus libfoo wird libfoo2), oder mit anderen Worten: das Major-Release > steckt im Libnamen. Einige Projekte arbeiten schon lang so. Stimmt. Bin gespannt wie KDE das machen wird... > > > > > 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. > > Ja, auf einigen Plattformen gibt es das, aber nicht überall. Aha, ich sehe schon ich hab bisher zu wenig platformuebergreifende Entwicklung betrieben (auch weil ich nur die eine habe, bzw. noch Windows)... > Außerdem besteht eine lib oft aus mehr als nur dem shared object. Jupp. s.o. ein wenig zu wenig nachgedacht ueber alle Konsequenzen (Doku wird sich ja evtl. auch aendern). > Der Aufwand für die Pflege mehrere Branchen sollte sich in engen > Grenzen halten, wenn man die Pakete nicht so groß macht. Ich hab mich mit CVS nicht allzulange beschaeftigt aber IIRC ist das branchen dort nicht unbedingt einfach/guenstig... Bzgl. der Pflege kommt es halt drauf an wie gross die Aenderungen sind und wieviele Leute mithelfen, denke ich. Bei wenig Leuten werden "uninteressante" oder alte Branches vllt. schnell vernachlaessigt. > > Major Releases werden genau deswegen gemacht, weil man die ABI und die > > API brechen muss um neue Dinge einfliessen zu lassen. > > Soweit okay. Aber dann sollte das Paket die Major-Version im Paketnamen > haben. Vielleicht sollten wir dieser noch etwas weiter unterscheiden: > > + Allgemeiner Name (zB. "OpenSSL) -> für den User > + Kanonischer Name (zB. "openssl") > + Major-Revision: 1,2,3 ... > + Voll qualifizierter Kanonischer Name (zB. openssl-1) -> für Deps. > > Dabei muß aber auch sicher gestellt werden, daß verschiedene > Majors parallel existieren können. Nunja, das ist ja wieder eine Sache die die Installationsprozedur vorschreibt... Existierende Applikationen/Libs die sich ordentlich nach <irgendeinpfad>/<beliebigerName> installieren lassen und dort drunter die benoetigte Verzeichnisstruktur erstellen sind relativ leicht parallel installierbar. Das groesste Problem dann ist aufzupassen (aber das macht ja dann das Buildsystem) dass die darauf aufbauende Applikation nicht die falsche Version nimmt. Allerdings gibts auch teilweise Probleme, z.B. bei Python Packages. Wenn die nicht ueber distutils/ez-setup sondern mit anderen Methoden (z.B. PyQt nutzt selbstgeschriebenes configure.py und daraus generierte Makefiles) installiert werden wird eine Parallelinstallation von verschiedenen Versionen erschwert. > > Ich weiss nicht wie das bei anderen Projekten aussieht und entschuldige b > > itte 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. > > Grade bei KDE verstehe ich nicht, warum man sich immer gezwungen > sieht, solche "großen Würfe" machen zu wollen. Weil eben nur eine begrenzte Anzahl Entwickler da sind und diese schaffen es nicht frueher. Uebrigens soll die KDELibs API bis Ende des Jahres (evtl. sogar schon Oktober) so stabil sein, dass Anwendungsentwicklung damit "gestartet" werden kann. (ja, ja ich weiss, das ist ne Beta-Version mit der entwickelt man keine Anwendungen). > Man hat manchmal ein Eindruck, daß es sich um ein riesiges > Mammut-Projekt, anstatt vieler einzelner handelt. Das ist ja in gewisser Weise auch richtig, weil zu einem KDE-Release eben ein komplettes DE geliefert werden soll. > Übrigends einer der wesentlichen Gründe, warum ich nichts > von KDE halte. Bei GNOME scheint mir das bei weitem nicht so schlimm, > obwohl einige Paketen (zB. glib+gtk) auch schon viel zu überzüchtet > sind. Auch kdelibs besteht aus mehreren Teilen. Allerdings lassen die sich nicht einzeln, losgeloest von KDE benutzen. Jedenfalls nicht in KDE3. Fuer KDE4 ist aber geplant eine strengere Trennung in "Core", "Ui" usw. vorzunehmen, so dass KDE-Technologie auch ausserhalb reiner KDE-Anwendungen genutzt werden kann (z.B. KIO). > Mir scheint, es liegt dem ein Streben nach einer superlativen > eierlegenden Wollmilchsau zugrunde. Evtl. resultiert dieses wiederum > aus dem Großgruppen inherenten Drang zur Gleichschaltung ... Das gilt IMHO im DE-Bereich allgemein. Man will nunmal das ultimative DE fuer alle herstellen. Ja das ist ein Streben nach Windows-Aehnlichkeit und nein ich finde das nicht immer gut. > > > > 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. > > Nein, aber ich habe einige grundlegende Methodiken und Prinzipien. > > Sagt Dir "design by contract" etwas ? Jupp. Ich hab ja Softwaretechnik gehoert *bruest* ;-) Im Ernst mir ist prinzipiell schon klar was du meinst. Ich denke ein Problem duerfte sein, dass dies nicht fuer alle (alteingesessenen) Entwickler gilt. Und der Mensch ist von Natur aus traege, er lernt keine neuen Kunststuecke mehr (oder nur sehr ungern). > Sagt Dir (strikte) "Modularisierung" etwas ? Ja auch das ist mir ein Begriff. > An Deinem Beispiel Qt: > > Die Basis-Bibliothek (libqt) enthielte dann nur ein paar ganz > grundlegende Basis-Typen, (QObject, etc). Die heist bei Qt4 libQtCore.so enthaelt u.a. QObject, QString, den Meta-Object-Spass und IIRC auch die Container-Geschichten. > Weder widgets noch andere > komplexe Typen haben hier etwas zu suchen - das kommt in eine > andere Library und ggf. sogar in ein separates Paket. UI ist in libQtGui, dann haben wir noch libQtXml, libQtNetwork und libQtSql. Alles Qt4. Qt3 hat sowas nicht "gebraucht" (in der Tat war der Schrei der Nutzer so gross, dass es fuer Qt4 umgesetzt wurde). > Aber ganz prinzipiell halte ich für ein System wie Qt/KDE einen GC für > Grundvorraussetzung. Das würde die Code-Komplexität, Du meinst die Destruktoren der Klassen waeren leer? Eventuell noch einige Stellen an denen, Dialoge auf dem Heap erzeugt werden, aber noch in derselben Funktion wieder geloescht werden (was aber auch Bloedsinn ist, da Qt dafuer ein passendes Flag bereithaelt - DeleteOnClose) > und damit auch die Fehlermöglichkeiten und damit verbundenen > Arbeitsaufwand, massiv zu reduzieren. Hmm, QObjects und alle UI-Elemente sind bereits mit GC ausgeruestet. Zumindestens in der einfachen Form, dass sobald das Elternobjekt verschwindet sie auch geloescht werden. Wenn ich also ein Fenster schliesse und es mit DeleteOnClose auch geloescht wird, werden dessen Ressourcen wieder freigegeben. So ein Monster ist KDE im Speicher glaube ich gar nicht (mehr), OOo und X11 selbst druecken (hier jedenfalls) viel eher. > > 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. > > Genau hier haben wir ja ein massives Problem in gängiger SWE: > Es wird viel Zeit damit vergeudet, irgentwelche memleaks zu finden, > die bei sauberer Strukturierung (und dazu gehört ab einer gewissen > Graphenkomplexität auch ein GC) grundlegend vermieden würden. Was ich von GC immer hoere ist, dass es die Programme langsamer macht. Selbst hab ich dazu erstmal keine Meinung, weil ich keine ausreichenden Erfahrungen damit gesammelt habe... > Ich kenne jetzt keine wirklich brauchbaren Statistiken, aber aus > eigenen Projekten weiß ich, wieviel Zeit ich durch (zT. natürlich > auch selbst verschuldeter) unsauberer Strukturen im Debugging > verbrennen mußte. Jetzt im Nachhinen weiß ich, daß es zT. > besser gewesen wäre, das eine oder andere Projekt neu zu programmieren. Ja, genau das habe ich gemacht. Eines ist bisher noch nicht neu angefangen worden (nach dem 3. Fehlversuch), das andere wurde beim 2. Anlauf fertig. Beim 3. bin ich dabei den 3. Anlauf gleich in einer neuen PS zu schreiben. > > > 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. > > Oh, da hat man ja sehr schnell reagiert - wie viele Jahre gibts > Qt nun schon ? ;-o Ich denke 10 Jahre, Qt3 ist aber IIRC nur etwa 3 oder 4 Jahre alt. Qt2 kenn ich nicht. Und es wird auch erwartet dass Qt3 noch eine Weile weiter besteht, da die Portierung zu Qt4 beinahe einem Rewrite der Applikation (jedenfalls bei was komplexerem als Hello World) gleichkommt. > > 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. > > Eierlegende Wollmilchsau. Man baut eine 5te Struktur, damit man die > vier existierende nicht verstehen muß ... irgentwie widersinnig. Nunja, man kann die von Qt definierten Datentypen weiterverwenden und muss sich nicht mit den diversen DB-Lib-API's rumaergern. > Okay, wenn man schon unbedingt schon ein paar Qt-Konzepte haben will > (zB. die Signals) in einer SQL-Library braucht (warum auch immer ...), Ich glaube weniger Signals, aber z.B. Qt Datentypen wie QString, QByteArray, QDate. Ich muss ansonsten die Konvertierung von char* selbst durchfuehren, das nimmt mir Qt an der Stelle ab. > warum dann nicht ein separates Qt-SQL, das auf Qt aufbaut, und evtl. > sogar gleich vorhandenes und erprobtes (unixODBC) wiederverwendet ? s. Qt4, das gibts jetzt. ODBC-Treiber haben sie IIRC auch. Andreas -- Bank error in your favor. Collect $200. -- 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)
