> > 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.
I think this is what I need, but I'll continue below. > > 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 was merely trying to build upon your argument, stating that we can only really trust what we build, and we approve/release, and that Gump was just (in Leo's words) an automated developer. My argument was merely that we can't trust what users build, and Gump is just an automated user. > > 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 my answer -- they are NOT releases, they are however (unfortunately ... executable) artifacts. > > 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. Ok, good. > 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. How would you suggest that I raise the issue? I don't want to be opening a hole, so am glad to go along w/ ASF's decision. > 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. Perfect. > 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). Agreed. > >>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.] > > Very much agreed. Ok, I will look at this as part of Gump/Depot repository work. > 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. Ok, this is the process I asked about above. I'll wait and see what others say & then leave it to you. Thanks for your help. regards, Adam --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
