You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stephen Colebourne <sc...@btopenworld.com> on 2004/03/02 01:15:46 UTC

[PROPOSAL] End Gump builds for sandbox projects

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)

Gump is the key mechanism used in apache to ensure that everything keeps
building. By removing the sandbox projects, we should encourage other
projects not to depend on the sandbox unless they are willing to help push
the project to a release.

Normally decisions such as this have been left to each project, but IMHO its
time for commons-dev to take control. Any views? Do we vote or just do it?

Stephen



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

Re: [PROPOSAL] End Gump builds for sandbox projects

Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 02 Mar 2004, Stefan Bodewig <bo...@apache.org> wrote:

> BTW, this would be the ripple effect if we'd stop building
> jakarta-commons-sandbox projects in Gump:

> The strongest effect stems from commons-io which isn't in the
> sandbox anymore, right?

Adapting to the change, we still get

Dropping project jakarta-turbine-fulcrum because of Exception java.lang.Exception: project "commons-util" not found processing project jakarta-turbine-fulcrum
Dropping project jakarta-turbine-site because of Exception java.lang.Exception: project "jakarta-turbine-fulcrum" not found processing project jakarta-turbine-site
Dropping project jakarta-turbine-3 because of Exception java.lang.Exception: project "jakarta-turbine-fulcrum" not found processing project jakarta-turbine-3
Dropping project jakarta-turbine-2 because of Exception java.lang.Exception: project "commons-email" not found processing project jakarta-turbine-2
Dropping project jakarta-turbine-flux because of Exception java.lang.Exception: project "jakarta-turbine-3" not found processing project jakarta-turbine-flux
Dropping project jakarta-turbine-orgami because of Exception java.lang.Exception: project "jakarta-turbine-2" not found processing project jakarta-turbine-orgami
Dropping project commons-jelly-tags-jms because of Exception java.lang.Exception: project "commons-messenger" not found processing project commons-jelly-tags-jms
Dropping project maven-bootstrap because of Exception java.lang.Exception: project "commons-graph" not found processing project maven-bootstrap
Dropping project jakarta-turbine-stratum-full because of Exception java.lang.Exception: project "commons-messenger" not found processing project jakarta-turbine-stratum-full
Dropping project jakarta-taglibs-jmstags because of Exception java.lang.Exception: project "commons-messenger" not found processing project jakarta-taglibs-jmstags
Dropping project jakarta-turbine-tdk because of Exception java.lang.Exception: project "commons-util" not found processing project jakarta-turbine-tdk
Dropping project commons-jelly-tags-ant because of Exception java.lang.Exception: project "commons-grant" not found processing project commons-jelly-tags-ant
Dropping project incubator-altrmi because of Exception java.lang.Exception: project "commons-attributes" not found processing project incubator-altrmi
Dropping project jakarta-turbine-stratum because of Exception java.lang.Exception: project "commons-messenger" not found processing project jakarta-turbine-stratum
Dropping project jakarta-turbine-jyve because of Exception java.lang.Exception: project "jakarta-turbine-2" not found processing project jakarta-turbine-jyve
Dropping project werkz because of Exception java.lang.Exception: project "commons-jelly-tags-ant" not found processing project werkz
Dropping project jakarta-jetspeed because of Exception java.lang.Exception: project "jakarta-turbine-2" not found processing project jakarta-jetspeed
Dropping project scarab because of Exception java.lang.Exception: project "jakarta-turbine-3" not found processing project scarab
Dropping project maven because of Exception java.lang.Exception: project "werkz" not found processing project maven
Dropping project incubator-geronimo because of Exception java.lang.Exception: project "maven" not found processing project incubator-geronimo
Dropping project excalibur-instrument-client because of Exception java.lang.Exception: project "incubator-altrmi" not found processing project excalibur-instrument-client
Dropping project excalibur-instrument-manager-altrmi because of Exception java.lang.Exception: project "incubator-altrmi" not found processing project excalibur-instrument-manager-altrmi
Dropping project commons-jelly-tags-jsl because of Exception java.lang.Exception: project "commons-grant" not found processing project commons-jelly-tags-jsl

