commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <mdigg...@latte.harvard.edu>
Subject Re: [PROPOSAL] End Gump builds for sandbox projects
Date Tue, 02 Mar 2004 03:02:54 GMT


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


Mime
View raw message