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 24 juli 2024 00:53]
/i/1319552223.png?f=imagegallery)
/i/1200057701.png?f=fpa)
/i/1349176008.png?f=fpa)
/i/1332268778.png?f=fpa)
:strip_exif()/i/1317812597.gif?f=fpa)
:strip_exif()/i/1302169583.gif?f=fpa)
/i/1213971184.png?f=fpa)
/i/1227630077.png?f=fpa)
/i/1318421752.png?f=fpa)
/u/63085/congrats_avatar.png?f=community){kind=avatar}
:strip_icc():strip_exif()/u/162143/crop5b6d888e9cc79_cropped.jpeg?f=community){kind=small}
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.
Geen idee hoe ze het voor elkaar krijgen maar de boel is toch echt allemaal geladen. Een grote vooruitgang, jammer dat daarom die mooie grafische start van Fedora nooit in openSUSE zal komen 
:strip_exif()/u/260741/crop5a4e4cc5a1f75_cropped.gif?f=community){kind=small}
/u/200133/artemis_square_e_60-60.png?f=community){kind=small}
:strip_icc():strip_exif()/u/368341/tux-mad-s.jpg?f=community){kind=small}
/u/99291/logo-square.png?f=community){kind=logo}
/u/350932/crop56fec4a56d096_cropped.png?f=community){kind=small}
/u/180271/av.png?f=community){kind=small}
:strip_icc():strip_exif()/u/81611/headcrop.jpg?f=community){kind=small}
/u/306263/Strafe_icon.png?f=community){kind=icon}
:strip_icc():strip_exif()/u/226826/aardblij-60.jpg?f=community){kind=small}
:strip_exif()/u/301133/crop6737b754ae5aa_cropped.gif?f=community){kind=small}
:strip_exif()/u/14668/fs.gif?f=community){kind=small}
:strip_icc():strip_exif()/u/18339/rem.jpg?f=community){kind=small}
:strip_icc():strip_exif()/u/220992/profilemini_sharp_dark.jpg?f=community){kind=small}
:strip_icc():strip_exif()/u/139411/T.net.jpg?f=community){kind=small}
:strip_icc():strip_exif()/u/263383/crop610ea70faf524_cropped.jpg?f=community){kind=small}
Daarbij krijg je bij het installeren de keuze welke desktop je wilt gebruiken (KDE, Gnome of zelfs anderen):strip_exif()/u/47900/baph.gif?f=community){kind=small}
/u/179202/crop56484cad6dfaa_cropped.png?f=community){kind=small}
:strip_icc():strip_exif()/u/111342/crop59c23ae9896fe_cropped.jpeg?f=community){kind=small}
