On 02/26/2010 08:52 PM, Kevin Kofler wrote: > Adam Jackson wrote: >> By my count, that's three misrepresentations in one paragraph. I >> certainly hope they were not deliberate. > > I'm not deliberately misrepresenting anything or anyone, I just stated my > perception of the facts. It may well be that I missed some details in the > hectic and chaotic discussion. > >> A more parsimonious explanation is that Matthew's simply been busy the >> last few days and hasn't gotten around to it yet. Again, this may or >> may not be true, but Occam's Razor suggests it's more likely. > > The problem is, when will it be ready? If it's ready on Tuesday afternoon > and the vote gets done on Tuesday evening, that's too short a notice to > gather appropriate feedback. Do you seriously not understand how FESCo works? If it's not ready by tomorrow when we discuss it, we'll delay discussion again, since that's the only practical thing to do. >> You create package A. Someone else has created package B, with a >> triggerin script on A, unbeknownst to you, and you don't have B >> installed. Your testing of A will not reflect the experience of anyone >> with B installed. B's triggerin script might rm -rf /, for example. > > Uh, why do we even allow triggers without explicit FESCo approval (including > notification to the maintainers of the packages being triggered on)? They're > much more dangerous than linking a static library or bundling a library! Other corner cases where your case was wrong include new packages that Obsolete existing packages. >> "Slipping through testing" is itself the problem. It means that testers >> aren't using testing! We should fix the technical and UX problems that >> make testing hard to consume. > > Even if you fix all the fixable problems, testing will still not be a silver > bullet! Nobody is saying that it is! Merely that it's better than not having testing! >> If I had a dollar for every obviously correct one-line fix that broke >> something, I could probably quit this software game. > > X11 is particularly dangerous for this kind of changes, given how low it is > in the software stack and how some code necessarily looks like (hardware > drivers in particular are always scary stuff). The average leaf package is > much less propice to breakage induced by minimal changes. This is just plain bull. High level packages also have one line fixes that are simple, elegant, and wrong. -- Peter -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel