Where is the new FC1 kernel which fixes the local DoS as described in http://linuxreviews.org/news/2004-06-11_kernel_crash/index.html ?

[Jeff Spaleta]

On Wed, 16 Jun 2004 12:57:07 -0400 (EDT), William Hooper
<whooperhsd3 at earthlink.net> wrote:
> That said, having the updates-testing in your sources list should be enough to let you > know there are new packages out.

You missed the point, there are people, competent testers, who do not
eat everything that comes down the testing pipeline and do NOT keep
the testing repo in their update tools as a matter of risk management.
And there are people who really really want to have some indication as
to what the new testing update is before they go to install it.  This
isn't a 'special' update and Dave pretty much that in his blog as
well. I expect similar best-practises to apply to ALL testing updates
that come down the wire. And that means producing a testing release
annoucement.

And its not completely a matter of informing the people who are
already looking for a fix to a specific problem. Its about informing
the competent testers, the people who know enough to actually do
competent troubleshooting and provide accurate bugreports about
regressions and problems in a timely manner. The people who read about
this in slashdot and are clamoring for a fix i doubt are those people.
In fact I'm pretty sure the competent testing volunteers have high
demands on their time, similar to the demands on the developers time.
Its important and vital that communication to the competent testers in
the community is used effectively.  Instead of a simple formalized
annoucement post that includes a changelog snippet and the md5sums and
the eta on release....the competent testers who aren't kneejerk
slashdot readers are going to have to cobble that information together
from a string of posts...its wasteful and its a good way to make sure
that the right people are NOT testing the packages.  Developer's
perogative to pick which communication medium is the prefered way to
reach testers... test-list is it. But developers still need to use
that medium effectively and make an effort to give relevant
information to testers in a succint and straight forward fashion. I
don't give a crap about people who already are aware of the bug via
laypress news aggregators like slashdot. What I care about is making
sure that competent testers know as succintly as possible all the
relevant information to form a baseline for testing for
regressions...for every package that comes down the wire.

>  And during release development we certainly don't need a message for every 
> package updated in rawhide

Am I talking about rawhide? No.....I'm talking about updates with the
intent to be pushed as released-updates. Rawhide has its own daily
communication mechanism via automated buildhost reports in
-devel-list.

> Communication is a good thing, but let's not get bent out of shape over one or two 
> missed announcements.

What your bar for getting bent out of shape?
What I'm bent out of shape about...is dave jone's comment in this thread:

"It'll move from updates/testing to updates proper today/tomorrow.
No-one seems to be screaming about the testing kernel, so either
no-one has tested it, or it's perfect 8)"

No-one seems to be screaming...because the competent people who know
enough to test for regressions didn't get told. Might as well just
stick the damn package directly into updates-released, and be done
with it. That will shut up the people screaming for a fix rather
nicely, without the token wait for people to test it. If the intent
was actually to wait and release this after a fair attempt to get
regression feedback..its wasted waiting, if there isn't an effort as a
matter of testing update policy to get an annoucement out. Expecting
feedback when no annoucement is made beforehand gets us nowhere.

-jef"off to poke a few other developer's in the eye about annoucement
messages"spaleta