I have created new JIRA projects for those "production plugins" that didn't one before:
axistools - MAXISTOOLS build-helper - MBUILDHELPER findbugs - MFINDBUGS idlj - MIDLJ jaxb2 - MJAXB netbeans-freeform - MNETBEANSFREEFORM ounce - MOUNCE sql - MSQL All issues, including closed ones, have been moved from MOJO to the new JIRA project for each of the above plugins. The corresponding component in the MOJO JIRA project have been deleted. All released production versions have been added to JIRA for each of the above plugins. I used the timestamps from svn as release dates. There is also one unreleased version for each plugin. The number for that upcoming version has been taken from the <version> element in the pom.xml that is in svn trunk. Still need to update poms with the new issueManagement urls. Dennis Lundberg wrote: > +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
