[Obm] Fin d'annee 2009

2009-09-06 Par sujet Sebastien POMPIER

Bonjour,

Je vais mettre en place OBM et MiniG en production ce mois-ci.

J'ai donc quelque questions :

- vous semblez avancer à vitesse grand V sur le développements, la version 2.3 
va t'elle sortir bientôt (auquel cas je préfère attendre quelque jours pour 
mettre
en place cette version majeure),

- quand MiniG sera t'il réellement en production chez OBM, en effet, la version 
est en anglais uniquement, peu configurable (après de multiples tests et essais 
grâce à la mailing list, rien y fait).

Encore merci à vous pour votre travail et vos réponses

Sébastien



_
Messenger débarque dans Hotmail ! Essayez-le !
http://www.windowslive.fr/hotmail/web-messenger/___
Obm mailing list
Obm@list.aliasource.fr
http://www.list.aliasource.fr/mailman/listinfo/obm


Re: [Obm] Fin d'annee 2009

2009-09-06 Par sujet Thomas Cataldo
On Sun, 2009-09-06 at 14:31 +, Sebastien POMPIER wrote:
 Bonjour,
 
 Je vais mettre en place OBM et MiniG en production ce mois-ci.
 
 J'ai donc quelque questions :
 
 - vous semblez avancer à vitesse grand V sur le développements, la
 version 2.3 va t'elle sortir bientôt (auquel cas je préfère attendre
 quelque jours pour mettre
 en place cette version majeure),

Le modèle de versionning/releases a été un peu modifié depuis la 2.2.X
(X==6 il me semble mais pas complètement sur)

Soit une version X.Y.Z :

 - X.Y.Z+1 est une bugfix release qui ne peut contenir que des bugfix
sans changements d'UI. Pour ces versions nous nous efforcons à ce que
_tous_ les changement soit trackés dans notre bugzilla visible sur
http://www.obm.org/bugzilla/ 

 - X.Y+1.Z est une version avec améliorations fonctionnelles. Notre
bugzilla est au coeur de notre suivi. Si vous voulez savoir ce que va
changer la 2.3.X, regardez simplement les bugs identifiés en tant que
roadmap_feature auquel nous avons associé la sévérité MUST.

Nous avons modifié notre mode de release pour partir sur des time based
releases plutot que sur des features based releases. C'est à mon avis
le seul mode de fonctionnement viable.

En terme calendaire, entre X.Y.0 et X.Y+1.0 nous avons adopté le modèle
suivant :
 - 3 mois de dev (60 jours ouvrés) puis tag d'une X.Y+1.0-rc0
 - création de la branche X.Y+2 à partir de X.Y+1.0-rc0
 - Déploiement de X.Y+1.0-rc0 sur notre prod interne à partir des
packages
 - 1 mois de test de la X.Y+1.0-rcX
 - release de X.Y+1.0

Le trunk de svn.obm.org correspond à ce qui va devenir la 2.3.0-rc0.

De manière pragmatique il était évident que ce modèle n'était pas
applicable à 100% des composants d'obm :

 - au niveau obm-sync on s'autorise les additions d'API
 - au niveau minig, nous avons pris l'engagement de de pouvoir
fonctionner avec obm 2.2.x et obm 2.3.x mais nous nous autorisons les
changements fonctionnels.
 - le dev minig va rester feature based pendant encore un moment. La
dernière release officielle reste la 2.2.10.836. La 2.2.11 d'obm est
sortie mais la 2.2.11.889 de minig n'a pas été mise en ligne sur les
dépots obm.org car nous avions identifié des regressions que nous ne
pensions pas acceptables.

La 2.3.0-rc0 devrait entrer en test fin septembre. Quelques un des
changements à venir sont annoncés sur http://planet.obm.org/ le post de
Sylvain du 14 aout présente le calendrier obm 2.3.

 
 - quand MiniG sera t'il réellement en production chez OBM, en effet,
 la version est en anglais uniquement, peu configurable (après de
 multiples tests et essais grâce à la mailing list, rien y fait).
 

