From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1FogRn-0007Cu-At for garchives@archives.gentoo.org; Fri, 09 Jun 2006 12:50:43 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.6/8.13.6) with SMTP id k59CmBDM023825; Fri, 9 Jun 2006 12:48:11 GMT Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.192.81]) by robin.gentoo.org (8.13.6/8.13.6) with ESMTP id k59Ch0QZ013167 for ; Fri, 9 Jun 2006 12:43:00 GMT Received: from nightcrawler (c-24-21-135-117.hsd1.or.comcast.net[24.21.135.117]) by comcast.net (rwcrmhc11) with SMTP id <20060609124258m1100hcfjce>; Fri, 9 Jun 2006 12:42:59 +0000 Date: Fri, 9 Jun 2006 05:42:01 -0700 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Project Sunrise thread -- a try of clarification Message-ID: <20060609124201.GA917@nightcrawler> References: <44887368.9030302@gentoo.org> <1149803837.19443.101.camel@cgianelloni.nuvox.net> <4488A4F3.5060908@gentoo.org> <1149811589.19102.23.camel@vertigo.twi-31o2.org> <4488C58A.5060205@gentoo.org> <1149855392.19102.37.camel@vertigo.twi-31o2.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PNTmBPCT7hxwcZjr" Content-Disposition: inline In-Reply-To: <1149855392.19102.37.camel@vertigo.twi-31o2.org> User-Agent: Mutt/1.5.11 X-Archives-Salt: f9f49b32-b26d-43c3-9bba-5887d9f97542 X-Archives-Hash: 112d27bed1cfcc0d9916f5bb642945d8 --PNTmBPCT7hxwcZjr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 09, 2006 at 08:16:32AM -0400, Chris Gianelloni wrote: > On Fri, 2006-06-09 at 02:49 +0200, Markus Ullmann wrote: > > > This is a bug for an ebuild that the user does not think is related to > > > the pam_skey. Go back and read what I wrote. > > >=20 > >=20 > > it was agreed upon that we don't keep extra bugzilla or whatever for all > > things on o.g.o but keep track of all issues within bugs.g.o. and btw, > > most work on "new" bugs is done by bug wranglers and not the common > > devs. So if they say the workload from it is too high, I'll take it as > > valid reason as they have to handle it. >=20 > I'm sorry, but you're avoiding the question here. How will the > bug-wranglers even *know* that this is related to a package in the > overlay? They wouldn't. As I ststed *repeatedly* now. The user has > not mentioned that they're using pam_skey, as is a common occurrence in > bugs. Curious, how will the wrangler know in general? *cough* they won't. You're using a generic arguement against a specific target- iow, apply=20 it to overlays.g.o in general instead of singling sunrise out via it. Meanwhile, answer to that one is better bug data for reporting- dump=20 of (random out of the ass example) first level deps, and where they=20 came from (overlay/portdir). Downside to that data is that slackers will automatically punt the bug=20 if they see non portdir in cases where it's obvious it's an issue in=20 the pkg rather then the deps, but there always is a downside... > > We're not the first large overlay project, there are other ones out > > there already and these "wrong" bugs aren't a new thing arising here... >=20 > No. You're the first large overlay project that is on official Gentoo > infrastructure, even after it was agreed that there wouldn't be > something like this. With the non-official projects, we simply don't > support any bugs from anyone using them. It's that simple. With this > project, you're vying for official status, meaning we cannot do that. > This will be an *enormous* time sink for the entire ebuild developer > pool. Same for above re: "large overlay", realistically, like it or not the=20 general case of N overlay/repo is coming down the pipe. Personally, I'd rather see this particular case be handled from the=20 get go as an experiment- lay out from the start the exit conditions=20 for it (if it becomes a dumping ground, out she goes). Reason? Devs/users have been after a true testing branch/repo from=20 day one, if we're doing overlays and people are willing to try and=20 supply that demand, lets get the question answered once and for all=20 (instead of everyone and their mother shooting off about every=20 potential they can think of for why it might fail). ~harring --PNTmBPCT7hxwcZjr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEiWyZvdBxRoA3VU0RAp7wAJ4jcj5Y9DU5MufUMbGUwMHEuLVTZACghixa km7HeVMBYoajbgz93GB9ZhY= =8kY4 -----END PGP SIGNATURE----- --PNTmBPCT7hxwcZjr-- -- gentoo-dev@gentoo.org mailing list