Stefan

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

Re: [PROPOSAL] End Gump builds for sandbox projects

Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 02 Mar 2004, Stefan Bodewig <bo...@apache.org> wrote:

> What do you want to stop?  Building of the jars or just publishing
> them?

BTW, this would be the ripple effect if we'd stop building
jakarta-commons-sandbox projects in Gump:

Dropping project jakarta-turbine-fulcrum because of Exception java.lang.Exception: project "commons-util" not found processing project jakarta-turbine-fulcrum
Dropping project db-torque because of Exception java.lang.Exception: project "commons-io" not found processing project db-torque
Dropping project jakarta-turbine-site because of Exception java.lang.Exception: project "jakarta-turbine-fulcrum" not found processing project jakarta-turbine-site
Dropping project jakarta-turbine-3 because of Exception java.lang.Exception: project "db-torque" not found processing project jakarta-turbine-3
Dropping project jakarta-turbine-2 because of Exception java.lang.Exception: project "commons-email" not found processing project jakarta-turbine-2
Dropping project jakarta-turbine-flux because of Exception java.lang.Exception: project "jakarta-turbine-3" not found processing project jakarta-turbine-flux
Dropping project jakarta-turbine-orgami because of Exception java.lang.Exception: project "jakarta-turbine-2" not found processing project jakarta-turbine-orgami
Dropping project commons-jelly-tags-jms because of Exception java.lang.Exception: project "commons-messenger" not found processing project commons-jelly-tags-jms
Dropping project maven-bootstrap because of Exception java.lang.Exception: project "commons-io" not found processing project maven-bootstrap
Dropping project jakarta-turbine-stratum-full because of Exception java.lang.Exception: project "commons-messenger" not found processing project jakarta-turbine-stratum-full
Dropping project jakarta-taglibs-jmstags because of Exception java.lang.Exception: project "commons-messenger" not found processing project jakarta-taglibs-jmstags
Dropping project jakarta-turbine-tdk because of Exception java.lang.Exception: project "commons-util" not found processing project jakarta-turbine-tdk
Dropping project commons-jelly-tags-ant because of Exception java.lang.Exception: project "commons-grant" not found processing project commons-jelly-tags-ant
Dropping project incubator-altrmi because of Exception java.lang.Exception: project "commons-attributes" not found processing project incubator-altrmi
Dropping project jakarta-turbine-stratum because of Exception java.lang.Exception: project "commons-io" not found processing project jakarta-turbine-stratum
Dropping project jakarta-turbine-jyve because of Exception java.lang.Exception: project "jakarta-turbine-2" not found processing project jakarta-turbine-jyve
Dropping project werkz because of Exception java.lang.Exception: project "commons-jelly-tags-ant" not found processing project werkz
Dropping project xml-fop because of Exception java.lang.Exception: project "commons-io" not found processing project xml-fop
Dropping project jakarta-jetspeed because of Exception java.lang.Exception: project "jakarta-turbine-2" not found processing project jakarta-jetspeed
Dropping project scarab because of Exception java.lang.Exception: project "jakarta-turbine-3" not found processing project scarab
Dropping project maven because of Exception java.lang.Exception: project "werkz" not found processing project maven
Dropping project incubator-geronimo because of Exception java.lang.Exception: project "maven" not found processing project incubator-geronimo
Dropping project excalibur-instrument-client because of Exception java.lang.Exception: project "incubator-altrmi" not found processing project excalibur-instrument-client
Dropping project dom4j because of Exception java.lang.Exception: project "xml-fop" not found processing project dom4j
Dropping project excalibur-instrument-manager-altrmi because of Exception java.lang.Exception: project "incubator-altrmi" not found processing project excalibur-instrument-manager-altrmi
Dropping project commons-jelly-tags-jsl because of Exception java.lang.Exception: project "commons-grant" not found processing project commons-jelly-tags-jsl
Dropping project db-ojb because of Exception java.lang.Exception: project "db-torque" not found processing project db-ojb

