geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: M4 - QA Branch details
Date Tue, 12 Jul 2005 03:07:14 GMT
"Geir Magnusson Jr." <> wrote on 12/07/2005 10:21:24 AM:

> >>
> >> 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.

It seems that there is no practical way of removing all SNAPSHOTs (without 
having our own specially built "temporary" versions).  For example, I sent 
a mail to the cglib dev list asking them to post their latest version to 
the maven repo and I haven't got a response in approx 2 weeks.  Maybe they 
are busy or maybe they are on holidays.  My point is that I don't think it 
is always going to be possible to get a project (that isn't one of the 
projects we are tight with) to build a special version for us when we want 

It appears we have already been building defacto releases of external 
libraries, e.g. the cglib library in our repo:

Maybe a compromise is to properly document in the release notes any 
special versions of code we have with the following information:

* Have a disclaimer stating that a special version of the library is being 
used temporarily and we plan on moving to the a formal release of the 
library as soon as possible.  Maybe mention there could be a 'chance' of 
compatibility issues when we move to the formal version?
* A description of why a special version of a library is needed and what 
the library is used by
* The version of the code that was patched
* A link/reference to the bug/issue tracking records for the problem with 
the library and the patch(s) that were submitted to the external project.

Users would appreciate the openness and can then make their own decision 
on whether they are willing to run their systems on the software. They 
aren't given that information at the moment.

If users want to report a problem with a library to an external library 
project, they are going to be asked what version they are using and they 
should see from our documentation (or by the name of the JAR in the 
repository) that it is a special version. 

> > 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.

Are you suggesting in the M4 release?

> >
> >
> >>
> >> 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


This e-mail message and any attachments may contain confidential, 
proprietary or non-public information.  This information is intended 
solely for the designated recipient(s).  If an addressing or transmission 
error has misdirected this e-mail, please notify the sender immediately 
and destroy this e-mail.  Any review, dissemination, use or reliance upon 
this information by unintended recipients is prohibited.  Any opinions 
expressed in this e-mail are those of the author personally.

View raw message