From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 3B6661381F3 for ; Mon, 5 Nov 2012 15:17:21 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B3D0EE0459; Mon, 5 Nov 2012 15:16:58 +0000 (UTC) Received: from smtpout.karoo.kcom.com (mercury.karoo.kcom.com [212.50.160.61]) by pigeon.gentoo.org (Postfix) with ESMTP id 4FEE2E0458 for ; Mon, 5 Nov 2012 15:16:02 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.80,715,1344207600"; d="scan'208";a="919215448" Received: from unknown (HELO rathaus.eclipse.co.uk) ([91.85.56.89]) by smtpout.karoo.kcom.com with ESMTP; 05 Nov 2012 15:16:00 +0000 Date: Mon, 5 Nov 2012 15:31:33 +0000 From: "Steven J. Long" To: gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] Re: Re: Maintainer needed: dev-libs/icu Message-ID: <20121105153133.GA2452@rathaus.eclipse.co.uk> Mail-Followup-To: gentoo-dev@lists.gentoo.org References: <508EF70A.9010801@gentoo.org> <508EFE13.7080802@flameeyes.eu> <201210310418.18469.Arfrever.FTA@gmail.com> <50909A20.9020604@flameeyes.eu> <20121101061818.6045.qmail@stuge.se> <50921600.9040306@flameeyes.eu> <20121101064239.8139.qmail@stuge.se> <50921BA5.7060508@flameeyes.eu> <20121102022301.GA7812@rathaus.eclipse.co.uk> <509330D6.5090500@flameeyes.eu> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <509330D6.5090500@flameeyes.eu> X-Archives-Salt: 296562a7-7c9d-4233-b50b-fe57ea25e35c X-Archives-Hash: 2c80b382c40742822cde98d54bfccd5c On Thu, Nov 01, 2012 at 07:32:54PM -0700, Diego Elio Petten=C3=B2 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. >=20 > _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. =20 > > Not that I agree with the argument: a tinderbox that can handle overlay= s 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 overla= y is > > just as easy to script, so same amount of work, or less. Of course if t= he overlay > > is badly maintained, you don't have to do anything you don't want. >=20 > 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 exp= lanation. 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 d= o 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 adde= d to tree under p.mask, and no need for that variety to be added to unmask in the chr= oot. 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 tin= derbox, or > > deem your tinderbox irrelevant to _their_ workflow. >=20 > 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 t= heir 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 fi= ne. Does that mean runs where you tried out their overlay, or runs where they w= ere forced to add loads of packages to the tree, and then back them out again t= o 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. >=20 > 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. >=20 > 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 th= at 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 pack= age would by definition not be in the tree, and you wouldn't have to file any b= ugs 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 stress= ful 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, wh= ich is a major factor in the process. Anyhow, no worries: good luck with your work. --=20 #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)