The strongest effect stems from commons-io which isn't in the sandbox
anymore, right?  Could you please review
<http://cvs.apache.org/viewcvs.cgi/gump/project/jakarta-commons-sandbox.xml>
to identify more components that have been graduated without Gump
reflecting the change?  Remember, all Apache committers have karma for
the gump module.

Stefan

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

Re: [PROPOSAL] End Gump builds for sandbox projects

Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 02 Mar 2004, Stefan Bodewig <bo...@apache.org> wrote:

> What do you want to stop?  Building of the jars or just publishing
> them?

BTW, this would be the ripple effect if we'd stop building
jakarta-commons-sandbox projects in Gump:

Dropping project jakarta-turbine-fulcrum because of Exception java.lang.Exception: project "commons-util" not found processing project jakarta-turbine-fulcrum
Dropping project db-torque because of Exception java.lang.Exception: project "commons-io" not found processing project db-torque
Dropping project jakarta-turbine-site because of Exception java.lang.Exception: project "jakarta-turbine-fulcrum" not found processing project jakarta-turbine-site
Dropping project jakarta-turbine-3 because of Exception java.lang.Exception: project "db-torque" not found processing project jakarta-turbine-3
Dropping project jakarta-turbine-2 because of Exception java.lang.Exception: project "commons-email" not found processing project jakarta-turbine-2
Dropping project jakarta-turbine-flux because of Exception java.lang.Exception: project "jakarta-turbine-3" not found processing project jakarta-turbine-flux
Dropping project jakarta-turbine-orgami because of Exception java.lang.Exception: project "jakarta-turbine-2" not found processing project jakarta-turbine-orgami
Dropping project commons-jelly-tags-jms because of Exception java.lang.Exception: project "commons-messenger" not found processing project commons-jelly-tags-jms
Dropping project maven-bootstrap because of Exception java.lang.Exception: project "commons-io" not found processing project maven-bootstrap
Dropping project jakarta-turbine-stratum-full because of Exception java.lang.Exception: project "commons-messenger" not found processing project jakarta-turbine-stratum-full
Dropping project jakarta-taglibs-jmstags because of Exception java.lang.Exception: project "commons-messenger" not found processing project jakarta-taglibs-jmstags
Dropping project jakarta-turbine-tdk because of Exception java.lang.Exception: project "commons-util" not found processing project jakarta-turbine-tdk
Dropping project commons-jelly-tags-ant because of Exception java.lang.Exception: project "commons-grant" not found processing project commons-jelly-tags-ant
Dropping project incubator-altrmi because of Exception java.lang.Exception: project "commons-attributes" not found processing project incubator-altrmi
Dropping project jakarta-turbine-stratum because of Exception java.lang.Exception: project "commons-io" not found processing project jakarta-turbine-stratum
Dropping project jakarta-turbine-jyve because of Exception java.lang.Exception: project "jakarta-turbine-2" not found processing project jakarta-turbine-jyve
Dropping project werkz because of Exception java.lang.Exception: project "commons-jelly-tags-ant" not found processing project werkz
Dropping project xml-fop because of Exception java.lang.Exception: project "commons-io" not found processing project xml-fop
Dropping project jakarta-jetspeed because of Exception java.lang.Exception: project "jakarta-turbine-2" not found processing project jakarta-jetspeed
Dropping project scarab because of Exception java.lang.Exception: project "jakarta-turbine-3" not found processing project scarab
Dropping project maven because of Exception java.lang.Exception: project "werkz" not found processing project maven
Dropping project incubator-geronimo because of Exception java.lang.Exception: project "maven" not found processing project incubator-geronimo
Dropping project excalibur-instrument-client because of Exception java.lang.Exception: project "incubator-altrmi" not found processing project excalibur-instrument-client
Dropping project dom4j because of Exception java.lang.Exception: project "xml-fop" not found processing project dom4j
Dropping project excalibur-instrument-manager-altrmi because of Exception java.lang.Exception: project "incubator-altrmi" not found processing project excalibur-instrument-manager-altrmi
Dropping project commons-jelly-tags-jsl because of Exception java.lang.Exception: project "commons-grant" not found processing project commons-jelly-tags-jsl
Dropping project db-ojb because of Exception java.lang.Exception: project "db-torque" not found processing project db-ojb

