FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)

Kevin Kofler kevin.kofler at chello.at
Sat Feb 27 01:52:23 UTC 2010


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.

> 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!

> "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!

> 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.

        Kevin Kofler



More information about the devel mailing list