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