geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From siss...@insession.com
Subject Re: M4 - QA Branch details
Date Mon, 11 Jul 2005 23:53:25 GMT
"Geir Magnusson Jr." <geirm@apache.org> wrote on 12/07/2005 08:46:53 AM:

> 
> On Jul 11, 2005, at 3:24 PM, Alan D. Cabrera wrote:
> 
> > Geir Magnusson Jr. wrote, On 7/11/2005 5:39 AM:
> >
> >
> >>
> >> On Jul 11, 2005, at 7:46 AM, Jacek Laskowski wrote:
> >>
> >>
> >>> sissonj@insession.com wrote:
> >>>
> >>>
> >>>
> >>>>  Can't we resolve the SNAPSHOTs issue by modifying the branch 
> >>>> before releasing and at least using dated jar files if we can't 
> >>>> move to a formal release of a dependency?
> >>>>
> >>>>
> >>>
> >>> How could we use the dated jar files? Do they have to be 
> >>> released  by respective projects or can we do it ourselves?
> >>>
> >>
> >>
> >> They have to be released by respective projects.
> >>
> >
> > 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.  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.

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?

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

Here is a (hopefully not too stupid) analogy.. 
If you buy a car and the brakes fail, would you be happy if the car 
company said you had the choice of:
a) to wait until the revised brake components come off one of their 
supplier's production lines and they don't know when that is? The car 
company cannot expect the production line to tool up immediately just for 
them because they are already committed to manufacturing other models of 
components for other manufacturers (waiting for a formal version of a 
dependency).
b) use some brake components they found lying around at the factory.  They 
aren't sure when they were made and what revisions may have been made to 
their design since and what problems they may have had in their design 
(SNAPSHOTs)
c) A technician from the car company takes your brakes and makes some 
small modifications to rectify the problem and puts the car through the 
standard brake tests and has documented information on what they did 
(versioned SNAPSHOTs)

I think this is a serious issue and we need to discuss how this is going 
to be addressed going forward.

Thanks,

John

> 
> Just my 0.02 :)
> 
> geir
> 
> 
> -- 
> Geir Magnusson Jr                                  +1-203-665-6437
> geirm@apache.org
> 
> 

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.

Mime
View raw message