Est-ce qu'il y a des retours venant d'Ubuntu? Les correctifs de bugs dans les paquets Ubuntu sont-ils renvoyés à Debian ou pas?
There are contributions coming back, yes. Some of them can be followed using the (Debian) bug tracking system. For instance, at the end of the https://wiki.ubuntu.com/Debian/Usertagging wiki page there are a couple of interesting links, listing all (Debian) bug reports originating from Ubuntu, as well a similar listing of bug reports containing a patch coming from Ubuntu. Other examples of collaborations are "mixed" packaging team formed by both Debian and Ubuntu people. Does this mean that collaboration is perfect? Well, no. In principle Debian should expect to Ubuntu to give back all its work to Debian, in perfect fulfillment of a sane "upstream/downstream" relationship; but in principle we in Debian should be perfect in pushing changes to our upstreams and we are not. Let's say that we are starting to realize that and working together to decrease the "viscosity" of patch flow in all
directions.
Quelles sont, selon toi, les raisons de préférer Debian par rapport à Ubuntu ?
I've discussed the more general topic of the relevance of Debian in my recent talk "bits from the DPL" delivered at DebConf10 in New York, at the beginning of August (http://penta.debconf.org/dc10_schedule/events/569.en.html , video at http://meetings-archive.debian.net/pub/debian-meetings/2010/(...)
Debian is still unique among "mainstream" distributions for several reasons. There are some technical reasons (e.g. portability), but more important than that there are philosophical reasons. Debian is independent from money as it is not backed by any single company that can drive its decisions. Even more so, Debian is a do-ocracy and a democracy, which is quite peculiar among "corporate" distro. Finally, Debian has been spreading what I call the culture of freedom since 1993 and it is still doing that, without imposing non-free software or services to any of its users and developers. For me, this is a quite strong motive for choosing Debian over most other distros out there (and we should all keep in mind that some of the most popular distros out
there are heavily *based* on the work being done in Debian and that would have very hard time surviving without Debian)
Dans la dépêche annonçant ton élection [https://linuxfr.org//2010/04/18/26746.html] il est dit que le nombre de développeur Debian est au plus bas depuis 2003. Quelles sont les raisons données par ceux qui sont partis?
Claiming that the number of developers has decreased since 2003 is just a poor observation of data, without knowing the underlying details. We have had a sharp decrease *on paper* in the last 2 years, but that is just because DAM (the Debian Account Manager) has started to clean up old/unused accounts quite incisively, by pinging and then removing the accounts of people who have neither voted nor uploaded a package in the past 2 years. So, in fact, we cannot conclude from that data that people power have decreased, we have simply got the official numbers closer to reality.
As of today, we have about 900 DDs and 120 DMs (Debian maintainers), so we are pretty much in the same 1'000 ballpark numbers, with the advantage that most of the inactive people no longer figure in the count. Arguably then, our people power has increased.
Est-ce que l'introduction du nouveau statut de Debian Maintainer aux côtés de celui de Debian Developper est une bonne chose ?
Absolutely yes! As I've discussed above DMs are doing a lot of work and maintain several even important packages, without needing to be as committed to the project as DDs are. Additionally (even though I don't have [yet] numbers to back this out) we all have the feeling that becoming DM is for a lot of people a first step to become DD. Hence the role of DM is de facto reducing the contribution barrier to maintain packages independently and also help in getting more enthusiastic people becoming DD.
Si on ne parle pas anglais et qu'on ne sait pas programmer comment aider quand même le projet Debian ?
This is a tricky problem. We are well aware that there are problems in contributing to Debian without speaking English. In an ideal world, one should be able to contribute to Debian in her own language for every possible contributions, including bug reporting. Unfortunately arriving there would require a huge amount of translation people power, that we currently lack.
Nevertheless it is possible to contribute without knowing English, as code is code for everyone. Obviously, it is more difficult when all the other contributors of the code only speak English, as communicating with them becomes more difficult.
The look and feel is the most reported answer to this question. It is being worked on and we have already released some sub-site with a new look and feel. The debian-www team deserves lots of kudos for the ongoing work and the delay is essentially related to the lack of people power working on that stuff (it's way easier to complain it has not been done yet than actually getting to understand what are the blockers).
More importantly than that however, I believe we should use the website to explain more why Debian is unique in the distro world of today. I plan to work on that together with the debian-www team, although I haven't yet started doing that.
Est-il possible de se procurer un paquet source vierge du site web afin de faire des essais pour l'améliorer ?
It is not packaged in a standalone package, but maintained using version control system and appropriate alioth group. Every Debian Developer can easily join the group, as well as any non-DD which has shown she is able to contribute (via patches to the BTS or the like). All information on how to contribute can be found at http://www.debian.org/devel/website/
À quand le freeze de Squeeze ? A quand la sortie de la version finale de Squeeze ?
Thanks to my delay in replying to this interview, Squeeze is now frozen!, it has been announced during DebConf10 a few days ago. As
usual, it will be "released when it's ready", which for us is guarantee of quality: we are not willing to give up on package quality in order to meet some arbitrary deadline. If we all work together (not only DDs/DMs, but also contributors sending patches), I believe we can easily do that during 2010 Q4. If people would like to help, the best way to do that is helping fixing release critical bugs that are affecting Debian Squeeze; an easy to go through list is available at: http://bts.turmzimmer.net/details.php?bydist=squeeze&sor(...)
Est-ce qu'il est envisageable d'avoir des freeze qui soient périodiques (time based) même si la sortie de la stable reste en mode "quand c'est prêt" (when it's ready).
This is a very "hot topic" in Debian, that we will for sure discuss at the beginning of the release cycle of Squeeze+1. It is a far reaching topic, on which we would like to have agreement first of all from the Release Team and surely a large consensus in the developer body. Personally, I think that time-based freezes (which is not the same thing of time-based releases) is something good, for the simple reason that enable developers to plan in advance big changes. But again, this is a discussion for Squeeze+1 we will have all together and from which you'll surely hear back in the news.
Quel sera le nom de la prochaine stable après Squeeze ?
I don't know. The Release Team does a very hard and often thankless work in Debian, which tends to attract more flames thank kudos. Among the few fun privileges the Release Team enjoys, there is the honor of getting to choose release names. Usually, the Release Team announces that at the beginning of the release cycle, so nobody will know before the release of Squeeze. If you want to know earlier, you should help releasing Squeeze!
Est-ce que le mandat de DPL d'un an n'est pas trop court ? Qu'est-ce qu'il est vraiment possible de faire en à peine un an ?
This is a tricky question. I'm now at about 1/3 of my DPL term and I agree that 1 year is kind of short, mainly because it takes some time in the beginning to understand the job and start doing it efficiently. On the other hand we are all volunteers and the DPL work is quite challenging, asking volunteers to do that for more than 1 year might scary away potential candidates. I really don't know whether a different arbitrary length would be better or worse.
A propos de Mancoosi, est-ce que ce projet a apporté quelque chose concrètement dans Debian ?
Of course my answer on this is biased, but I argue that yes, Mancoosi is giving back quite some contributions to Debian. First of all we are maintaining several Quality Assurance infrastructure and tools, such as the edos-debcheck package (used routinely to check that the archive contains no uninstallable packages before a release) and the http://edos.debian.net services. Additionally, we are now working with package manager developers to improve the quality of dependency solving in Debian (and in other distros) by using technologies we have developer in Mancoosi such as CUDF. Readers interested in the topic should know that they can contribute to the initiative, by reporting (a-la popcon) their dependency solving issues via the "mancoosi-contest" package that can be found at http://mancoosi.debian.net.
Sans langue de bois est-ce que le projet Debian GNU/kFreeBSD est vraiment utile ? Combien de gens utilisent ça au lieu de choisir la vraie version FreeBSD ?
I can't predict the future, so I really don't know how many users will choose it over the "real" FreeBSD. Nor I think it does matter. Debian is quite unique already in its port availability. The fact that all official ports thus far have been Linux-based ports is however not a goal. Debian goals are to create free operating system and it is written nowhere that it should remain Linux-only. Obviously, I don't see the most popular Debian kernel changing anytime soon, but at the same time I'm well aware that the most widespread/functional port of GNU/Hurd today is Debian GNU/Hurd and I'm proud of that. On the same vein, I'm proud that there is a possibility of releasing Squeeze, for the first time, with 2 non-Linux ports that are kFreeBSD-based.
After all, let's not forget that we are volunteers and that we work for fun. It is evident that there are out there capable volunteers that did manage to bring Debian GNU/kFreeBSD to a potentially releasable state. Kudos to them! For the evaluation of user acceptance of those ports we have time ... but no such evaluation would have been possible if the ports weren't there in the first place!
Si on regarde cette page de stats pour le noyau 2.6.34 [http://www.remword.com/kps_result/2_6_34_whole.html] on voit que Debian est seulement en 93ème position des contributeurs avec à peine 5 patchs. Est-ce que c'est la réalité ? Si non comment inciter les développeurs Debian a rendre plus visibles leurs contributions ?
This question seem a bit trollish at first glance :-)
First of all the idea of a comparison among corporate distributions and Debian would be totally unfair, as companies have *employees* that contribute to the Linux kernel, while Debian has *volunteers*. Furthermore, the moral argument for which companies "have to" contribute to Linux is rooted on the fact that they make money with it; that argument is trivially non applicable to Debian.
But even if we let that go, it is clear that Debian contributions are not consistently reported under the name "Debian" (which is OK as, again, Debian is not a company, so Debian volunteers are free to do the accounting of their contribution as they please).
Just to mention a significant example, Ben Hutchings is a prominent member of the Debian kernel team. His contributions are, at least in the few examples I've checked, reported under the "Hobbysts" category rather than under the Debian one. For Linux 2.6.34 Ben has contributed 17 patches, 12 for 2.6.32, while for Linux 2.6.33 the number climbs up to 38 patches.
So, those numbers are nice, but are appropriate only to rank companies whose contributors are, I suppose, *expected* to mention the company in their contributions. For Debian this is not the case, but that means nothing in terms of how much the Debian kernel team contributes back to the Linux kernel.
In my humble opinion the situation has advanced more in the past 6 months than in the past 4 years (not for my merit, but thanks to the efforts of the Debian Python community). For instance, the python-defaults and python3-defaults packages, which determine which are the default Python interpreter versions in Debian, are now co-maintained.
The situation on the (versioned) Python interpreters themselves is indeed stuck, but as all social issues it is not an easy one to deal with. Unfortunately, now that the Technical Committee has been invoked, we can basically only wait for their decision, as the committee is the highest technical authority in Debian. Only a General Resolution can override the committee or decide in its place.
Dans ta plateforme tu as indiqué "I will fight strong package ownership when it conflicts with quality". Quels sont les pouvoirs du DPL dans ce domaine ?
You're right that there is no specific power the DPL can use for that. The only non-power that can be used is a relatively higher
popularity / consensus, coming from the fact that I've been voted on a platform containing that statement. Anyhow, I believe I've done more in that direction before becoming DPL with my RCBW campaign (see http://deb.li/rcbw for more info) than afterwords.
The key idea is that in Debian we really need to generalize our culture and realize that to continue releasing the way we are doing it now, we really need more collaboration among package maintainers and that NMU (Non-Maintainer Uploads) are a viable tool for such collaboration. This topic has been discussed at DebConf10 in a BoF I've organized on the subject (http://penta.debconf.org/dc10_schedule/events/609.en.html ,video at http://meetings-archive.debian.net/pub/debian-meetings/2010/(...)
Plus généralement comment gérer les cas de développeurs non coopératifs au sein d'un projet communautaire ?
In its generality, this is quite a tricky question to answer.
In Debian, we are getting better at that: encouraging and welcoming NMU is the first needed step. If that is accepted, then it becomes relatively easy to identify packages which are being neglected by their legitimate maintainers (e.g. it is enough to look for packages maintained essentially only via several NMUs in a row). At that point, we do have hijacking and QA procedures that we can use to pass the package to who has been working on it for the last uploads.
Maintenant que micrologiciels (firmwares) posant des problèmes juridiques de redistribution sont séparés du noyau Debian est-ce que le projet va chercher à être officiellement approuvé par la FSF comme par exemple gNewSense ?
It's interesting that you ask this question, as I've been discussing recently with both FSF people and gNewSense people of this matter. I share your point of view that we should work in that direction to improve the relationship among Debian and FSF. On the other hand, gNewSense folks are very happy of our choice as that will make their work easier.
Yep. C'est d'ailleurs la conclusion de l'article LWN:
"The most unfortunate aspect of the bug is the length of time it took to fix. Not just the two months between its discovery and fix, but also the five years since Delalleau's presentation. We need to get better at paying attention to publicly accessible security reports and fixing the problems they describe.".
>>> Aucune idée, personnellement je m'en moque, cherche…
mouais....mais là le problème c'est que c'est moi qui désire communiquer par vidéo avec ma soeur (pour voir la bouille de mon neveu) ou avec mon frère (pour voir la gueule de son appartement à Hong-Kong).
C'est un besoin réel que j'ai et ils sont tous les deux sous Windows...donc comment faire ?
Google Chat est peut-être une solution (en attendant qu'un soft libre multipleforme soit réellement disponible).
mmm....d'autres disent que la faille de l'époque n'était pas accompagnée d'un exploit et qu'elle paraissaient donc plus théorique que réelle. Comme en plus le fix d'Andrea Arcangeli était jugé très invasif et "ugly" il n'a pas été accepté.
Avec l'exploit de 2010 les devs ont pris conscience du souci et un fix minimal et élégant a été implémenté (totalement différent du patch d'Andrea donc).
Il y a tout un article au sujet de ce bug sur le site LWN: http://lwn.net/Articles/400746/ [article qui sera ouvert à tous jeudi prochain].
Évidemment, comme à chaque fois qu'il s'agit de sécurité, on retrouve Brad Spengler et PaXTeam dans les commentaires te ça trolle dur. Difficile de savoir qui a vraiment raison dans toute cette polémique.
>>> pourquoi X tourne-t-il avec les privilèges root ? Cela ne serait pas envisageable de le faire tourner uniquement pour l'utilisateur en cours ? C'est pour les performances ?
Depuis que les pilotes graphiques sont dans le noyau (kernel mode setting) ça devient envisageable de faire tourner X en non-root.
Il me semble qu'Ubuntu a annoncé un projet pour faire ça.
Il y a eu aussi le prix Gauss qui est revenu au français Yves Meyer. Il est surtout connu pour ses travaux sur les ondelettes qui est un domaine ayant une tonne d'applications (notamment le format de compression JPEG-2000).
Est-ce qu'il existe un binaire Windows d'Empathy que je puisse recommander à mon frère afin de lui permettre de chater en vidéo entre son ordi sous WinXP et mon ordi sous Linux ?
Si ce n'est pas le cas alors, oui, Google Chat sera LA solution à privilégier par rapport à Skype.
C'est déjà pas mal.
>>> J'ai essayé de nombreuse fois de contribuer à Gedit, notamment d'ajouter le support de splitview/multiview
Si tu va sur http://live.gnome.org/Gedit/Plugins tu verras qu'il y a un plugin split view
Je l'utilise en permanence pour écrire les dépêches LinuxFr un peu longues.
>>> Ensuite la communauté c'est rarement principalement lié a la licence, mais plus souvent au project leader (et perso entre Chris Lattner et le Stallman, je crois que je prefere Lattner ;)
Stallman n'est pas le project leader de GCC : http://gcc.gnu.org/steering.html
Il y a un comité technique qui prend les décisions de façon collégiale.
>>> Aujourd'hui, un chercheur qui ne publierait rien pendant 4 ans (ou plus, comme l'exemple donné plus bas) serait rayé de son labo, purement et simplement
Ouais enfin il y a aussi beaucoup de chercheurs ayant le statut de fonctionnaire et qui donc peuvent glander à vie sans rien publier (et être augmentés juste par le biais de l'ancienneté). Je connais une chercheuse à l'INSERM et elle m'a raconté des histoires à faire dresser les cheveux sur la tête.
Donc bon le système français à des vertus mais aussi des gros défauts.
>>> Cette année, deux Français (dont un naturalisé il y a quelques mois) ont obtenu ce fameux prix
J'avais prédit la médaille de Ngo en mars dernier [http://linuxfr.org//comments/1110576,1.html] et j'avais dit que je n'hésiterai pas une seconde à m'auto-louanger. C'est fait ;-)
>>> les deux gagnants sont passés, comme par hasard, à l'École Normale
C'est plus incroyable que ça. A part Alexandre Grothendieck (interné dans un camp lors de la guerre car juif) tous les autres mathématiciens français sont des anciens élèves de l'Ecole Normale supérieure. Tous !
C'est une domination absolument incroyable. Je ne crois pas qu'il existe une seule université dans le monde qui puisse ainsi s'enorgueillir d'avoir 10 médailles Fields à son palmarès.
>>> Quelle différence faîtes-vous entre les systèmes académiques français et, disons, américain ?
C'est un peu une tarte à la crème mais le système français permet (aux meilleurs des) mathématiciens d'avoir un poste fixe. Ils peuvent ainsi se consacrer à leur recherche sans avoir à sauter de post-doc en post-doc et à vivre sous le couperet du "publish or perish".
Les postes des CNRS permettent de faire de la recherche à 100% sans aucune tâche d'enseignement et sans crainte de l'avenir car le poste est stable.
Cela doit bien sûr engendrer des abus mais cela a aussi accouché des travaux de Laurent Lafforgue. Recruté au CNRS à la sortie de sa thèse il a bossé pendant 7 ans sans publier quoi que ce soit avant de sortir son grand article qui lui a valu sa médaille Fields.
Au USA ils se serait fait éjecter du système pour ne pas avoir sorti de papier pendant une période aussi longue.
>>> Non, car pour moi tu n'as rien à rembourser : si celui qui te file les logiciels offre la chose gratos, c'est son choix, tu ne dois rien
J'employais le terme "rembourser" au sens métaphorique. Bien entendu comme tu le souligne, je ne dois rien au sens propre du terme...mais je me sens moralement redevable et donc j'essaye de compenser un peu en faisant un truc.
En plus c'est fun d'écrire des dépêches !
>>> permettre aux auteurs de dépêches de pouvoir mettre leur code flattr, afin qu'ils soient rémunérés par dépêche (patrick_g deviendra alors sans doute millionnaire :) )
Tu disais ça pour rigoler mais je réagis quand même, on sait jamais. Je ne sais pas quelle est l"opinion des autres auteurs de news mais en ce qui me concerne j'écris mes dépêches pour tenter de rembourser mon usage des logiciels libres (vu que je ne code pas). Ce serait donc bizarre d'en retirer un bénéfice financier non ?
Et puis le déclenchement du processus se fait par l'injection d'une substance liquide. On se demande comment cette substance contient toute l'architecture du rêve qui a été soigneusement conçue à destination de la cible.
Mais bon en dépit de ces scories le film reste excellent. En plus Ellen Page et Marion Cotillard sont absolument charmantes.
mmm...pas besoin de totem spécifique alors. Il suffit de regarder ta bite ton corps en détail car personne ne le connait autant que toi et n'est capable de le reproduire en rêve dans ses moindres détails.
Un film tout à fait excellent et même impressionnant...mais qui souffre quand même de quelques incohérences.
Par exemple deux trucs évidents:
- Toute l'histoire tourne autour du fait que Leo veut absolument vivre a nouveau avec ses enfants et il est prêt à accepter toutes les missions pour atteindre ce but. C'est pour ça que Ken Watanabe lui propose le marché de faire annuler son mandat d'arrêt. Mais pourquoi Leo ne se contente pas de faire venir ses enfants dans le pays ou il vit ? C'est trop dur de passer un coup de fil au grand-père ayant la garde pour lui dire "Hey Grand'pa ramène toi en France avec les gamins que je puisse les chouchouter" ? Bon c'est sûr que si il fait ça il n'y a plus de film.
- Pourquoi le Totem est-il censé nous informer qu'on est dans un rêve ou pas ? Après-tout si il ne se comporte pas comme d'habitude cela peut aussi bien faire partie du rêve non ?
Concernant la section de la news "références à d'autres films" j'ajouterai qu'on peut également évoquer des livres de science-fiction comme Simulacron 3 de Galouye ou presque tous les romans de Dick.
Quand on annonce que 16 000 bugs ont été corrigés cela devrait vouloir dire que 16 000 dysfonctionnements ont réellement été corrigées dans KDE. Sinon cela perd tout son sens.
Bien entendu que vérifier les doublons c'est du boulot, mais cela ne corrige pas un dysfonctionnement dans KDE !
Sinon ils peuvent aussi dire que 16 000 trous ont été creusés puis rebouchés. C'est assurément un sacré travail que de creuser et de reboucher autant de trous mais je en vois pas en quoi cela améliore directement KDE.
Je ne dénigre pas du tout le boulot des devs de KDE. Je dis juste qu'ils feraient mieux de laisser tomber cette mesure des bugs fermés car elle est absurde.
>>> Le libre n'est pas non plus a l'abri de choix stupides.
Je n'ai jamais prétendu cela. J'ai juste dit que "les chances de se gourer sont réduites".
J'ajoute que les décisions de la lkml se basent sur des arguments techniques et que la volonté marketing d'une firme ne joue pas de rôle...à l'inverse d'une entreprise qui appliquerait la politique du "tu decides selon tes propres desirs uniquement, et tu controles tout ce qui se passe".
J'ajoute à ta réponse un petit commentaire à destination de PasBill au sujet de sa phrase:
"Quand tu controles la chaine de bout en bout, tu decides vite, tu decides selon tes propres desirs uniquement, et tu controles tout ce qui se passe, c'est un gros avantage.
Certes tu peux décider vite en théorie (imr t'a expliqué pourquoi cela n'est pas toujours le cas) mais surtout tu te prive des retours de la communauté !
Le fait de décider dans ton coin, selon tes propres désirs, peut t'emmener vers une solution sous-optimale ou même, pire, vers une impasse technique.
Quand, à l'inverse, on choisit d'envoyer des patchs sur la lkml et que la décision d'inclusion est prise à la suite un consensus communautaire obtenu de haute lutte auprès de pairs à l'esprit critique ô combien aiguisé...ben les chances de se gourer sont réduites.
Regarde par exemple les compétitions entre solutions techniques comme LVM contre EVMS ou comme NGPT contre NPTL ou encore perfmon contre perfcounters.
Cette compétition darwinienne explique en partie le succès technique de Linux...et elle n'existe pas quand tu décides dans ton coin, selon tes propres désirs.
# Original version (questions in french and answers in english)
Posté par patrick_g (site web personnel) . En réponse à la dépêche Entretien avec Stefano Zacchiroli, Responsable du Projet Debian. Évalué à 10.
There are contributions coming back, yes. Some of them can be followed using the (Debian) bug tracking system. For instance, at the end of the https://wiki.ubuntu.com/Debian/Usertagging wiki page there are a couple of interesting links, listing all (Debian) bug reports originating from Ubuntu, as well a similar listing of bug reports containing a patch coming from Ubuntu. Other examples of collaborations are "mixed" packaging team formed by both Debian and Ubuntu people. Does this mean that collaboration is perfect? Well, no. In principle Debian should expect to Ubuntu to give back all its work to Debian, in perfect fulfillment of a sane "upstream/downstream" relationship; but in principle we in Debian should be perfect in pushing changes to our upstreams and we are not. Let's say that we are starting to realize that and working together to decrease the "viscosity" of patch flow in all
directions.
Quelles sont, selon toi, les raisons de préférer Debian par rapport à Ubuntu ?
I've discussed the more general topic of the relevance of Debian in my recent talk "bits from the DPL" delivered at DebConf10 in New York, at the beginning of August (http://penta.debconf.org/dc10_schedule/events/569.en.html , video at http://meetings-archive.debian.net/pub/debian-meetings/2010/(...)
Debian is still unique among "mainstream" distributions for several reasons. There are some technical reasons (e.g. portability), but more important than that there are philosophical reasons. Debian is independent from money as it is not backed by any single company that can drive its decisions. Even more so, Debian is a do-ocracy and a democracy, which is quite peculiar among "corporate" distro. Finally, Debian has been spreading what I call the culture of freedom since 1993 and it is still doing that, without imposing non-free software or services to any of its users and developers. For me, this is a quite strong motive for choosing Debian over most other distros out there (and we should all keep in mind that some of the most popular distros out
there are heavily *based* on the work being done in Debian and that would have very hard time surviving without Debian)
Dans la dépêche annonçant ton élection [https://linuxfr.org//2010/04/18/26746.html] il est dit que le nombre de développeur Debian est au plus bas depuis 2003. Quelles sont les raisons données par ceux qui sont partis?
Claiming that the number of developers has decreased since 2003 is just a poor observation of data, without knowing the underlying details. We have had a sharp decrease *on paper* in the last 2 years, but that is just because DAM (the Debian Account Manager) has started to clean up old/unused accounts quite incisively, by pinging and then removing the accounts of people who have neither voted nor uploaded a package in the past 2 years. So, in fact, we cannot conclude from that data that people power have decreased, we have simply got the official numbers closer to reality.
As of today, we have about 900 DDs and 120 DMs (Debian maintainers), so we are pretty much in the same 1'000 ballpark numbers, with the advantage that most of the inactive people no longer figure in the count. Arguably then, our people power has increased.
Est-ce que l'introduction du nouveau statut de Debian Maintainer aux côtés de celui de Debian Developper est une bonne chose ?
Absolutely yes! As I've discussed above DMs are doing a lot of work and maintain several even important packages, without needing to be as committed to the project as DDs are. Additionally (even though I don't have [yet] numbers to back this out) we all have the feeling that becoming DM is for a lot of people a first step to become DD. Hence the role of DM is de facto reducing the contribution barrier to maintain packages independently and also help in getting more enthusiastic people becoming DD.
Si on ne parle pas anglais et qu'on ne sait pas programmer comment aider quand même le projet Debian ?
This is a tricky problem. We are well aware that there are problems in contributing to Debian without speaking English. In an ideal world, one should be able to contribute to Debian in her own language for every possible contributions, including bug reporting. Unfortunately arriving there would require a huge amount of translation people power, that we currently lack.
Nevertheless it is possible to contribute without knowing English, as code is code for everyone. Obviously, it is more difficult when all the other contributors of the code only speak English, as communicating with them becomes more difficult.
En quoi le site http://debian.org reste-t-il à améliorer ?
The look and feel is the most reported answer to this question. It is being worked on and we have already released some sub-site with a new look and feel. The debian-www team deserves lots of kudos for the ongoing work and the delay is essentially related to the lack of people power working on that stuff (it's way easier to complain it has not been done yet than actually getting to understand what are the blockers).
More importantly than that however, I believe we should use the website to explain more why Debian is unique in the distro world of today. I plan to work on that together with the debian-www team, although I haven't yet started doing that.
Est-il possible de se procurer un paquet source vierge du site web afin de faire des essais pour l'améliorer ?
It is not packaged in a standalone package, but maintained using version control system and appropriate alioth group. Every Debian Developer can easily join the group, as well as any non-DD which has shown she is able to contribute (via patches to the BTS or the like). All information on how to contribute can be found at http://www.debian.org/devel/website/
À quand le freeze de Squeeze ? A quand la sortie de la version finale de Squeeze ?
Thanks to my delay in replying to this interview, Squeeze is now frozen!, it has been announced during DebConf10 a few days ago. As
usual, it will be "released when it's ready", which for us is guarantee of quality: we are not willing to give up on package quality in order to meet some arbitrary deadline. If we all work together (not only DDs/DMs, but also contributors sending patches), I believe we can easily do that during 2010 Q4. If people would like to help, the best way to do that is helping fixing release critical bugs that are affecting Debian Squeeze; an easy to go through list is available at: http://bts.turmzimmer.net/details.php?bydist=squeeze&sor(...)
Est-ce qu'il est envisageable d'avoir des freeze qui soient périodiques (time based) même si la sortie de la stable reste en mode "quand c'est prêt" (when it's ready).
This is a very "hot topic" in Debian, that we will for sure discuss at the beginning of the release cycle of Squeeze+1. It is a far reaching topic, on which we would like to have agreement first of all from the Release Team and surely a large consensus in the developer body. Personally, I think that time-based freezes (which is not the same thing of time-based releases) is something good, for the simple reason that enable developers to plan in advance big changes. But again, this is a discussion for Squeeze+1 we will have all together and from which you'll surely hear back in the news.
Quel sera le nom de la prochaine stable après Squeeze ?
I don't know. The Release Team does a very hard and often thankless work in Debian, which tends to attract more flames thank kudos. Among the few fun privileges the Release Team enjoys, there is the honor of getting to choose release names. Usually, the Release Team announces that at the beginning of the release cycle, so nobody will know before the release of Squeeze. If you want to know earlier, you should help releasing Squeeze!
Est-ce que le mandat de DPL d'un an n'est pas trop court ? Qu'est-ce qu'il est vraiment possible de faire en à peine un an ?
This is a tricky question. I'm now at about 1/3 of my DPL term and I agree that 1 year is kind of short, mainly because it takes some time in the beginning to understand the job and start doing it efficiently. On the other hand we are all volunteers and the DPL work is quite challenging, asking volunteers to do that for more than 1 year might scary away potential candidates. I really don't know whether a different arbitrary length would be better or worse.
A propos de Mancoosi, est-ce que ce projet a apporté quelque chose concrètement dans Debian ?
Of course my answer on this is biased, but I argue that yes, Mancoosi is giving back quite some contributions to Debian. First of all we are maintaining several Quality Assurance infrastructure and tools, such as the edos-debcheck package (used routinely to check that the archive contains no uninstallable packages before a release) and the http://edos.debian.net services. Additionally, we are now working with package manager developers to improve the quality of dependency solving in Debian (and in other distros) by using technologies we have developer in Mancoosi such as CUDF. Readers interested in the topic should know that they can contribute to the initiative, by reporting (a-la popcon) their dependency solving issues via the "mancoosi-contest" package that can be found at http://mancoosi.debian.net.
Sans langue de bois est-ce que le projet Debian GNU/kFreeBSD est vraiment utile ? Combien de gens utilisent ça au lieu de choisir la vraie version FreeBSD ?
I can't predict the future, so I really don't know how many users will choose it over the "real" FreeBSD. Nor I think it does matter. Debian is quite unique already in its port availability. The fact that all official ports thus far have been Linux-based ports is however not a goal. Debian goals are to create free operating system and it is written nowhere that it should remain Linux-only. Obviously, I don't see the most popular Debian kernel changing anytime soon, but at the same time I'm well aware that the most widespread/functional port of GNU/Hurd today is Debian GNU/Hurd and I'm proud of that. On the same vein, I'm proud that there is a possibility of releasing Squeeze, for the first time, with 2 non-Linux ports that are kFreeBSD-based.
After all, let's not forget that we are volunteers and that we work for fun. It is evident that there are out there capable volunteers that did manage to bring Debian GNU/kFreeBSD to a potentially releasable state. Kudos to them! For the evaluation of user acceptance of those ports we have time ... but no such evaluation would have been possible if the ports weren't there in the first place!
Si on regarde cette page de stats pour le noyau 2.6.34 [http://www.remword.com/kps_result/2_6_34_whole.html] on voit que Debian est seulement en 93ème position des contributeurs avec à peine 5 patchs. Est-ce que c'est la réalité ? Si non comment inciter les développeurs Debian a rendre plus visibles leurs contributions ?
This question seem a bit trollish at first glance :-)
First of all the idea of a comparison among corporate distributions and Debian would be totally unfair, as companies have *employees* that contribute to the Linux kernel, while Debian has *volunteers*. Furthermore, the moral argument for which companies "have to" contribute to Linux is rooted on the fact that they make money with it; that argument is trivially non applicable to Debian.
But even if we let that go, it is clear that Debian contributions are not consistently reported under the name "Debian" (which is OK as, again, Debian is not a company, so Debian volunteers are free to do the accounting of their contribution as they please).
Just to mention a significant example, Ben Hutchings is a prominent member of the Debian kernel team. His contributions are, at least in the few examples I've checked, reported under the "Hobbysts" category rather than under the Debian one. For Linux 2.6.34 Ben has contributed 17 patches, 12 for 2.6.32, while for Linux 2.6.33 the number climbs up to 38 patches.
So, those numbers are nice, but are appropriate only to rank companies whose contributors are, I suppose, *expected* to mention the company in their contributions. For Debian this is not the case, but that means nothing in terms of how much the Debian kernel team contributes back to the Linux kernel.
Quelle est la situation de Python au sein de Debian ? Au vu de http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=573745 est-ce que la situation n'est pas bloquée ?
In my humble opinion the situation has advanced more in the past 6 months than in the past 4 years (not for my merit, but thanks to the efforts of the Debian Python community). For instance, the python-defaults and python3-defaults packages, which determine which are the default Python interpreter versions in Debian, are now co-maintained.
The situation on the (versioned) Python interpreters themselves is indeed stuck, but as all social issues it is not an easy one to deal with. Unfortunately, now that the Technical Committee has been invoked, we can basically only wait for their decision, as the committee is the highest technical authority in Debian. Only a General Resolution can override the committee or decide in its place.
Dans ta plateforme tu as indiqué "I will fight strong package ownership when it conflicts with quality". Quels sont les pouvoirs du DPL dans ce domaine ?
You're right that there is no specific power the DPL can use for that. The only non-power that can be used is a relatively higher
popularity / consensus, coming from the fact that I've been voted on a platform containing that statement. Anyhow, I believe I've done more in that direction before becoming DPL with my RCBW campaign (see http://deb.li/rcbw for more info) than afterwords.
The key idea is that in Debian we really need to generalize our culture and realize that to continue releasing the way we are doing it now, we really need more collaboration among package maintainers and that NMU (Non-Maintainer Uploads) are a viable tool for such collaboration. This topic has been discussed at DebConf10 in a BoF I've organized on the subject (http://penta.debconf.org/dc10_schedule/events/609.en.html ,video at http://meetings-archive.debian.net/pub/debian-meetings/2010/(...)
Plus généralement comment gérer les cas de développeurs non coopératifs au sein d'un projet communautaire ?
In its generality, this is quite a tricky question to answer.
In Debian, we are getting better at that: encouraging and welcoming NMU is the first needed step. If that is accepted, then it becomes relatively easy to identify packages which are being neglected by their legitimate maintainers (e.g. it is enough to look for packages maintained essentially only via several NMUs in a row). At that point, we do have hijacking and QA procedures that we can use to pass the package to who has been working on it for the last uploads.
Maintenant que micrologiciels (firmwares) posant des problèmes juridiques de redistribution sont séparés du noyau Debian est-ce que le projet va chercher à être officiellement approuvé par la FSF comme par exemple gNewSense ?
It's interesting that you ask this question, as I've been discussing recently with both FSF people and gNewSense people of this matter. I share your point of view that we should work in that direction to improve the relationship among Debian and FSF. On the other hand, gNewSense folks are very happy of our choice as that will make their work easier.
[^] # Re: Découvert et corrigé en 2004... puis oublié
Posté par patrick_g (site web personnel) . En réponse à la dépêche Problème de sécurité entre le serveur X et le noyau. Évalué à 2.
"The most unfortunate aspect of the bug is the length of time it took to fix. Not just the two months between its discovery and fix, but also the five years since Delalleau's presentation. We need to get better at paying attention to publicly accessible security reports and fixing the problems they describe.".
[^] # Re: Empathy, Gajim, Pidgin
Posté par patrick_g (site web personnel) . En réponse au journal google chat: enfin une solution vidéo aboutie pour les distributions les plus répandues (debian et ubuntu). Évalué à 4.
mouais....mais là le problème c'est que c'est moi qui désire communiquer par vidéo avec ma soeur (pour voir la bouille de mon neveu) ou avec mon frère (pour voir la gueule de son appartement à Hong-Kong).
C'est un besoin réel que j'ai et ils sont tous les deux sous Windows...donc comment faire ?
Google Chat est peut-être une solution (en attendant qu'un soft libre multipleforme soit réellement disponible).
[^] # Re: Découvert et corrigé en 2004... puis oublié
Posté par patrick_g (site web personnel) . En réponse à la dépêche Problème de sécurité entre le serveur X et le noyau. Évalué à 2.
[^] # Re: Découvert et corrigé en 2004... puis oublié
Posté par patrick_g (site web personnel) . En réponse à la dépêche Problème de sécurité entre le serveur X et le noyau. Évalué à 7.
mmm....d'autres disent que la faille de l'époque n'était pas accompagnée d'un exploit et qu'elle paraissaient donc plus théorique que réelle. Comme en plus le fix d'Andrea Arcangeli était jugé très invasif et "ugly" il n'a pas été accepté.
Avec l'exploit de 2010 les devs ont pris conscience du souci et un fix minimal et élégant a été implémenté (totalement différent du patch d'Andrea donc).
Il y a tout un article au sujet de ce bug sur le site LWN: http://lwn.net/Articles/400746/ [article qui sera ouvert à tous jeudi prochain].
Évidemment, comme à chaque fois qu'il s'agit de sécurité, on retrouve Brad Spengler et PaXTeam dans les commentaires te ça trolle dur. Difficile de savoir qui a vraiment raison dans toute cette polémique.
[^] # Re: « X, le serveur graphique de Linux »
Posté par patrick_g (site web personnel) . En réponse à la dépêche Problème de sécurité entre le serveur X et le noyau. Évalué à 6.
Depuis que les pilotes graphiques sont dans le noyau (kernel mode setting) ça devient envisageable de faire tourner X en non-root.
Il me semble qu'Ubuntu a annoncé un projet pour faire ça.
[^] # Re: Pour info...
Posté par patrick_g (site web personnel) . En réponse au journal Où l'on trolle sur la médaille Fields.. Évalué à 4.
[^] # Re: Et Empathy ?
Posté par patrick_g (site web personnel) . En réponse au journal google chat: enfin une solution vidéo aboutie pour les distributions les plus répandues (debian et ubuntu). Évalué à 10.
Est-ce qu'il existe un binaire Windows d'Empathy que je puisse recommander à mon frère afin de lui permettre de chater en vidéo entre son ordi sous WinXP et mon ordi sous Linux ?
Si ce n'est pas le cas alors, oui, Google Chat sera LA solution à privilégier par rapport à Skype.
C'est déjà pas mal.
[^] # Re: Ca existe toujours ça ?
Posté par patrick_g (site web personnel) . En réponse à la dépêche Vim 7.3. Évalué à 3.
Si tu va sur http://live.gnome.org/Gedit/Plugins tu verras qu'il y a un plugin split view
Je l'utilise en permanence pour écrire les dépêches LinuxFr un peu longues.
[^] # Re: To FUD or not to FUD
Posté par patrick_g (site web personnel) . En réponse au journal Apple prépare-t'il un coup 'à la Oracle'?. Évalué à 2.
Stallman n'est pas le project leader de GCC : http://gcc.gnu.org/steering.html
Il y a un comité technique qui prend les décisions de façon collégiale.
[^] # Re: Fields medal
Posté par patrick_g (site web personnel) . En réponse au journal Où l'on trolle sur la médaille Fields.. Évalué à 10.
Ouais enfin il y a aussi beaucoup de chercheurs ayant le statut de fonctionnaire et qui donc peuvent glander à vie sans rien publier (et être augmentés juste par le biais de l'ancienneté). Je connais une chercheuse à l'INSERM et elle m'a raconté des histoires à faire dresser les cheveux sur la tête.
Donc bon le système français à des vertus mais aussi des gros défauts.
# Fields medal
Posté par patrick_g (site web personnel) . En réponse au journal Où l'on trolle sur la médaille Fields.. Évalué à 10.
J'avais prédit la médaille de Ngo en mars dernier [http://linuxfr.org//comments/1110576,1.html] et j'avais dit que je n'hésiterai pas une seconde à m'auto-louanger. C'est fait ;-)
>>> les deux gagnants sont passés, comme par hasard, à l'École Normale
C'est plus incroyable que ça. A part Alexandre Grothendieck (interné dans un camp lors de la guerre car juif) tous les autres mathématiciens français sont des anciens élèves de l'Ecole Normale supérieure. Tous !
C'est une domination absolument incroyable. Je ne crois pas qu'il existe une seule université dans le monde qui puisse ainsi s'enorgueillir d'avoir 10 médailles Fields à son palmarès.
>>> Quelle différence faîtes-vous entre les systèmes académiques français et, disons, américain ?
C'est un peu une tarte à la crème mais le système français permet (aux meilleurs des) mathématiciens d'avoir un poste fixe. Ils peuvent ainsi se consacrer à leur recherche sans avoir à sauter de post-doc en post-doc et à vivre sous le couperet du "publish or perish".
Les postes des CNRS permettent de faire de la recherche à 100% sans aucune tâche d'enseignement et sans crainte de l'avenir car le poste est stable.
Cela doit bien sûr engendrer des abus mais cela a aussi accouché des travaux de Laurent Lafforgue. Recruté au CNRS à la sortie de sa thèse il a bossé pendant 7 ans sans publier quoi que ce soit avant de sortir son grand article qui lui a valu sa médaille Fields.
Au USA ils se serait fait éjecter du système pour ne pas avoir sorti de papier pendant une période aussi longue.
[^] # Re: Feedback
Posté par patrick_g (site web personnel) . En réponse au journal Flattr, en particulier sur linuxfr ?. Évalué à 2.
J'employais le terme "rembourser" au sens métaphorique. Bien entendu comme tu le souligne, je ne dois rien au sens propre du terme...mais je me sens moralement redevable et donc j'essaye de compenser un peu en faisant un truc.
En plus c'est fun d'écrire des dépêches !
[^] # Re: Feedback
Posté par patrick_g (site web personnel) . En réponse au journal Flattr, en particulier sur linuxfr ?. Évalué à 6.
Tu disais ça pour rigoler mais je réagis quand même, on sait jamais. Je ne sais pas quelle est l"opinion des autres auteurs de news mais en ce qui me concerne j'écris mes dépêches pour tenter de rembourser mon usage des logiciels libres (vu que je ne code pas). Ce serait donc bizarre d'en retirer un bénéfice financier non ?
Je suis de l'avis de Fabien : http://linuxfr.org/comments/1153705,1.html
Ce qu'il faut c'est plus de contributeurs pour faire vivre le site.
[^] # Re: C'est une copie
Posté par patrick_g (site web personnel) . En réponse à la dépêche Inception. Évalué à 6.
Hérétique ! Brûle, brûle !
Sans déconner la fin de la nouvelle de Dick est 100x fois meilleure que la fin moisie de Total Recall.
[^] # Re: pan t'es mort !
Posté par patrick_g (site web personnel) . En réponse à la dépêche Inception. Évalué à 4.
Donc pour moi:
1) Brazil
2) La cité des enfants perdus
3) Le voyage de Chihiro
[^] # Re: C'est pas un peu trop subjectif comme dépêche?
Posté par patrick_g (site web personnel) . En réponse à la dépêche Inception. Évalué à 2.
Mais bon en dépit de ces scories le film reste excellent. En plus Ellen Page et Marion Cotillard sont absolument charmantes.
[^] # Re: Cessons les analyses !
Posté par patrick_g (site web personnel) . En réponse à la dépêche Inception. Évalué à 3.
Mais le lien est mort donc il faut le consulter par là http://web.archive.org/web/20050312154645/http://pserve.club(...)
[^] # Re: pan t'es mort !
Posté par patrick_g (site web personnel) . En réponse à la dépêche Inception. Évalué à 10.
Fastoche. C'est Brazil évidemment.
[^] # Re: Super film
Posté par patrick_g (site web personnel) . En réponse à la dépêche Inception. Évalué à 10.
# Super film
Posté par patrick_g (site web personnel) . En réponse à la dépêche Inception. Évalué à 9.
Par exemple deux trucs évidents:
- Toute l'histoire tourne autour du fait que Leo veut absolument vivre a nouveau avec ses enfants et il est prêt à accepter toutes les missions pour atteindre ce but. C'est pour ça que Ken Watanabe lui propose le marché de faire annuler son mandat d'arrêt. Mais pourquoi Leo ne se contente pas de faire venir ses enfants dans le pays ou il vit ? C'est trop dur de passer un coup de fil au grand-père ayant la garde pour lui dire "Hey Grand'pa ramène toi en France avec les gamins que je puisse les chouchouter" ? Bon c'est sûr que si il fait ça il n'y a plus de film.
- Pourquoi le Totem est-il censé nous informer qu'on est dans un rêve ou pas ? Après-tout si il ne se comporte pas comme d'habitude cela peut aussi bien faire partie du rêve non ?
Concernant la section de la news "références à d'autres films" j'ajouterai qu'on peut également évoquer des livres de science-fiction comme Simulacron 3 de Galouye ou presque tous les romans de Dick.
[^] # Re: Qt mais pas complètement ?
Posté par patrick_g (site web personnel) . En réponse au journal Sortie de exxEditor - version 0.9. Évalué à 2.
[^] # Re: Vers où va KDE ?
Posté par patrick_g (site web personnel) . En réponse à la dépêche Sortie de KDE 4.5. Évalué à 6.
Quand on annonce que 16 000 bugs ont été corrigés cela devrait vouloir dire que 16 000 dysfonctionnements ont réellement été corrigées dans KDE. Sinon cela perd tout son sens.
Bien entendu que vérifier les doublons c'est du boulot, mais cela ne corrige pas un dysfonctionnement dans KDE !
Sinon ils peuvent aussi dire que 16 000 trous ont été creusés puis rebouchés. C'est assurément un sacré travail que de creuser et de reboucher autant de trous mais je en vois pas en quoi cela améliore directement KDE.
Je ne dénigre pas du tout le boulot des devs de KDE. Je dis juste qu'ils feraient mieux de laisser tomber cette mesure des bugs fermés car elle est absurde.
[^] # Re: Link
Posté par patrick_g (site web personnel) . En réponse au journal Vendredi 13: soleil noir pour le logiciel libre.. Évalué à 2.
Je n'ai jamais prétendu cela. J'ai juste dit que "les chances de se gourer sont réduites".
J'ajoute que les décisions de la lkml se basent sur des arguments techniques et que la volonté marketing d'une firme ne joue pas de rôle...à l'inverse d'une entreprise qui appliquerait la politique du "tu decides selon tes propres desirs uniquement, et tu controles tout ce qui se passe".
[^] # Re: Link
Posté par patrick_g (site web personnel) . En réponse au journal Vendredi 13: soleil noir pour le logiciel libre.. Évalué à 5.
"Quand tu controles la chaine de bout en bout, tu decides vite, tu decides selon tes propres desirs uniquement, et tu controles tout ce qui se passe, c'est un gros avantage.
Certes tu peux décider vite en théorie (imr t'a expliqué pourquoi cela n'est pas toujours le cas) mais surtout tu te prive des retours de la communauté !
Le fait de décider dans ton coin, selon tes propres désirs, peut t'emmener vers une solution sous-optimale ou même, pire, vers une impasse technique.
Quand, à l'inverse, on choisit d'envoyer des patchs sur la lkml et que la décision d'inclusion est prise à la suite un consensus communautaire obtenu de haute lutte auprès de pairs à l'esprit critique ô combien aiguisé...ben les chances de se gourer sont réduites.
Regarde par exemple les compétitions entre solutions techniques comme LVM contre EVMS ou comme NGPT contre NPTL ou encore perfmon contre perfcounters.
Cette compétition darwinienne explique en partie le succès technique de Linux...et elle n'existe pas quand tu décides dans ton coin, selon tes propres désirs.