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