The strongest effect stems from commons-io which isn't in the sandbox
anymore, right?  Could you please review
<http://cvs.apache.org/viewcvs.cgi/gump/project/jakarta-commons-sandbox.xml>
to identify more components that have been graduated without Gump
reflecting the change?  Remember, all Apache committers have karma for
the gump module.

Stefan

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

Re: [PROPOSAL] End Gump builds for sandbox projects

Posted by Stefan Bodewig <bo...@apache.org>.
I'm not exactly sure what you are asking for, so please help me to
understand the proposal.

Gump builds stuff and under certain circumstances it publishes the
generated jars.  For example, the build system that is currently
sending the nag emails is not publishing the build artifacts at all.

What do you want to stop?  Building of the jars or just publishing
them?

I think building sandbox components is as important as building any
other component.  How would the authors of a sandbox component get to
know that their usage of JDOM relies on jdom-b9 and will not compile
against JDOM 1.0 when released?

Publishing is a different story IMHO.

Stefan

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

Re: [PROPOSAL] End Gump builds for sandbox projects

Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.

Henri Yandell wrote:

> Okay, so you just mean no gump for sandbox [deletes long rant about
> importance of nightly builds]. Summary of it is, that I think gump and the
> apache repository need to be hooked together so each project is updating
> the SNAPSHOT whenever it changes.
> 

Nick's probably going to insert something to the effect that Gump isn't 
a nightly build publishing system, its a continuous integration testing 
system. ;-)

The dealio with publishing nightly snapshots was to hopefully get them 
into somewhere like

/www/cvs.apache.org/builds/java-repository

the reasoning is that www/www.apache.org is reserved for official 
releases while cvs.apache.org is reserved for nightly builds, stuff that 
really goes out to the world for external projects to build off of 
actually goes into ibiblio in the end, all nightlies stay at Apache. 
[Mark repeats himself yet again...crickets, silence...sigh]

> Last Lang SNAPSHOT was the end of January.
> 
> +1 to kill gump builds for sandbox projects. In fact, +1 to kill it for
> all unreleased projects [sorry dIon/Phil/Mark].
> 

More motivation to get that Math release out sooner ;-)

> Hen
> 
> On Mon, 1 Mar 2004, Nick Chalko wrote:
> 
> 
>>As long as project don't decide to use gump anyways and cheat relying on
>>a version sandbox projects jar checked into CVS then I think this is a
>>reasonable thing.
>>Stephen Colebourne wrote:
>>
>>
>>>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)
>>>
>>>Gump is the key mechanism used in apache to ensure that everything keeps
>>>building. By removing the sandbox projects, we should encourage other
>>>projects not to depend on the sandbox unless they are willing to help push
>>>the project to a release.
>>>
>>>Normally decisions such as this have been left to each project, but IMHO its
>>>time for commons-dev to take control. Any views? Do we vote or just do it?
>>>
>>>Stephen
>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>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: commons-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 

-- 
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu

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

Re: [PROPOSAL] End Gump builds for sandbox projects

Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.

Henri Yandell wrote:

