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 "Team thoughts on continuous improvement 31"

(Communication, Documentation)
(Other Projects)
 
(8 intermediate revisions by 2 users not shown)
Line 1: Line 1:
= WTP 3.1 Debriefing 07/09/2009 =  
+
= WTP 3.1 Debriefing 07/09/2009 =
  
== Purpose ==
+
== Purpose ==
  
 
Following our WTP 3.1 release, we had short post mortem to discuss possible ways our project might improve. This starts with a list of things we like and don't like about how the release went, and will evolve into action items with people assigned to be responsible, where appropriate.  
 
Following our WTP 3.1 release, we had short post mortem to discuss possible ways our project might improve. This starts with a list of things we like and don't like about how the release went, and will evolve into action items with people assigned to be responsible, where appropriate.  
  
Below are the notes from our 7/9/2009 status meeting.
+
Below are the notes from our 7/9/2009 status meeting.  
  
== Things we've done well ==
+
== Things we've done well ==
  
 
Policy and practice of firm deadline for weekly I-build with same-day declare.  
 
Policy and practice of firm deadline for weekly I-build with same-day declare.  
Line 19: Line 19:
 
Team discussion "broken out" to their own regular meetings, so they don't overwhelm WTP status call with detail (that only a few on call are interested in).  
 
Team discussion "broken out" to their own regular meetings, so they don't overwhelm WTP status call with detail (that only a few on call are interested in).  
  
Dates on Google calendar helps keep all coordinated by having dates in a central spot.
+
Dates on Google calendar helps keep all coordinated by having dates in a central spot.  
  
Frequent (weekly) but short status calls.
+
Frequent (weekly) but short status calls.  
  
== Things we'd like to improve on ==  
+
== Things we'd like to improve on ==
  
=== Build, process, practice ===  
+
=== Build, process, practice ===
  
 
Too many intermittent junit failures: especially in that there are too many long periods build failures. Failures (even compile errors) begin to be ignored since failures so common.  
 
Too many intermittent junit failures: especially in that there are too many long periods build failures. Failures (even compile errors) begin to be ignored since failures so common.  
  
Builds take too long: especially in that it takes a long time to get notified if problem or not after checking in code.
+
Builds take too long: especially in that it takes a long time to get notified if problem or not after checking in code.  
  
Lots of code checked in with no junit test (both new function and bug fixes).
+
::break up build into smaller pieces
  
Lack performance suite or benchmarks.
+
::make tests more reproducible on build machine (suite by suite)
  
=== Communication, Documentation ===
+
::build break leader board?
 +
 
 +
::Insist each build is green -- or fix within 24 hours.
 +
 
 +
::provide better summary of failures ... Summary at top of page
 +
 
 +
::Mail notices: better document severity, repeatedness, exact issues
 +
 
 +
::improve versioning page so errors easier to see.
 +
 
 +
::in general, too much noise ... change versioning errors back to warnings ... make blocking for milestones
 +
 
 +
::remove intermittant failure JUnits until they are fixed<br>
 +
 
 +
::log junit failures in database (for more history)
 +
 
 +
::use API tools
 +
 
 +
::Investigate Hudson and Athena Common Builder?
 +
 
 +
::Builds need to be able to be run locally and not dependant on a specific machine.
 +
 
 +
::Committers need to practice continuous integration.  Synchronize with the repository before checking in or starting work on code to make sure you have the latest code from head.
 +
 
 +
::Synchronize with CVS and dependant projects code bases daily.
 +
 
 +
Lots of code checked in with no junit test (both new function and bug fixes).
 +
 
 +
::project leads should instill the attitude and practice
 +
 
 +
::are there tools or training we can give ourselves to make it easier?
 +
 
 +
Lack performance suite or benchmarks.
 +
 
 +
::someone (dw?) still needs to re-do our build scripts?
 +
 
 +
=== Communication, Documentation ===
  
 
Lack of dependent project communication, such as emf or platform, both if and when "breaking" changes coming and once we learn of it, seems there's no central place to learn of all "breaking changes".  
 
Lack of dependent project communication, such as emf or platform, both if and when "breaking" changes coming and once we learn of it, seems there's no central place to learn of all "breaking changes".  
  
:: dw to work with Planning Council on common area for "migration issues" (similar to our 'new help for old friends).  
+
::dw to work with Planning Council on common area for "migration issues" (similar to our 'new help for old friends' pages).
 +
 
 +
Hard for newcomers (even adopters) to get "acquainted" or integrated with WTP policies, practice, and rhythms so testing isn't done early enough and communication is awkward, hard and takes too long to get worked out. [The break-out meetings such as for JEE have helped.]
 +
 
 +
:Improve documentation: hotbug process, "How to contribute to WTP", "How to Ask Questions", "How to submit a bug", ...
 +
:Improve home web page
 +
 
 +
::Orient and highlight around type of use or participation:
 +
 
 +
:::use-only? then how to
 +
::::download
 +
::::bugs
 +
:::develop? then how to
 +
::::get source from cvs
 +
::::contribute a patch
 +
:::adopt in product or project? then how to
 +
::::test early
 +
::::how to prereq various features
 +
 
 +
<br> <br>
  
Hard for newcomers (even adopters) to get "acquainted" or integrated with WTP policies, practice, and rhythms so testing isn't done early enough and communication is awkward, hard and takes too long to get worked out. [The break-out meetings such as for JEE have helped.]
+
===Other Projects===
  
:: Documents to improve: hotbug process, "How to contribute to WTP", "How to Ask Questions", "How to submit a bug", ...  
+
Other projects also have their own "retrospectives". Some are linked here, to cross-reference others observations and findings.  
  
<br>
+
* [[Eclipse/Galileo/Retrospective| Eclipse Project]]
<br>
+
  
[[Category:WTP Continuous Improvement| ]]
+
[[Category:WTP_Continuous_Improvement| WTP_Continuous_Improvement]]

Latest revision as of 12:44, 17 June 2010

WTP 3.1 Debriefing 07/09/2009

Purpose

Following our WTP 3.1 release, we had short post mortem to discuss possible ways our project might improve. This starts with a list of things we like and don't like about how the release went, and will evolve into action items with people assigned to be responsible, where appropriate.

Below are the notes from our 7/9/2009 status meeting.

Things we've done well

Policy and practice of firm deadline for weekly I-build with same-day declare.

Regular, consistent weekly (Thursday) is build good, even if actual delivery following Tuesday.

Some long standing performance bugs finally addressed (in XML Editing and related).

Plans (XML format and bugzilla entries) with dynamic, iterative updates worked well.

Team discussion "broken out" to their own regular meetings, so they don't overwhelm WTP status call with detail (that only a few on call are interested in).

Dates on Google calendar helps keep all coordinated by having dates in a central spot.

Frequent (weekly) but short status calls.

Things we'd like to improve on

Build, process, practice

Too many intermittent junit failures: especially in that there are too many long periods build failures. Failures (even compile errors) begin to be ignored since failures so common.

Builds take too long: especially in that it takes a long time to get notified if problem or not after checking in code.

break up build into smaller pieces
make tests more reproducible on build machine (suite by suite)
build break leader board?
Insist each build is green -- or fix within 24 hours.
provide better summary of failures ... Summary at top of page
Mail notices: better document severity, repeatedness, exact issues
improve versioning page so errors easier to see.
in general, too much noise ... change versioning errors back to warnings ... make blocking for milestones
remove intermittant failure JUnits until they are fixed
log junit failures in database (for more history)
use API tools
Investigate Hudson and Athena Common Builder?
Builds need to be able to be run locally and not dependant on a specific machine.
Committers need to practice continuous integration. Synchronize with the repository before checking in or starting work on code to make sure you have the latest code from head.
Synchronize with CVS and dependant projects code bases daily.

Lots of code checked in with no junit test (both new function and bug fixes).

project leads should instill the attitude and practice
are there tools or training we can give ourselves to make it easier?

Lack performance suite or benchmarks.

someone (dw?) still needs to re-do our build scripts?

Communication, Documentation

Lack of dependent project communication, such as emf or platform, both if and when "breaking" changes coming and once we learn of it, seems there's no central place to learn of all "breaking changes".

dw to work with Planning Council on common area for "migration issues" (similar to our 'new help for old friends' pages).

Hard for newcomers (even adopters) to get "acquainted" or integrated with WTP policies, practice, and rhythms so testing isn't done early enough and communication is awkward, hard and takes too long to get worked out. [The break-out meetings such as for JEE have helped.]

Improve documentation: hotbug process, "How to contribute to WTP", "How to Ask Questions", "How to submit a bug", ...
Improve home web page
Orient and highlight around type of use or participation:
use-only? then how to
download
bugs
develop? then how to
get source from cvs
contribute a patch
adopt in product or project? then how to
test early
how to prereq various features



Other Projects

Other projects also have their own "retrospectives". Some are linked here, to cross-reference others observations and findings.

Back to the top