Dear Grid-friends,

to make a long story short:

The discussion about the level of testing and the availability of
packages for 2.3.1 missed the real issue.

I hope that I can clarify this a bit:

The release of  2.3.1 was motivated by several security  patches.

When we prepared the release we got carried away and added a few other
packages that have been sought after by the experiments since quite
some time.
By this we diluted the concept of a security release and slowed  down
the release process. (A clear mistake)
The only non security related component that we should have added was
the patched version of the YAIM scripts (to release config scripts that
destroy the
config on the sites makes not much sense in a situation where fixed
version exist and are already in use).

What we learned from this mistake is the following:

Security releases have to be handled different than standard releases

- The security patches can only contain the minimal number of new RPMs
and a description of the config changes needed.
- Testing has to be reduced to speed up the process
- The patched versions of the software are allowed to provide new
functionality only if the back porting of a patch is too expensive
- The security release has to be handled like an upgrade, it will
always be based on a version in production and can't be used as a
self-contained release.
                This means a site has to install first 2.3.0  and then follow the
instructions of the latest  upgrades to 2.3.x

I am very sorry for all the confusion and disappointment  that I
created by the last  (pseudo)-security release and hope that we will do
this in a smoother way in the future.

Since the ability to deploy security patches quickly is essential to
manage security in egee, we should consider to include this in one of
the next  security service challenges.

               markus

p.s. Some of  the contributions to the discussions that followed the
release had been in tone and contents at a level that can be called
de-motivational.
        For new staff, not aware of the culture of this project, and not
knowing the actors personally,  the  communication style on several of
the LCG lists appears sometimes more hostile than appropriate. The
resulting friction inside the project doesn't help to move the project
forward.  It is absolutely not my intention to mute criticism, but we
should try to voice our concerns in a less confrontational way.








On Mar 19, 2005, at 2:42 PM, Gordon, JC (John) wrote:

> Maarten, your argument doesn't really hold up. A better APEL release
> has
> been available since about the time 2_3_0 was released and has been
> used
> in production by lots of sites although not in the release so it has
> actually had better testing than the version in the release. Since the
> version in 230 is buggy and is replaced manually immediately after
> installation it would have made sense to include a later release in
> 231.
> I didn't expect this since 231 is a 'security release' but it seems it
> isn't really:-(
>
> John
>
>> -----Original Message-----
>> From: LHC Computer Grid - Rollout
>> [mailto:[log in to unmask]] On Behalf Of Maarten
>> Litmaath, CERN
>> Sent: 17 March 2005 22:05
>> To: [log in to unmask]
>> Subject: Re: [LCG-ROLLOUT] rgma going mad on 2.3.1
>>
>> On Mon, 14 Mar 2005, Burke, S (Stephen) wrote:
>>
>>> LHC Computer Grid - Rollout
>>>> [mailto:[log in to unmask]] On Behalf Of Mario
>> David said:
>>>> Of course my question which will remain "unanswered" for
>> sure is Why
>>>> LCG2.3.1 does not have this version??
>>
>> Because the RH7.3 rpms for that version were received only
>> shortly before we decided what to put into the release.
>> There was no time to test them, and we did not want to risk
>> making things even worse.
>>
>>> Proably because it was just supposed to be a security patch
>> release (I
>>> think the APEL version in the release is also well out of date). Of
>>> course, that didn't stop the lcg-* changes being introduced, even
>>> though some things may be broken because they aren't fully backward
>>> compatible ... it seems that CERN products get special treatment
>>> compared with UK products!
>>
>> No.  The lcg-utils simply had been tested during many weeks
>> (+) and did not require any configuration changes.  Their
>> improvements were long overdue, so we decided we might as
>> well lump them in.
>>
>> (+) With the certification test suite; unfortunately that did
>> not catch
>>     the lcg-del bug exposed by the SFT.
>>
>
>

************************************************************************
*******
Markus Schulz
CERN IT