> Okay, so you just mean no gump for sandbox [deletes long rant about
> importance of nightly builds]. Summary of it is, that I think gump and the
> apache repository need to be hooked together so each project is updating
> the SNAPSHOT whenever it changes.
> 

Nick's probably going to insert something to the effect that Gump isn't 
a nightly build publishing system, its a continuous integration testing 
system. ;-)

The dealio with publishing nightly snapshots was to hopefully get them 
into somewhere like

/www/cvs.apache.org/builds/java-repository

the reasoning is that www/www.apache.org is reserved for official 
releases while cvs.apache.org is reserved for nightly builds, stuff that 
really goes out to the world for external projects to build off of 
actually goes into ibiblio in the end, all nightlies stay at Apache. 
[Mark repeats himself yet again...crickets, silence...sigh]

> Last Lang SNAPSHOT was the end of January.
> 
> +1 to kill gump builds for sandbox projects. In fact, +1 to kill it for
> all unreleased projects [sorry dIon/Phil/Mark].
> 

More motivation to get that Math release out sooner ;-)

> Hen
> 
> On Mon, 1 Mar 2004, Nick Chalko wrote:
> 
> 
>>As long as project don't decide to use gump anyways and cheat relying on
>>a version sandbox projects jar checked into CVS then I think this is a
>>reasonable thing.
>>Stephen Colebourne wrote:
>>
>>
>>>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)
>>>
>>>Gump is the key mechanism used in apache to ensure that everything keeps
>>>building. By removing the sandbox projects, we should encourage other
>>>projects not to depend on the sandbox unless they are willing to help push
>>>the project to a release.
>>>
>>>Normally decisions such as this have been left to each project, but IMHO its
>>>time for commons-dev to take control. Any views? Do we vote or just do it?
>>>
>>>Stephen
>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>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: commons-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 

-- 
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu

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

Re: [PROPOSAL] End Gump builds for sandbox projects

Posted by Henri Yandell <ba...@generationjava.com>.
Okay, so you just mean no gump for sandbox [deletes long rant about
importance of nightly builds]. Summary of it is, that I think gump and the
apache repository need to be hooked together so each project is updating
the SNAPSHOT whenever it changes.

Last Lang SNAPSHOT was the end of January.

+1 to kill gump builds for sandbox projects. In fact, +1 to kill it for
all unreleased projects [sorry dIon/Phil/Mark].

Hen

On Mon, 1 Mar 2004, Nick Chalko wrote:

> As long as project don't decide to use gump anyways and cheat relying on
> a version sandbox projects jar checked into CVS then I think this is a
> reasonable thing.
> Stephen Colebourne wrote:
>
> >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)
> >
> >Gump is the key mechanism used in apache to ensure that everything keeps
> >building. By removing the sandbox projects, we should encourage other
> >projects not to depend on the sandbox unless they are willing to help push
> >the project to a release.
> >
> >Normally decisions such as this have been left to each project, but IMHO its
> >time for commons-dev to take control. Any views? Do we vote or just do it?
> >
> >Stephen
> >
> >
> >
> >---------------------------------------------------------------------
> >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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>


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

Re: [PROPOSAL] End Gump builds for sandbox projects

Posted by Henri Yandell <ba...@generationjava.com>.
Okay, so you just mean no gump for sandbox [deletes long rant about
importance of nightly builds]. Summary of it is, that I think gump and the
apache repository need to be hooked together so each project is updating
the SNAPSHOT whenever it changes.

Last Lang SNAPSHOT was the end of January.

+1 to kill gump builds for sandbox projects. In fact, +1 to kill it for
all unreleased projects [sorry dIon/Phil/Mark].

Hen

On Mon, 1 Mar 2004, Nick Chalko wrote:

