>-----Original Message----- >From: Marlon Pierce [mailto:[email protected]] >Sent: Monday, March 19, 2012 11:57 AM >To: [email protected] >Subject: Re: [PROPOSAL] tracking sandbox activities > >-----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).
What about Apache Extras or at least GitHub? > >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/Lo >n >HQ91328OtRjH72ou28TVc5Jx56akbWsZ+3SqhLUM0O0BLyJAN365kaD3N5ctRAi >c >2tTP9zQvCpxtsppmBS4txUj9zPjvVCDb75dEEdsk2VBcPgUOnHzBwI8zHSeoplhZ >kdV5c5mg/c7JOW3SSoDwq07jkQooUJU7+kHxNtAKHTizY0B0oBYqQfN4neeP27 >22 >7ua4JvAsqMLrggwhJUWp43CMWiinJ5+iHHst1wQ3nyYCgSoDpszgHZcac6lgZUW >L >mg5jY5/QsTlnDiPZTmdG+aDw2yuj4HD4JiYcMWR6bTti4QCXcqv6EYhtS8mGd80 >= >=uHu6 >-----END PGP SIGNATURE-----
