Distributions: The prerequisites on drupal.org

Cross-posting an email I sent to infrastructure list a few weeks ago, together with Kjartan's response.
It would be great if drupal.org supported distributions by the time Drupal 5 will be released.

The two mails (by Kjartan and me) outline a way to support distributions in an easy way (both for developers and end users). So what are your opinions on this?

frando said:

1. For me, naming seems to be still unclear and ambigous. We should
clarify this (profile/installation profile/distribution).

2. Now on my idea what we could do on d.o., I'll call it 'distribution'
for now. However, as I stated above, I'm not yet clear about the naming.

a) Create a new top-level term and cvs folder "distributions"
b) A particular distribution shall then only consists out of the following:
- a distname.install installation profile
- README, UPGRADE and so on
- a new distname.info. In this info shall be a list of all contrib
modules (each with a specific version - once again kudos to derek) and
themes and version of core used in the distribution. E.g.

[mydist.info]
core=drupal-5.0
modules=cck-5.0-1.1,views-5.0-1.0,project-5.0-2.1
themes=mytheme-5.0-1.0

- the package script (the only part of project that would actually need
improvements for this proposal) would then grab all the files together
(via cvs export):

* specified version of drupal core
* all the modules and themes specified in the distname.info (only
specific versions (tags) should be allowed - no branch/development
snapshots/releases, so that the distribution maintainer retains full
control over which exact code will be in the final tarball)
* everything that's in contributions/distributions/distname under the
appropriate release tag (e.g. additional docs, a logo, a
distribution-specific theme, ...)

and create a tarball out of it. All contrib that's includet via the
distname.info gets placed in profiles/distname/modules|themes. The final
tarball is then available for download via a normal project release node.

If any distribution needs more than this, drupal.org should not host it
directly.

However, I think that a distribution can achieve a lot with this system,
and the whole managment is still on d.o. (release system, issue tracker,
cvs access). It does ease pains for distribution maintainers, as they
can easily move issues to the appropriate modules and create releases
via the project.module. We avoid duplication of code and potential forks
by not duplicating the already existing contrib code in the
contributions/distributions/* dirs. And we ease the whole thing for
normal users as they can download ready-packed tarballs directly from d.o.

regards,
frando

Kjartan Mannes said:

This is identical to the system I was thinking of suggesting. It would
give "distributions" the power to customize Drupal, while making sure
that it does not needlessly duplicate the existing code in any way. It
also encourages "distribution" maintainers to work with the module
authors instead of seeing duplicated maintenance processes

Just like the contrib module/themes we should have some required files,
which should probably be more strongly enforced. I'd also like to see
them somehow add a field on the admin/logs/status detailing its a
distribution, with a link to a more detailed description of which
modules/themes are used and where they are from.

I'm pretty sure we can do this in two or three phases:

Phase 0: Determine the proper name to use. Distributions feels wrong to
me. Install profiles is too limited, and while discussing them people
tend to just leave out the "install" bit and then they risk being
confused with the profile module. I doubt we can get away from Install
profiles though, seeing the directory where they are stored is called
profiles/.

Phase 1: Add a "distributions" folder to the CVS repos so people can
start working on install profiles. Users who want to use these profiles
will have to download the necessary modules/themes from contrib
themselves. This gives "distribution" maintainers a chance to start
working and exploring the possibilities without waiting for Derek or
someone else to code the necessary backend.

Phase 2: Support distribution.info and launch the packaging script.
Should make it easier for the everyone and hopefully everyone will be happy.

Phase 3: Take a look at how everything is being used and see if there is
anything else that can be done to make it all better.