Hi,
2007/12/22, Brett Porter <[EMAIL PROTECTED]>: > 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. +1 > > 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. > +1 > 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. > +1 > 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. +0 (unless it is already production) > > 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. +1 > > iii) anything without a docck compliant site is pre-release. +0 (unless docck arrived after the plugin was production) > > iv) every project in either group must have a JIRA project, with a > complete set of versions +0 > > 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) +0 > > So, I'm happy to start working on this (consider it my Christmas > present to you all :D) - are there any objections? My only objection is that we should not downgrade from production to pre-release for plugins that where production before the rules where taken. Or the upgrade to the new rules must be done by the new rules proposer... Regards, Raphaël > > Cheers, > Brett > > > > > --------------------------------------------------------------------- > To unsubscribe from this list please visit: > > http://xircles.codehaus.org/manage_email > >
