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 1Folyk-00032m-3r for garchives@archives.gentoo.org; Fri, 09 Jun 2006 18:45:06 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.6/8.13.6) with SMTP id k59IhJEh011660; Fri, 9 Jun 2006 18:43:19 GMT Received: from smtp05.gnvlscdb.sys.nuvox.net (smtp.nuvox.net [64.89.70.9]) by robin.gentoo.org (8.13.6/8.13.6) with ESMTP id k59IcE49030338 for ; Fri, 9 Jun 2006 18:38:14 GMT Received: from cgianelloni.nuvox.net (216.215.202.4.nw.nuvox.net [216.215.202.4]) by smtp05.gnvlscdb.sys.nuvox.net (8.12.11.20060308/8.12.11) with SMTP id k59Ich57027977 for ; Fri, 9 Jun 2006 14:38:43 -0400 Received: by cgianelloni.nuvox.net (sSMTP sendmail emulation); Fri, 9 Jun 2006 14:35:59 -0400 Subject: Re: [gentoo-dev] Project Sunrise thread -- a try of clarification From: Chris Gianelloni To: gentoo-dev@lists.gentoo.org In-Reply-To: <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> <20060609124201.GA917@nightcrawler> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-bG8FJh+hx1zVGcEDaTXX" Organization: Gentoo Linux Date: Fri, 09 Jun 2006 14:35:58 -0400 Message-Id: <1149878158.22473.69.camel@cgianelloni.nuvox.net> 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 X-Mailer: Evolution 2.6.1 X-Archives-Salt: c15fbbf4-511f-4264-bb60-94d5e2a8fc13 X-Archives-Hash: 87b3626699559e73fec2bc7e00caa3c4 --=-bG8FJh+hx1zVGcEDaTXX Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2006-06-09 at 05:42 -0700, Brian Harring wrote: > 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 a= s > > > 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. >=20 > Curious, how will the wrangler know in general? *cough* they won't. I already covered this. If you're going to be a part of the conversation, try to keep up, will you? *grin* > 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. Except the other overlays are not designed as end-user overlays. They are designed to aid developers. Also, they are targeted at a specific task/goal, as opposed to being a dumping ground for the unwanted and unmaintained. > 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). I definitely agree that better bug data would help the situation. However, it does not change the fact that this is still a dumping ground. Again, this was something that was *explicitly* stated that overlays.gentoo.org would *not* become, yet here we are. > 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... Most people tend to not punt the bug so much as ask for proof that it isn't caused by the overlay. I know that we have done this in games and it has almost always ended up as something the user has done thanks to an overlay. In the cases where it truly is a bug, we fix it. > > > 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. >=20 > Same for above re: "large overlay", realistically, like it or not the=20 > general case of N overlay/repo is coming down the pipe. Sure. Doesn't mean I have to support anything but the one and only official Gentoo package repository. Complain all you want, but I became a Gentoo developer, not a $random_repository developer for a reason. > 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). I'd rather the things that were agreed upon when the overlays project was started were actually adhered to, instead. I guess it is just too much to ask from some people to keep their word. ...and people wonder why Gentoo developers don't trust each other anymore. > 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). Fine. Make a proposal to actually add it to the tree and do it properly. There's no need to have this sort of thing limited to a very small subset of developers who couldn't *possibly* keep up with the workload. Yes, there will only be a few developers and they'll be really busy, especially since they're going to be checking every commit to ensure that there's no malicious code...... --=20 Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux --=-bG8FJh+hx1zVGcEDaTXX Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQBEib+OkT4lNIS36YERAoW8AJ4hQkbhzyVUyBQjmXqnP3kyxG8JBQCeM5Xr dJoVYXrXsiOPNQDvAEyTPuk= =Uc+l -----END PGP SIGNATURE----- --=-bG8FJh+hx1zVGcEDaTXX-- -- gentoo-dev@gentoo.org mailing list