On Dec 22, 2007 10:55 PM, Brett Porter <[EMAIL PROTECTED]> 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?
I am
+1 on 1) 2) and 3),
-1 on 4) and
+0 on 5)
For 4) production/pre-release, what do we mean by production / pre-release ?
I'll take the example of the webstart plugin. It's a 2 years old
plugin, and although the next release is supposed to be 1.0-alpha-2, I
consider it to be good enough for production.
The reason it is not yet 1.0 is that I want to keep the ability to
make changes to the configuration before 1.0.
I also use some plugins like the shitty one which are not 1.0 but that
I would gladly consider using on any project.
Misc:
+1 on the Jira project per project (there should be a checklist of
things to do when releasing a project ouf ot the sandbox)
-1 on the test coverage as a criteria
Cheers,
Jerome
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
