Piratebab : Bonjour Julien, alias Ainulindale. Peux-tu nous en dire un peu plus sur toi, et sur ton pseudo ?

Ainulindale :
Mon pseudo est "Ainulindalë", et ça veut dire "Musique des Ainur".
Ça vient de Tolkien, c'est la génèse du monde. Enthousiasme de jeunesse, qui ne reflète que l'âme d'un mélomane !  :-)
Quant à moi, je suis actuellement ingénieur en sécurité dans une SSII française, je vis sur Vincennes (près de Paris), et je suis tombé dans le logiciel libre par hasard, pour tester, par curiosité intellectuelle, comme beaucoup de gens je suppose. Et depuis, je suis resté accro  :-)

Piratebab : Comment as-tu découvert l'openmoko et son freerunner ?

Ainulindale :
Si je me rappelle bien, c'était suite à un article sur LinuxFR.org.
J'ai apprécié l'initiative, et contrairement à beaucoup, j'ai pris ça pour ce que c'était : un "work in progress".
L'idée de pouvoir y participer m'a plu dès le début.

Piratebab : Et le fameux buzz, mythe ou réalité ?

Ainulindale :
Réalité tristement.
Mais grâce à Daniel Willman (alphaone) de FSO, mes deux freerunners sont à présent libres de toute perturbation électromagnétique, et mon téléphone a maintenant une très bonne qualité.

Piratebab : Comment SHR a-t-elle vu le jour ?

Ainulindale :
Bobby Martin (wurp), avec qui j'ai discuté longtemps sur IRC, a lancé le projet.
Le but était d'avoir une vraie distribution communautaire, permettant le maximum de modularité vis à vis des outils disponibles à l'époque (juillet 2008), et basée sur le framework de Freesmartphone.Org.
L'idée m'a plu, et je me suis jeté dans le bain !

Piratebab : Quels sont les principes de base de SHR ?

Ainulindale :
SHR est user centrique.
Le but est de permettre à l'utilisateur de faire ce qu'il souhaite, et de ne lui imposer aucun choix.
Nous n'y sommes pas encore, mais nous y oeuvrons.
C'est aussi une distribution dont la vocation est de délivrer une version *stable*, réellement stable et maîtrisée, où la communauté construite autour permette à chacun d'être cheville ouvrière du projet, et non pas simple consommateur.
D'où les votes, les suggestions, les demandes auprès de la communauté.

Piratebab : A part la téléphonie, quelles sont les applications disponibles pour SHR ?

Ainulindale :
Toutes les applications de OpenEmbedded, sur lequel nous nous basons, peuvent être disponibles sur demande via ticket sur le trac.
De plus, nous créons régulièrement des nouvelles "recettes" de packages pour les utilisateurs.
Dans les paquets actuellement disponibles, il y a plusieurs browsers (dillo, dillo2, midori, ...), des applications de paramétrage (shr-settings, shr-config), des applications GPS (tangogps, navit, openBmap..).
Le maître mot est ici : choix.
Nous souhaitons offrir un maximum de choix, un maximum de diversité, car au final, l'important est que l'utilisateur s'approprie un système qu'il considère comme apte à satisfaire ses besoins.

Piratebab : Quel est ton rôle dans ce projet ?

Ainulindale :
Je suis le "dictateur bénévole", c'est à dire que je gère le projet d'un point de vue managérial.
Je fais donc beaucoup de management d'équipe, d'organisation, et je gère en même temps le buildhost avec mrmoku.
Je participe également au développement de plusieurs projets, mais j'ai, à mon grand regret, de moins en moins de temps pour ça.
Et enfin, je suis par défaut le monsieur "Public Relations" de SHR, bien que ces derniers temps nous nous focalisons sur la release, et que je me suis fait silencieux !

Piratebab : De combien de personnes se compose la core team ?

Ainulindale :
11 personnes, ici classées au hasard :

  • Tom Hacohen - TAsn (Israël)
  • Sebastian Spaeth - spaetz (Suisse)
  • Didier 'ptitjes' - ptitjes (France)
  • David Wagner - Deubeuliou (France)
  • Cameron Frazier - Toaster (Canada)
  • Rafael Campos - methril (Espagne)
  • Mickey Lauer - mickeyl (Allemagne)
  • Pietro Montorfano - m0nt0 (Italie)
  • Sebastian Krzyszkowiak - dos (Pologne)
  • Klaus Kurzmann - mrmoku (Allemagne)
  • Julien Cassignol - Votre serviteur (France)

Piratebab : Qu'en est-il de la version stable annoncée il y a plusieurs semaines ? Pourquoi tant de retard ?

