Rhonda's Blog

Screenshots auf packages.debian.org

Rhonda — Fri, 20 Aug 2010 06:40:00 EDT

Die Leute wollen oft gerne wissen, wie eine Anwendung aussieht, bevor sie sie installieren. Das ist einer der Gr�nde, warum Christoph Hass den screenshots.debian.net-Dienst ins Leben gerufen hat. Man kann dort Screenshots f�r seine Lieblingsanwendungen hochladen, damit auch andere sie sehen k�nnen.

Schlussendlich sind diese nun der Einfachheit halber auch auf packages.debian.org integriert. Wenn ihr auf den Screenshot eines Pakets klickt, k�nnt ihr alle anderen verf�gbaren sehen.

Falls es noch keinen Screenshot gibt, wird die Seite ein Platzhalter-Bild anzeigen, das die screenshots-Seite des Pakets verlinkt, auf der ihr zum Nutzen aller einen Screenshot hochladen k�nnt. Bitte beachtet die Richtlinien beim Hochladen, sonst k�nnte das Bild abgelehnt werden.

Zu einem nicht komplett anderem Thema, die packages.ubuntu.com-Seite zeigt endlich ebenfalls Pakete aus maverick an. Sie zeigt jedoch noch keine Screenshots – falls ihr denkt, dass das Hinzuf�gen von Screenshots dort ebenfalls eine gute Idee w�re, lasst es mich bitte wissen!

Genie�t es!

/debian | permanent link | Comments: 5 |

Jerboa

Rhonda — Wed, 18 Aug 2010 07:52:00 EDT

Vor geraumer Zeit war ich mit meiner anderen H�lfte auf einem Konzert einer Band, die ich sp�ter mal empfehlen will. Dieses mal will ich jedoch die Vorband des Konzerts erw�hnen: Jerboa. Es war schon ein wenig seltsam, eine einzelne Person auf der B�hne zu sehen, die an einigen Kn�pfen herumgedreht hat, aber er hat unsere Aufmerksamkeit und unsere Herzen rasch eingefangen. Ebenfalls war es sehr nett, mit ihm im Nachhinein zu reden, als wir seine CD gekauft haben. Er verdient auf jeden Fall eure Aufmerksamkeit, und falls ihr es schafft, ihn Live zu sehen, nehmt die Chance wahr.

Number 1: Das offensichtliche erste Lied in der Liste. Perfekter Groove mit ebenfalls gro�artigem Video.
Running North (remix): Ebenfalls ein interessantes Produkt seiner Kreativit�t.
Just Another Number: Es beginnt recht ruhig, zieht dann aber enorm an. Es f�llt schwer, seinen Kopf bei diesem Lied nicht mitnicken zu lassen, und es ist sehr weit davon entfernt, lediglich nur eine weitere Nummer zu sein.

Tats�chlich h�tte ich gerne What if in der Liederliste mit erw�hnt, aber ungl�cklicherweise war das Lied nicht verf�gbar und ich musste mich nach einem Ersatz umsehen.

Genie�t es!

/music | permanent link | Comments: 2 |

Alles Gute zum 17. Geburtstag, Debian!

Rhonda — Mon, 16 Aug 2010 09:47:00 EDT

Alles Gute zum 17. Geburtstag, Debian! Du hast mich die letzten 10 Jahre auf Trab gehalten und ich freue mich wirklich darauf, was die n�chsten 10 Jahre in unserer Beziehung passieren wird.

Mein Dank gilt auch an all jene Leute, die es schaffen, ruhig zu bleiben und in Diskussionen auf den Punkt kommen, wenn diese hitziger werden. Ihr seid diejenigen, die das Arbeiten an Debian erfreulich macht.

Ebenfalls ein riesigen Dank an jene Leute, die die Kraft von positiver Ermutigung, wie sie derzeit auf der thank.debian.net-Website flie�t, verstanden haben.

Ebenfalls vielen herzlichen Dank an die immer gr��er werdende Anzahl an Distributionen, die auf Debian basieren, da dies ein Akt der ganz besonderen Wertsch�tzung unserer Arbeit darstellt.

Danke an euch alle!

/debian | permanent link | Comments: 0 |

Wieso das neue Design noch nicht online ist

Rhonda — Thu, 12 Aug 2010 11:09:00 EDT

Dieser Blog-Eintrag ist eigentlich eine Antwort auf einen Vortrag, der letzte Woche auf der Debian-Konferenz abgehalten wurde. Es war Margas Vortrag �ber Making Debian Rule, again. Jetzt da die Beta-Versionen der Vortr�ge zum Herunterladen verf�gbar sind, ist es mir m�glich korrekt zu zitieren, worauf ich mich beziehe: Gibt es einen Grund, warum wir die Website noch nicht aktualisiert haben?, vielleicht kann das jemand beantworten.

