gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam R. B. Jack" <aj...@trysybase.com>
Subject Re: legalities of jar publishing
Date Tue, 13 Jul 2004 20:48:12 GMT
> > 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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Mime
View raw message