Enhancing the Solaris LCFG Platform: final project report

https://devproj.inf.ed.ac.uk/project/show/9

The project started as an attempt to bring the Solaris LCFG support up to date with a number of LCFG developments which had passed Solaris by.

The project achieved some of its objectives, mainly the transition of the Informatics Suns to the same Subversion-based header files used by our other platforms and the resumption of regular patching of the Suns in a patching cycle driven by the Managed Platform and Services units.

Most other objectives were abandoned after it became clear that LCFG Solaris was not after all going to attract the interest which had been expected.

I think I've learned the following lessons from the project:

  • It's useful to have definite commitment from possible customers before beginning the project, rather than to start development in hopes of probable customer adoption. For instance, in the case of the EPCC we had what seemed like probable interest in LCFG Solaris which in the end didn't develop further. After that experience EPCC and Informatics moved to a more definite commitment to joint LCFG development in the SL5 port project.
  • In retrospect the project as originally planned seems to me to have been too big - it would have been better to have been split into several smaller projects, each covering one area of the project (for example install server support, package installation, patching, disk partitioning). This would have allowed for better consideration of the relative priority of each part of the project and for dependencies to be made more clear. In addition each part of the project would have benefited from more detailed planning.
  • Branching the Subversion repository can be very useful if you need to change a lot of headers and/or package files, especially when modifications can be introduced into the configuration of the LCFG servers to enable a handful of test machines to be run from your branch instead of from the normal header and package files; but it's only useful as a short term measure, because while the branch is in use, every change made to the mainstream versions of the header and package files needs to be individually screened to see if it should be copied to the branch as is, copied in a modified form, or if some other course of action is needed. This task needs to be done daily to be manageable.

-- ChrisCooke - 04 Dec 2007

Topic revision: r1 - 04 Dec 2007 - 11:40:28 - ChrisCooke
 
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies