Difference between revisions of "PDE/Retrospective/3.7"

From Eclipsepedia

Jump to: navigation, search
 
Line 14: Line 14:
 
* Enhancements (old or new) that we have no intention of fixing should be triaged as such.
 
* Enhancements (old or new) that we have no intention of fixing should be triaged as such.
 
** Instead of leaving enhancements open for years with no intention of fixing them, we should should mark them with the keyword 'helpwanted' and close as WONTFIX (after a certain grace period allowing the community to vote / discuss).
 
** Instead of leaving enhancements open for years with no intention of fixing them, we should should mark them with the keyword 'helpwanted' and close as WONTFIX (after a certain grace period allowing the community to vote / discuss).
* Use [PDE/BugzillaTags|Bugzilla Tags] to help differentiate bugs
+
* Use [[PDE/BugzillaTags|Bugzilla Tags]] to help differentiate bugs
  
 
== General Comments ==
 
== General Comments ==
  
 
* Meeting minutes were not helpful, whereas the actual meetings were productive.
 
* Meeting minutes were not helpful, whereas the actual meetings were productive.

Latest revision as of 15:38, 7 June 2011

This page will be used to collect comments about PDE and our development process that were noticed during 3.7. What did we do well? What could be better? What should we do next release?

[edit] Coding Best Practices

  • WDesign tests to be stable. Add redundant checks to deal with inconsistent I/O and UI operations. Intermittent failures caused headaches.
  • Always keep documentation in mind. If you see missing doc and don't fix, always file a doc bug.

[edit] Bugzilla

  • Add proper keywords: contributed for patches, noteworthy for big features, helpwanted for bugs that will only be fixed with contributed patches
  • When a patch is provided for review by a committer, only commit the patch if the issue is time sensitive and the patch creator has stated you can commit. In all other cases let the patch contributor commit their own fix.
  • Be more aggressive closing bugs with no feedback from the original submitter / community.
    • We have the same problem in Debug and Ant - when an issue comes in that a committer cannot reproduce and we ask for more information, we should be more aggressive in closing the issue if the community does not respond within a few days. As Pawel and Mike found while triaging the entire Debug and Ant inbox, there are many bugs that (still) cannot be reproduced and no more information has been provided. These issues should be closed as INVALID (or whatever PDE uses by default in this case).
  • Enhancements (old or new) that we have no intention of fixing should be triaged as such.
    • Instead of leaving enhancements open for years with no intention of fixing them, we should should mark them with the keyword 'helpwanted' and close as WONTFIX (after a certain grace period allowing the community to vote / discuss).
  • Use Bugzilla Tags to help differentiate bugs

[edit] General Comments

  • Meeting minutes were not helpful, whereas the actual meetings were productive.