+1 to most of the ideas you have proposed. I can help out with 4 iii and iv.
I'm not sure it's a good idea to separate production and pre-release in SVN though. The site I can understand, to give our users a better sense of which plugins are ready and which ones aren't quite there yet. What would be the gain of separating them in SVN? Brett Porter wrote: > Hi, > > I think Mojo is in need of another clean up. I know some stuff has been > done (particularly with docs), and it has been improving - but I have a > few more suggestions that might help with the problems I experienced as > a user coming in yesterday. > > I was in the position of kind of knowing that what I needed was here, > but wasn't able to find it on the site... then once I found it's site it > didn't really instruct me what to do. So now I'm doing the open source > thing and looking to patch it up and though it's had releases, it > doesn't have it's own JIRA project and there are quite a number of open > issues for it in the group project. As a contributor I'm faced with > either a lot of work or a high risk of my issue getting lost in the > noise. I think this story might apply to a number of plugins - and it > drags the reputation of Mojo as a whole down, despite the fact that > there's definitely some gold in here. > > I think we need to recognise Mojo as a collective rather than a project > - and each plugin is basically independent. Each should make or break > itself based on its own quality without affecting the perception of the > collective as a whole. Mojo should offer the facilities to make it easy > to fit in, but not try and tie everything together. > > So, here's what I propose: > > 1) give every released plugin it's own trunk, and separate the parent > POM (much like Maven's parent POM). > > We can still have externals to pull down everything, but I think we have > no need for a "build everything" POM in general use (we can still add > one as a convenience, but it would not be the parent of the mojos). This > recognises each plugin has it's own development cycle and can be more > easily tracked. > > 2) Make a separate module for the site > > This will not have releases, as it's just the website (and we may wish > to switch to using confluence export?). It houses living documents about > the project and links to / info about the various plugins. > > 3) create a separate sandbox with no tags/branches/trunk > > This is a collection of plugins that have just been started and never > released. This will be what the generic MOJO JIRA project will be used > for (component per plugin, as now - but no releases so no versions). > Plugins can have a site under /sandbox/plugin-name. > > 4) Split all other plugins into two groups: production and pre-release > (both in SVN and on the site) > > I see this as key in the clean up - basically where we change the > perception by making the high quality stuff the most visible, and set > the right expectations on the rest. > > Here are the criteria I envisage: > i) anything that is not yet consistently licensed is pre-release (there > a number of plugins suffering from this - such as those marked with the > ASF's header by accident). Mojo only has a license type preference, not > a restriction (other than it must be open source, as Codehaus dictates) > - but it does have to be properly licensed under the one it has chosen. > > ii) anything with an alpha, beta, gamma, omega or RC in the version is > pre-release. I'm not sure what to do with something that is currently > production and then goes into a pre-release cycle on trunk - maybe it > would be displayed separately in the two sections of the site. But > anything that has not yet reached final can not be in the production area. > > iii) anything without a docck compliant site is pre-release. > > iv) every project in either group must have a JIRA project, with a > complete set of versions > > We may even want to increase this criteria in future to encompass > certain quality levels like javadoc and test coverage - but I think the > above is a good start. > > 5) Anything with submodules should have it's own group Id (including the > plugin) > > So, I'm happy to start working on this (consider it my Christmas present > to you all :D) - are there any objections? > > Cheers, > Brett > > > > > --------------------------------------------------------------------- > To unsubscribe from this list please visit: > > http://xircles.codehaus.org/manage_email > > -- Dennis Lundberg --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