Ich denke es ist notwendig, darauf zu reagieren, da ich die Hauptperson bin, die die Sache vorantreibt. Ungl�cklicherweise wurde die Frage in einem Vortrag gestellt, bei dem niemand der daran beteiligten Personen anwesend war, statt sie an eben diese Personen direkt zu richten, und die Frage wurde mir vor dem Vortrag nicht zugeschickt, um eine Antwort f�r die Pr�sentation bieten zu k�nnen. Als besonderer Hinweis m�chte ich anmerken, dass dies meine eigene Sicht der Dinge ist und sich nicht notwendigerweise mit der der anderen beteiligten Personen decken muss. Ich hoffe, dass es trotzdem als eine Antwort angesehen werden kann.

Kleiner Hintergrund dazu, Kalles Vorschlag hatte schon viel geschafft, bevor ich �berhaupt �ber ihn gestolpert bin. Ich war einfach nur begeistert davon, und das nicht nur weil es eine gro�artiges Modell f�r die Seiten ist (und das ist es tats�chlich, meiner Meinung nach), sondern auch �berlegungen dazu enthielt, wie man nicht nur die Hauptsite sondern auch mehrere Untersites eingliedern k�nnte. Ebenfalls enthielt es Patches, was das direkte Anwenden stark vereinfachte.

Ich fing an, daran zu arbeiten, und mir wurde vorgeworfen, dass ich demotivierend bin, weil ich das tat, und au�erdem dass es eine ordentliche Abstimmung ben�tigen w�rde statt einfach so umgesetzt zu werden, aber das f�llt wieder unter den Kommunikations-Stil von Debian. Ich hab trotzdem nach und nach einige Test-Sites aufgesetzt, um mich damit zu spielen. Einige haben besser funktioniert (wie bei git, obwohl diese zuletzt gekommen ist und Kalle die CSS �ber die Zeit hinweg recht gut verbessert hat), einige waren noch nicht fertig (wie das wiki, dem z.B. die Einf�rbung f�r Versionsunterschiede fehlte, oder bei packages, wo die Unterscheidung zwischen den verschiedenen Abschnitten nicht sonderlich sichtbar ist). Die Zeit verging, andere Dinge forderten ebenfalls ihre Aufmerksamkeit ein.

Wie zum Beispiel dass unsere System-Administratoren mich dazu aufgefordert haben, einen neuen www-master-Server neu aufzusetzen. Da die Dokumentation der ben�tigten Pakete f�r die Webseiten ziemlich unvollst�ndig waren (um es freundlich zu formulieren) hat dies auch einiges an Aufmerksamkeit ben�tigt, speziell ist der Wunsch, die Abh�ngigkeiten sauber zu dokumentieren einfach offensichtlich, wenn man quasi von Null beginnt. Es gibt dabei nach wie vor einige Probleme, wie z.B. auf dieser Seite in der leeren Tabelle am Ende zu sehen ist. Das selbe Problem tritt auch auf meiner Testsite f�r das neue Design auf.

Der letzte Teil ist jedoch derzeit die gr��te Blockade f�r beide Anstrengungen. Es gibt keine M�glichkeit, in eine der beiden Richtungen weiterzugehen, ohne das gel�st zu haben. Simon Paillard hat gro�artige Arbeit dabei geleistet, die Umstellung voranzutreiben und den Thread �ber die Notwendigkeiten f�r den Server-Move, den ich auf der debian-www-Liste angesto�en habe, aktuell zu halten. Ungl�cklicherweise haben sowohl Kalle, Simon als auch ich einige private Zeitbeschr�nkungen (neben anderen Pflichten, die ihre Aufmerksamkeit ben�tigen), was nicht sonderlich hilfreich dabei ist, die Sache rascher voranzutreiben. Ungl�cklicherweise waren nicht sonderlich viele Leute daran interessiert, sich einzubringen, weil es nat�rlich einfacher ist, dem komplett falschen Publikum die Frage zu stellen, warum es noch nicht fertig ist.

