Just a few comments to be taken as constructive feedback...

On 21/01/2012 1:51 PM, Konstantin Olchanski wrote:
> The first bum nfs-utils package was issued around December 6th. Then a fixed
> package was issued around December 14th with exactly the same name
> to better defeat the nightly yum updates. So every SL6.1 machine
> has to be repaired manually (yum reinstall nfs-utils).

This should be easily scriptable with remote ssh commands... Team that 
up with ssh keys and it should take no longer than 10 minutes to do this 
to an entire subnet of machines.

> When I try to understand what happened, I see no mention of this on
> the sl-users list (on which I subscribe), no mention of this in sl-announce
> and no mention of this on the sl-errata mailing lists. (sl-errata is where
> one would expect to see an announcement of released and retracted packages).

sl-devel seems to be where all the bug reports end up. It might be an 
idea to be subscribed to this list for future reference.

> Finally, on the sl-developers list I see the discussion and the notices
> about reissue and traction.

Yup - as above.

> Recommendations:
> - do not build and issue packages on the 6th of the month

I don't see what the date has to do with when updates are released? 
Unless you mean build and issue the packages on the same day? Even then, 
why not?

> - in the *next* release of the nfs-utils package, please include a cron job
>    to delete core dumps from "/", just in case.

Woah, wait a minute. I would think that this is something that really 
should not be done in the package. Yes, if your setup is affected, then 
you can do it manually, but making assumptions about other peoples 
environment is a Really Bad Thing. If your environment is affected, you 
can easily copy a file to /etc/cron.d or /etc/cron.hourly to take care 
of things.

> - remember to post a notice to sl-errata when you push something into
>    every SL machine out there.

I get where you are coming from here. I think the correct course of 
action should have been:
	1) Post link to test RPMs on mailing list and collect feedback.
	2) If issue is resolved, push the RPMs to sl-fastbugs
	3) If no issues reported in 7-14 days, push the package to sl-security.

This is my opinion of course, and others may disagree with it.

> What a way to run a ship.

You are always welcome to subscribe all your machines to RHEL licenses. 
This will give you an avenue to support and a direct feed to techs at RH 
to fix these issues for you. You benefit in this situation, and 
indirectly, all SL and CentOS users benefit too.

-- 
Steven Haigh

Email: [log in to unmask]
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299