Dennis Lundberg wrote: > 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
I have put Brett as the project lead for all of these. Feel free to relieve him of that responsibility. > All issues, including closed ones, have been moved from MOJO to the new > JIRA project for each of the above plugins. No issues have been assigned to any fix version in JIRA. That's because I haven't got a clue what to assign them to. If you know more than me on that, please dive in and assign fix versions for them. > 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. This has been done now. > 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