Ich habe vor, viele Sites gleichzeitig umzustellen statt einer nach der anderen, einfach wegen dem Effekt aber auch, um weniger Ablenkung f�r die Benutzer zu produzieren, inklusive dass weniger Leute laufend nachfragen werden, wann diese oder jene Site ebenfalls umgestellt wird. Zumindest brauchen wir eine endg�ltige Diskussion dar�ber, welche Links an den Anfang und das Ende der Seiten hinein geh�ren, bevor die Umstellung passieren kann. Und einige sind immer noch der Meinung, dass so eine Umstellung etwas ist, das wir ohne eine Abstimmung einfach so entscheiden d�rfen, was ebenfalls mit ein Grund ist, warum wir es nicht einfach umgestellt haben.

Ich hoffe, das beantwortet die Frage hinreichend – und wie gesagt, wenn sie mir vor dem Vortrag gestellt worden w�re, h�tte man im Vortrag bereits eine Antwort pr�sentieren k�nnen, statt nur einem kurzes Kommentar �bers IRC �bermittelt zu bekommen (danke, Yoe!), da ich das Gl�ck hatte, mir die Zeit freizunehmen und den Vortrag ansehen zu k�nnen. Seid herzlich dazu eingeladen, es auf deban-www weiter zu diskutieren oder eure Hilfe anzubieten, insbesondere, wenn ihr damit vertraut seid, an CSS-Dateien zu arbeiten.

/debian | permanent link | Comments: 3 |

Zur Verwendung des BTS

Rhonda — Mon, 09 Aug 2010 13:15:00 EDT

Vielleicht erinnert ihr euch daran, dass ich damit begonnen habe, Release-kritische Fehler in stable zu schlie�en. Den Einsatz daf�r hab ich nicht eingestellt, daher hab ich beim RC Bug Squashing Contest mitgemacht, der w�hrend der Debian-Konferenz stattgefunden hat (an der ich nicht teilnehmen konnte). Die Regeln haben dies erlaubt, selbst wenn ich mir bewusst war, dass es nicht mit den Leuten verglichen werden d�rfte (oder sollte), die an unstable/testing arbeiten, und es wurde eine eigene spezielle Kategorie daf�r erstellt.

Es gibt jedoch offenbar nach wie vor einiges an Verwirrung dar�ber, wie das die Fehlerdatenbank (BTS) arbeitet, speziell in Bezug auf die Verfolgung von Versionen. Mir wurde sogar vorgeworfen, dass ich f�lschlicherweise das Schlie�en von Fehlern f�r mich beansprucht h�tte, da der Fehler bereits von jemandem anderem geschlossen wurde. Dies war jedoch nicht der Fall, sonst h�tten die Fehlerberichte bereits vor langer Zeit archiviert sein m�ssen^[1] – da ich von jener Person erwartet h�tte, dass sie wei�, wie das archivieren von Fehlern funtioniert und auch aufgrund der enormen Anzahl von Fehlern, die ich f�r stable einfach schlie�en konnte, ist es wohl notwendig, das ganze breiter zu beleuchten, wieso manche Fehlerberichte nicht wie erwartet archiviert werden.

Falls ihr meinen IRC-Vortrag zur Verwendung des BTS im letztem Monat gefolgt seid, d�rftet ihr wohl schon eine Idee dazu haben, was vorsich geht. Es gibt mehrere unterschiedliche Gr�nde, warum Fehlerberichte noch nicht zum Archivieren markiert sind. Ich versuche diese hier erkl�ren soweit ich sie w�hrend meiner Arbeit an Fehlern �ber die vergangenen 10 Jahre hinweg verstanden habe (da ich weder in den debbugs-Code geschaut noch mit dessen Entwicklung zu tun habe).

