On Jul 11, 2005, at 7:53 PM, [EMAIL PROTECTED] wrote:
"Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote on 12/07/2005
08:46:53 AM:
On Jul 11, 2005, at 3:24 PM, Alan D. Cabrera wrote:
Not technically true. We can generate our own snapshots, e.g.
outside-project-GERONIMO-200507111432.jar
The problem is that there are a *ton* of projects that we use.
I think this is a bad idea. We would be in effect publishing/
distributing software that
a) isn't ours in that we have no real clue over the provenance and
b) isn't something we'd want to see done to us.
I mean, would you like to see geronimo-kernel-
jboss-200507111423.jar? Or have to deal with questions about
stacktraces and behavior that we just can't understand because it
comes from code that really isn't ours?
Yes I would prefer that to the current situation of using SNAPSHOTs.
I think that we're all in agreement to dump the snapshots. And I'm
not arguing against using datestamped releases of things if they come
from the source project - I find that *vastly* preferable to
SNAPSHOTS as long as the source of that dated thingy is recorded
somewhere.
What I'm arguing against is the Geronimo project creating de facto
releases of other projects code for a bunch of reasons, including
that we'd never tolerated it being done by others.
Just
say a user does send us a stack trace.. If they are using
SNAPSHOTs, how
do we know what day/time their SNAPSHOT was taken? How do we go about
reproducing their problem considering that if we try to rebuild
Geronimo
to match their environment we will most likely end up with something
different, since some of the SNAPSHOT dependencies have been updated
since.
Right. Agreed. No SNAPSHOTS.
But for what I was arguing, take it a step further - that the user is
using a gernonimo-kernel jar produces by some *other* project, with
code that's not even in our SVN. Forget the date time - you could
search forever and *never* find the code that could produce the
stacktrace :)
That's what we could potentially be doing to other projects if we
release their stuff with patches, for example.
Something I haven't considered is what if the SNAPSHOTs we are
depending
upon are also depending upon SNAPSHOTs. Looks like we need to dump
the
whole tree of dependencies and identify where the SNAPSHOTs are?
Yes! Get rid of all snapshots in anything we distribute as a release
of any sort.
Now, I realize that we are really close to some projects (like have
100% committer overlap) so you might say that we do have a clue, but
I wouldn't want to set the practice, if we are so close then why not
just do it 'there', etc
When we create software for distribution, which is exactly what we'd
be doing here, we are making a statement that this software conforms
to the ASF process for IP provenance, oversight, etc...
How are we going to deal with the situation where just before a
release or
after a release a serious bug is found where changes are needed to
be made
to a dependency. Users are not going to accept "Oh, we can't ship
a new
release until dependency x fixes the problem and ships a formal
release,
which may be a week or it may be a year".
Well, that's true - but we're not facing that kind of emergency
situation here. And if dependency X takes a year, and this is a
major dependency of ours, I'd vote to just get a copy of the source
and keep going with that.... :)
I hope we never face this.
geir
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
