offtipic, maar wellicht interessant:
Vanuit mijn rol als systeembeheerder kan ik helemaal achter dit soort releases staan, ik moet er niet aan denken dat ik met een OS te maken heb dat rolling updates uitvoerd. (zoals gentoo)
Maar als ontwikkelaar heeft het toch ook nadelen.
Ik werd afgelopen weekend negatief verrast door deze release.
Sinds enkele weken ben ik weer druk aan het ontwikkelen aan een van de projecten waar ik aan bijdraag. Na ruim een half jaar geen radiostilte heb ik op 6 oktober versie 0.1.0 van ristretto uitgebracht[0], kort daarop gevolgd door 0.1.1 (minor bugfix mbt compilatie). Het eind-doel is het opleveren van een stabiele applicatie ten tijde van de release van Xfce 4.10, een applicatie die volledig is afgestemd op deze release...
Na feedback van de Xfce design SIG is voor 0.2.0 de user-interface van ristretto aangepast[1]. En afgelopen weekend is het belangrijkste onderdeel van ristretto, de image-viewer geport naar cairo[2], een grote stap die de stabiliteit en beheersbaarheid van de applicatie ten goede komt. Dit is tevens een vereiste voor een mogelijke port naar Gtk+3.
Datzelfde weekend is er een bug gevonden in versie 0.1.0 en 0.2.0 waardoor de applicatie in zeldzame gevallen kan crashen.[3] Deze bug is opgelost in de master branch, simpelweg omdat de condities voor deze crash niet meer kunnen voorkomen. Een oplossing van dit probleem voor gebruikers zou zijn om te upgraden naar een nieuwe versie waarin deze bug niet meer optreed. (0.3?)
Dit is vanwege de het releasemodel van OpenSuSE (en anderen, zoals ubuntu) niet mogelijk, zij leveren versie 0.1.0 mee, en zullen het dus moeten doen met patches op deze codebase[4].
Dit is een probleem waar veel kleine projecten en distributies die dit release-model hanteren last van ondervinden. Als een applicatie nog aan veel veranderingen onderhevig is loop je het risico dat een distributie 'per ongeluk' een development-release packaged. Of een release waar, naar later blijkt, een ontwerpfout in zit die voorkomt dat een probleem binnen het bestaande ontwerp kan worden opgelost. Om dit dan netjes te doen wordt een deel van het ontwerp herzien en wordt de applicatie gerepareerd. Als deze reparaties impact hebben op de ervaring van de gebruiker, of samenvallen met een andere wijziging (mogelijk door een UI change) worden deze minder snel (lees: niet) opgenomen als bugfix in een release van bijvoorbeeld OpenSuSE.
Mocht je deze mensen toch niet in de kou willen laten staan dan ben je als ontwikkelaar bezig om meerdere keren een oplossing te bouwen voor hetzelfde probleem.
Met dit voorbeeld wil ik aantonen dat het voor kleine en grote opensource projecten verstandig is om eens in de zoveel tijd een release uit te brengen waar je voor langere periode bugfixes voor 'garandeerd'. Dit voorkomt dat je straks 25 verschillende versies van je code aan het onderhouden bent, 1 voor elke distributie met een specifiek probleem op een specifieke versie van je code, en 1 met de nieuwste bugfixes en features.
Door helder te communiceren over het release-proces, (zoals wordt gedaan voor de Xfce core[5]) kun je voorkomen dat niet-technische gebruikers zitten opgescheept met een stukje code waar je eigenlijk geen fixes voor wilt of kunt leveren.
[0]
http://mail.xfce.org/pipermail/xfce/2011-October/029286.html
[1]
http://mail.xfce.org/pipermail/xfce/2011-October/029316.html
[2]
http://git.xfce.org/apps/...26e2ea3db3c7aa44528ae3ae1
[3]
https://bugzilla.xfce.org/show_bug.cgi?id=8036
[4]
http://git.xfce.org/apps/...bca9a356c9f31111f25f1bf62
[5]
http://www.xfce.org/about/releasemodel[Reactie gewijzigd door psyBSD op dinsdag 25 oktober 2011 19:28]
Waarom heeft dit model voor jouw als systeembeheerder voordelen? Nu heb je eens in de 4 or so maanden een update die een hoop veranderd en stukmaakt. Met een rolling releases heb je eens in de week (of een ander interval, wat je maar kiest) een update die meestal niks breekt, en af en toe iets groots doorvoert/breekt (gnome 3, kde 4, etc)
Dat laatste vind ik als systeembeheerder van m'n eigen 2 pc's aardig fijner werken, aangezien ik vrijwel altijd de nieuwste versie van mijn favo software draai
De nadelen van een fixed release schema geef je zelf al aan vanuit ontwikkelaars oogpunt. En ook vanuit gebruikers perspectief vind ik het ook geen pretje eigenlijk.
Hier op de uni hebben we 2 linux omgevingen, een gebaseerd op ubuntu en de ander op debian stable. Beide draaien oude meuk als firefox 3.6, kde 4.4, gnome 2, gcc 4.4, etc. Met als gevolg dat studenten zelf up to date packages gaan compilen.
Als systeembeheerder ben je niet hoofdzakelijk verantwoordelijk voor het OS, niemand verdient zijn geld met het gebruiken van een OS. Het is de software die er op draait die er toe doet.
Je gaat een gebruiker niet elke 3 maanden een andere interface voorschotelen, dan is men meer bezig met praten over hoe ze met de software moeten werken dan daadwerkelijk met de software werken.
Een bedrijf wil voor meerdere jaren stabiliteit, iets waar ze op kunnen bouwen. Als systeembeheerder wil je het bedrijf ondersteunen bij verandering, dat kan het best als de zaken waar jij van afhankelijk bent voorspelbaar zijn.
Als ik een project met een doorlooptijd van 6-12mnd begeleid wil ik erop kunnen vertrouwen dat de systemen waar ik van afhankelijk ben over 9mnd nog steeds in die vorm bestaan. Het is vervelend als je iets maakt voor PHP4(oud voorbeeld), en op een woensdag-ochtend kom je erachter dat dit niet meer ondersteund wordt en je alles moet upgraden naar PHP5, omdat dit vanaf vrijdag niet meer bestaat.
![[RSS]](http://tweakimg.net/g/if/v2/icons/rss_small.png){kind=icon}
![[quick]](http://tweakimg.net/g/if/icons/world_link_cropped.png){kind=icon}
08:57
16:35
Door 
Daarbij krijg je bij het installeren de keuze welke desktop je wilt gebruiken (KDE, Gnome of zelfs anderen)
Ik ben persoonlijk van mening dat als er goede standaard waarden gebruikt worden en de gebruiker in principe alleen op volgende hoeft te drukken de gebruiker - noob of pro - niet moet gaan zeuren dat wat technische details naar voren komen maar goed het is vrij lastig om een gulden middenweg te vinden hier in ben ik bang.![[show]](http://tweakimg.net/g/if/comments/button_down.png "Reactie uitklappen")
