Jump to: navigation, search

Difference between revisions of "Galileo/Final Daze/Modeling Project"

m (Projects)
m (Projects)
Line 17: Line 17:
     EMF Compare          10:45-11:15 am EDT (1445-1515 UTC) [done]
     EMF Compare          10:45-11:15 am EDT (1445-1515 UTC) [done]
     Ecore Tools          13:45-14:15 am EDT (1745-1815 UTC) [done]
     Ecore Tools          12:45-13:15 am EDT (1745-1815 UTC) [done]
     Mint                  2009-06-16 15:13 EDT [done]
     Mint                  2009-06-16 15:13 EDT [done]
     MWE                  11:45-12:15 am EDT (1545-1615 UTC) [done]
     MWE                  11:45-12:15 am EDT (1545-1615 UTC) [done]

Revision as of 12:17, 22 June 2009


Below is the list of projects in Galileo which have components. (GEF, GMF, and TMF-Xtext are also in Galileo but are single-component-projects.)

Please ensure that for projects w/ multiple component, only one component promotes their bits at a time. I suggest that each component lead should sign up below with the time they plan to do their promote below, so that no overlapping occurs. It's probably also wise to use #eclipse-modeling on IRC to support more immediate conversation/coordination.

Note that it's perfectly acceptable for multiple projects to publish concurrently, since they each have separate update sites. The only limitation is on components who share a common site.

EMF                      Time Of Promote
   EMF (Core)            9:00-9:30 am EDT (1300-1330 UTC) [done]
   Query                 12:30-12:55 am EDT (1630-1655 UTC) (will coordinate my Q-V-T)
   Transaction           12:30-12:55 am EDT (1630-1655 UTC) (will coordinate my Q-V-T)
   Validation            12:30-12:55 am EDT (1630-1655 UTC) (will coordinate my Q-V-T)
   Teneo                 10:15-10:45 am EDT (1415-1445 UTC)
   EMF Compare           10:45-11:15 am EDT (1445-1515 UTC) [done]
   Ecore Tools           12:45-13:15 am EDT (1745-1815 UTC) [done]
   Mint                  2009-06-16 15:13 EDT [done]
   MWE                   11:45-12:15 am EDT (1545-1615 UTC) [done]
   OCL                   11:00-11:30 am EDT (15:00-1530 UTC)[done] 
   UML2                  10:30-11:00 am EDT (14:30-1500 UTC)[done]
   UML2 Tools 
   XSD                   9:00-9:30 am EDT (1300-1330 UTC) [done]
   ATL                   10:30-11:00 am EDT (1430-1500 UTC) [done]
   JET                   09:45-10:10 am EDT (1345-1410 UTC) [done]
   Xpand                 12:00-12:30 am EDT (1600-1630 UTC)
   Acceleo               10:45-11:15 am EDT (1445-1515 UTC) [done]


What exactly should we do, and when?

Last year we met on IRC in #eclipse-modeling to make sure that projects were published in the correct order:

Ganymede/Final Daze/Modeling Project

The only real limitation w/ the current system is that people should NOT PROMOTE their final, renamed or rebuilt builds AT THE SAME TIME within the same project, as this will corrupt the p2 metadata generation process, and you'll end up with an unusable update site.

When should we do our final builds/renames and promote the bits?

See Monday 6/22 by 17:00 EDT, at the latest.

You can promote them as soon as they're ready; there's a file in CVS which controls the visibility of R builds, for example:


If there's a build ID listed in that file, it will NOT be shown on the downloads page, but will be available for the mirrors to pick it up and replicate it. If you remove the entry in the file, it will mark the build visible on www.eclipse.org.

You can even control this file from the promo.php page you use to promote builds:


When should we "unhide" our builds, making them visible to the public?

See Wednesday 6/24 @ 08:30 - 09:00 EDT.

Update sites are created only when promoted, right? Can I generate it locally?

If you want to test locally on your build server, you can use /home/www-data/build/modeling/scripts/buildUpdateSite.sh to create the update site without publishing it to download.eclipse.org. Run the script without options to get detailed usage instructions.

You could also just unpack the Update.zip somewhere in /var/www/html/ and test that, too, but that'll only verify YOUR update, not your component's contribution to a shared update site (eg. Query into EMF, UML2 into MDT).

What about .build files, used to control input to the Galileo update site?

Create them by hand, or create them as part of the publishing/promoting script. Your choice.

You can also generate them using /home/www-data/build/modeling/scripts/promoteToEclipse.sh and the -coordsiteonly galileo flag. Run the script without options to get detailed usage instructions re: the other required flags.