Revision as of 16:16, 13 September 2006

Draft
Report to the Planning Council from the Europa Build Workshop

Summary

Dates, attendees, summary of discussion topics, summary of recommendations to the Planning Council, i.e., that they should staff these four focii sufficiently to allow them to succeed in the Europa timeframe.

Eclipse Build Best Practices

What this is about. Why this is a good idea. What we intend that an effort in this area will accomplish. Explain how these are usually motherhood and apple pie type best practices, but that this effort is about specific recommendations at the level of detail that can be followed by engineers.

Action Items

Action items with dates and (where possible) individuals. For example:

• September 25: (Paul, Susan, William) Post an initial list of the best practices from the workshop to the wiki; send an email to all committers and project leads asking them to submit their own best practices to the wiki
• October 2: (Paul) Recommend to the Planning Council that they adopt practices X, Y, Z as requirements for Europa and M, N, P as 'should do' for Europa. Etc.
• October 15: (William) Send another email to the same group encouraging more conversation
• October 15: (Susan) ask EclipseCon 2007 to schedule a session around Build Best Practices.
• ...etc...

RSS Feeds

What this is about (common reporting mechanism for all projects). Why this is a good idea. Explain all the details we know so far including links to other pages on the topic. Explain the discussions that have occured (reasons) and why certain decisions were taken (for example, that Bjorn claims that all builds should be included, but the group decided to recommend against that because...) Explain outstanding discussion points such as whether to include nightly builds, whether to include failed builds, how to represent builds whose status is unknown, how we plan to define the vocabulary, etc. Specification should include where the URLs for the RSS feeds, etc.

Action Items

Action items with dates and (where possible) individuals. For example:

• September 15: (Nick) Improve the already good spec on the wiki/web to a highly detailed spec. Send email around to the Europa build engineers and project leads of the Europa leads asking them for feedback before October 15.
• October 15: (Nick) Declare the specification to be "mostly" frozen. Not withstanding continued incremental improvement, this is the RSS spec that all the projects will implement.
• November 15: (All Europa projects) Have implemented publishing RSS information for their build.

Buckminster/Maven Build Enablement for BIRT and ECF

What this is (Buckminster and Maven as a build technology). How Buckminster and Maven offered to help BIRT restructure their build. How ECF is the "small project" example. Why this is a good idea.

Action Items

Action items with dates and (where possible) individuals. For example:

• September 20: (Thomas) Implement new features X and Y in BIRT.
• September 20: (Sue) Write up the proposed new build process for BIRT.
• September 20: (Denis) Create accounts for Buckminster, Maven, and BIRT people on the build.eclipse.org machine.
• ...

Common Build Infrastructure

What this is. Why this is a good idea. What things go into a common build infrastructure. The 80/20 rule. How does this augment what is already in place. URLs to examples from Nick. Building and reporting. Common locations, and look and feel for all the builds/downloads is good because it helps with community understanding and adoption. Etc.

Action Items

Action items with dates and (where possible) individuals. For example:

• ...

Communication Channels

For Europa, there needs to be at least one designated contact from each project available via phone, email, IM, etc. For critical periods (milestones and release candidates), the Europa build engineers should be on a common IRC channel or IMs or something.