Re: [Dolibarr-dev] Nouvelles du fr ont. Dev passés et a venir.

[Rodolphe Quiedeville]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

paul POULAIN wrote:
> Gael Canal a écrit :
> 
>> Salut,
>>
>> En réponse au mail de Vianney, big brother, pour ceux que ça interesse,
>> c'est moi.
>>
>> Le jeudi 22 septembre 2005 à 07:45 +0200, Vianney ASSOFI [SQSI] a
>> écrit :
>>  
>>
>>>> Il faut que l'on arrete de coder des nouvelles fonctionnalités et
>>>> que l'on closent tous les bugs ouverts. Mais je sais comme il est
>>>> difficile de s'arreter de coder.
>>>>     
>>
>>
>> Question : ne peut-on pas simplement mettre un flag "STABLE" sur le
>> repository, et continuer le dev sur HEAD tout en patchant STABLE ? ...
>> cvs c'est un vrai bonheur ;-)
>>
>> Ok, c'est du boulot en plus, mais ça permet aux codeurs fous de coder,
>> et aux utilisateurs qui le souhaitent d'avoir une base saine.
>>
>> Le premier pas vers cet objectif serait de définir les "fonctionnalités"
>> à inscrire au titre de la version stable à venir.
>>
>> Ensuite, intégrer la philosophie stable/instable dans la gestion des
>> bugs, le suivi des problèmes de sécurité etc... bref, un pas à franchir
>> dans la gestion quotidienne du dev.
>>  
>>
> Pas mettre un flag, mais créer une branche. appelons là stable_20
> ensuite, il suffit de récupérer le cvs stable_20 dans un répertoire et
> le head dans un autre.
> Lorsque l'on veut mettre dans le head les mises à jour de l'autre
> branche, un
> cvs checkout -j stable_20 .
> dans le répertoire head va tout mettre à jour.
> Et introduire des bugs probablement au fur et à mesure que head et 20
> s'éloignent l'un de l'autre. Mais la synchro affiche les problèmes
> qu'elle a rencontré et met tout plein de >>>>>> et <<<<<<< pour qu'on
> s'y retrouve.
> 
> Mon avis, c'est qu'il faudrait surtout un "Release Manager" pour la 2.0.
> C'est à dire quelqu'un qui s'engage à faire aboutir la version 2.0
> pendant que les autres s'amusent sur la branche stable. Ca ne veut pas
> dire qu'il ferait tout, mais qu'il aurait la responsabilité de valider
> les fix et de dire si/quand c'est stable.
> Quitte à sortir une 2.0RC1, 2.0RC2...

Entièrement d'accord avec toi Paul, j'avais d'ailleurs déjà évoqué ce
sujet il y a quelque temps. Le nombre de developpeur augmentant un
release manager devient de plus en plus nécessaire. C'est d'ailleurs
pour palier son manque que j'ai volontairement réduit le nombre de
nouveaux développeur.

Cette charge me reviendrait naturellement, mais comme vous avez du le
voir je manque de temps, et mes compétences en cvs sont assez sommaires.

Personnellement je pense que tu ferais un excellent release manager.

> Mais il FAUT arréter les ajouts fonctionnels à un moment, sinon on ne
> s'en sort pas !

D'accord aussi, mais tu connais un méthode pour arréter un geek derrière
son clavier toi ?

A++

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDNV8MmyyHaHLx8g0RArHPAJ0fngCgHE1ms8mlYYasvs32v7WG1ACglxaV
6GW47QgMveLGEfbpXVoSSQg=
=2Pi9
-----END PGP SIGNATURE-----