Re: [Debian]:Updates fuer "slink" [was: mc 4.5.38-1 = fork-bomb?]
[ VERDAMMT NOCHMAL, WIE OFT MUSS MAN ES EUCH NOCH SAGEN: KEINE
UNGEKENNZEICHNETEN CC'S UND AM BESTEN KEINE CC's !]
On 99-09-27 Andreas Tille wrote:
> On Sun, 26 Sep 1999, Christian Kurz wrote:
> > Sicherlich, aber wenn ich dir heute Download-Zahlen fuer irgendwas
> > vorlege, dann koenne diese auch gefaelscht sein. Es muesste also wenn
> > schon, dass Logfile auch mitgeliefert werden und dies gibt Probleme mit
> > dem Datenschutz. Bei einer Abstimmung trifft aber jeder selbst die
> > Entscheidung seine Position offen zu vertreten und von daher ist dies
> > meiner Meinuyung nach auch gut so.
> Also ich habe genug Vertrauen in Paul, daß er keine Manipulation vornimmt
> und ich persönlich hasse Abstimmungen aus verschiedenen prinzipiellen
> Gründen, die hier nicht zu erörtern sind.
Vertrauen ist gut, aber vetraust du jedem, der die sagt, dass das etwas
gebraucht wird und doch x mal von seinem Server downgeloaden wurde? Ich
denke, du wirst dies auch von der Person abhaengig machen, wie gut oder
schlecht du sie kennst. Und von daher ist deine Aussage sicherlich nicht
falsch, aber nicht generell gueltig.
> > Ich habe oben versucht dazulegen, warum Download-Zahlen keinerlei
> > sinnvolles Kriterium fuer eine solche Abschaetzung darstellen und
> > Aussagen von Personen immer subjektiv sind.
> Ich glaube, daß die Leute, die eine so sinnvolle Sache wie die
> Bereitstellung von aktueller slink-Software in Angriff nehmen, besseres
> zu tun haben, als irgendwelche Statistiken/Logfiles zu manipulieren.
Dass ist wiederum reine Einschaetzung deinerseits und durch nichts
belegbar. Ausserdem rede ich nur von dem nennen falscher Download-Zahlen
und nicht von dem Manipulieren von Logfiles. Bitte wirf solche Dinge
nicht durcheinander, denn dies sind unterschiedliche Problem.
Man kann zwar hoffen, dass die Leute, die an einem solchen "Port"
interessiert sind, nicht so etwas machen wollen, aber man kann sich
nicht sicher sein und darauf wollte ich hinaus.
> > Sicherlich, aber woher soll ich sicher sein, dass diese Zahlen echt sind
> > und nicht gefaked sind? Und da man nicht jeden bei Debian kennt, ist
> > auch Vetrauen nicht immer moeglich und gerade bei einer, meiner Meinung
> > nach wichtigen Sache, sollte man schon einen deutlichen Beweis haben.
> Siehe oben. Bitte Christian, mag sein, daß eine Abstimmung besser ist;
> ist mir egal, weil ich nicht dran teilnehmen würde. Aber unterstelle
Was beschwerst du dich dann ueber die Idee einer Abstimmung? Warum
ignorierst du es nicht einfach?
> doch bitte keinem, der uneigennützig hilfreiche Dienste zur Verfügung
> stellt, quasi-kriminelle Machenschaften. Auf diese Weise laufen wir
Ich unterstelle hier niemand eine krimininelle Machenschaft, aber
wuerdest du einem Fremden, dem du nur dem Namen nach kennst, vertrauen,
wenn dir eine Statistik vorlegt und sagt, dass Projekt y gebraucht wird?
Wuerdest du dich dann einfach so dafuer engagieren und deine Manpower
darein investieren, oder erstmal dass ganze pruefen und
vetrauenswuerdiger Beweise verlangen?
> Gefahr, daß Leute, die sich auf Ihre Weise bei der Verbreitung freier
> Software beteiligen, sich vergnatzt zurückziehen.
Wie bitte? Nur weil man sagt, dass man nicht jedem Fremden, denn man
nicht persoenlich kennt, nur dem Namen nach, vertraut, vegraule ich
damit Leute, die sich fuer freie Software interessieren und beteiligen
(wollen)? Fuehlst du dich gleich gekraenkt, nur wenn dir jemand sagt,
dass er dich nicht kennt und daher lieber deutlichere Beweise als deine
Aussage will? Nein, warum dann im anderen Fall?
> > Fuer mich ist nunmal die Qualitaet eines Produktes wichtig und dass hat
> > bei Software viel mit Bugfixing und QA zu tun.
> Das ist schön und Leute wie Du werden sicher noch viel mehr gebraucht.
> Unser Endprodukt soll und muß so stabil wie möglich sein und dafür
> brauchen wir Entwickler, die sich knallhart darum bemühen.
Und von daher ist es wichtig, dass dieser "Port" von offiziellen
Maintainer gemacht wird, womit wir wieder an dem Punkt sind, dass ich
keine Lust habe, Manpower zu investieren, nur weil mir jemand sagt, dass
es gebraucht wuerde.
> > Also dass soll sich ja auch mit der Zeit aendern, aber wenn man bedenkt,
> > wie wenige Leute, die Hauptarbeit bei Debian machen und wieviele einfach
> > nur neue Software packen, dann wundert mich nicht, dass es laenger
> > dauert.
> Ein gewichtiges Argument, das vielleicht zu wenig zur Sprache kommt.
Viel zu wenig, aber es gibt auch Aenderungen, die mehr Mitarbeit
erlauben, trotz wenig Zeit.
> Selbstkritisch muß ich zugeben, daß ich auch nur zur Gruppe der
> Software-Packer gehöre, die sich nicht um die "Hauptarbeit" kümmern
> gehöre. Aber mehr Zeit habe ich einfach nicht.
Okay, dass mag fuer einen gelten, aber wenn ich mir anschaue, dass es
ueber 500 Maintainer gibt, dann wundert es mich doch sehr, dass immer
wieder dieselben an QA und Bugfixing arbeiten.
> > Nein, aber zur sinnvollen Steuerung, damit nich 10 Leute dasselbe Pakete
> > rekompilieren. Auch fuer die resultierenden Bugs waere es auch
> > hilfreich, wenn man dann nur einen Ansprechpartner hat und nicht erstmal
> > ein Rundmailing machen darf, wer ist fuer das Paket zustaendig.
> Wie wäre es denn, wenn man versucht, noch weiter zu gehen und unter
> Hinzunahme von Pauls Argument, daß ja mehr Nutzer auch mehr Fehler
> entdecken würden, wenn die aktuelle Software für stable verfügbar
> wäre, folgendes Schema aufbaut:
Solche Planspiele sind ganz nett, aber solange nicht von offizieller
Seite aus an einem solchen "Port" gearbeitet wird und es eine Policy
dafuer gibt, sehe ich in einem solchen Plan wenig Sinn.
> - [sinnvoller name] - bei jedem Update eines Paketes in unstable wird
> automatisch durch das geniale Paket-System ein stable-Paket
> gepackt. Falls es sich nicht kompilieren läßt, kriegt der Maintainer
> eine Information und kann sich drum kümmern oder läßt es sein.
Und schon dies sollte man in einer Policy genau definieren, sonst haben
wir bald wunderbare Flame-Wars auf debian-devel, wie man sich denn nun
zu verhalten hat.
> Welche Pakete in diesen Service einbezugen werden, kann der jeweilige
> Maintainer per zu schaffendem Flag einstellen (sicher sollte
Laesst sich wohl sinnvoller mit einer Datenbank loesen.
> Das ganze kommt auf einen Rechner, auf dem Du einsicht in das
> Logfile nehmen kannst, so daß Du Dich von dem Bedarf höchstpersönlich
> informieren kannst
Nein, kein Bedarf, da ich meine wenig Zeit fuer Debian lieber in QA und
Bugfixing investieren, als in so etwas.
> Bug-Reports werden ganz normal ausgefüllt. Der Maintainer darf Bugs
> mit dem Hinweis: "Fehler tritt in konsistentem unstable/frozen"
> nicht auf schließen. Nutzung auf eigene Gefahr!!!!!!!!!!
Auch solche Dingen koennen leicht zu Flamewars fuehren und sind daher
besser in einer Policy deutlich zu regeln.
Ciao
Christian
--
********************************************************************
* Christian Kurz Debian Developer/QA-Team *
* Use Debian - a free Operating System *
********************************************************************
------------------------------------------------
Um sich aus der Liste auszutragen schicken Sie
bitte eine E-Mail an majordomo@jfl.de die im Body
"unsubscribe debian-user-de <deine emailadresse>"
enthaelt.
Bei Problemen bitte eine Mail an: Jan.Otto@jfl.de
------------------------------------------------
Anzahl der eingetragenen Mitglieder: 727
Reply to: