On 3/3/06, Martin Cooper <[EMAIL PROTECTED]> wrote:
> On 3/3/06, Henri Yandell <[EMAIL PROTECTED]> wrote:
>
> <snip/>
>
>
> > I think we should be folding the site into one site, with manuals per
> > subproject. Release info would be put in a release structure (src,
> > javadoc) and other reports would be hooked into the CI system.
> > Separating the user and developer consumer-requirements, hopefully
> > making our life easier.
>
>
> If all that was in place, how many sites would the average Commons developer
> be required to maintain? It sounds like 3 to me - the component site, the
> shared site, and the CI site. IMO, that is 2 too many. Right now, we're only
> at 1 too many.
>
> If anything, I would be in favour of moving in the opposite direction.
> Everything about component X stays on the component X site, so the
> developers of component X only need to worry about maintaining one site. If
> someone wanted to add some automation to 'pull' some information from
> component sites to the main Commons site, that would be fine, but don't make
> the component developers have to go put it there. What makes the site
> updates a pain today is that there is more than one to maintain.

Right. So I'm suggesting:

1) Shared site. Containing links to the important info. Commons blurb.

A larger version of:  http://www.osjava.org/genjava/ (which needs
improving to handle versions).

2) Component site. Though site is the wrong word. Ideally there
shouldn't be a component site; there's no reason for one. What it is
is a series of release items that are stored in versioned structure:

i) javadoc
ii) source xref if we think that's important enough
iii) user manual
iv) release notes (probably fold dependencies list into this).

All the individual items that are linked to from 1) basically - and
probably matching those included in the zip. The downside here is a
lessening of component individuality - it's an enforced information
architecture.

3) CI site. Lots of developer reports - such as Maven loves to
produce. Updated nightly, so the reports are actually useful.

I don't know about whether that is more work or less. It is a change
of mindset on releases; a release is more than just a zip/tar.gz/jar -
there's a structure of documentation to go with it - but not a
website.

This all probably just comes down to:

a) CI site. Something I should just go ahead and try and work on to
see if people like it. http://builds.osjava.org/osjava/ is my
prototype demo.

b) Moving standard information from the individual Commons component
index pages to the Commons index page so they become (quite sparse)
user manuals in some cases, and having a structured main Commons site.

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to