[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[news.eclipse.technology.kepler] Re: Kepler build management 
Hi Thomas,

Thomas Hallgren wrote:
Scott Lewis wrote: 
Hi Folks,

This begs the question: what exactly should we consider in scope for work on Kepler 'build management'?

I (Scott) have been assuming that for the Europa simultaneous release that Kepler's build management focus would/should be on 'whatever the Europa projects require to produce Europa-deployable artifacts'.

This is perhaps over-pragmatic...it is focused primarily on making it feasible and manageable to have existing EF large and small projects participate in Europa without 'breaking their backs' manually doing release engineering work.

So without going too far into it, it seems to me that the initial parts of Kepler build management would have to be headless:

1) build of plugins/bundles
2) build of features
3) build of update sites (since Europa projects deploy as update sites)

I (Thomas) think one important aspect of Kepler is to be domain agnostic and to provide a generic model that defines the build process (among other things but I'm focusing on Build Management here). The Europa simultaneous release will focus more or less 100% on PDE artifacts and thus solely on the PDE domain specific model. It's important that our Build Management covers other domains as well so that we can support various SOA's and other web type applications.

Even if the PDE model is a very good start for Kepler (since it's one of the richest), PDE together with the releng basebuilder etc. also provide the best support for build management in Eclipse today.

I agree that Kepler Build Management should incorporate the steps #1 -#3 above. I also think that good initial support for the PDE Model is advantageous in many ways. I just want to point out that we must be careful not to tie Kepler too firmly to the PDE artifacts.

I don't disagree about the need for generality for Kepler...my point is purely pragmatic: my assumption is that for Kepler to be useful for EF projects, and relevant in the community, it must get some usage/traction among EF projects...and Europa (and subsequent simultaneous releases) is the dominant externally-visible project release structure.


With all of the requisite dependency and version handling for allowing these artifacts to be produced...along with communication of error/exceptional conditions to/among relevant people (e.g. notifications, etc) so that problems can be responded to easily, quickly, by the right people.

Buckminster and Corona have been discussing this. A first step could be to make Buckminster BillOfMaterials (the result of a resolution, not very different from a team project set) act as a containers in the Corona workgroup. We could then use the Corona event framework to send various types of build events between the participants in that workgroup. It would be very easy to have such an event trigger a Buckminster Action.

I think this sounds like a really exciting added value. Looking forward to it.



Of course, there are lots of other things that could be (and probably eventually should be) considered in scope for Kepler build management;

4) Automated testing
5) Production of reports (automated tests and build itself)
6) Creation/modification of user and developer documentation
7) Supporting/enhancing the workflow among team members to support greater efficiency
8) ...

I think item #4 and #5 eventually should evolve into a good integration with the TPTP project. They do great stuff in this domain. 

That's great.  Will they contribute it to Kepler?



But I've been assuming that Kepler would be more successful to

a) take a sequenced approach to dealing with these things (and many others not listed here)
b) get Kepler build management doing the 'top 3' above
c) get some Europa participating projects successfully using Kepler technologies immediately and consistently
d) use experience from a-c to expand Kepler automation in necessary/appropriate ways

So I put the question out to all on this newsgroup for discussion:

What should be considered in scope for Kepler build management in the short term (next 6 months)? Does tying it to Europa build needs work for people? Or are there other things more appropriately in build management that should be addressed other than build support for participating Europa projects?

In one sense (real production), I think Kepler is too late for Europa. The projects in Europa need to rely on stable and well tested software for their build management. Kepler will not fulfill that requirement before EclipseCon and during the time between that and the Europa end-game, nobody will want to be guinea pigs.

What I think we can do, is to continue the approach that we've been taking with Buckminster. We talk to other projects and we try using Buckminster on their current setup. Kepler could gain acceptance and rise the code quality that way.

Yes. BTW...I haven't been assuming that Kepler (or Buckminster or both) could gain acceptance of even a majority of the Europa projects, but rather I think that successful usage in several Europa projects could set the proper stage for usage by all 2008 simultaneous release projects.


I agree with Scotts item a). I think b) should be:
1) Let us agree on a common, agnostic model for build management.

I think we/Kepler should persue a common (and agnostic) model. But it seems to me that the model has to be sufficient in PDE domian for building 1-3 above in order to get 'c'.

The
Buckminster team has been working a long time evolving our CSPEC with that purpose in mind and my suggestion is that we use that as the base for our discussions.

I have no problems with CSPEC as base, but I think we should naturally look at several extant models as the basis of a common model...including at least CSPEC, Maven (see http://wiki.eclipse.org/index.php/Kepler_Project under Project Model reading list).

BTW, is there an xml schema for CSPEC available?

2) Take a look at what Buckminster can do to cover the step #1 - #3 that Scott mentions above. A good start is to build a Buckminster update site using Buckminster (I will add wiki page explaining how to do that).

OK. It's been my assumption that any project participating in Europa whether supported by Buckminster (or Kepler) or not, would have to produce an update site (as that's the input to the Europa deploy as I understand it: http://wiki.eclipse.org/index.php/Europa_Simultaneous_Release

BIRT has been using Buckminster to do builds recently...so are they building an update site with Buckminster?


Step c) as I mentioned, is in line with what we are currently doing and I think that needs to be more of a prototype/test/improve cycle then aimed towards Europa production at this point.

My point was to have it be a prototype/test/improve cycle for *a few* Europa projects (say, 3). This will need to be production for those projects by next May, of course, but that doesn't seem impossible to me given the state of Buckminster, other technologies, build workshop contributions possible from EMFT, TPTP, Corona, ECF, etc.

Scott