Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "PDE/Retrospective"

< PDE
(General Comments)
Line 1: Line 1:
This page will be used to collect comments about PDE and our development process that were noticed during 3.6.  What did we do well?  What could be better?  What should we do next release?
+
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 ==
 
== Coding Best Practices ==
  
* If you write new core/model/non-UI code, '''write tests''' for it
+
* When writing tests, try to keep them stable.  Intermittent failures cause headaches.
* If you create any kind of UI make sure it has a help topic. Also '''ensure''' that you create the help topic(s) at the time the UI is created. '''DO NOT''' leave it until the doc pass at the end of the release.  At a minimum, create a doc bug so that we can plan to fix it during the RC builds.
+
* Always keep documentation in mind.  If you see missing doc and don't fix, always file a doc bug.
  
 
== Bugzilla ==
 
== Bugzilla ==
  
* Only mark a bug with a specific target milestone if you seriously plan on fixing it during that milestone
+
* 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 ==  
 
== General Comments ==  
  
* Planning in 3.6 was a huge improvement over 3.5.  Wiki plan was easy to update, gave overall feel of progress.  Weekly meetings were short but effective.
+
* Meeting minutes were not helpful, whereas the actual meetings were productive.
* Several patches from the community were ignored due to time constraints.  Other patches were committed without enough review.
+
* Did a good job at maintaining stability, but still had a couple late features that would have been better to have been done sooner (Feature based launch/targets and import from CVS).
+
* Late features don't always get polished/cleaned up - Target Wizard (3.6), Categories on export (3.5)
+
* Trade off bug fixing/polish for late features - RC1 pass always feels short dur to late feature work
+
 
+
== API Tools ==
+
 
+
* Planning was much better - as it was done along-side PDE proper.
+
* Not as many features were provided as we would have liked (due to time / resource constraints). Some notable features that did make it in were (1) API use UI / launch configurations and (2) problem filter comments
+
* Performance was significantly improved
+

Revision as of 11:11, 31 May 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

  • When writing tests, try to keep them stable. Intermittent failures cause headaches.
  • Always keep documentation in mind. If you see missing doc and don't fix, always file a doc bug.

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.

Back to the top