�blicherweise werden Fehler zum Archivieren markiert, wenn sie testing nicht betreffen. Das bedeutet, dass ein Fehler, der gegen eine Version, die sich nur in unstable befindet und in unstable behoben wird, direkt zum Archivieren freigegeben wird (tats�chlich nicht ganz so direkt: Das Paket muss auf allen Architekturen, f�r das es verf�gbar ist, ebenfalls synchron sein); anderenfalls muss die Reparatur des Fehlers nach testing rutschen, bevor der Fehler zum Archivieren in Betracht gezogen wird.
Manchmal wird der Fehler jedoch immer noch als unstable betreffend angesehen, selbst wenn eine reparierte Paketversion bereits nach testing gewandert ist. Dies ist der Fall, wenn das Paket auf hurd-i386 in unstable veraltet ist und kann in der �bersicht des Pakets auf packages.debian.org herausgefunden werden, dort ist ein roter Eintrag neben den gr�nen zu sehen (die roten Eintr�ge f�r die debports-Architekturen k�nnen jedoch ignoriert werden!). Ihr m�sst daf�r dann ein architekturspezifisches L�sch-Ansuchen melden, um diese Fehler archiviert zu bekommen.
F�r Pakete in experimental ist die Situation recht �hnlich, abgesehen davon, dass Pakete von experimental nirgendwohin automatisch rutschen und daher durchaus f�r geraume Zeit unarchiviert bleiben k�nnen, falls diese Fehler auch unstable betreffen.
Was kann also der Grund sein, wenn die Behebung bereits in testing verf�gbar ist, der Fehler aber immer noch nicht archiviert wird? Diese F�lle bedeuten, dass der Fehler f�r stable als relevant erachtet wird und dort ebenfalls zu beheben ist. Fehler, die daf�r herangezogen werden, haben einen release-kritischen Schweregrad; Fehler mit geringerer Schwere werden als f�r stable nicht relevant erachtet, da es unwahrscheinlich ist, dass diese in stable behoben werden und werden daher archiviert. Was kann man aber gegen diese Fehler tun?
- Betreffen sie stable tats�chlich? Solche Fehler zu bearbeiten ist, was ich die letzten Monate gemacht habe. Sie werden h�ufig f�r �nderungen in Bibliotheken, FTBFS (baut nicht mehr vom Quellcode) oder bei �nderungen in den verwendeten Hilfsprogrammen gemeldet, oder andere Dinge, die f�r stable nicht anwendbar sind. Diese in stable zu schlie�en ist einfach:
  - Wenn die Versionsinformationen verloren gegangen sind (durch eine Neuzuordnung oder �hnliches), ist es lediglich notwendig, die found-Version wieder hinzuzuf�gen, falls diese h�her ist als jene in stable.
  - Wenn die Versions-Informationen korrekt sind (da in unstable immer noch die gleiche Version zum Zeitpunkt des Meldens vorhanden ist), kann man sie mit + squeeze sid markieren, was dem BTS mitteilt, den Fehler nur f�r diese Releases zu erachten und daher nicht mehr denkt, dass es lenny ebenfalls betrifft.
- Einige betreffen stable, sind jedoch nicht schwerwiegend genug, um eine Aktualisierung des Pakets in stable zu rechtfertigen (z.B. f�r Dokumentations-Korrekturen in debian/copyright oder �hnlichem). Wenn ihr solche findet, kontaktiert bitte das Release-Team, um diese mit mit lenny-ignore markiert zu bekommen, tut das nicht selbst, da diese Markierung nur vom Release-Team zu setzen ist!
- Falls die Fehler stable tats�chlich ebenfalls betreffen (z.B. bei Sicherheitsproblemen, die vom Sicherheitsteam jedoch als zu gering erachtet werden, um daf�r ein DSA herauszugeben, oder andere schwerwiegende Bedienbarkeitsprobleme), portiert die entsprechende Reparatur daf�r zur�ck, schlagt dem Release-Team auf ihrer Mailing-Liste ein diff vor und ladet es nach lenny-proposed-updates hoch, um es in der n�chsten Aktualisierung von stable repariert zu bekommen.

Ich hoffe, dass dieser Artikel auch andere dazu animieren wird, Fehler in stable zu beheben. Tats�chlich schicke in den Betreuern von Paketen, deren Fehler in die letzte Kategorie fallen, einen Hinweis, dass diese zu beheben w�ren. Einige von euch d�rften bereits solche Hinweise erhalten haben und ich bin all jenen dankbar, die sie tats�chlich dankbar aufgegriffen und bereits einige davon ebenfalls behoben haben. Vielen Dank daf�r, dass ihr stable zu einem besserem Ort macht!

Um auf den RCBC zur�ckzukommen, es war ein interessanter kleiner Wettbewerb (wenn auch nur in meinen Gedanken) zwischen mir selbst und jenen, die an RCs in testing/unstable gearbeitet haben. Es w�re nett gewesen, in stable zumindest genausoviele Fehler wie in testing/unstable geschlossen zu bekommen, da die Anzahl immer noch um einiges h�her ist, aber ich bin erfreut �ber die geschafften Dinge. Und es tut gut zu wissen, dass es nicht jeder als verschwendete Liebesm�he ansieht, die RC-Anzahl in stable kleiner zu bekommen (wie mir ebenfalls f�r meinen Einsatz gesagt wurde). Vielen Dank daher auch aus diesem Blickwinkel!

^[1] Es sind derzeit 2688 Fehler immer noch nicht archiviert, die bereits letztes Jahr geschlossen wurden! Diese Abfrage der UDD kann euch helfen:
select count(*) from bugs where status = 'done' and last_modified <= '2009-12-31';

/debian | permanent link | Comments: 0 |