La langue est héritée des préférences obm récupérées via obm-sync par
minig. MiniG est par défaut english only sauf si on le connecte à un
obm qui lui indique que l'utilisateur souhaite être en francais.

Si vous regardez les releases notes minig
http://code.google.com/p/minig/source/browse/trunk/NEWS vous trouverez
que faire un lien vers /minig/WebmailUI.fr.html force minig a être par
défaut en français. Si votre minig ne bascule pas tout seul en français,
c'est peut être que quelque chose interdit la requete entre
minig-backend et obm-sync pour appliquer la langue obm.

MiniG est beaucoup plus configurable que son interface le laisse croire.
De nombreuses prefs sont appliquées (les prefs obm par exemple).

Dans l'avenir nous allons utiliser bcp plus nos dépots rc pour
permettre à la communauté de voir les choses que nous avons en chantier.

 Encore merci à vous pour votre travail et vos réponses


___
Obm mailing list
Obm@list.aliasource.fr
http://www.list.aliasource.fr/mailman/listinfo/obm


Re: [Obm] Fin d'annee 2009

2009-09-06 Par sujet Pierre Baudracco

- vous semblez avancer à vitesse grand V sur le développements, la
version 2.3 va t'elle sortir bientôt (auquel cas je préfère attendre
quelque jours pour mettre
en place cette version majeure),


La version 2.3.0 est prévue pour mi-novembre, apres un mois de freeze.


Le modèle de versionning/releases a été un peu modifié depuis la 2.2.X
(X==6 il me semble mais pas complètement sur)

Soit une version X.Y.Z :

 - X.Y.Z+1 est une bugfix release qui ne peut contenir que des bugfix
sans changements d'UI. Pour ces versions nous nous efforcons à ce que
_tous_ les changement soit trackés dans notre bugzilla visible sur
http://www.obm.org/bugzilla/ 


 - X.Y+1.Z est une version avec améliorations fonctionnelles. Notre
bugzilla est au coeur de notre suivi. Si vous voulez savoir ce que va
changer la 2.3.X, regardez simplement les bugs identifiés en tant que
roadmap_feature auquel nous avons associé la sévérité MUST.

Nous avons modifié notre mode de release pour partir sur des time based
releases plutot que sur des features based releases. C'est à mon avis
le seul mode de fonctionnement viable.


En gros le sujet est que nous souffrions de rajouter des features dans 
les versions stables.

Ce ne sera donc plus le cas.
Mais par contre nous augmentons la cadence de sortie des versions 
majeures, afin de ne pas attendre une feature simple un an.



En terme calendaire, entre X.Y.0 et X.Y+1.0 nous avons adopté le modèle
suivant :
 - 3 mois de dev (60 jours ouvrés) puis tag d'une X.Y+1.0-rc0


nous visons 3 mois, mais ceci pourra varier ou etre ajuster, afin de ne 
pas avoir 15 versions stables a maintenir. A priori entre 3 mois et 6 mois.



 - création de la branche X.Y+2 à partir de X.Y+1.0-rc0
 - Déploiement de X.Y+1.0-rc0 sur notre prod interne à partir des
packages
 - 1 mois de test de la X.Y+1.0-rcX
 - release de X.Y+1.0

Le trunk de svn.obm.org correspond à ce qui va devenir la 2.3.0-rc0.

De manière pragmatique il était évident que ce modèle n'était pas
applicable à 100% des composants d'obm :
...


--
Pierre Baudracco, Directeur GSO - 05 62 19 24 91 - 06 82 84 63 67
OBM project leader, www.obm.org, pierre.baudra...@obm.org
AliaSource devient LINAGORA GSO
___
Obm mailing list
Obm@list.aliasource.fr
http://www.list.aliasource.fr/mailman/listinfo/obm