Difference between revisions of "PDE/Retrospective/3.7"

From Eclipsepedia

Jump to: navigation, search
(Action Items for 3.8)
Line 3: Line 3:
 
== Coding Best Practices ==
 
== Coding Best Practices ==
  
* When writing tests, try to keep them stable.  Intermittent failures cause headaches.
+
* 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.
 
* Always keep documentation in mind.  If you see missing doc and don't fix, always file a doc bug.
 +
* 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).
  
 
== Bugzilla ==
 
== Bugzilla ==
Line 10: Line 14:
 
* Add proper keywords: '''contributed''' for patches, '''noteworthy''' for big features, '''helpwanted''' for bugs that will only be fixed with contributed patches
 
* 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.
 
* 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.
 +
  
 
== 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.
 
== Action Items for 3.8 ==
 
 
# Apply proper keywords to bugs to assist with triage.
 
# 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 myself 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).
 
# A follow-up from (2) - 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 triage them as HELPWANTED and close as WONTFIX (after a certain grace period allowing the community to vote / discuss).
 

Revision as of 15:34, 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?

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.
  • 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).

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.


General Comments

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