[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: péremption



Jérôme Marant <jerome.marant@free.fr> writes:
> On Sat, Feb 02, 2002 at 01:37:24AM +0100, Raphael Hertzog wrote:
> > > - les "wishlist items" marqués "wontfix" et qui datent de plusieurs
> > >   années
> > 
> > C'est bien pour cela qu'il y a wontfix ... pour dire que ca trainer
> > encore longtemps. Moi je préfère les fermer au bout d'un certain temps.
> 
>   wontfix est surtout là pour montrer que le bug a déjà été ouvert,
>   que le problème est connu et ne sera pas corrigé.
>   Si on ferme le bug, il y a un « risque » de voir un nouveau bug
>   ouvert et le développeur sera obligé de perdre son temps à des
>   discussions dont tout a déjà tranché dans le bug taggé wontfix.

Pour les souhaits c'est normal que le mainteneur décide de le faire ou
pas. Mais pour les bugs il faudrait quand même un contrôle sur la
durée de résolution. C'est un besoin basique de la gestion de projets.

Par exemple le paquet ppp (qui n'est pas un des moindres) à 5 bugs
normaux de plus de 3 ans, 15 de plus de deux et 20 de plus de 1 an. Il
faudrait que le mainteneur soit moralement « obligé » de faire quelque
chose pour un bug après un certain temps dépendant de la sévérité :

- si le bug n'est pas reproductible, il faut que celui qui l'a soumit
  fournisse plus d'information ou alors le bug est clos.
- si le mainteneur ne sait pas le corriger, il le passe en help ou
  quoi que ce soit. Mais il faut qu'il est un suivi du responsable de
  la release dans ce cas.
- sinon il faut que le mainteneur dise comment il compte le corriger
  et approximativement quand. Ce qui n'est pas fait actuellement (ex:
  33782). il faut aussi que ça soit mis à jour si ce n'est pas fait
  dans les temps.

  C'est possible d'automatiser cela avec un courrier envoyé au
  mainteneur pour lui rappeler.

L'efficacité pour la résolution des bugs est un des rares critères
objectifs pour juger la qualité du travail qui est fait.

-- 
Laurent Pelecq



Reply to: