Adam R. B. Jack wrote:
Stefano wrote:
NOTE: board hat off.
Noted.
NOTE: board hat continously off unless explicitly stated. (I do this because I use the same email address for all apache communication and that might create problems understanding which hat I'm wearing)
apologies if this seems like splitting hair, but I've been flamed in the past for having mis-contextualized my comments so I'm overly cautious ;-)
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.
OK.
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?
I would say so, yes. Gump creates artifacts that should *NOT* be considered released and officially endorsed by the ASF, any use of those artifacts, if made available, should come with a big WARNING label that should discouradge people from using them in any requirements where trust is an issue.
Note: I am not trying to split hairs, I am trying to understand "the line".
No problem.
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 sorry, I'm not sure I follow you here 100%, could you please elaborate more. This is a critical issue and I don't want to misunderstand you.
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?
what releases? I'm sorry, I can't contextualize what you're saying :-/
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 I said, I have no problem in *making artifacts available* for download as long as they have WARNING signs all over the place.
NOTE: again, this is just my personal opinion, the board will have the final say on this matter and I don't know their opinion on this since it was never discussed.
So, as long as those jars are available, you can let other gumps download them. This is a perfect example of a need for such jars that is just used as a "preparatory artifact" for the generation of some other metadata.
As long as these jars are not officially supported, branded, signed and released by the foundation, I see no problem in allowing them to be made available.
What I have a problem in using gump as an automatic build system that will generate jars that will be released officially by the foundation. That, IMO, will never be acceptable, unless gump stops building projects that the foundation doesn't control (which would be a severe limitation of gump functionalities).
I could look at this w/ a repository of built releases. Things would scale aAs 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.
lot better if I could download those previously built. :-) [That said, we
can do that from a repo of releases.]
Very much agreed.
I would like to hear comments from others and when we reach consensus I can run this thru the board and see what they think.
-- Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
