We announced this before, but we didn't have time to make it
happen. The VDT mailing lists will be moving as of Friday, September
29, 2006. We have to mailing lists, both will change:
firstname.lastname@example.org will change to email@example.com
firstname.lastname@example.org will change to email@example.com
For a few months, we will forward from the old email addresses to the new ones, then we will cut them off.
We will send an announcement on Friday the 29th to let people know that the change has been made.
We are tentatively changing our VDT software release policy. The policy on our web site is basically similar to others, including Condor and Globus: stable and development releases, and new features only go into development releases. You can read it online.
We will not change our basic release strategy, but we will change the details.
We will have a stable series and a development series The stable series has even numbers (1.2, 1.4, 1.6...) The development series has odd numbers (1.3, 1.5, 1.7...)
We recognize that our recent releases that have been labelled as development are really stable releases. We test them quite thoroughly, and with the addition of the validation testbed, they can certainly be labelled as a stable release.
So the release we are calling 1.3.12 will now be 1.4.0.
(Actually, it might be 1.6.0: I am likely to release VDT 1.3.11 as 1.4.0, so that it can be on the ITB. I've made some bug fixes anyway, so it's a good idea.)
We will do more development releases, but they will be much less tested than our current development series. We will not ensure that all tests pass on all platforms. We will release when we want to make something available. For example, if we believe that BDII is ready to be tested on most of out platforms, we will release a new development release even if some components are not yet solid. The development releases will be low cost to release.
A stable release will still have our one week minimum of testing, including testing on the OSG validation testbed.
We will drop our requirement that a new component must be in a development release before it is in a stable release. However, major changes will cause increase the release number. If we add a new package after 1.4.0, it will be in 1.6.0, not 1.4.1.
One result: Version numbers will increase much more quickly.
OSG Validation Test Bed may test development releases. The OSG Integration Test Bed will test stable releases.
We're thinking of being able to add new components to an existing version by labelling them as unsupported. We can do this after release. This lets us try out a new component within an existing release without waiting for a new major release.
We'll do this with an explicit label. For example, if we add RGMA to VDT 1.4.0, we'll call the package Unsup-RGMA, and we'll warn the user that the package might change at any time, without warning. (Exact details may be different: perhaps we'll have an extra cache instead of labelling it as Unsup.)
In order to support interoperability with LCG, we are likely to add some site functional tests to the VDT. Rob Quick said that he is preparing a list of exactly what is needed.
Rob Quick, Leigh, and Alain talked a bit about coordination on tickets. For some tickets from the GOC, the VDT hasn't been getting enough of a description, and attachments are not always forwarded. We'll work on improving the situation.
Burt asked about a particular care where an error on a remote cluster doesn't get propagated back to Condor-G directly (it is reported as a stage-out error instead of a job killed error). Alain talked about the difficulty of error propagation in general, and encouraged Burt to contact the Condor team directly, copying Alain on the email, to see what we can do.