BEWARE: a problematic glibc made it to stable (F16)
mmaslano at redhat.com
Mon Oct 24 07:59:50 UTC 2011
On 10/24/2011 02:47 AM, Henrik Nordström wrote:
> sön 2011-10-23 klockan 17:04 -0500 skrev Rex Dieter:
>> The fail(*), imo, was with 12.999 going stable containing known-regressions.
>> So, any suggestions, if any, to prevent any similar series of events?
> My suggestions:
> Disable automatic push to stable when there is any negative karma,
> requiring the package maintainer to initiate the push even if karma
> kriteria have been met.
> Don't automatically push to stable until at least X days (3?) have
> passed, enabling sufficient time for regressions to be detected. Package
> maintainer can initiate push earlier by "Push to stable" if needed and
> confident there is no regressions.
> Make "push to stable" require extra confirmation when there is negative
> karma, making sure that whoever is initiating the push have actually
> looked at why there is negative karma.
I don't think that any policy, which was introduced to prevent broken
glibc updates helped. glibc can broke many packages, so it's perfect
candidate for automatic tests, which should include even rebuilds.
I wouldn't punish other people who test their packages properly or even
wrote a test suite.
More information about the devel