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: net...@crc.id.au
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299

Reply via email to