Difference between revisions of "PDE/Retrospective"

From Eclipsepedia

< PDE
Jump to: navigation, search
(General Comments)
 
(13 intermediate revisions by 4 users not shown)
Line 1: Line 1:
This page will be used to collect comments about PDE and our development process that were noticed during 3.5.  What did we do well?  What could be better?  What should we do next release?
+
Each year the PDE team participates in a retrospective where we look at what areas we have improved in and what areas we need to improve in the next release.  We try to create action items out of these suggestions.
  
== Coding Best Practices ==
+
[[PDE/Retrospective/3.8|3.8 Retrospective]]
  
* If you write new core/model/non-UI code, '''write tests''' for it
+
[[PDE/Retrospective/3.7|3.7 Retrospective]]
  
* '''Don't''' release a major change just before a milestone release or even right before an I build
+
[[PDE/Retrospective/3.6|3.6 Retrospective]]
  
* 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.
+
[[Eclipse/Helios/Retrospective|Eclipse Retrospective]] - The retrospective for the Helios release of the top level Eclipse project
 
+
== Bugzilla ==
+
 
+
* If you add someone as a reviewer, add them as a cc
+
 
+
* Only mark a bug with a specific target milestone if you seriously plan on fixing it during that milestone
+
 
+
* If you are unsure about a change or the code you are committing is a major change, add a reviewer and get them to verify it
+
 
+
== General Comments ==
+
 
+
* In 3.5 the target platform changes ended up dropping too late M6/M7 to get proper feedback.  We recognized this as a risk beforehand and still went forward and we did get burned for this to some extent.  There were too many RC fixes required to get it working.
+
 
+
* Regularly run a profiler (or the like) over any new larger changes to catch performance regressions earlier
+
 
+
* It would be good to always have another pair of eyes (or two) verify all fixes
+
 
+
* We released 3.5 with two bugs marked BLOCKER and one CRITICAL. I haven't really checked if these really are severe defects, but we probably can have communicated better on the actual status of these issues.
+
 
+
* Planning for API tooling was better than for PDE UI in that plan items were more concrete and scoped. The PDE UI plan was more vague - we knew we wanted to make major improvements to target platforms (which we did), but the plan items were not as well described/scoped/understood (this is an another reason it arrived late in the release). Similarly, support for categories in exported p2 repos appeared late. In 3.6 we need better plan items/descriptions and understanding of the scope of work items. Big items must come first to avoid stability issues late in the cycle.
+
 
+
* PDE has a diverse committer pool. This is good. As the committers represent different interests from different organizations, we need to ensure that everyone participates in the planning process to understand what work will be going on and where we can benefit from common interests. As well, we need to ensure there is good ongoing communication throughout the cycle.
+
 
+
* When possible, doc was written during the cycle (for example, when API tooling problem severity settings were re-worked). This greatly reduced the burden at the end of the cycle. There was still plenty of target platform doc to be created at the end (but one could argue that this was in tandem with the feature delivery).
+

Latest revision as of 16:02, 18 June 2012

Each year the PDE team participates in a retrospective where we look at what areas we have improved in and what areas we need to improve in the next release. We try to create action items out of these suggestions.

3.8 Retrospective

3.7 Retrospective

3.6 Retrospective

Eclipse Retrospective - The retrospective for the Helios release of the top level Eclipse project