[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [pde-build-dev] PDE Build and RCP - my observations


Andrew Niefer wrote on 06/06/2006 11:02:00 AM:
> > Would I be correct in saying that for a large project you would
> > probably need a dedicated build engineer to keep it all in check?
> > Making sure that developers are telling you about which plug-ins
> > should be in which feature, making sure they're writing their test
> > plug-ins correctly. Making sure that the map files are in synch with
> > the feature.xml files.
>
> Eclipse itself has 2 build engineers (yay Sonia & Kim!).  If the
> developers concentrated on making sure the plug-ins they own build
> properly (maintaining map file entries, the manifest and the plug-in
> build.properties) then ideally the build engineer only has to worry
> about the features.  Though in practice it may not always work out that way.

I'd like to amplify this a bit.  The Releng team is responsible for the care and feeding of the build system and do a wonderful job.  The responsibility for designing the features largely falls on the PMC as those choices ultimately define what the project is shipping (i.e., our product from the user's point of view).  Maintaining map files is relatively easy and is the responsibility of the developers.  When a new plugin is added someone has to add it to a map and define its location etc.  Most teams then have one or two people who regularly version off all the projects that have changed and update the map files before an integration (I) build.  The "Releng Tools" are great for doing this (I'll be darned if I can find them now however...).  Andrew?  Pascal?

Note that you can have more entries in a map file than are listed in/used by a feature/build so the developers actions and the feature maintainers act with relatively independence.  Clearly a bundle must be in a map file before it can be in a build otherwise the builder would not know where to get it.

Our features all list 0.0.0 as the plugin version numbers so we almost never have to edit the feature.xmls.  In our case we are relatively stable wrt new plugins (in 3.2 we added something like 20) and this does not turn out to be an issue.

> > It seems to me that there is a lot of room for error in this system.
> > What are your thoughts on these issues? Am I making a mountain out of
> > a molehill? Is it just the job of a build engineer to do all of this?
> > Have I just been making a lot of mistakes along the way?

The problems you are encountering are surely real and they do impact the success of the team.  It is not clear however that there are really ways around this.  For example, someone should be deciding what it is you are actually going to ship.  Someone also has to determine what CVS versions are the current good ones.  These two pieces of information basically drive the build regardless of what mechanism you are using.  

There is some potential for automatically detecting and fetching prerequisites.  This could be quite useful.  It could also be problematic if a dependency is satisfied using the wrong version or supplier.  It is a double edged sword.

Summary:  Your points are well taken and happily received.  We are currently looking at what to do for 3.3 and this is one potential area for improvement.   Don't be shy about opening bug reports for specific suggestions or problems.

Jeff