Skip to main content
Jump to: navigation, search

Europa Build Workshop Breakout Results

Revision as of 19:37, 12 September 2006 by (Talk | contribs) (RSS)

Build Best Practices Breakout

(computer crashed in the middle of typing in the result)

  1. Proper version numbering
  2. Making builds reproducible
  3. Tag files from each release with the same human-readable tag
  4. API checking tool from WTP
  5. avoid circular dependencies
  6. documentation up-to-date; current link available on website; remove old content
  7. backup redundant systems
  8. separate publishing script from “build” (compilation)
  9. able to turn functions on the build on or off e.g. turn off publishing
  10. regularly scheduled builds
    1. public humiliation
    2. send email to mailing list
    3. send email to plug-in owner
  11. have an update site; optimize update sites
  12. pack 200
  13. feature design – group plug-ins based on functional grouping


  • Common model
    • Backbone
    • Graphical model input
    • Buckminster and Buckminster model
    • Maven in Eclipse and Maven model
    • Maven
  • Suggest that they adopt a Europa project and help revise that project's build. Nick volunteered one of the smaller EMFT projects; another candidate is BIRT (Sue); don't want to take on too much - want one/few good success stories rather than broad swath of mediocrity
  • Document the process as a part of working with one of the projects.


  • Dennis summarizing Nick's summary of RSS:
    • when EMF build succeeds it writes an RSS
    • UML consumes the RSS to trigger a new build
    • Platform will be publishing RSS soon (very soon)
    • UML assumes a linear ordering (reads just one feed, not many feeds)
    • RSS has a variety of statii: build done, tests done, etc
    • RSS is on a download site so that mirrors will be updated with files and then the RSS
    • RSS is committed to CVS for history
    • Dennis and Nick recommend that this is being used by three projects that are part of Europa, so we should just adopt it and try it and use it and agilely improve it
    • Nick is willing to be the point person for initial communication
    • Which builds to publish for? nightly? integration? good? failed?
      • Kim brings up "how to define what 'good' is - what if it was a test fixture failure (as determined by a human) instead of a test failure - then the human says 'this is a good build' and yet the RSS says 'bad'".

Back to the top