You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@rave.apache.org by Ate Douma <at...@douma.nu> on 2012/03/19 16:34:26 UTC
[PROPOSAL] tracking sandbox activities
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
RE: [PROPOSAL] tracking sandbox activities
Posted by "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-----
Re: [PROPOSAL] tracking sandbox activities
Posted by Marlon Pierce <ma...@iu.edu>.
-----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-----