[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: infrastructure modest proposal

On Fri, Dec 12, 2008 at 11:17 AM, Kevin Martin <kevintm ameritech net> wrote:
> It sounds as if I touched a nerve here and, if so, I apologize.  I was
> simply trying to point out an "industry practice" that makes some
> sense.  That being said:

No apologize necessary... I'm just laying it out for you. This is a
community effort. If we need to enhance update QA, the solution is
going to have to involve more community contributors working on the
problem. There is no way around it.  But some thought has already gone
into the structure being used. Users may not be aware of Koji, but its
there, and maintainers and developers use it to cut update packages.

I use koji's scratch ability, I don't throw updates out to the repos
without testing them for myself. But I also don't have to deal with
serious security vulnerabilities for the packages that I maintain...so
I don't have the same pressures that more critical component
maintainers have so I'm not going to go out of my way to pontificate
on their workflow.

> I could be convinced to help implement more "automated testing" if I
> understood what that meant.

It's going to mean writing code which can be run to test specific
functionality for a given package.

> The argument of getting "critical" and security fixes out in a timely
> fashion seems valid but it's apparent that, in this case, testing of the
> "fix" would have gone a long way in preventing the issue at hand from
> occuring (and should these fixes *really* not be QA'd at all?

A mistake was made with this package. No one is denying that.  But the
unanswered question is, other than deliberately refusing to allow
security updates to be rushed how do we reduce the risk of that
mistake from happening again?  How important is security to you?  Are
you fine with holding up ALL security updates for a few days to offset
the risk of this sort of thing from happening again? I don't think I
could support that. And since I'm not a security expert I can't say I
would do a good job of vetting individual security updates to know
whether or not they need to be rushed or not. And even that vetting
would be an additional delay for all security updates.

> No, I don't have updates-testing enabled since my only Fedora box is my
> production laptop that I use for work (and continues to run F8 as a
> result until F10 is stable) *and* personal use...if this had occured on
> this laptop I would have been royally f*d!

Its a community project. If we want better QA we have to step up and
be a part of that effort.

I have updates-testing enabled on my day-to-day work laptop. I turn on
package caching in yum so I can revert to an older update something
goes very very wrong. This allows me to test and give me a safety net
to work from for most breakage scenarios. Worst case rpm no longer
works and I have to use rescue mode from media to back out the rpm
update.  I purge the cache based on package age.

I update the laptop either at the beginning of the day or at the end,
depending on my schedule to give me time to revert breakage and report
if I notice any. That is what I do.
I do a bad job of noticing breakage however as my day-to-day workload
involves very few things beyond python scripts, a terminal, ssh and a
web browser.

> Again, I'm not trying to criticize the work done by the Fedora
> developers/maintainers et. al.  I'm simply saying that, possibly, better
> procedures may have stopped this from happening in the first place.

I'm all ears. What are specific procedure recommendations which would
have prevented this mistake? It was a valid security update  and it
was mistakenly pushed to stable instead of testing. What could have
been done differently? And how would that policy change impact all the
other valid time-critical security updates?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]