RE: [PROPOSAL] tracking sandbox activities

["Franklin, Matthew B." <mf...@mitre.org>]

>-----Original Message-----
>From: Marlon Pierce [mailto:marpierc@iu.edu]
>Sent: Monday, March 19, 2012 11:57 AM
>To: rave-dev@incubator.apache.org
>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-----