Please Raphael, there are only 7 bugs
currently "Closed" in bugzilla, how can you say that bugs are closed
too quickly or that the process is not followed ?
Most of the bugs are currently either "Opened"
or in "Resolved" status, which globally match the proposed Eclipse
process at this step.
De : Raphael FAUDOU [mailto:raphael.faudou@xxxxxxxxxxxxxx]
Envoyé : vendredi 11 juin
2010 11:33
À : TANGUY Yann 176637
Cc : Papyrus Project list
Objet : Re: [mdt-papyrus.dev]
suggestion of process improvment
TANGUY Yann 176637 a
écrit :
Hi,
You can find some information regarding
Bugzilla use here : http://wiki.eclipse.org/Development_Resources/HOWTO/Bugzilla_Use
Well, as you notice, the Bugzilla suggested process
mentions a transition to "verified" state before "closed".
It does not seem that everybody follows this process...
Can we postpone these process
discussion to any date after 0.7.0 release ?
Sure we can.
But the idea was to provide both a better quality of bugzilla state for the
community and save time by avoiding to create bad bugs or to reopen bugs not
closed.
sorry that you could not see the benefits.
regards
raphaël
Best regards,
Yann
Hi all,
currently there is huge effort to clean the bugzilla repository by closing
bugs. There are two different situations that are not well addressed today and
I give suggestions to improve the process.
- 1. some bugs are
closed too quickly , either because the bug was not compteley understood
or the verification was not complete. Then the bug must be reopen. It
might give "bad image" to the user community.This is not so
important for now as the user community is limited but let us take good
habits and try to avoid such situation.
- Suggestion :
leave the responsability of closing the bug to the reporter of the bug
and on milestone releases (not on nightly builds). This is a common
strategy used on maintenance process, even in open source. To avoid bugs
never closed, the following steps can be followed:
- when
the bug is fixed/implemented, the developper changes the state and
comments by giving information where the fix/implementation can be
tested. Something like "fixed in head" or "implemented in
branch XXX".
- At
next milestone, the fix/implementation is available to the user
community into a packaged release. After a given period (let us say 1
month), if the reporter did not closed the bug, a comment is put to ask
him/her to check and close the bug.
- After
another waiting period (let us say 1 month), if the reporter did not
react, the bug is closed.
- 2. some bugs are
open or reopen too quickly, in a context when code base is not stable;
After some changes in the architecture or in important foundation classes,
there might be some temporary regression or some bugs here and there.
Perhaps it is not necessary to create bugs immediatly as this situation is
known and is about to be fixed in the next days.
- suggestion : open
bugs only on milestone releases and not on nightly builds. note that it
requires to get milestone releases available quite often.
If everybody agrees (or nobody disagrees) I will put
those rules on the wiki.
Regards
raphaël
--
![Image Signature IOC](gifYBaphPaH5Z.gif)
|
Raphaël FAUDOU
Responsable cellule Innovation / bureau
méthodes
Head of Innovation & Method Definition
Embedded systems & critical systems
Atos
Origin
Tel : +33 (0)5 34 36 32 89
Tel : +33 (0)6 10 53 50 44
Mail : raphael.faudou@xxxxxxxxxxxxxx
|
Atos
Origin
6, Impasse Alice Guy
BP 43045
31024 Toulouse Cedex 3, France
|
P
Avant d'imprimer cet e-mail, pensez à
l'environnement. Ce message et les pièces jointes
sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il
peut également être protégé par le secret professionnel. Si vous recevez ce
message par erreur, merci d'en avertir immédiatement l'expéditeur et de le
détruire. L'intégrité du message ne pouvant être assurée sur Internet, la
responsabilité du groupe Atos Origin ne pourra être recherchée quant au
contenu de ce message. Bien que les meilleurs efforts soient faits pour
maintenir cette transmission exempte de tout virus, l'expéditeur ne donne
aucune garantie à cet égard et sa responsabilité ne saurait être recherchée
pour tout dommage résultant d'un virus transmis.
P Please consider your environmental responsibility before
printing this e-mail. This e-mail and the documents attached
are confidential and intended solely for the addressee; it may also be
privileged. If you receive this e-mail in error, please notify the sender
immediately and destroy it. As its integrity cannot be secured on the
Internet, the Atos Origin group liability cannot be triggered for the message
content. Although the sender endeavours to maintain a computer virus-free
network, the sender does not warrant that this transmission is virus-free and
will not be liable for any damages resulting from any virus transmitted.
|