Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 27 reacties
Bron: ZDNet

Linus Torvalds heeft aangekondigd dat kernel-ontwikkelaars die kort voor de release van de volgende kernel-versie een nieuw onderdeel aan de kernel willen toevoegen teleurgesteld zullen worden. De Linux-pionier heeft namelijk besloten dat slechts twee weken na de release van de vorige kernel-versie nieuwe features aan de volgende versie zullen worden toegevoegd. De rest van de tijd tussen twee kernel-releases zal worden gebruikt om bugs op te lossen en de kernel uitgebreid te testen. De maatregel lijkt noodzakelijk, omdat de laatste release. 2.6.14, bijna een maand te laat is uitgebracht doordat er op het laatste moment een aantal bugs werden gemeld die release onmogelijk maakte. De bugmeldingen bleken echter niet te kloppen, waardoor de vertraging eigenlijk zinloos was.

Linus TorvaldsUiteraard zijn niet alle ontwikkelaars blij met dit nieuwe beleid. Bijvoorbeeld James Bottomley, die het SCSI-gedeelte van de kernel onderhoudt, zegt dat veel patches die hij krijgt aangeleverd slecht getest zijn, waardoor het bijna onmogelijk is om ze in een relatief korte tijdspanne van twee weken geschikt te maken voor opname in de kernel. Torvalds is echter ongevoelig voor deze kritiek, omdat het probleem van Bottomley volgens hem eenvoudig op kan worden gelost door hogere eisen te stellen aan de patches die ontwikkelaars aanleveren.

Moderatie-faq Wijzig weergave

Reacties (27)

Torvalds is echter ongevoelig voor deze kritiek, omdat het probleem van Bottomley volgens hem eenvoudig op kan worden gelost door hogere eisen te stellen aan de patches die ontwikkelaars aanleveren.
..of je wacht met de patch tot de volgende cyclus/release... :*)
precies. nix mis met dit systeem, imho. als de patch nog niet goed genoeg is om in de kernel te komen, wacht ie nog een maand of 2, en dan komt de volgende ronde. in de tussentijd kan de mantainer of maker iets doen met de kritiek die hij kreeg...
Ik zie het probleem niet zo. Bij de ontwikkeling van FreeBSD (en waarscheinlijk ook de andere varianten) is het de dood normaalste zaak dat code bevroren wordt vlak voor een release. Alleen zaken die dan noodzakelijk zijn worden toegevoegt. Dit komt de stabliteit ten goede. Dat betekent niet dat de innovatie langzamer gaat. De ontwikkelaars kunnen rustig door ontwikkelen en hoeven zich niets aan te trekken van de bevroren code.
Het doorontwikkelen kan nu ook wel gewoon. Alleen voor het toevoegen van code voordat de versie bevroren wordt is nu maar 2 weken. Dus je hebt maar 2 weken om de code in een nieuwe release in te stoppen. Daarna is het alleen bugfixing.
Aan de ene kant hoeft het niet qua innovatie te schelen, maar aan de andere kant, als jij een hele grote change hebt of veel moet testen, heb je misschien wel meer dan 2 weken nodig.
Bijvoorbeeld James Bottomley, die het SCSI-gedeelte van de kernel onderhoudt, zegt dat veel patches die hij krijgt aangeleverd slecht getest zijn, waardoor het bijna onmogelijk is om ze in een relatief korte tijdspanne van twee weken geschikt te maken voor opname in de kernel.
Dan sla je toch een release over, wat is er daar nou moeilijk aan.
Als patch op patch een tijd moet wachten, gaat het met de inovatie dus een stuk minder hard.

Aan de ene kant, moet hij ervoor zorgen dat de kernel snel en veel nieuwe functies krijgt, aan de andere kant, moet het hoogwaardige kwaliteit hebben, en uiterst stabiel zijn. Dat gaat heel moeiljk samen.

Linus heeft vaak een duidelijke (koppige) mening over iets, en dat laat hij nu weer blijken.
Ik heb zelf tegenwoordig weinig ervaring met linux, maar het valt me op dat het hele ontwikkelproces nogal ouderwets verloopt. Ook het punt dat je nergens een snapshot vandaan kan halen vind ik raar, zeker voor een kernel die beweert/verwezen wordt als voorbeeld van open source.

Kijk ik naar de verschillende BSD's dan kan ik gewoon een complete kernel/userland uit cvs halen, en ook nog browsen via http://www.freebsd.org/cgi/cvsweb.cgi/ of http://cvsweb.netbsd.org/bsdweb.cgi/
Het blijkt maar weer dat je eerst is beter in het onderwerp moet verdiepen voordat je kritiek levert. Want deze kritiek is gebaseerd op niets...
Ok prima. Ik lever ook niet zozeer kritiek, het was meer een vraag. En blijkbaar bestaat dat git ook nog niet zo lang.

Punt is, dat dit hele artikel naar mijn mening een resultaat is van een slecht release engineering proces.

Bij de release engineering op bijvoorbeeld de bsd platforms wordt de release branche gefreezed, en mogen alleen mensen nog veranderingen committen op die branch met toestemming van het team wat verantwoordelijk is voor de release.

