On Thu, Nov 01, 2012 at 07:32:54PM -0700, Diego Elio Pettenò wrote: > 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.
Yeah, my bad, sorry: I just had that url in log following our "discussion" in #openrc when you pretty much displayed the same attitude, ie "no overlays" and no explanation. > > 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. No-one's asking you to. You just give the impression of being the "official QA and tinderbox" guy, and speak with assumed authority, but as I said, no explanation. I appreciate that it's old ground for you, but it would be better imo if you posted your own explanation urls upfront, instead of letting someone else do it for you several emails into the discussion, after it's got difficult. After all, we're busy people too, and if you're prescribing methodology, it's helpful if you present the reasoning. And again, it's actually less work all round, since all that's needed is a chroot with tree and a single overlay added, no need for a variety of things to be added to tree under p.mask, and no need for that variety to be added to unmask in the chroot. No need for automated bug reports, and the associated costs, either. > > 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. Good, then stop telling everyone they *must* package.mask from overlay or their QA is automatically bad. As that's the impression you leave, and frankly it's bogus. > 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. Does that mean runs where you tried out their overlay, or runs where they were forced to add loads of packages to the tree, and then back them out again to fix any problems? Cos yeah, that sounds like a wonderfuel process to iterate over. > 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_? Not at all: you don't care about overlays at all, so of course it's not a limitation from your point of view. Do you still fail to see why people who do care about overlays, and want to get their sets of packages into a better state than p.masked before pushing to tree, might find your method completely useless, and prefer to use a tinderbox that can cope with layman -a? > 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. 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? Quite apart from the fact that you appear to be missing that you could work with overlay developers (who are targetting the tree) on a much less stressful basis, and keep the beta releases out of the tree altogether; which is why many use overlays. It's also a helluva a lot easier for testers to work with, which is a major factor in the process. Anyhow, no worries: good luck with your work. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
