gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam R. B. Jack" <>
Subject Re: legalities of jar publishing
Date Tue, 13 Jul 2004 20:06:04 GMT
Stefano wrote:

> NOTE: board hat off.


BTW: I've been quiet on this 'til now 'cos it is now that I need to get past
this (if possible) again, so I can extend functionality.

> If a nightly build is a release, then it is a svn|cvs checkout and if
> you want the PMC to approve any checkout, we clearly kill our ability to
> scale.

Seems a key point to me. So can we say that these artifacts are NOT
considered release?

Note: I am not trying to split hairs, I am trying to understand "the line".

> I agree with Leo that the problem of jar distribution is absolutely not
> technical, it's legal and security. Gump executes code downloaded from
> repositories that the ASF doesn't consider legally trustful.
> say I was the author of a weird library that some weird commons code
> depended on, it is entirely possible to write a task in a build.xml file
> that recompiles a class in tomcat and opens a back door, it might take a
> while to notice.

Interesting. Yes, I see that. Hmm, say one creates a bogus jars that
(perhaps) overrides or subverts some Ant task, and hence local (by user)
builds of tomcat now have such back door. Surely ASF isn't liable there, and
surely CVS|SVN isn't something to shut off (allowing only releases we sign).
Hmm, also, what is a committer is tricked into submitting a bogus jar into
CVS, so home done builds are again not trustworthy.  Surely we are primarily
responsible for things we label as releases.

I'm not trying to stretch, but I'm asking -- if we are 100% clear that these
are untrustworthy, and NOT releases, could we do this? [See why below]

> Releasing executable artifacts by gump will have my permanent -1
> *FOREVER*. The way gump works is intrinsically unsafe, but this is not a
> problem if what gump is producing is "metadata" about code, not
> executable code directly.

Yes, that is true. So, are these releases?

I have a serious problem if we can't do this. I wish to deploy cascaded
Gumps, Gumps that download the 'latest Gumped jar' from other Gumps. The
purpose of these jars is almost metadata, it is a compile/run interface so
the downstream Gumps do not have to replicate cycle & can focus on their own
work. If we can't allow these artifacts to be downloaded (even by other
Gumps) we can scale nicely like this.

> As for making gump both a nightly build and a continuous integration
> system, I think projects should be allowed to specify their "preferred"
> checkout tag of any dependency, that would allow gump to be *way* more
> useful.

I could look at this w/ a repository of built releases. Things would scale a
lot better if I could download those previously built. :-) [That said, we
can do that from a repo of releases.]



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message