Op deze manier kan er rustig verder worden ontwikkeld, terwijl sommige bugfixes gebackport worden naar de release branch.

Maar goed, voor de duidelijkheid, ik wil hiermee verder linux niet afzeiken. Het lijkt me opzich een prima kernel.
Voor git was er een bk, daarvoor waren er nog systemen die ongeveer hetzelfde werken (qua output, uiteraard niet interne werking)...
Torvalds is echter ongevoelig voor deze kritiek, omdat het probleem van Bottomley volgens hem eenvoudig op kan worden gelost door hogere eisen te stellen aan de patches die ontwikkelaars aanleveren.
Dan krijg je dus gewoon minder tot geen pathces..ook niet echt een oplossing ofzo |:(
Maar als de patches die je nog wel krijgt goed van kwaliteit zijn, bespaart het toch tijd.

OT: lekkere foto weer :Y)
In dat geval zijn de patches klaarblijkelijk dus niet nodig. Waarom zit iemand dan zijn tijd er aan te besteden?

Ik weet niet of die gasten hiervoor betaald krijgen, maar volgens mij zijn er zat mensen die dit in hun eigen tijd doen. Ik zou er persoonlijk niet heel erg vrolijk van worden als ik zo'n patch aanlever, maar die vervolgens niet in gebruik wordt genomen. Dan zou ik mezelf toch eens afvragen waarom ik m'n tijd er aan besteed.
Mo: dat is gewoon Torvald's vage humor, dat heeft hij vaker. Dat is niet zo zeer arrogantie ofzo hoor. Al lijkt het idd wel zo en zou je haast denken "stik er dan maar in! hufter!" :P

darulez: dat kan je wel zeggen maar Mo heeft absoluut gelijk dat zijn taalgebruik nou niet bepaald netjes is, en dat hoge eisen stellen aan mensen waar je AFHANKELIJK van bent best wel ver gaat. Tuurlijk heb jij weer gelijk dat het zijn geesteskindje is maar zonder de community was het nooooooit geworden wat het nu is. Laat dat duidelijk zijn ;)
De meesten doen het idd als hobby. Maar wat Torvalds hier bedoelt is dat mensen te laat aan komen zetten met patches (in de vorm van features in het bijzonder) voor de NIEUWSTE versie. Ben je dus idd een klusser die in z'n vrije tijd wat heeft gemaakt, en je bent te laat, dan kan hij gewoon nog mee met de volgende versie. Mits je dan natuurlijk geen versieconflicten krijgt maar dat zul je dan zelf op kunnen/moeten lossen als de kernel weer gefreezed is en ze weer met de niewere versie beginnen. Zo lullig is het dus niet, gewoon efficient
Prima, als dat op een nette manier gaat. Maar op de manier waarop Torvalds het stelt, komt er bij mij weinig respect over:
"If people miss the merge window or start abusing it with hurried last-minute things that just cause problems for -rc1 [the first release candidate], I'll just refuse to merge, and laugh in their faces derisively when they whine plaintively at me, and tell them there's going to be a new opening soon enough," he said.
Het zijn nog altijd liefhebbers die het doen, en die kunnen net zo goed hun tijd ergens anders aan gaan besteden. Maargoed, het kan twee kanten op werken. Of Torvalds schiet zich hiermee in de voet, of het komt allemaal ten goede van het product.
Ik heb het idee dat de heer Torvald het recht heeft om dit soort eisen te stellen, aangezien het hele systeem grotendeels van zijn handen komt.
Dan moet meneer Torvalds ook eens goed begrijpen dat hij het systeem nu niet meer onderhoud. Maakt hij die SCSI drivers soms? Volgens mij niet. Als er niet zo veel vrijwilligers waren geweest die hier hun tijd aan hadden willen besteden, dan was Linux nooit geweest wat het nu is.

En tuurlijk, hij is eindverantwoordelijke, en zal toch enige eisen moeten stellen. Maar hij moet het wel op een normale manier doen en niet degene af zitten zeiken die hier toch hun vrije tijd aan besteden.
Om daarvoor in aanmerking te komen (kernel ontwikkelen) moet je al vrij hard werken en toch enige programmeertalent hebben (niet gering trouwens), dus dan weet je wel waarom jen et doet :P
Minder en minder snel. En dan nog vraag ik me af of dit gaat helpen. Je kan de eis stellen dat het goed getest moet zijn voordat het eens bekeken kan worden of het aangenomen wordt maar zelfs dan kan je niet afdwingen dat de kwaliteit goed is. Testen is een vak apart.
Die vergelijking is niet eens zo slecht met Theo de Raadt van Openbsd. Die zei:"software managen is soms developers over de bol aaien en soms een trap onder hun reet geven"

Linus doet nu dus het laatste.
ik neem aan dat de prepatches nog wel die nieuwe patches blijven krijgen. en toevallig is ook net 2.6.14.2 uit zie ik.
De Linux-pionier heeft namelijk besloten dat
* 786562 teh_twisted

uhm... wat dacht men van... research doen voor het posten van artikelen?
Kunnen ze niet gewoon een langere periode tussen de updates hanteren? Of zeg ik nu iets heel doms?... :?
Ohja, een beetje vertraging in ruil voor een hele hoop stabiliteit :)

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True