On Wed, 16 Jun 2004 12:57:07 -0400 (EDT), William Hooper <whooperhsd3@xxxxxxxxxxxxx> 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
