RE: [cross-project-issues-dev] Europa Build Workshop - Best pract ices

[Doug Schaefer <DSchaefer@xxxxxxx>]

I’m not sure it’s been seriously considered, but it is something I’d love to see. The CDT does not have a release engineer. Once in a while, when I absolutely have to, I’ll play with the build scripts I wrote. The regular builds are triggered via cron once in a while and for releases I run a couple of scripts and hand edit my site.xml and index.html files. We certainly don’t follow many of the common practices that the Platform and other teams follow, and I don’t have people lining up to volunteer to take care of this stuff.

 

So I’m sure there are economies of scale to be had by having a common release engineering team. I’d almost question whether something like this could fit into the mandate of the Foundation, just like managing the eclipse.org infrastructure, but I’m sure someone had thought of that already. At any rate, I’m looking forward to whatever comes out of the Build Workshop, especially if all I need to do is s/something/cdt/g and get away with it.

Cheers,

Doug Schaefer
QNX Software Systems
Eclipse CDT Project Lead
http://cdtdoug.blogspot.com

 

---

From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Ed Burnette
Sent: Tuesday, October 03, 2006 12:28 PM
To: Cross project issues
Subject: RE: [cross-project-issues-dev] Europa Build Workshop - Best practices

 

I know Kim's going to throw something at me, but has it been considered to have one shared (bigger) release engineering team for all Eclipse projects rather than each project doing their own builds? I know this goes against the idea of having projects be independent, but are build reliability, plug-in version numbering schemes, and build terminology really something that different projects need to differentiate themselves with?

 

I would imagine that Linux distros for example are going to want to learn one way of building 'eclipse' and not 10 different ways to build the different projects with their own little quirks. I would also imagine that if I were starting a new project I'd like to concentrate on coding and not trying to understand all the build rules and numbers and tools.

 

<ducks/>

 

 

---

From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Kim Moir
Sent: Tuesday, October 03, 2006 11:50 AM
To: Cross project issues
Subject: [cross-project-issues-dev] Europa Build Workshop - Best practices

At the Europa build workshop (http://wiki.eclipse.org/index.php/Europa_Build_Workshop), one of the action items that  arose was the desire to share best practices and tools across projects with respect to release engineering.  We discovered that multiple teams have written tools with similar functionality to incorporate into their builds, such as comparing plugins and feature versions across releases, api comparison tools and others .  It makes sense to share these tools instead of duplicating committer efforts.

 We also learned that teams that recompile our builds for redistribution, for example, linux distrubutions, have suggestions on how to make our builds easier to reproduce  for their respective communities.  We heard from new eclipse projects who have had difficulties getting their builds started and hope that these best practices will be able to help them out.   I invite you to add any recommended techniques or tools that you have incorporated into your builds to the list on the wiki.

http://wiki.eclipse.org/index.php/Europa_Build_Workshop_Report#Eclipse_Build_Best_Practices

Kim