Jump to: navigation, search

Difference between revisions of "Eclipse/Kepler Retrospective"

(New page: Patch review days were good. Increase in contributions, some community feedback on improved patch acceptable from platform - Patch reviews depends on team, some have low patch volume an...)
 
(Community)
 
(6 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 +
This page contains notes from a retrospective discussion held during the Eclipse project weekly architecture call.
  
Patch review days were good. Increase in contributions, some community feedback on
+
== Community ==
improved patch acceptable from platform
+
  
- Patch reviews depends on team, some have low patch volume and can review as they come in
+
* Patch review days were good. Increase in contributions, some community feedback on improved patch acceptable from platform
others have high patch volume and patch review days work well.
+
* Patch reviews depends on team, some have low patch volume and can review as they come in others have high patch volume and patch review days work well.
 +
* Platform UI team did 2 days at start of each milestone, with additional follow-up as required to iterate patches
 +
* Gerrit is great for managing patches, rebasing easily to keep them up to date rather than getting stale in bugzilla
 +
* Gerrit tempts you to merge directly from web UI, but this is a dangerous practice because you're not pushing what you tested (or worse, you didn't test)
 +
* CBI was a net loss for us so far. It was a very large volume of work just to get our build back to its old state. There is benefit for others in the community to make it easier for them to run builds independently. For Platform committers it hasn't delivered value yet, but introduced new maintenance cost due to Maven deficiencies ({{bug|410966}}, {{bug|387802}}, {{bug|386114}}).
 +
* Still lots of rough edges in our build that we need to address. For example we can't currently diff JARs reliably between repositories/distributions.
  
- Gerrit great for managing patches, rebasing keeping them up to date
+
== Performance ==
Not so great for merging straight from web UI - looks easy but means you can't test the code
+
  
CBI was a net loss for us so far. It was a very large volume of work just to get our build back
+
* Performance testing was non-existent. We need to get those back in place.
to its old state. There is benefit for others in the community to make it easier for them to run
+
* Get them running, and then get useful ongoing data out of them.
builds independently. For committers it hasn't delivered any value yet.
+
* Performance pass during M6 - dedicated time built into plan to work on performance.
 +
* Consider doing performance test pass in earlier milestone such as M3
 +
* Do further automated analysis on performance data to get more useful signals out of data
  
Still lots of rough edges in our build that we need to address.
+
== Planning ==
Can't currently diff JARs reliably between builds.
+
  
Planning happened very late. We need to get the plan in place much earlier.
+
* Planning happened very late. We need to get the plan in place much earlier.
 +
* Add topics to call in advance so we have time to think about it
 +
* Far too many platforms to test, not enough people/time to test them.
 +
* Consider dropping 32-bit for Mac, AIX, Solaris, HP-UX
 +
* JDK matrix - consider only having Java 7 reference platforms for next release (and possibly Java 8)
 +
** That doesn't mean all projects need to set their BREE to JavaSE-1.7
 +
** However, since org.eclipse.osgi is already at JavaSE-1.6, compatibility with older EEs like 1.5, 1.4, or CDC/Foundation is not important any more
  
Far too many platforms to test, not enough time to test them.
 
Maybe we can drop 32-bit for Mac, and server class machines.
 
If there is demand for these
 
 
JDK matrix - maybe reference platforms only Java 7 for next release (and possibly Java 8)
 
 
Performance testing was non-existent. We need to get those back in place.
 
Get them running, and then get useful ongoing data out of them.
 
Performance pass during M6 - dedicated time built into plan to work on performance.
 
Maybe do performance test pass in earlier milestone
 
Do further automated analysis on performance data to get more useful signals out of data
 
 
Add topics to call in advance so we have time to think about it
 
 
 
Large focus on maintenance in 4.3
 
Shift more towards new development in Luna
 
 
less stress
 
another major build transition
 
 
Value of these calls?
 
 
tagging
 
POM files
 
Equinox Luna changes
 
 
Mention install problems on Mac
 
  
 
[[Category:Eclipse Project]]
 
[[Category:Eclipse Project]]

Latest revision as of 10:43, 28 June 2013

This page contains notes from a retrospective discussion held during the Eclipse project weekly architecture call.

Community

  • Patch review days were good. Increase in contributions, some community feedback on improved patch acceptable from platform
  • Patch reviews depends on team, some have low patch volume and can review as they come in others have high patch volume and patch review days work well.
  • Platform UI team did 2 days at start of each milestone, with additional follow-up as required to iterate patches
  • Gerrit is great for managing patches, rebasing easily to keep them up to date rather than getting stale in bugzilla
  • Gerrit tempts you to merge directly from web UI, but this is a dangerous practice because you're not pushing what you tested (or worse, you didn't test)
  • CBI was a net loss for us so far. It was a very large volume of work just to get our build back to its old state. There is benefit for others in the community to make it easier for them to run builds independently. For Platform committers it hasn't delivered value yet, but introduced new maintenance cost due to Maven deficiencies (bug 410966, bug 387802, bug 386114).
  • Still lots of rough edges in our build that we need to address. For example we can't currently diff JARs reliably between repositories/distributions.

Performance

  • Performance testing was non-existent. We need to get those back in place.
  • Get them running, and then get useful ongoing data out of them.
  • Performance pass during M6 - dedicated time built into plan to work on performance.
  • Consider doing performance test pass in earlier milestone such as M3
  • Do further automated analysis on performance data to get more useful signals out of data

Planning

  • Planning happened very late. We need to get the plan in place much earlier.
  • Add topics to call in advance so we have time to think about it
  • Far too many platforms to test, not enough people/time to test them.
  • Consider dropping 32-bit for Mac, AIX, Solaris, HP-UX
  • JDK matrix - consider only having Java 7 reference platforms for next release (and possibly Java 8)
    • That doesn't mean all projects need to set their BREE to JavaSE-1.7
    • However, since org.eclipse.osgi is already at JavaSE-1.6, compatibility with older EEs like 1.5, 1.4, or CDC/Foundation is not important any more