On 01/11/2012 19:23, Steven J. Long wrote: > He's right tho: the topic was "Why doesn't your tinderbox work with > overlays?" Your response was to insult Arfrever and not actually answer > the point.
_Arfrever himself_ point to my reason in that blog post, FFS. > Not that I agree with the argument: a tinderbox that can handle overlays > sounds > much more useful. The process outlined is that you can do special runs against > p.masked packages, given an email from the developer. Adding the overlay is > just as easy to script, so same amount of work, or less. Of course if the > overlay > is badly maintained, you don't have to do anything you don't want. Yeah it _could_ be the same amount of work _if_ the overlay is well-maintained. But since those overlays are pretty rare, I'm not going to go out of my way just because. > Just don't be surprised > when people who work in overlays for whatever reason choose another > tinderbox, or > deem your tinderbox irrelevant to _their_ workflow. I'm not surprised. And I honestly don't give a rat's ass about it. Gnome works in an overlay, but there is a tipping point when the overlay content is stable enough that it enters the tree under p.mask. Qt did the same as well. Both of them had asked me runs in the past, and it's fine. Now of course there are "experimental" overlays. I don't care about those, they'll probably add noise rather than signal, so, there they go, out of the window. What about those overlays who're never targeting into the tree? Well, duh, I don't care about those because if it's not in the main tree, for me it's not Gentoo, full stop. Do you still fail to see why I don't find it a _limitation_? The only moment when I can actually get decent signal out of a tinderbox run is when the package _is_ good enough to get into p.mask; if _all_ packages fail to build because the API is totally broken and nobody fixed it, it'll just add to the number of open bugs I have. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
