-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We have primarily used sandbox projects as templates and examples: "here is how you extend Rave to replace the DefaultUserService," for example. Since this involves people without Apache SVN write access, we have moved most of this activity to other places (SourceForge SVN).
I think it is very useful to have extension examples assuming we want to continue to use the current overlay approach, but labeling them "sandbox" is no longer accurate. However, if we provide them as examples, they will need to be more carefully maintained and/or associated with specific Rave release versions. Marlon On 3/19/12 11:34 AM, Ate Douma wrote: > As we're planning to start quite a lot of work shortly in a sandbox, but with > the intend to later merge this into the 'mainstream' Rave life-cycle, I think > this is a good moment to further discuss how to track and manage sandbox > projects from a (P)PMC perspective. > > Right now we have two sandbox 'projects': rave-extensions (with 2 sub > modules) and science-gateways (with 4 sub modules). > > So far, some (but definitely not all) activities in these sandboxes have been > recorded in JIRA, but with no tracking/marking of any status, version(s) or > related components. IMO this is not preferred as it kind of 'pollutes' JIRA > and makes it more difficult to assess the status of these sandbox projects. > > I think we can improve on this and that the (P)PMC should take more > responsibility or at least oversight on the ongoing work in these sandboxes. > > First of all, IMO these sandbox projects should have a specific goal and > intended lifespan. As being part of our SVN tree, the PMC is formally > responsible of its content and its relevance to the project and an open-ended > or indefinite scope isn't really meaningful. > > As a minimum we can at least track the ongoing work in JIRA and label it > appropriately. > > One way we might do this is using of the JIRA 'Component' classification. > My proposal is to define a separate Component for each sandbox (module) and > include a sandbox- prefix to separate them from 'endorsed' components, like: > > sandbox-extension-sso > sandbox-vanilla-extension > sandbox-science-gateways-gadgets > sandbox-science-gateways-gridship-extensions > ... > > Furthermore, we can mark the non-versionable characteristic of these sandbox > components and thereby also prevent end up with endless un-versioned issues. > As JIRA versions are plain strings, we can simply introduce a 'sandbox' > version and use that for all JIRA issues concerning these sandbox projects. > One 'sandbox' version should suffice IMO as there shouldn't be sandbox > 'releases' anyway. > > And maybe we should even use this 'sandbox' version for artifacts within the > sandbox, e.g. rave-vanilla-extension-sandbox-SNAPSHOT instead of > rave-vanilla-extension-0.10-SNAPSHOT. That'll make it very clear sandbox > projects are not endorsed nor life-cycle managed. > Once a sandbox project becomes really useful this will also help 'drive' it > out of the sandbox, just to get rid of the annoying 'sandbox' label ;) > > And if a sandbox project doesn't build up traction, gets too far out-of-sync > with or behind the main project, or its testing/exploration purpose has been > fulfilled, sandbox projects probably should either be 'retired' (moved to a > rave 'attic' svn folder?) or else simply deleted. > I definitely don't like sandbox projects (like I do see in other TLP > projects) which are abandoned and left to 'rot'. > > Assuming lazy consensus on the JIRA part of this proposal as it is easily > revertible at any rate, I'll add to JIRA a 'sandbox' version and new > 'sandbox-' prefixed components for the new content services proposal. And if > there is general agreement on this, we should do the same for the other > sandbox projects. > > WDYT? > > Ate -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPZ1c2AAoJEEfVXEODPFIDJMUH/j6wsS5h0M3cxTnKpIrR/Lon HQ91328OtRjH72ou28TVc5Jx56akbWsZ+3SqhLUM0O0BLyJAN365kaD3N5ctRAic 2tTP9zQvCpxtsppmBS4txUj9zPjvVCDb75dEEdsk2VBcPgUOnHzBwI8zHSeoplhZ kdV5c5mg/c7JOW3SSoDwq07jkQooUJU7+kHxNtAKHTizY0B0oBYqQfN4neeP2722 7ua4JvAsqMLrggwhJUWp43CMWiinJ5+iHHst1wQ3nyYCgSoDpszgHZcac6lgZUWL mg5jY5/QsTlnDiPZTmdG+aDw2yuj4HD4JiYcMWR6bTti4QCXcqv6EYhtS8mGd80= =uHu6 -----END PGP SIGNATURE-----
