Simon PJ writes:
What we want, I think, is an aggregation mechanism. In particular
there could be one or more "contrib" packages, optionally hosted at fptools/libraries, containing code contributed and maintained by different folk, but packaged and distributed by one person, a Contrib Builder (better titles welcome)
Actually, I think we need multiple contrib builders just as there are for GHC at the moment. Specifically: - we need someone who knows about and cares about FreeBSD to produce freebsd ports of libraries - we need someone who knows about and cares about Windows to produce .msi packages - we need someone who knows about and cares about Debian to produce debian packages and so on for each format we want releases in. It's unlikely that one person will have experience of all the different systems we want releases for so it has to be multiple people. For any one format, it may be easier to have one person do all packages for all compilers and all libraries or it may be easier to split the task by compiler, by software license, by repository, or whatever. (Obviously, using a common infrastructure makes it easier for one person to handle more libraries and more compilers.) Simon also says:
The Contrib Builder will probably want to do automated nightly build/test runs of the package.
I think this suggestion blurs the distinction between library writers and contrib builders. It is a library writer's responsibility to deal with bugs - they would probably benefit hugely from this sort of infrastructure. Contrib builders should only be dealing with bugs they have introduced in a particular package or, arguably, with portability issues. The way I see it, there should be a very clearly defined interface between library writers and contrib builders. Library writers should provide version numbered releases (absolutely _not_ daily CVS snapshots) together with certain metadata (documentation, which version number this is, which particular versions of other libraries the library works with, etc.). Contrib builders apply some patches to customize it for a particular system (debian, freebsd, etc.), compiles it, runs the testsuite, builds the documentation and packages it up. Contrib builders might also act as a conduit for bug reports. -- Alastair Reid ps The above assumes that we want binary packages (I think there's plenty of evidence (Redhat, Debian, etc.) that this is what people want to use). It assumes that we want to work with the 'native' package mechanism on a system rather than providing our own parallel mechanism. It assumes that authors aren't always able to update their library whenever there is a significant change in one of the things they depend on: the nightly tests fail every night for a month before they get dealt with. Finally, it assumes that most people want official releases of code that the author feels are in a usable state rather than random snaphots of an evolving system.