geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <>
Subject Re: M4 - QA Branch details
Date Tue, 12 Jul 2005 00:21:24 GMT

On Jul 11, 2005, at 7:53 PM, wrote:

> "Geir Magnusson Jr." <> 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  

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 Magnusson Jr                                  +1-203-665-6437

View raw message