[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[Debian]:Re: Updates fuer "slink" [was: mc 4.5.38-1 = fork-bomb?]



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.
 
> 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.
Oder gibt's für sowas jetzt schon nennenswerte Geldbeträge, daß sich
der Aufwand zu solchem Schwachsinn lohnen würde $-((.
 
> 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
doch bitte keinem, der uneigennützig hilfreiche Dienste zur Verfügung
stellt, quasi-kriminelle Machenschaften.  Auf diese Weise laufen wir
Gefahr, daß Leute, die sich auf Ihre Weise bei der Verbreitung freier
Software beteiligen, sich vergnatzt zurückziehen.
 
> 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.
 
> 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.
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.

> 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:

- stable - wie gehabt
- unstable und frozen - wie gehabt
- experimental - wie gehabt
- [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.
  Welche Pakete in diesen Service einbezugen werden, kann der jeweilige
  Maintainer per zu schaffendem Flag einstellen (sicher sollte
  glibc nicht mit zu den Paketen gehören).
  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
  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!!!!!!!!!!

Auf diese Weise würden Mehrfach-Kompilationen vermieden und der
Aufwand für die Entwickler wäre minimal.  Die Abstimmung erfolgt
sozusagen mit den Füßen, indem die Nutzer zu diesem System hinstreben
oder nicht.  

Viele Grüße

          Andreas.

------------------------------------------------
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: