[jwt-dev] Re: AW: JWT - jBPM - Bull meeting 20081121 - notes

[Marc Dutoo <marc.dutoo@xxxxxxxxxxx>]

Hello

Please find my notes below, including the following TODOs :

   * get and forward answer of Wayne Beaton approving it
   * declare intent
   * first : choose release engineer (Mickaël told me he's OK with it),
draft rampdown policy
   * next : basic update site setup, making consuming orbit work, see
galileo TODOs bugzilla

Next exchanges will be on the jwt mailing list only.

Regards,
Marc


---++ Participants
   * John Graham
   * Miguel Valdes, Bull
   * Koen Aers, jBoss
   * Florian Lautenbacher, University of Augsburg
   * Marc Dutoo, Open Wide

Mainly, John gives insight and feedback about what it is like to become
part of the yearly release train.


---++ Get in the release & first requirements
   * declare intent by 12th of december on the right Galileo wiki page
      * TODO Marc or Florian
   * Wayne needs to agree that our project can be in the release train
(approval, forwarded email)
      * Florian sent it, TODO forward it to the right person & our mailing
list


---++ Build process :
1. the update site
   * each project has an update site, with an XML file configuration
(metadata on which features, where are their jars...)
   * in CVS
   * which file has to be set up, which permissions to set : John will help
to get answers or the right people from Richard Gronack
   * Florian : JWT has already an update site
   * This one can already be used for a start !
      * TODO see what remains to be done and do it
   * tip : have a separate, non-mirrored hidden update side for the release
train, so updates can be made quickly
      * once in the release train and patching up bugs that appear, this
quickly becomes required
      * TODO prepare it

2. the process
   * based on the XML file describing which jars to consume, the build
process is done
   * though it sounds simple, it is amazing how many times the build
doesn't work ! Thus the release engineer
   * basically very flexible


---++ Other requirements
   * project plan is an XML file ; JWT has it already

Rampdown policy
   * intent is to say what will happen at the endgame : when code is
frozen, how last second bugs will be distributed for resolution...
   * text document
   * John & al. can help giving good practices, old Ganymede rampdown
policies also ; can be built progressively

other requirements
   * get third party library from orbit, configured in map file ; TODO see
how to do it, make it work (only one jar for now)
   * pack200 : compression way for jars ; TODO optional ?
   * signed jars ; JWT already has it


---++ Working in the release train
Working in the CVS
   * will be another branch at some point :
   * only when we won't be able to do without because of conflicts,
      * 1. then create a branch for old Ganymede build,
      * 2. and working in the head for Galileo (since it will be our
ultimate target)

Making sync'd releases work
   * the magic thing : dependencies will be changing, bugs will be
appearing
   * there's a 2-3 week delay between a milestone's first release and the
final (GA, public) one. It gives a chance to patch it before the public
release.
      * This delay gets shorter at the end, but the rampdown ensures
there'll be less changes happening also.

Other info
   * What's in a milestone is up to the project ; no new feature in a
milestone is OK.
   * Feature freeze day at the end of April.

Problems coming from integrated projects (dependencies) for JWT
   * Good news : the biggest changes come from the platform and core
plugins, but those occur the earlier.
   * JWT for now is not extended by other Galileo plugins, so we won't risk
to break other plugins.
   * GEF can sometimes be an issue.


---++ Other related issues

---+++ About APIs in Eclipse project
   * Only API should be exposed i.e. not internal in the plugin.xml ; API
is what is documented and in the public javadoc.
   * API is a graduation requirement, but not for Galileo. Better say that
there's no API for now, otherwise it has to be supported forever.
   * API will be thought about while working for extensibility with vendors
like Bull and JBoss.

---+++ Release engineer
TODO choose it
   * The release engineer has to be available (to answer email 24/24 in a
short period), for ex. when a Galileo build has failed, so he can be
contacted to test or package and put up new releases.
   * The right person could be Mickaël, since Marc is not available on
site much - but this also depends on fundings securing his availability.
Ideally he'll have support of an intern. At worst Marc will try to be as
much on site as possible during May and June.
   * At some point, everybody can help !  Miguel, Florian and Koen are
willing to contribute help for testing, proposing solutions, patching bugs.

...

---+++ Tests
Test plan :
   * new to this release, not much info yet
   * see also cross project mailing list (for coordination)
   * for this and the rest, John will help to find the right people to talk
to, to help when we don't do the right thing at the right time (which
requires a vote of the committer council).

testing :
   * we've got help from Koen !
   * Some things can be easily unit tested, others not (Diagram...).
   * NB. in the eclipse community, perimeter and depth of testing varies
widely.
      * Ex. EMF generates automated tests, but on GEF it's very hard.

NB. Florian is willing to do a european research project proposal, Miguel
is completely open to european fundings.


---++ Next step
TODOs
   * get and forward answer of Wayne Beaton approving it
   * declare intent
   * first : choose release engineer (Mickaël told me he's OK with it),
draft rampdown policy
   * next : basic update site setup, making consuming orbit work, see
galileo TODOs bugzilla