LinuxFr.org diffuse des dépêches depuis plus d’une décennie. La longueur moyenne des dépêches a augmenté (multipliée par six en dix ans !), ce qui a visiblement pour effet secondaire de décourager les contributeurs. Autre effet secondaire : LinuxFr.org ne couvre pas l’actualité avec réactivité.

Afin de coller au mieux à l’actualité des logiciels libres et sujets afférents, vous êtes toutes et tous encouragés à contribuer avec des « petites brèves ». C’est assez facile :

• prenez deux ou trois informations dans la charte ;
• rédigez un paragraphe minimum par info ;
• remplissez deux phrases minimum par paragraphe.

Avec la page de rédaction, il est aisé de contribuer de manière collaborative(*). Ainsi, vous pouvez aider ou vous faire aider : commencez ou terminez un paragraphe ou une news.

(*) NdM : pour accéder à l’espace de rédaction proposé, le statut « writer » est nécessaire (concrètement : avoir déjà posté une dépêche précédemment ou simplement demander à un administrateur d’obtenir ce statut). Cette mesure temporaire a été prise dans l’attente d’une refonte de l’espace de rédaction.

La Linux Foundation a publié récemment un guide intitulé How To Participate In the Linux Community, rédigé par Jonathan Corbet, l'un des principaux éditeurs du site Linux Weekly News et co-auteur du livre Linux Device Drivers. Ce guide met tout d'abord en avant l'importance de contribuer à la version officielle (dite mainline) du noyau, puis décrit le processus de contribution au noyau et comment éviter les erreurs couramment commises.

Bien que la communauté du noyau soit déjà très active, avec 1.000 contributeurs de plus de 100 sociétés qui ont contribué l'an passé, la Linux Foundation, qui emploie notamment Linus Torvalds, souhaite par ce guide, encourager la participation en vulgarisant les processus de contribution au noyau, qui reposent souvent sur des règles implicites non-écrites qui peuvent être difficiles à saisir pour un nouveau venu ou une entreprise.

Le guide aborde les thématiques suivantes :

• Le processus de développement, avec le cycle des sorties et le mécanisme de la fenêtre de fusion (merge window)
• La planification initiale et l'importance d'impliquer tôt la communauté dans son projet
• Le processus de développement, ainsi que les règles pour les patches
• La soumission des patches pour relecture
• Le travail avec les relecteurs, une étape du processus de développement
• Des sujets avancés, comme la gestion des patches avec Git et la relecture des patches soumis par d'autres

Sur le même sujet, Linus Torvalds a récemment accordé une interview à ZDNet.co.uk, dans laquelle il indique «Ce n'est définitivement pas simple de devenir un 'gros contributeur' [...] Le noyau est relativement gros et complexe, and ça prend inévitablement du temps d'apprendre toutes les règles -- pas seulement le code, mais aussi comment le processus de développement dans son ensemble fonctionne». Il revient également sur l'importance de discuter très tôt avec la communauté des fonctionnalités qu'on souhaite ajouter un noyau, au risque d'arriver avec un énorme patch qui sera rejeté par la communauté, une mise en garde également présente dans le guide de la Linux Foundation. De façon générale, Linus semble plutôt satisfait du processus de développement actuel: « Je pense qu'une des choses sur laquelle nous avons été très bons est le passage à l'échelle, avec un bon réseau de mainteneurs, de manière à ce que la plupart des gens impliqués ne travaillent en fait de manière rapprochée qu'avec une poignée d'autres personnes ».

Je peux vous garantir, en ayant fait moi-même l'expérience, qu'on ne ressort pas indemne d'une plongée dans le processus de développement de Linux ! Savez-vous par exemple que l'équipe de développement du noyau sort une version toutes les sept à huit semaines avec un nombre de lignes de code ajoutées, modifiées ou supprimées à chaque fois qui est de l'ordre du million ? Que le développement se fait en toute transparence sur Internet ?

Comparez avec Vista qui est sorti dans la douleur, au bout de 5 années de développement effectué derrière des portes fermées.

Mon article, essayant de décrire tout ce processus, est disponible sur Internet sous forme Wiki (donc éditable par tous). Les améliorations seront les bienvenues, je cherche en particulier de l'aide pour les chapitres consacrés aux distributions Fedora, Ubuntu, SuSE, etc.