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