Hallo Guido, *, On Sat, Dec 10, 2005 at 11:06:09PM +0100, Guido Ostkamp wrote: > Christian Lohmaier <[EMAIL PROTECTED]> wrote: > [...] > > Genau. Aber was nützen öffentliche Betas, Release Candidates (und > > auch die Milestones) wenn die keiner anschaut/keine Issues > > geschrieben werden? > > Entschuldige mal, aber das kannst Du nicht ernst meinen?!?
Doch. > Ich und andere sind nicht "keiner". Wir haben sie angeschaut und es > wurden Issues geschrieben - rechtzeitig. Nur wurden die einfach > ignoriert. Rechtzeitig ist relativ. In der RC-Phase ist es eigentlich schon zu spät. Bugs die als Showstopper gelten können sollten da schon nicht mehr zu finden sein (und die meinte ich in erster Linie). Und "ignoriert" ist vielleicht das falsche Wort. Wir haben mehrere hundert issues die auf eine Bearbeitung warten, bei weitem aber nicht genug Entwickler um jeden einzelnen zu beheben. > > Du willst die neue Version in 3 Jahren haben? - Dann deinstalliere > > die 2.0, nutze die 1.1.5... Und höre Dir die ewig gleichen > > Beschwerden an (von Features die in der 2.0 drin sind, in der 1.1.5 > > aber fehlen, von Fehlern die schon längst gefixed sind, etc). > > Ich möchte eine Version, die zumindest keine Bugs enthält, mit denen > man sich augenblicklich bis auf die Knochen öffentlich blamiert; das > ist alles. > > Bugs haben im Übrigen mit Features, die Du oben ansprichst, nichts zu > tun - fehlende Features beeinträchtigen nämlich nicht die Stabilität > oder Nutzbarkeit im Rahmen der bestehenden Spezifikation. Nichts mit Bugs, aber mit Benutzbarkeit. PDF export mit Inhaltsverzeichnis z.B., die System-Integration, die xml-Formulare, etc. sind ein Grund die 2er Linie einsetzen zu wollen. Und klar hat das was damit zu tun, schließlich habe ich von den Beschwerden die kommen gesprochen. Und den Leuten ist es egal ob das worüber sie sich beschweren ein fehlendes Feature oder ein Bug ist. > > So ziemlich jeder schreibt in einen Issue "der ist sooo wichtig, der > > muß unbedingt ins nächste Release!!!1!!1!" Auch wenn der Fehler > > bekannt war wurde er ganz klar falsch eingeschätzt. Kann passieren. > > Weder auf der qa-Liste noch auf der release-Liste wurde dieser > > Fehler erneut angesprochen. > > Schön, das auf diese Weise IssueZilla als unzureichend deklariert > wird. Das man auch noch auf einer Release Liste Bugs erwähnen muß, war > mir bis dato nicht bekannt, aber ich werde es mir merken. Sofern der issue release-relevant ist und noch kein target hat, dann ja. Schließlich bleibt die Zeit nicht stehen bis der Issue gecheckt worden ist. > > Klar, rummeckern ist immer leichter als sich aktiv am QA-Prozeß zu > > beteiligen. > > Wovon redest Du, bitte? Das ich getestet und einige Issues geschrieben > und bestehende kommentiert habe ist wohl für Dich kein aktives > Beteiligen am QA-Prozeß, oder? Doch. Aber die meisten kratzen nur an der Oberfläche. Deine 10/15 Issues in allen Ehren, aber nur den Issue allein zu schreiben bzw. einen Kommentar zu einem anderen Issue absetzten reicht halt leider nicht immer. Nochmals: Will man was am target-milestone ändern, muß die Liste angesprochen werden. Issues mit einem sptäteren TM schauen die Entwickler i.d.R. erst dann an wenn sie den Stapel mit den früher fälligen Issues abgearbeitet haben. Da nützt es nix sich Kommentare im Issue zu verlassen. (Oft kann/darf der Entwickler auch nicht selbst über den TM entscheiden). Das Verhältnis zwischen offenen Issues/vorhandene Ressourcen ist einfach zu schlecht um das ohne die Liste zu regeln. Und das impliziert natürlich auch daß nur die wirklich wichtigen Issues auf der Liste landen sollten. > > Fakt ist daß der aktuelle Stand des codes jederzeit verfügbar ist > > (die Milestones), daß es Betas gab, daß es mehrere RCs gab. Trotzdem > > sind die Fehler halt keinem aufgefallen. > > Wie bitte? Wie ich schon schrieb sind die Bugs mindestens 5 Leuten > inkl. mir aufgefallen und zwar weit vor der Freigabe von OOo 2.0.0. /Die/ bugs? Zu dem Numerierungsbug siehe oben bzw. unten und die Mail auf die Du geantwortet hast. > > Das Problem mit der Kapitelnumerierung fällt ja auch nicht auf wenn > > man nur versucht "funktionierts, funktionierts nicht" sondern erst > > wenn man sie wirklich intensiver nutzt. > > Definiere mal 'intensiv'. Das ist auch relativ. Es reicht schon: "Nicht nur oberflächlich ausprobieren so wie in es in der evtl. vorhandenen Testbeschreibung steht" > Es reichte bei mir völlig aus, aus einem > alten Dokument per Cut'n Paste ein Kapitel in ein neues > rüberzukopieren. Außerdem stolpert da quasi jeder drüber, der mehr als > zwei Seiten Brief schreibt und daher Überschriften einsetzt. Eben. Aber wie Du selbst bemerkt haben dürftest ist OOo ein großes Projekt, es gibt auch nicht nur den Writer sondern auch andere Komponenten. Damit die wenigen Leute mit der Release-QA fertig werden, werden halt die Funktionen mal ausprobiert, mehr nicht. Da fehlt einfach die Zeit/Manpower. > Ich würde meinen, selbst ein einfacher Komponententest des > implementierenden Entwicklers hätte diese Bugs finden müssen. Is aber nicht gefunden worden. Und als er gefunden wurde wurde er falsch eingeschätzt (falsches Target) und keiner hat aufgemuckt. Siehe oben. > >> Je mehr basisnah eine Funktionalität ist, desto wichtiger ist sie > >> auch. Bsp: Wenn schon triviale Dinge wie Backspace oder > >> automatische Nummierungen nicht funktionieren, brauche ich mir um > >> exotischere Dinge wie gesperrte Schrift, Kapitälchen, Marginalien, > >> Kerning, Schusterjungen, 3D Effekte etc. erst recht keine Gedanken > >> mehr zu machen. > > > > Das ist nettes bla,bla (sorry). Das ist sowas von klar. > > Offenbar nicht, denn sonst bräuchte es keine von Dir angeregten > Extra-Erwähnung auf der release Liste, damit solche trivialen Dinge > endlich korrigiert werden. Wenns so trivial ist, dann mach halt einen Bugfix/Patch. Issues beheben sich nicht von alleine. Und auch auf die Gefahr hin mich zu wiederholen: Die Ressourcen sind begrenzt. Damit die Entwickler eine Auswahl treffen können "wichtig oder nicht", muß sich die Community rechtzeitig zu Wort melden. Wir haben z.Zt. 5245 offene Bugs (defect und new oder unconfirmed, mit den Feature requests und RFEs fang ich erst gar nicht an) und nicht einmal ein zehntel Entwickler (viiiieeeel weniger). Man kann nicht von einem Entwickler erwarten daß er alle issues durchschaut und mal schaut was denn da besonders wichtig ist oder nicht. Die sind mit den mehr als 1000 bereits in Arbeit befindlichen Issues (started oder reopened) schon reichlich bedient. Wenn die anderen Bugs dann ein Target OOo later oder irgendein anderes späteres Release hat: Warum soll der Entwickler seine Zeit damit verschwenden in dieser Liste nach issues zu suchen wenn er noch eine andere Liste mit issues hat, die bereits das nächste Release als target tragen und noch nicht abgearbeitet ist? > >> In dem Zusammenhang verstehe ich z.B. zur Zeit überhaupt nicht, > >> wieso Import-Bugs wie in Issue #58777 beschrieben einfach auf > >> Target OOo 3.0 gelegt werden. > > > > Es muß auch irgendwer da sein der den Issue beheben kann. > > Programmierer sind rar und die anderen sind schon ausgelastet. > > Nett gesagt. Soll das jetzt heißen, die weitere Bearbeitung von > Dokumenten der vorigen OOo Version ist so unwichtig, daß sie zwei > Jahre warten kann? Das heißt: Ja, manche Bugs werden nicht gefixed. Manche werden mit der Zeit obsolet. Life sucks. Wenn man meint daß das früher gefixed werden sollte, dann muß man sich darum bemühen das target zu korrigieren. Und das geht im Endeffekt nur über die Mailingliste (aus den oben dargelegten Gründen). > Was meinst Du, was eine Firma oder Behörde zu so etwas sagen wird? So > etwas ist völlig indiskutabel, die wollen doch nicht zwei Versionen > von OOo gleichzeitig administrieren und warten müssen. Das ist mir eigentlich egal. Und wie Du darauf kommst daß man deswegen die alte Version behalten muß ist mir auch nicht ganz klar. Zu dem Bug gibt es mindestens vier workarounds: 1) im neuen Format speichern. Wenn sowieso nicht zweigleisig mit der alten Version gefahren wird kann mans ja machen. 2) den Cursor davor setzen und <del> drücken 3) mit <shift>+<links>, <backspace> löschen 4) eine andeere Absatzvorlage zuweisen und dann <backspace> drücken. > >> [...] Auch bei der deutschen Online-Hilfe habe ich momentan nicht > >> den Eindruck, daß sich bei den verschiedenen RC's irgendwas ändert. > > > > Tut sich auch nicht. RCs sind was sie sind: Release Candidates. Da > > wird nicht mehr viel geändert. > > Schön - dann ist es ja auch ziemlich sinnlos groß herumzutesten, wenn > Bugs sowieso nicht mehr rechtzeitig behoben werden. Irgendwann muß durchgeschaut werden. Daß das de-Projekt relativ spät damit angefangen hat ist bedauerlich aber nicht mehr zu ändern. Wenns jetzt durchgecheckt wird ist es dann wenigstens fürs nächste Release fertig. Legt man die Durchsicht auf Eis und fängt erst wieder an wenn das nächste Release ansteht, dann wird es mit Sicherheit wieder zu spät für die Integration. > >>- die dümpelt seit fast 2 Monaten immer noch als unconfirmed herum > > > > issues die unconfirmed sind schaut sich ein Entwickler wenn > > überhaupt nur zufällig an. Zusätzlich ist der genannte issue dem > > falschen Projekt zugeordnet. > > Dann schnarcht also der zuständige Issueverwalter seit zwei Monaten > wohl vor sich hin. Logisch, denn der hat ja nur den einen Issue zu bestätigen. > Und das soll dann die Leute zum Testen und > Schreiben von Issues animieren? Man kann auch als freiwilliger um die nötigen IZ-Rechte bitten damit man selbst die Issues confirmen kann. > Was für ein Projekt wäre übrigens denn richtig gewesen? documentation → Online Help ciao Christian -- NP: Linkin Park - Papercut --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
