Forum

oui, avec un peu retard dû à diverses choses (comme tout le monde demande des trucs à nous sur irc sur un mode horaire (les gens, je l'espère se reconnaîtront)), Anne et moi avons passé en revue les différentes propositions faites par des années au cours de la première période de la distribution, et avant de Mandriva. Nous avons pris en compte les retours de personnes sur le forum, sur ml, e ceux que nous avons vu lors des événements. Nous avons également discuté avec les développeurs d'autres distributions que nous savons de openSUSE, Fedora, Debian, Ubuntu sur leur cycle de publication, le choix qu'ils ont faits et de leurs raisons.



Avant d'aller à la proposition, un point peu de vocabulaire:



cycle de sortie: le temps entre 2 versions.



du cycle de vie, le temps où nous offrons la distribution sur la plupart des miroirs, et un plan pour offrir à cette infra (backports à jour de sécurité,), et d'accepter ou de corriger des bugs. IE, "support" sur le niveau de la distribution.



Pour simplifier la discussion, les propositions sont toutes fondées sur le fait que 2 ou 3 rejets pourraient être soutenus à la fois. Nous aurions pu régimes différents pour que (LTS chaque nouvelle version X (ubuntu), différents niveaux de support (mandriva)), mais comme il s'agit d'une discussion un peu différente, supposons 2 versions prises en charge pour l'instant, et nous allons discuter plus tard, pour que soit ( la semaine prochaine, une fois celui-ci est terminé)



Et à peu près, pour lancer la discussion, nous avons 3 cycles potentiel de presse, basée sur toutes les entrées que nous avions:



Proposition 1:

6 mois cycle de sortie -> 12 mois du cycle de vie (Fedora, Ubuntu, Mandriva <2010,1 et 2006,0 = & Mandriva!)



Proposition 2:

9 mois cycle de sortie -> 18 mois du cycle de vie (opensuse ~ et celui que nous utilisons pour Mageia 1)



Proposition 3:

12 mois cycle de sortie -> 24 mois du cycle de vie (Mandriva> 2010.1)







Proposition 1:

---------------

Avantages:

- Une meilleure prise en charge matérielle

- Les versions à jour / projets en amont (il faut avoir pour les développeurs)





Inconvénients:

- Calendrier très serré: doit comprendre un remue-méninges, les spécifications, développements, les versions de développement

- Sentiment d'être la libération de tous les temps

- Cycle de vie court (rien à long terme)





Proposition 2

----------------

Avantages:

- Compromis entre la proposition 1 et la proposition 3

- Version de développement plus facile à gérer pour inclure toutes les mesures

- Permet de libérer en l'absence d'autres distributions, donc nous pouvons être sûrs d'avoir assez de communication





Inconvénients:

- Pas synchronisé avec gnome ou autres qui utilisent un cycle de 6 mois

- Potentiellement relâcher quand il n'y a pas beaucoup d'activité (comme pendant les vacances)





Proposition 3:

------------



Avantages:

- Les utilisateurs ne mise à jour moins souvent, car cela est souvent perçu comme fastidieux.

- Demandé par certains utilisateurs professionnels





Inconvénients:

- Moins de visibilité, car il ya moins de communication

- Les codeurs et les emballeurs ressentir une certaine envie de pousser la dernière minute pour fonction de ne pas attendre un an, en ajoutant des difficultés à gérer la planification sur 1 an sans version intermédiaire

- Le support matériel potentiellement à la traîne





Les lecteurs astucieux verrez que les 3 propositions sont tout le temps en fonction et les 2 solutions de rechange type de sortie serait:

- Pas de libération

- Des fonctionnalités basées.



Nous n'avons pas élaboré une proposition sur eux.

Le modèle de non-publication n'est pas vraiment un cycle de publication, par définition (si la planification de la libération est de ne rien faire, ce n'est pas un processus de planification).



Le modèle de base de fonction (autre titre: "la libération quand il sera prêt"), tout en étant séduisante, est une voie dangereuse, puisque le projet de trop nombreux sont en retard en raison d'un manque de planification formelle. Étant basé sur les caractéristiques ajouter plus de complexité à quelque chose comme une distribution compte tenu de la grande échelle des changements à mettre en œuvre, et le nombre élevé d'interaction. Ce n'était donc pas pris en compte pour cela.





Des thèses 3 propositions, Anne a été en faveur de la version 2 (9 mois), basé sur son expérience avec 1 (Mandriva) et 3 (Mandriva 2006.0).



Personnellement, j'ai été heureux avec 1 et 3 en tant qu'utilisateur, principalement parce que je suis parfaitement capable de prendre soin de toute question, donc je ne suis pas vraiment en mesure de donner une préférence. (J'utilise de bureau et serveur, même si la dichotomie est plutôt «des choses que je veux mettre à jour souvent» (poste de travail personnel, serveur à la maison) et de "trucs que je préfère pas mettre à jour souvent» (poste de travail des parents, un serveur externe).



Maintenant, rappelez-vous les règles.



- Toutes les propositions doivent être justifiées (et pourquoi ils sont meilleurs que ceux en cours).



- La discussion sera terminé le 22 Juin. Après cela, il est trop tard jusqu'à ce que nous rediscuter à nouveau (comme quelques années, si tout a changé).



- Si aucun consensus clair émergent, nous aurons à décider à l'aide d'une autre manière. Il faudra probablement faire des gens tristes si leur option préférée n'est pas celle qui est utilisée, mais telle est la vie.



- Si la discussion devient ingérable, n'oubliez pas les photos dans le sujet du canal irc des administrateurs système.





Maintenant, si quelqu'un pouvait point les autres équipes de cette discussion, ce serait utile. Anne m'a promis d'envoyer une note à l'anglais des forums à ce sujet.



Mais ne pas envoyer l'e-mail, demandez aux gens de parler au-dev plutôt que de discuter sur others_comm_channel $ (comme irc, forum, mls d'autres). Les gens ne poste pas sur-dev vont perdre leur droit de se plaindre qu'ils n'ont pas été écoutés. Si quelqu'un est volontaire pour recueillir des commentaires sur leur propre groupe, il fera beau.