gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <rdon...@apache.org>
Subject Re: [VOTE] retire java gump
Date Sun, 20 Jun 2004 17:11:52 GMT
On 20 Jun 2004, at 11:10, Sebastian Bazley wrote:
> ----- Original Message -----
> From: "robert burrell donkin" <rdonkin@apache.org>

<snip>

>> IIRC there are some issues about allowing the artifacts created by 
>> gump
>> to be distributed from ASF machines. i think that the board is of the
>> opinion that only releases approved by a pmc can be distributed.
>
> Surely these are not "releases"?
> Or does it mean that the only software that can be distributed is a 
> release
> approved by a PMC?

IANAL but IIRC the general thrust of the argument is that the ASF can 
only protect itself and those working on it's behalf if it can 
demonstrate supervision. there's a school of thought that says that 
when the artifacts produced by gump are distributed they become defacto 
releases and therefore need to be approved by a pmc.

some of those who hang out here will probably be able to give you a 
much more definitive statement of the current board policy than me, so 
hopefully they'll jump in here...

>> if this is the case, then i'd say that the -1 is probably invalid. if
>> the output can't be redistribute directly then the presence or absence
>> of this feature shouldn't be an issue.
>
> But the point is that Gump does not only run on ASF machines.

but anyone who wishes can easily continue to use traditional gump. 
being open sourced, they can continue development of tradition gump (if 
they so wish). AIUI this vote is simply about discontinuing the 
official development of traditional gump and the switching of official 
ASF machines to use python gump: traditional gump is not being deleted, 
just the development officially discontinued.

>> i do agree that it would be good to make available distributions
>> created by gump but this may need to happen offshore. one approach
>> would be to ask ibiblio if they were willing to host unofficial daily
>> builds of ASF products created offshore. we'd then need to find a
>> volunteer willing to run an unofficial gump on a spare machine and 
>> push
>> the results to ibiblio. only when these measure were in place would 
>> the
>> ability to push the gump results to ibiblio be necessary.
>
> I take your point, but until Python Gump supports redistributable jars,
> hosting Gump offshore cannot happen with Python Gump.

they could easily be hosted offshore with traditional gump but unless 
some people step up and make the offshore builds happen, they won't. 
for me, this is the major obstacle and is independent of the decision 
to officially stop development of traditional gump.

there seems to be only limited development energy available for gump 
and IMHO it makes much more sense to recognize officially that this 
effort is being put entirely into python gump.

- robert


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


Mime
View raw message