[gentoo-dev] Re: Re: Maintainer needed: dev-libs/icu

["Steven J. Long" <slong@rathaus.eclipse.co.uk>]

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 ;-)