XROOTD-L Archives

Support use of xrootd by HEP experiments

XROOTD-L@LISTSERV.SLAC.STANFORD.EDU

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Peter Elmer <[log in to unmask]>
Date:
18 Feb 2005 14:18:07 +0100Fri, 18 Feb 2005 14:18:07 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (141 lines)
  Hi Andy,

On Fri, Feb 18, 2005 at 05:14:32AM -0800, Andrew Hanushevsky wrote:
> Oh yeah, one more thing. It seems that the source directories for versions
> we are running in production have been deleted. That makes it very
> difficult to use dbx. Any chance of restoring those or just throw in the
> towel and press on in getting to new releases.

  These can obviously be restored. You should be able to check out the
source code for that version anywhere and point dbx at it.

  But I agree that we should so some basic system tests and push the latest
version out onto the production system at SLAC and elsewhere when they like.

                                   Pete
  

> On Fri, 18 Feb 2005, Peter Elmer wrote:
> 
> >   Hi Heinz and Andy,
> >
> >   Nothing like release/version management to pull everyone into the discussion!
> >
> >   Heinz, I'm not sure what this has to do with tagging. Note that the server
> > itself contains the version string, so I don't think "retagging" is an option.
> > Doing another build with a new tag to indicate that it had extra system testing
> > seems like overkill.
> >
> >   If it helps I can try to find a small gif of a skull and crossbones (or
> > similar) and we can label the versions as:
> >
> >    untested development version, developers only! (skull-and-crossbones)
> >    tested development version, developers only!
> >    production version
> >
> > or something equally scary looking. People who blur the lines between these
> > things probably just blur everything anyway.
> >
> >   Heinz, the reason we are so insistent on even test versions having a
> > specific version number is that the test versions seem to propagate
> > onto production systems. This used to happen all the time with the, uh,
> > simplified versioning scheme used for the AMS ({pro,old,new} IIRC) and
> > we had tremendous problems operationally trying to figure what was going
> > on after the fact.
> >
> >   Note that >real content< to this discussion will be discussing how to
> > do a basic system functionality test that is well automated and (perhaps)
> > site-independent.
> >
> >                                    Pete
> >
> > On Fri, Feb 18, 2005 at 01:03:55PM +0100, Heinz Stockinger wrote:
> > > I agree with Andy on that. One can even tag such to-be-tested releases
> > > differently so that only developers take them. Once they've been through
> > > the testing phase, they can be retagged or fixed.
> > >
> > > Cheers,
> > > Heinz
> > >
> > > Andrew Hanushevsky schrieb:
> > >
> > > >Hi Pete,
> > > >
> > > >What you say is good but the problem is that the rest of the world blurs
> > > >the line between development releases and production releases. My druthers
> > > >is that development releases never get to the web page. Only tested
> > > >releases should make it to the web page. To simplify things, at most two
> > > >or three (though that's probably too much) production releases should be
> > > >available via the web.
> > > >
> > > >Andy
> > > >
> > > >On Fri, 18 Feb 2005, Peter Elmer wrote:
> > > >
> > > >
> > > >
> > > >> Hi Andy,
> > > >>
> > > >>On Fri, Feb 18, 2005 at 02:32:15AM -0800, Andrew Hanushevsky wrote:
> > > >>
> > > >>
> > > >>>All of this points out to a packaging problem we have. The only way we
> > > >>>really test releases is to create what we call a development release.
> > > >>>That,
> > > >>>unfortunately, makes it available to everyone else -- even before we can
> > > >>>certify it as being materially correct. I do know we've had some
> > > >>>development releases that should have never seen the light of day, but
> > > >>>unfortuantely the process lets them out. We are trying to get a new
> > > >>>process in to place that will *never* cut a release unless we know that
> > > >>>it
> > > >>>will actually work on a reasonablly sized system.
> > > >>>
> > > >>>
> > > >> Releasing something as a "development" release for testing is independent
> > > >>from demonstrating that there are no bugs which prevent it from working
> > > >>on some canonical testbed system. (And this has nothing to do with
> > > >>packaging, either.)
> > > >>
> > > >> The thing we can add here is obtain and use the requested small testbed
> > > >> at
> > > >>SLAC plus define some set of standard functionality tests which are done
> > > >>on the development releases. The fact that we do or don't do such tests
> > > >>shouldn't however prevent the release of clearly labeled "development"
> > > >>versions to get feedback in the open-source sense. This will in any case
> > > >>be necessary as the testbed system by definition cannot test all of the
> > > >>configurations people might use out in the world.
> > > >>
> > > >> To summarize, what I would like to see happen is:
> > > >>
> > > >>  1) we develop a set of basic (and relatively automated) system
> > > >>     functionality tests
> > > >>  2) development releases are made as they are now
> > > >>  3) when each development release comes out, we use the system
> > > >>     functionality tests on the testbed at SLAC (and perhaps post the
> > > >>     results as a followup to the release announcement)
> > > >>
> > > >> This implies that #3 is easy to do, of course. In the open source style,
> > > >>people can wait for #3 to happen or not before trying to use it.
> > > >>
> > > >> How does that sound?
> > > >>
> > > >>                                  Pete
> > > >>
> >
> >
> >
> > -------------------------------------------------------------------------
> > Peter Elmer     E-mail: [log in to unmask]      Phone: +41 (22) 767-4644
> > Address: CERN Division PPE, Bat. 32 2C-14, CH-1211 Geneva 23, Switzerland
> > -------------------------------------------------------------------------
> >



-------------------------------------------------------------------------
Peter Elmer     E-mail: [log in to unmask]      Phone: +41 (22) 767-4644
Address: CERN Division PPE, Bat. 32 2C-14, CH-1211 Geneva 23, Switzerland
-------------------------------------------------------------------------



ATOM RSS1 RSS2