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 1FocRA-000120-O4 for garchives@archives.gentoo.org; Fri, 09 Jun 2006 08:33:49 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.6/8.13.6) with SMTP id k598VwIX006915; Fri, 9 Jun 2006 08:31:58 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by robin.gentoo.org (8.13.6/8.13.6) with ESMTP id k598SRpj023564 for ; Fri, 9 Jun 2006 08:28:28 GMT Received: from [10.0.0.13] (dslb-084-063-047-196.pools.arcor-ip.net [84.63.47.196]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 8A36C6513F for ; Fri, 9 Jun 2006 08:28:26 +0000 (UTC) Subject: Re: [gentoo-dev] Project Sunrise thread -- a try of clarification From: Patrick Lauer To: gentoo-dev@lists.gentoo.org In-Reply-To: <1149811589.19102.23.camel@vertigo.twi-31o2.org> References: <44887368.9030302@gentoo.org> <1149803837.19443.101.camel@cgianelloni.nuvox.net> <4488A4F3.5060908@gentoo.org> <1149811589.19102.23.camel@vertigo.twi-31o2.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-tT4HXPi54XflpWp5ARKf" Organization: Gentoo Date: Fri, 09 Jun 2006 10:28:18 +0200 Message-Id: <1149841698.9743.20.camel@localhost> 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: e4cdb274-a276-4397-9741-c6469954cb97 X-Archives-Hash: cb4ce0c3274b98b9cc02a23ff29d9bd9 --=-tT4HXPi54XflpWp5ARKf Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2006-06-08 at 20:06 -0400, Chris Gianelloni wrote: > > You don't need a subversion client, you perhaps notice the http in fron= t > > of the url.. just open it up in your browser and you get the source > > immediately. >=20 > Umm... so now I need to go and instead of clicking a nice link in > bugzilla, trawl through the subversion repository and find what I'm > looking for? How exactly is downloading things via http any different > than downloading them from bugzilla, which is also http? just my point of view -=20 bugzilla sucks. Ever had to download 10 attachments for one ebuild? It is a good tool for discussion, but I would prefer a simple tool (like layman) that can automatically update things. You obviously don't like overlays, but that shouldn't be a reason to stop us from using it.=20 > > Or, if you want some history like sources.g.o, you can do so as well he= re: > > http://overlays.gentoo.org/proj/sunrise/browser/ >=20 > Excellent. So we're moving the history from being in a single location > (the bug) to being in multiple locations. That will definitely improve > the development process. =20 Yes, now it is easier to check out the ebuilds. More users =3D=3D> better testing. ;-) > No offense, but everything I have seen looks > as if it will add even *more* overhead to actually getting packages into > the tree. The only thing this seems to provide is a half-baked > repository for the users to get marginally-tested ebuilds for software > that wasn't interesting enough for inclusion in the tree. That differs from the 20 or so overlays maintained by users how? Honestly I'd prefer an overlay where I can marginally trust the content over a "foreign" repository maintained by people I don't know. And the quality of some of the overlays ... better have that supervised by devs, they should know how to handle b0rkage. > > > Except that I can *look* at an ebuild without having to break out a > > > subversion client currently. > > See my answer in 3) > See mine. ;] Hmmm ... bugzilla. Instead of a simple cvs up; cd /usr/local/portage/category/package I need to search for ALL bugs with $name in it, look which one it is, curse bugzilla for falling asleep again, see which attachments are relevant, download them, curse bugzilla for falling asleep again, copy them to my overlay, read the bugcomments to see if any special renaming or directory structure is needed ... Hmmm. I think an overlay does have some advantages there ... >=20 > Again, read what I wrote. I said that the developer would see "sunrise" > in the PORTDIR_OVERLAY of the user's emerge --info, which you reiterated > without considering. This is a login bug. At no point did they make > mention of having installed pam_skey from this overlay. This means that > I, as the developer getting this bug, am now responsible for looking at > *every package* in the sunrise overlay to determine if *any* of them > could *possibly* be affecting this package or causing this bug, then > asking the user if they have any of them installed. This differs from a manually patched ebuild in /usr/portage by virtue of sh= owing you that an overlay is used ... > Wouldn't this process be *infinitely* easier if instead of "sunrise" > there was a "pam" overlay with *only* the pam stuff? Ooooh, cool. Now I need about 75 overlays to get things done, and of course= there will be no bad interaction between them ;-) Having one overlay with a focus on not-in-portage ebuilds should not cause the scenario you described and will most likely cause less weird bugs because of intra-overlay dependencies. > That is *exactly* what we get with the other overlays like php and > vmware. I *know* that if I'm looking at a glibc bug and the user has > "php" as an overlay, that it isn't going to be a concern. ... and if we control the overlay we can exclude things like system packages easily. Could be part of the policy to not touch existing ebuilds. > This is a prime example of totally glossing over any discussion to make > it sound promising for you.=20 If bugzilla wasn't so sucky people wouldn't try to use other methods of communication ;-) And again, one svn repo vs. 113 hard-to-find bugs ... > Even better, if I am the proxy > maintainer for a particular set of ebuilds for one or more > user/maintainers, why do I need it in your big, bloated, and completely > inappropriately-named "sunshine" overlay versus a developer overlay of > my own? =20 You don't. Please use your developer overlay. Please don't try to take away our more open overlay. > After all, I am the *only* proxy maintainer. Why should there > be the added *insecurity* of allowing any number of people that *I* > might not trust complete access to the small number of packages where I > am the proxy? It's your choice. Either you get mailbombed with each minor version update = or you trust them to not screw up with the sunrise overlay. And the users could just create their own overlay, get it added to layman and we'd have the same without supervision. From where I'm standing it's better to have the possibility to nuke a bad ebuild in the overlay instead of asking some random user to change this in that overlay because of $problem. Maybe we even find some motivated new ebuild monkeys that have the motivation to become devs ... one can always hope :-) Patrick --=20 Stand still, and let the rest of the universe move --=-tT4HXPi54XflpWp5ARKf 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-ecc0.1.6 (GNU/Linux) iD8DBQBEiTEiqER3hOUoZM4RAhVXAJ9xcACAMnSFmR/4HFdmRuV9tArtUACbB+De P07my/vSHBpfAH3uo0XdVmY= =4OPP -----END PGP SIGNATURE----- --=-tT4HXPi54XflpWp5ARKf-- -- gentoo-dev@gentoo.org mailing list