> As long as project don't decide to use gump anyways and cheat relying on
> a version sandbox projects jar checked into CVS then I think this is a
> reasonable thing.
> Stephen Colebourne wrote:
>
> >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)
> >
> >Gump is the key mechanism used in apache to ensure that everything keeps
> >building. By removing the sandbox projects, we should encourage other
> >projects not to depend on the sandbox unless they are willing to help push
> >the project to a release.
> >
> >Normally decisions such as this have been left to each project, but IMHO its
> >time for commons-dev to take control. Any views? Do we vote or just do it?
> >
> >Stephen
> >
> >
> >
> >---------------------------------------------------------------------
> >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: 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

Re: [PROPOSAL] End Gump builds for sandbox projects

Posted by Nick Chalko <ni...@chalko.com>.
As long as project don't decide to use gump anyways and cheat relying on 
a version sandbox projects jar checked into CVS then I think this is a 
reasonable thing.
Stephen Colebourne wrote:

>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)
>
>Gump is the key mechanism used in apache to ensure that everything keeps
>building. By removing the sandbox projects, we should encourage other
>projects not to depend on the sandbox unless they are willing to help push
>the project to a release.
>
>Normally decisions such as this have been left to each project, but IMHO its
>time for commons-dev to take control. Any views? Do we vote or just do it?
>
>Stephen
>
>
>
>---------------------------------------------------------------------
>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

Re: [PROPOSAL] End Gump builds for sandbox projects

Posted by Stephen Colebourne <sc...@btopenworld.com>.
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

Re: [PROPOSAL] End Gump builds for sandbox projects

Posted by "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...

regards

Adam



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

Re: [PROPOSAL] End Gump builds for sandbox projects

Posted by Stefan Bodewig <bo...@apache.org>.
I'm not exactly sure what you are asking for, so please help me to
understand the proposal.

Gump builds stuff and under certain circumstances it publishes the
generated jars.  For example, the build system that is currently
sending the nag emails is not publishing the build artifacts at all.

What do you want to stop?  Building of the jars or just publishing
them?

I think building sandbox components is as important as building any
other component.  How would the authors of a sandbox component get to
know that their usage of JDOM relies on jdom-b9 and will not compile
against JDOM 1.0 when released?

Publishing is a different story IMHO.

Stefan

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

Re: [PROPOSAL] End Gump builds for sandbox projects

Posted by "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...

regards

Adam



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

Re: [PROPOSAL] End Gump builds for sandbox projects

Posted by Nick Chalko <ni...@chalko.com>.
As long as project don't decide to use gump anyways and cheat relying on 
a version sandbox projects jar checked into CVS then I think this is a 
reasonable thing.
Stephen Colebourne wrote:

>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)
>
>Gump is the key mechanism used in apache to ensure that everything keeps
>building. By removing the sandbox projects, we should encourage other
>projects not to depend on the sandbox unless they are willing to help push
>the project to a release.
>
>Normally decisions such as this have been left to each project, but IMHO its
>time for commons-dev to take control. Any views? Do we vote or just do it?
>
>Stephen
>
>
>
>---------------------------------------------------------------------
>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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

RE: [PROPOSAL] End Gump builds for sandbox projects

Posted by "Noel J. Bergman" <no...@devtech.com>.
> This is a proposal to begin to end the abuse of the sandbox.

I agree with your concern, I disagee with your method.

We are awaiting new hardware.  One of the new machines will be dedicated to
GUMP processing (possibly some other related tasks).  My understanding, and
there are reasons for this, is that the output from the machine will be
reports.  The builds will not be available at all.  That addresses your
concern without breaking the value of GUMP.

  -1 to kill GUMP for sandbox
  -1 to kill it for unreleased projects

Remember: GUMP is for *our* use, and the latter point would mean that no
project within the ASF could even start to use a library until after it had
a formal release, which could lead to a Catch-22.  The whole purpose for
GUMP is to catch problems EARLY in the development cycle, not to be a build
and test server for released components.  The new GUMP configuration will
eliminate the problem of people using GUMP builds, so let's not throw out
the baby with the bathwater.

	--- Noel


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