| [higgins-dev] Agenda Item for Thursday Call |
|
I would like to propose an agenda item for Thursday's call, if there is time.
The issue is builds for the various Higgins components. I am concerned because I currently have no way to reproduce what was done for the IIW demo. The jar files that were deployed on our demo servers came from builds that were done on various people's personal computers - using code that had not been checked in and for which there was (and still is not) an "official" build.
I understand that when we are under pressure and are putting together demos, this is often a necessary mode of operation, but once everyone is satisfied that the demo is ready, I would like to be able to get back to the source and all dependencies that were used for the demo so that I can reproduce it and tweek it as needed. This is often very difficult to do if the developers have moved on and checked in hundreds of new fixes, features, etc. - or are busy refactoring everything. This has not been a high priority item, but I think it should be. I would really, really like to see this take on a higher priority and urgency. Specifically, we need official builds (including source) for the following components:
idas, ldap context provider, sts, and the card generator (currently part of the sts).
In addition, we need to know how we are going to handle this going forward. I would like to see us discuss the following sub-issues with respect to builds:
1) Packaging of source along with jar files - so the jar files can always easily be associated with the source that was used to generate it. I would also like to recommend that we create tags in the CVS repository for specific milestones and/or other important events that we might want to preserve and get back to (such as demos). BTW: If our repository were Subversion, this would be much easier, because we could simply use a SVN version number.
2) A way to trigger a build at any time. This is important when putting together a demo, because what I really want to do is to ask a developer to check in their "fixes" and then manually do an "official" build that we incorporate immediately into the demo. That way we aren't as prone to forget to check stuff in and save off an official build that corresponds to our demo before we move on and start doing other features. -- We simply discipline ourselves to only use official builds when putting together demos - but that is only possible if it is easy to generate official builds multiple times a day on demand.
3) #2 implies that the builds need a more granular naming scheme than date - it needs to include hour, minute, and second as well - because we may do multiple builds in one day, not just a single nightly build.
4) List of dependencies that were used to do the build. I know we cannot redistribute these things ourselves, but we ought to at least keep a list that is current - so we can know exactly what versions of things were used to do the build.
In my mind, it is critical that we get a robust "build management" system in place now - including whatever standards we think people ought to follow. People are starting to do things (demos, etc.) where reproducibility is going to be very important. We want to do this before we lots going on and are attempting to support it with a build system that grew up in a haphazard way without careful thought and planning.
|