[Fwd: Re: [PROPOSAL] End Gump builds for sandbox projects]

[Antoine Lévy-Lambert <an...@antbuild.com>]

I am not sure whether this email reached the gump list.
Forgive me if this is spam.
Antoine
-------- Original Message --------
Subject: 	Re: [PROPOSAL] End Gump builds for sandbox projects
Date: 	Wed, 3 Mar 2004 23:26:17 -0000
From: 	Stephen Colebourne <sc...@btopenworld.com>
Reply-To: 	Jakarta Commons Developers List <co...@jakarta.apache.org>
To: 	Jakarta Commons Developers List <co...@jakarta.apache.org>
References: 	<00...@oemcomputer> 
<13...@tsws1>



I found this description of Gump and future aims quite interesting. So I'll
withdraw this proposal.

Stephen


----- Original Message -----
From: "Adam R. B. Jack" <aj...@apache.org>
> > This is a proposal to begin to end the abuse of the sandbox. (The
sandbox
> > was intended as a temporary 'play area' for new ideas, not a long term
> > project home)
>
> This is a fascinating approach, and not unlike something that drove me
> towards Gump in the first place. I was a heavy user of a common (sandbox)
> project that after a lot of (user) investment on my part went badly
> stagnant. I felt pretty mift, and wished I had some metrics (or similar)
to
> help me make my choices of dependencies in the first place.
>
> I turned to Gump to attempt to determine which projects were healthy
> (stagnant isn't a bad thing for a feature rich, stable product, with a
> stable stack below it) and which weren't. I feel it is only 'open' to give
> an assessment of a project's status, and what better way that the
> 'googlesque' (I'm sure it is a word waiting to enter the dictionary ;-)
> approach of letting community usage/satisfaction do the talking. Increase
> the rating of a project by using it, depending on it. Decrease it by
walking
> away (as I did) breaking dependency.
>
> Here Gump attempts to 'rate' a project by 'FOG Factor' (eventually
something
> mystical, a combination of all, but right now a ratio of successes verse
> failures, including those of the dependency stack)  :
> http://lsd.student.utwente.nl/gump/gump_stats/project_fogfactor.html
>
> This is by 'count of dependees' (how many projects depend on the project):
> http://lsd.student.utwente.nl/gump/gump_stats/module_dependees.html
>
> This is by last updated (on the module) - yup, sadly bogus for commons, I
> know. :(
> http://lsd.student.utwente.nl/gump/gump_stats/module_updated.html
>
> Gump is far from done, we'll work with folks to create new views/new
stats,
> but it is amasing valuable (albethem statistical) insights into projects
on
> a daily basis.
>
> As such - please do NOT remove these things from Gump, please help us use
> Gump to publically determine the wheat from the chaff, whilst you apply
PMC
> or peer means to clean house of projects that have failed to achieve mass.
> Gump might be in a position (especially with help of users like you
seeking
> solutions) to help you determine what course of action to take for each
> component...



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org





---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org