[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[news.eclipse.technology.kepler] Re: Kepler build management
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.

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.


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.


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.

I agree with Scotts item a). I think b) should be:
1) Let us agree on a common, agnostic model for build management. 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.
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).

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.

Kind Regards,
Thomas Hallgren