On 05/11/2012 07:31, Steven J. Long wrote: > Are you really missing the fact that by testing someone's overlay, the package > would by definition not be in the tree, and you wouldn't have to file any bugs > at all, just (automatically) email the output back to the overlay developer?
Which means I wouldn't be filing bugs for the problems with the _existing_ packages that are in tree, which is what the users actually _use_ by default. If the users are forced to use overlays to get working packages, then I feel I'm perfectly right with screaming at the developers who are using overlays for development because they leave users in a sorry state. Let me try to re-explain this to you: let's say I import overlay $foobar and $foobar has library A and packages B C D E and F. Now there's package G in main tree that also uses library A. It fails in the tinderbox run. Who I have to report it to? Well, I first have to figure out where the fuck the version of library A is coming from when it failed, which is far from easy. Then I have to report it to the overlay maintainer (And you say it's easier by email? FFS you have no idea how bugs work, do you?) who might or might not act on it, and in the mean time I'd be overlooking _real_ bugs in the tree. Now let's say I add more one overlay and there are _three_ copies of library A each with a different set up, parameters, flags etc. and the packages between these don't work correctly. Who do I report bugs for? So seriously, you've got to get a grip on the _trouble_ that overlays cause, and that about every developer had to face at one point or another. You're romanticizing overlays because they give _you_ as an user power, but you're ignoring all the headaches that the developer get from them. And you're also failing to understand how the whole tinderbox works. I suggest you read the two posts I wrote on the topic, which will form a basis for the documentation of the tinderbox: http://goo.gl/SM9Rp http://goo.gl/SF0Dz -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/