On 3/3/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > 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.
This doesn't make sense to me. If I'm looking at a particular user guide and decide I want to look at the release notes, I have to go to the main Commons site to do that? And if your answer is no, there's a nav link in the user guide that will take me there, why do I not have a component site any more? There's your need for a component site right there - one place I can go to get all of the information on a specific component, without having to wade through a list of all available components (again - I already had to do that to get to the user guide). I think doing (1) is fine, if that's what floats your boat, but that should be generated from what's in the component's SVN and / or site, and the component sites should be left alone. -- Martin Cooper 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] > >