Ainulindale :
Je refuse, à titre personnel, de créer une version stable avec du matériel jugé "non stable".
Il s'avère que nous affrontons un bug dans les méandres de la librairie DBus qui sert de base à tout le framework.
Ce bug est quelque peu gênant : les appels asynchrones se perdent parfois.
Le résultat est que, par exemple, un sous-système du framework reste coincé sur un appel qui ne retourne jamais : plus de suspend, plus d'appels, etc.
Il est donc hors de question de releaser quelque chose qui ne sera pas fonctionnel à 99% au minimum (bien qu'il y aura, cela va sans dire, et c'est triste, des bugs).

Piratebab : Testing ou Unstable: laquelle choisir ?

Ainulindale :
Malheureusement testing est trop peu souvent mise à jour actuellement, car nous n'avions pas de "maintainer" officiel. Cela va changer.
Il y aura à présent des mises à jour fréquente de paquets jugés "testing material", qui iront donc vers testing, et permettront un cycle de vie plus "sain", et éviteront les reflashs.

Piratebab : D'après toi, quels sont les problèmes actuels de SHR qui peuvent être les plus gênants pour  les utilisateurs, et qui doivent être corrigés avant la release de la stable ?

Ainulindale :
Question difficile  :-)
Les comportements imprévisibles du framework sont pour nous la priorité : nous voulons un framework stable à 100%.
Il faut ensuite pouvoir être capable de se servir correctement de la téléphonie.
J'aurais aimé que le PIM fasse partie de la release, mais il nous faudra du temps pour le tester, aussi, je ne pense pas que cela sera le cas.
Enfin, il y a quelques changements esthétiques et de praticité qui s'avèrent nécessaires : organiser le launcher, facilité la vue des appels manqués, offrir la possibilité de manipuler le volume en appel, ce genre de chose.

Piratebab : Certains utilisateurs reprochent les mises à jour nécessitant un reflashage  trop fréquent, au lieu d'une mise à jour au fil de l'eau. Pourquoi ce choix ?

Ainulindale :
Il est malheureusement impossible, aujourd'hui, d'assurer un "upgrade path" viable avec OpenEmbedded.
Nous pourrions, en tant qu'équipe, nous focaliser là-dessus, mais cela nous prendrait un temps considérable.
Nous avons fait le choix de nous focaliser sur l'intégration de fonctionnalités "au plus vite", et sur la stabilité, quitte à en faire pâtir la procédure de mise à jour.
C'est un choix, malheureux ou pas, nous avons vôté  :-)
Rassurez-vous cependant, une procédure de sauvegarde/restauration de vos paramètres est en train d'être mise au point pour la home directory !  :-)

Piratebab : Quelles sont les autres améliorations prévues à court terme ?

Ainulindale :
Nous voulons offrir 100% de modularité sur tous les points.
Par exemple, d'un point de vue interface graphique, nous souhaitons offrir la possiblité aux développeurs d'appeler des méthodes fonctionnellement contextualisées leur permettant d'utiliser le framework sans s'en soucier : afficher un contact, ajouter un contact, envoyer un message pré-rempli ...
De plus, ceci permettrait de gérer dynamiquement les interfaces graphiques : si un utilisateur aime la librairie GTK pour les messages, la EFL pour le dialer, ce sera possible.
Et à terme, on souhaite qu'il soit possible de dire "si j'ai moins de 10% de batterie, utiliser la librairie ncurses", "si je suis en mode occupé, utiliser des notifications", etc... Nous souhaitons "contextualiser", selon les voeux de l'utilisateur, les interfaces graphiques, pour que chaque personne puisse construire une distribution à son image.
Après tout, certes, nous développons, mais ce n'est pas la distribution des développeurs SHR, c'est la distribution des utilisateurs de SHR, avant tout !

Piratebab : Peux-tu  me donner 4 raisons d'utiliser SHR plutôt qu'une des nombreuses autres distributions disponibles pour le freerunner ?

Ainulindale :
1) Nous nous basons sur OpenEmbedded, qui est *le* choix communautaire pour le déploiement de distribution embarqué.
C'est éprouvé, très actif, et complet.
2) Notre couche "middleware" est le framework de Freesmartphone.org, qui est selon nous l'idéal pour nous permetre de gérer chaque élément de la couche "physique" de manière abstraite, quel que soit le téléphone (ainsi nous pourrions nous déployer sur d'autres téléphones que le freerunner, assurant notre pérennité)
3) Nous souhaitons avant tout fédérer les solutions.
Nous avons nos développements internes, mais si quelqu'un vient avec une meilleure solution (UI, package, etc.), nous l'accueillerons à bras ouvert !
4) Enfin, l'orientation est clairement communautaire : nous ne vivons pas pour et par les développeurs, mais pour et par les utilisateurs.
Les requêtes, remarques, suggestions, sont prises en compte.
Tout choix impactant est soumis à la validation des utilisateurs, car vous êtes les premiers consommateurs.

Merci à toi !

PS : pour en savoir plus vous pouvez visiter le trac ou le blog de SHR, sans oublier bien sûr la page dédiée sur le wiki et les billets sur ce blog.