FreeBSD 11.0 Release ist raus

Auf dem Hacktop (Chromebook) ja, auf dem Heimserver nein, eher, wenn ich Zeit/Muße dafür habe. Läuft ja alles.
 
Software ist niemals fertig. Also gibt es ohne Termin auch kein Release.

Man muss da ein Datum festlegen und dann muss man den aktuellen Stand halt gut genug fürs Release machen. Sonst würde alle Leute nur an Current arbeiten und es gäbe gar keine benutzbaren Releases. Done, when it's done funktioniert nicht. Oder hat es etwa bei Duke Nukem Forever zur erhofften Qualität geführt?
 
Ich fände es ein erträgliches Schicksal, auf CURRENT arbeiten zu "müssen". Dieser Versionierungswahn im Heimanwenderbereich, wo LTS und sonstiger Quatsch ja nun wirklich nicht so wichtig ist, übersteigt meine Denkkapazitäten.
 
Yamagi schrieb:
Das ist eher ein Errata Candidate, für den es kurz nach dem Release eine Errata Notice geben wird. Irgendwie pendelt man im Moment auch zwischen Extremen. Nachdem 10.3 wirklich hingerotzt wirkte und dank mehrerer übler Bugs (Deadlocks in ZFS, Deadlocks im VM, falsche Segfaults) kaum nutzbar war, übertreibt man es nun bei 11.0 und beißt sich ewig an Kleinigkeiten fest, die man auch hinterher hätte rauspatchen können...
Zum Vergrößern anklicken....

mhmm - ich habe keine Probleme mit 10.3 gehabt... Läuft auch auf (meinen) Servern stabil... bis jeztz :)
 
-Nuke- schrieb:
Aber auch unabhängig von einer Release-Meldung... springt ihr auf euren Produktiv-Systemen gleich am Tag-1 auf die neue Version? Ist das nicht etwas schnell geschossen?
Zum Vergrößern anklicken....

Produktiv ist so eine Frage.
Ich nutze meinen Desktop-PC, mein Desktop-Netbook und meinen Fileserver mit FreeBSD privat, da aber auch für alle Aufgaben, die ich mit einem PC so erledige. Daneben habe ich noch ein oder zwei Mac-Books im Gebrauch und die machen aber deutlich weniger und haben auch alte Releases und werden nicht upgedatet.
Ist das nun produktiv? Im Grunde ist es Hobby, Heimgebrauch.

Keinesfalls bin ich jemand, der unbedingt das Neueste haben muss oder besonders schnell Updates versucht.
Deshalb lese ich auch überhaupt nichts, das mir irgendwelche Termine suggeriert.
Gelegentlich, und besonders, wenn ich eine neue Version erwarte, dann schaue ich auf dem Update-Server von freebsd-update nach, ob sie schon vorhanden ist. Nachdem es RC3 gab, war damit zu rechnen, dass irgendwann innerhalb weniger Wochen das fertige RELEASE erscheint. Und das habe ich nicht gleich am ersten Tag upgedatet.

Trotzdem war es eben kein fertiges RELEASE und wie ich hier lernen musste, hat das nicht nur mit einer unglücklichen Namenswahl zu tun.
Es war einfach nicht gut, dass da ein unfertiges RELEASE vorab auf den Servern auftauchte. Ich hätte niemals danach geschrien oder gefordert, dass es nun endlich kommen soll.
Mit den möglicherweise erhöhten Anforderungen, wenn denn nun das "endgültig fertige" RELEASE erscheint, werde ich sicher (mit eurer Hilfe) auch fertig werden können. Ich rege mich darüber nicht auf, dass das nun mal so passiert ist.

Es ist aber unglücklich gelaufen und zwar nicht von einem vorauseilenden Journalismus propagiert, sondern ganz alleine schon in der Handhabung bei FreeBSD.
Auch heute findet man auf diesen Servern ein 11.0-RELEASE und die nötigen Mechanismen zum Upgrade. Es ist auch bereits ein Patch eingeflossen, 11.0-RELEASE-p1 wird mit freebsd-update installiert. Das funktioniert bei mir alles, ich habe gar keinen Grund mich zu beschweren und vor allem nicht, wenn nun in einem einfachen p2 das finale RELEASE eingespielt wird. Dann ist das nämlich nur Namenswirrwar.
Aber auch der wäre unnötig gewesen und hätte einfach vermieden werden können.
 
Ich glaube ehrlich gesagt, dass Release Planning im Open Source Bereich sehr wichtig ist, nicht nur wegen Marketing. Es geht darum das zum einen alle Bescheid wissen, was der Plan ist und vor allem auch ein wenig Druck zu machen, dass das Release auch an einem Tag drauf ist. Sowas kann ja schon bei kleineren, nicht verstreuten und an ein Unternehmen gebundenes Team eine Herausforderung darstellen. Ich denke, dass es wichtig ist zu sagen, dass da jetzt ein Freeze ist, dass man seine Sachen davor fertig hat und dann am Besten nur noch Bugs sucht, etc.

Auch, dass man weiß, was Alpha, Beta, RC, etc. bedeutet ist einfach wichtig zu vermitteln und wenn man das so prominent hat, dann ist das finde ich deutlich professioneller. Auch, dass man dann weiß warum es sich verschoben hat und Leute das irgendwo nachvollziehen können.

Das soll jetzt nicht heißen, dass das der einzig richtige Weg ist, aber es ist der Weg den das FreeBSD-Projekt offenbar gewählt hat und das ist meiner Meinung nach etwas, wo es einfach darum geht sich für eine Art zu entscheiden. Ist so ähnlich, wie andere Themen, zum Beispiel Code Style. Wichtig ist, dass da jeder weiß wie Dinge gehandhabt werden. Diese Einheitlichkeit braucht ein Projekt einfach. OpenBSD macht es anders, aber auch einheitlich. Selbes gilt für diverse andere Projekte.

Ich denke nicht, dass einen Plan haben dem "es ist fertig, wenn es fertig ist" komplett widerspricht. Man muss sich halt im Klaren sein, dass der Plan das Ideal wäre - wenn alles glatt Läuft, es keine (groben) Bugs gibt, etc. Der Grund dass so ein Plan, auch wenn man ihn nicht einhalten kann wichtig ist, ist dass man damit verhindert, dass sich das Ganze irgendwo verlauft und es schlussendlich nie zu einem Release kommt. Damit hatte ja Debian unter anderem zu kämpfen. Gut, die hatte auch andere Gründe, aber es ist wirklich so, dass manche Projekte das einfach brauchen und gerade wenn viele Leute mitbauen wird es wichtiger.

EDIT: Achja und weil das Thema "schnell auf das neue Release wechseln" aufkam. Bei Netflix lassen sie angeblich viele (alle?) Systeme mit dem aktuellen CURRENT laufen.
 
Zuletzt bearbeitet:
Wenn ich sehr viele Maschinen hätte, würde ich eine Hand voll auf CURRENT produktiv laufen lassen (entsprechende Failover-Mechanismen vorausgesetzt). So dass ich Bugs finde bevor sie ins Release kommen. Aber natürlich lässt man den Großteil der Maschinen auf einem Release laufen, sonst profitiert man ja gar nicht davon CURRENT zu fahren.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben