+1
Do you mean on #4 to have both production and prerelease sites for
plug-ins that have previous releases? I see this to be helpful.
Regards,
Garvin LeClaire
[EMAIL PROTECTED]
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
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
