Articles précédents : Développeur
- [47] FFmpeg et MPlayer : Appel au dons pour un nouveau serveur
- [56] Bilan du sommet 2005 des développeurs du noyau Linux
- [66] Le moteur de Gecko en version serveur ?
- [11] JSAN : un « CPAN » pour JavaScript
- [74] Sortie de Qt 4
- [120] Support d'Ajax dans Ruby on Rails
- [12] Brevet sur le XML et sur le Fichier::Enregistre/Sauver?
- [114] Nouveau rebondissement dans l'affaire du pilote PWC
- [33] Sortie de l'émulateur Qemu 0.7.0
- [68] Toutes les API GNOME dans tous les langages et pour bientôt ?
Liens connexes
- KernelTrap: Junio Hamano New Git Maintainer (224 hits)
- KernelTrap: Git Homepage (616 hits)
- KernelTrap: 2.6.13-rc4, Improved Development Process (346 hits)
- KernelTrap: Weekly Status Summaries (652 hits)
- LinuxFr: Bilan du sommet 2005 des développeurs du noyau Linux (502 hits)
- LinuxFr: Le développement du noyau continue autour de Git (354 hits)
Dépêche modérée par
Dépêche éditée par
Développeur : Nouvelles du noyau : Git et modèle de développement
Posté par Thomas Petazzoni (page perso, ). Modéré le 08 août 2005.Depuis, le développement de cet outil a suivi son cours, s'améliorant, se voyant doté d'interfaces graphiques ou de scripts évolués. Linus Torvalds a décidé fin juillet de passer la main pour la maintenance et l'évolution de cet outil à Junio Hamano. En effet, Linus a expliqué qu'il avait « toujours dit qu'il ne voulait pas vraiment le maintenir sur le long terme ». Ceux qui s'intéressent à Git pourront lire le Kernel Hackers' Guide to git, suivre la liste de discussion, ou même consulter la toute nouvelle homepage du projet.
Par ailleurs, depuis le Kernel Summit, également couvert sur LinuxFr, Linus a décidé de modifier sensiblement le modèle de développement du noyau. Désormais, suite à la sortie d'une version du noyau, des ajouts de fonctionnalités et modifications importantes ne seront acceptés que pendant deux semaines. Au delà de ce délai, et jusqu'à la sortie de la prochaine version, le travail des développeurs sera consacré à la correction de bugs.
Enfin, toujours suite aux discussions ayant eu lieu durant le Kernel Summit, Andrew Morton, mainteneur de la branche -mm, a publié son weekly report. Dans celui-ci, il liste les grands changements qui sont intégrés pour la prochaine version du noyau, ainsi qu'une estimation de la date de sortie de ce dernier. Il doit permettre aux mainteneurs des différents sous-systèmes du noyau d'être mieux tenus au courant des évolutions en cours.
KernelTrap: Junio Hamano New Git Maintainer (224 hits)
KernelTrap: Git Homepage (616 hits)
KernelTrap: 2.6.13-rc4, Improved Development Process (346 hits)
KernelTrap: Weekly Status Summaries (652 hits)
LinuxFr: Bilan du sommet 2005 des développeurs du noyau Linux (502 hits)
LinuxFr: Le développement du noyau continue autour de Git (354 hits)
> Lire les commentaires (6 commentaires, moyenne: 8).
Suite à la sortie d'une version du noyau...
Si comme moi, vous vous posez des questions au sujet de ce "suite à la sortie d'une version du noyau" et qu'en plus vous avez la flemme d'aller y voir de plus près, alors voilà peut-être la réponse à votre question:
Il s'agit de sortie de noyau stable, en x.y.z. Cela signifie, par exemple, qu'après la sortie du 2.6.13 (qui est imminente), les développeurs n'auront que deux semaines pour convaincre Linus d'intégrer leurs patchs dans le 2.6.14.
Donc comme le dit Linus, s'il y a des patchs que vous souhaitez voir intégrer dans la branche stable ASAP, n'oubliez pas de réveiller votre dév préféré en temps voulu...
-
[^]Re: Suite à la sortie d'une version du noyau...
Posté par Clément varaldi (page perso, ) le 09/08/2005 à 07:22. (lien). Évalué à 3.Ca veut dire aussi que si le dev a une idée géniale, et qu'il met deux semaines et un jour à la développer, ben il ne pourra pas la voir arriver avant le noyau suivant, il devra attendre patiemment.
J'aime bien l'idée dans le principe, mais dans les faits, je trouve ça assez dommage : ne risque-t-on pas de voir des développeurs proposer à droite et à gauche des patches pour inclure des fonctionnalités prévues non pour le noyau suivant, mais pour celui d'encore après ?
On avait déjà pas mal de noyaux patchés dans les distributions, cela ne risque-t-il pas de s'intensifier ?-
[^]Re: Suite à la sortie d'une version du noyau...
Posté par Thomas Petazzoni (page perso, ) le 09/08/2005 à 07:29. (lien). Évalué à 10.Actuellement, le rythme de sortie du noyau est d'environ un par mois ou un tous les mois et demi, donc la fonctionnalité n'attendra pas trop longtemps avant d'être intégrée.
C'est à l'époque du 2.5 que les distributions backportaient énormément de patches: le 2.5 n'était pas assez stable pour être utilisé, et le 2.4 manquaient de nombreuses fonctionnalités, en particulier en terme de support matériel.
-
[^]Re: Suite à la sortie d'une version du noyau...
Posté par Matthieu Moy (page perso, ) le 09/08/2005 à 07:37. (lien). Évalué à 10.De toutes façons, un patch n'est intégré au noyau qu'après avoir été testé un certain temps (je crois qu'un séjour dans la branche -mm est obligatoire). Donc, même si la fonctionalité était prête un jour avant la "deadline", elle ne serait pas intégrée pour autant. Les 15 jours ne correspondent pas au temps pour développer une nouvelle fonctionalité, mais au temps pour convaincre Linus d'appliquer le patch.
-
[^]Re: Suite à la sortie d'une version du noyau...
Posté par tinodeleste () le 09/08/2005 à 07:39. (lien). Évalué à 10.et puis les idées géniales, c'est bien, mais quand elles sont codées avec les pieds, ca n'aide pas;
http://kerneltrap.org/node/5528(...) Andrew Morton sur l'évolution et le traitement des bugs :
There are 60 bugs here. They're almost all post-2.6.12 regressions. Longer-term we simply have to do better than this, else we'll stabilise at a pretty buggy level. (...)
il faudrait que tout les développeurs fassent un peu plus attention à leurs bugs, vu que pas mal des bugs apparus après le 2.6.12 sont des régressions par rapport aux noyaux précédents.
-
Mercurial vs. git
(reprise d'un message à l'origine posté sous un journal)
A propos de systèmes de gestion de versions, j'ai découvert Mercurial (abbrévié "hg"), un autre système de gestion de versions distribué qui bénéficie d'un format de stockage et de transmission réseau très efficace. A titre d'exemple, trois mois d'historique de la branche de Linus du noyau 2.6 ne prennent que 200 Mo (pour environ 5000 changesets), et quelques minutes à télécharger avec un ADSL 1024.
Mercurial est très intéressant car, comme Bazaar-ng, il est écrit en Python, il dispose d'à peu près les mêmes fonctions, et il semble beaucoup plus performant.
La page d'accueil de Mercurial :
http://www.selenic.com/mercurial/(...)
Une comparaison Mercurial / git / BitKeeper :
http://www.selenic.com/hg/?cmd=file;filenode=b0166ba7a8977756db92a8(...)
Naviguer dans le miroir sous Mercurial de Linux 2.6 (branche Linus) :
http://www.kernel.org/hg/linux-2.6/(...)
Cloner cette branche dans un repository local :
$ hg clone http://www.kernel.org/hg/linux-2.6/(...) hg-linux




Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.