Re: legalities of jar publishing (was: Re: [VOTE] retire java gump)
> And what is the use of publishing jars that are built against the latest > jars ? My usage for them is for personal and/or cascaded Gumps. If the root Gumps build the public projects then I ought be able to NOT build them for my work Gumps. I'd like to keep current (no point Gumping, unless) so I'd want automated downloads of the latest Gump'ed jars. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: legalities of jar publishing (was: Re: [VOTE] retire java gump)
And what is the use of publishing jars that are built against the latest jars ? They will be useless in a real environment or even test environments and will probably not get any support from the project concerning. It simply is not a nightly build against the dependencies set by the project. Gump "just" points out to a project and it's dependencies when something bad is going to happen. It is looking ahead for us, where we programmers forgot to do that Log4J was a good example of this. So besides legal issues, I would never want a nightly build made by gump for my projects to be used by others, unless gump uses the exact versions for the dependencies I defined, but that defeats gumps main goal, as far as I am concerned. Mvgr, Martin On Mon, 2004-06-21 at 11:48, Leo Simons wrote: > Disclaimer: IANAL. > > IIRC There is no "board policy" about redistribution of materials by > gump. There is just concern, and the concern is not just with the board. > The Gump PMC is supposed to be protecting the legal interests of the ASF > wrt gump, and it is gump people who disabled jar distribution. I don't > remember any of the details, but here's a few things I do know: > > * the ASF only wants to distribute software written and owned by the > ASF > * the ASF licenses all of its software under the apache license, and > this must be true for all distributions published > * distribution of software by the ASF projects should be done by PMCs > or ASF officers, for legal protection > * the ASF has high standards about releases. We want to provide things > like MD5 files, gpg signatures, etc. Users need to trust that the > things the ASF distributes are high-quality, and for that to be true, > high quality must be consistent. > > * gump builds non-ASF-owned software under other licenses than the > apache license > * the gump pmc does not check the quality or validity of the outputs > of gump, nor take an active approach to publishing those results > * gump does not generate MD5 files, gpg signatures, etc > > From the above it should be clear that we're a bit reluctant about > publishing the jars gump produces! > > People have put in work to alleviate these concerns (the tag > is one example of that), but I'm not sure where we're at right now. > > Sure, third parties are free to use gump and publish those jars, and > they could do that using python gump. But that's not really what's > happening right now. I think the only host who still publishes jars is > covalent, and that is more like a shared hosting box that covalent loans > to the gump team than a seperate entity. So that repository is likely > going away, too. > > Python gump does generate the jar repository, and publishing it is a > rather trivial task (see http://nagoya.apache.org/jira/browse/GUMP-67). > The issue is not technical. > > > cheers, > > > - LSD > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
legalities of jar publishing (was: Re: [VOTE] retire java gump)
Disclaimer: IANAL. IIRC There is no "board policy" about redistribution of materials by gump. There is just concern, and the concern is not just with the board. The Gump PMC is supposed to be protecting the legal interests of the ASF wrt gump, and it is gump people who disabled jar distribution. I don't remember any of the details, but here's a few things I do know: * the ASF only wants to distribute software written and owned by the ASF * the ASF licenses all of its software under the apache license, and this must be true for all distributions published * distribution of software by the ASF projects should be done by PMCs or ASF officers, for legal protection * the ASF has high standards about releases. We want to provide things like MD5 files, gpg signatures, etc. Users need to trust that the things the ASF distributes are high-quality, and for that to be true, high quality must be consistent. * gump builds non-ASF-owned software under other licenses than the apache license * the gump pmc does not check the quality or validity of the outputs of gump, nor take an active approach to publishing those results * gump does not generate MD5 files, gpg signatures, etc From the above it should be clear that we're a bit reluctant about publishing the jars gump produces! People have put in work to alleviate these concerns (the tag is one example of that), but I'm not sure where we're at right now. Sure, third parties are free to use gump and publish those jars, and they could do that using python gump. But that's not really what's happening right now. I think the only host who still publishes jars is covalent, and that is more like a shared hosting box that covalent loans to the gump team than a seperate entity. So that repository is likely going away, too. Python gump does generate the jar repository, and publishing it is a rather trivial task (see http://nagoya.apache.org/jira/browse/GUMP-67). The issue is not technical. cheers, - LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] retire java gump
robert burrell donkin wrote: 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. I believe that individual administrators should be able to choose whether to allow downloading of the results from a gump build on a case-by-case basis and therefore that Python Gump should provide a mechanism to enable this. However, I strongly believe that Gump should remain a continuous integration tool and not try to become many things to many people. How about if Python Gump had an option (in a configuration file: on|off) to give the results of the build to a repository tool such as Apache Depot). This means that Depot gets to do all the hard work, all we have to do is work with the Depot guys to define the interface. Hmm, I think i've seen some of the Depot guys hang out here occasionally. ;) -- Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] retire java gump
On 20 Jun 2004, at 11:10, Sebastian Bazley wrote: - Original Message - From: "robert burrell donkin" <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] retire java gump
- Original Message - From: "robert burrell donkin" <[EMAIL PROTECTED]> To: "Gump code and data" <[EMAIL PROTECTED]> Sent: Sunday, June 20, 2004 10:01 AM Subject: Re: [VOTE] retire java gump > On 19 Jun 2004, at 22:49, Sebastian Bazley wrote: [...] > > The -1 was primarily intended to ensure that there would be continuing > > access to redistributable build outputs, which none of the Python Gump > > installations seem to offer at present. I'm not a -1 once that has been > > addressed; I just want to ensure continuity. > > am i right in thinking that by 'redistributable build outputs' you mean > the jar's etc that result from running gump? Yes > 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? > 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. > 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. Sebastian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] retire java gump
On 19 Jun 2004, at 22:49, Sebastian Bazley wrote: Sebastian, Any follow-up? I'd like to find a way to ensure/clarify that you aren't a -1. Sorry for the delay in replying. The -1 was primarily intended to ensure that there would be continuing access to redistributable build outputs, which none of the Python Gump installations seem to offer at present. I'm not a -1 once that has been addressed; I just want to ensure continuity. am i right in thinking that by 'redistributable build outputs' you mean the jar's etc that result from running gump? 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. 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. 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. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] retire java gump
- Original Message - From: "Adam R. B. Jack" <[EMAIL PROTECTED]> To: "Gump code and data" <[EMAIL PROTECTED]> Sent: Friday, June 18, 2004 2:49 PM Subject: Re: [VOTE] retire java gump > Sebastian, > > Any follow-up? I'd like to find a way to ensure/clarify that you aren't > a -1. Sorry for the delay in replying. The -1 was primarily intended to ensure that there would be continuing access to redistributable build outputs, which none of the Python Gump installations seem to offer at present. I'm not a -1 once that has been addressed; I just want to ensure continuity. It would also be nice if the following java Gump features were included in the Python version: - regex nags - continuous log output (I see this is being worked on) but neither of these is critical enough for a -1. My -0 was partly about diversity - different ways of building may throw up different compatibility issues - and partly about what happens to the java Gumps when the metadata changes and they stop producing much/any useful output. Again, these are not critical enough to warrant a -1. Hope that clarifies my position - if not, please ask. Sebastian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] retire java gump
Sebastian, Any follow-up? I'd like to find a way to ensure/clarify that you aren't a -1. regards Adam - Original Message - From: "Adam R. B. Jack" <[EMAIL PROTECTED]> To: "Gump code and data" <[EMAIL PROTECTED]> Sent: Wednesday, June 09, 2004 5:39 PM Subject: Re: [VOTE] retire java gump > > -0 (if that's allowed) > > > > But -1 if the proposal is to stop non-Python Gumps at present. > > I don't think anybody is intending the stop them, and I proposed a way to > let them continue to function (as we move Python out, into SVN, etc.) > > > > I'd suggest tagging CVS and making it clear that java gump may deviate > > > from documentation, etc but permit changes to the code. My main concern > > > > +1 > > Sadly the metadata is shared, and quite soon the by Python, not by Java) will destroy the value of the Java ones. It is > already happening, this jsut makes it official. > > > As far as I can see, the Python Gumps are currently in the minority, so it > > makes sense to allow the Java Gumps to continue. > > I'd love to know if that is true, or not. > > > The more, the merrier, as there's then more chance that the inevitable > > installation differences will help find subtle build problems. > > I thought that, but with one metadata base it is getting unmanageable. We > could fork the metadata (I think I proposed that). > > > Also, none of the Python Gumps seem to make any generated jars available, > > even if they are redistributable. > > They still create them (if redistributable) they just don't publish them. I > am working on that very thing. I'd 'guarantee it' if that would grant this > your +1. > > regards > > Adam > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: (CVS & SVN) Re: [VOTE] retire java gump
Adam R. B. Jack wrote: We could take the opportunity to: 1) Move Gump (Python) core to SVN 2) Move Gump Metadata to a separate CVS repository [to move to SVN one day in the future, when all ASF committer are "comfortable" w/ SVN]. We could leave the current repository as is, tagged but even CVS HEAD stable, for automated Gumps out there that depend upon things there. +1 My main concern at the moment is that python gump seems a /lot/ slower than java gump on my under-powered, over-worked Sun Ultra 5. On that machine a Java gump run would take in the order of 19 hours. I started a Python gump run on the 6th June at 2.33pm local time and it still isn't finished (as of the 8th June at 5.05pm). Performance has become my bugbear w/ this stuff. I just don't get the language well enough to be able to crack it. I've just completed another full gump run (same definition as the public gumps). I started the run at Thu Jun 10 08:16:23 WEST 2004 but Gump says the run started at Thu, 10 Jun 2004 08:23:40 (WEST), some 7 minutes later. Gump says the run finished at Sat, 12 Jun 2004 21:28:52 (WEST) but the process actually terminated at Sun Jun 13 02:26:12 WEST 2004, some 5 hours later. What was Gump doing during this time? I also tried gumping just ant, which took 4 hours. FWIIW: I find small (50 project) workspaces zip by, but large ones (500+) seem to creep. BTW: How many projects do you have in this workspace? What is the purpose of it? Do you "trim/tailor" the project sequence by passing "myproj*" project masks? BTW: Do you use forrest batch, or not forrest xdocs? I think I can answer that one by saying "I don't know - the default". Could you point me to some docs that describe how to set up the other? -- Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] retire java gump
> -0 (if that's allowed) > > But -1 if the proposal is to stop non-Python Gumps at present. I don't think anybody is intending the stop them, and I proposed a way to let them continue to function (as we move Python out, into SVN, etc.) > > I'd suggest tagging CVS and making it clear that java gump may deviate > > from documentation, etc but permit changes to the code. My main concern > > +1 Sadly the metadata is shared, and quite soon the As far as I can see, the Python Gumps are currently in the minority, so it > makes sense to allow the Java Gumps to continue. I'd love to know if that is true, or not. > The more, the merrier, as there's then more chance that the inevitable > installation differences will help find subtle build problems. I thought that, but with one metadata base it is getting unmanageable. We could fork the metadata (I think I proposed that). > Also, none of the Python Gumps seem to make any generated jars available, > even if they are redistributable. They still create them (if redistributable) they just don't publish them. I am working on that very thing. I'd 'guarantee it' if that would grant this your +1. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] retire java gump
- Original Message -
From: "Michael Davey" <[EMAIL PROTECTED]>
To: "Gump code and data" <[EMAIL PROTECTED]>
Sent: Tuesday, June 08, 2004 5:07 PM
Subject: Re: [VOTE] retire java gump
> Leo Simons wrote:
>
> > Hi gang!
> >
> > And now for something completely different...
> >
> > Saw both Adam and Stefan suggest this recently. I concur. Let's retire
> > ("kill off" sounds way to harsh for this faithful servant!) the java
> > version of gump. The python one is now superior in most ways, and Adam
> > keeps getting a headache keeping all the undocumented awkwardness in
> > sync!
>
> +0.
-0 (if that's allowed)
But -1 if the proposal is to stop non-Python Gumps at present.
>
> I'd suggest tagging CVS and making it clear that java gump may deviate
> from documentation, etc but permit changes to the code. My main concern
+1
As far as I can see, the Python Gumps are currently in the minority, so it
makes sense to allow the Java Gumps to continue.
The more, the merrier, as there's then more chance that the inevitable
installation differences will help find subtle build problems.
Also, none of the Python Gumps seem to make any generated jars available,
even if they are redistributable.
S.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] retire java gump
Stefan Bodewig wrote: +1 I'd rather try to find the time to understand Gumpy in order to implement the things missing (javadoc for example). Playing catch-up with Gumpy isn't fun and nothing should stop Gumpy to go into ways that Java Gump won't follow fast enough. +1 -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [VOTE] retire java gump
+1 I'd rather try to find the time to understand Gumpy in order to implement the things missing (javadoc for example). Playing catch-up with Gumpy isn't fun and nothing should stop Gumpy to go into ways that Java Gump won't follow fast enough. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] retire java gump
+1 for stopping maintenance on and running java gump.
Mvgr,
Martin
On Tue, 2004-06-08 at 17:25, Leo Simons wrote:
> Hi gang!
>
> And now for something completely different...
>
> Saw both Adam and Stefan suggest this recently. I concur. Let's retire
> ("kill off" sounds way to harsh for this faithful servant!) the java
> version of gump. The python one is now superior in most ways, and Adam
> keeps getting a headache keeping all the undocumented awkwardness in sync!
>
> +1 from me.
>
> - LSD
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
Mvgr,
Martin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
(CVS & SVN) Re: [VOTE] retire java gump
> I'd suggest tagging CVS and making it clear that java gump may deviate > from documentation, etc but permit changes to the code. We could take the opportunity to: 1) Move Gump (Python) core to SVN 2) Move Gump Metadata to a separate CVS repository [to move to SVN one day in the future, when all ASF committer are "comfortable" w/ SVN]. We could leave the current repository as is, tagged but even CVS HEAD stable, for automated Gumps out there that depend upon things there. > My main concern > at the moment is that python gump seems a /lot/ slower than java gump on > my under-powered, over-worked Sun Ultra 5. On that machine a Java gump > run would take in the order of 19 hours. I started a Python gump run on > the 6th June at 2.33pm local time and it still isn't finished (as of the > 8th June at 5.05pm). Performance has become my bugbear w/ this stuff. I just don't get the language well enough to be able to crack it. I've done profiling, GC inspection, reference inspection, and I don't get it. Some things do grow (although I can see no leak) but I can't imagine that too much memory is consumed. I have work to do here. [BTW: The branch I currently have has a lot of __del__ work done, to try to ensure no circular references. Python seems to really need help with those.] FWIIW: I find small (50 project) workspaces zip by, but large ones (500+) seem to creep. BTW: How many projects do you have in this workspace? What is the purpose of it? Do you "trim/tailor" the project sequence by passing "myproj*" project masks? BTW: Do you use forrest batch, or not forrest xdocs? regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] retire java gump
Leo Simons wrote:
Hi gang!
And now for something completely different...
Saw both Adam and Stefan suggest this recently. I concur. Let's retire
("kill off" sounds way to harsh for this faithful servant!) the java
version of gump. The python one is now superior in most ways, and Adam
keeps getting a headache keeping all the undocumented awkwardness in
sync!
+0.
I'd suggest tagging CVS and making it clear that java gump may deviate
from documentation, etc but permit changes to the code. My main concern
at the moment is that python gump seems a /lot/ slower than java gump on
my under-powered, over-worked Sun Ultra 5. On that machine a Java gump
run would take in the order of 19 hours. I started a Python gump run on
the 6th June at 2.33pm local time and it still isn't finished (as of the
8th June at 5.05pm).
--
Michael
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] retire java gump
> Let's retire the java version of gump. +1. And with thanks for the years of service... regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] retire java gump
Leo Simons wrote:
...
Saw both Adam and Stefan suggest this recently. I concur. Let's retire
("kill off" sounds way to harsh for this faithful servant!) the java
version of gump.
+1
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] retire java gump
+1 from me.
On Tue, 08 Jun 2004 17:25:23 +0200, Leo Simons <[EMAIL PROTECTED]> wrote:
>
> Hi gang!
>
> And now for something completely different...
>
> Saw both Adam and Stefan suggest this recently. I concur. Let's retire
> ("kill off" sounds way to harsh for this faithful servant!) the java
> version of gump. The python one is now superior in most ways, and Adam
> keeps getting a headache keeping all the undocumented awkwardness in sync!
>
> +1 from me.
>
> - LSD
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] retire java gump
Hi gang!
And now for something completely different...
Saw both Adam and Stefan suggest this recently. I concur. Let's retire
("kill off" sounds way to harsh for this faithful servant!) the java
version of gump. The python one is now superior in most ways, and Adam
keeps getting a headache keeping all the undocumented awkwardness in sync!
+1 from me.
- LSD
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
