Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt-papyrus.dev] suggestion of process improvment
+1 to postpone the discussion

TANGUY Yann 176637 wrote:

Hi,

 

You can find some information regarding Bugzilla use here : http://wiki.eclipse.org/Development_Resources/HOWTO/Bugzilla_Use

Can we postpone these process discussion to any date after 0.7.0 release ?

 

Best regards,

 

Yann

 

De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Raphael FAUDOU
Envoyé : vendredi 11 juin 2010 10:54
À : Papyrus Project list
Objet : [mdt-papyrus.dev] suggestion of process improvment

 

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:
      1. 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".
      2. 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.
      3. 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

 

 


_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev

Back to the top