From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1M4s6V-0007aU-EH for garchives@archives.gentoo.org; Fri, 15 May 2009 07:45:15 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C8E36E03A5; Fri, 15 May 2009 07:45:13 +0000 (UTC) Received: from wp165.webpack.hosteurope.de (wp165.webpack.hosteurope.de [80.237.132.172]) by pigeon.gentoo.org (Postfix) with ESMTP id 744B4E03A5 for ; Fri, 15 May 2009 07:45:13 +0000 (UTC) Received: from 79.142.224.149.nat.router2.bolignet.dk ([79.142.224.149] helo=marsupilami.localnet); authenticated by wp165.webpack.hosteurope.de running ExIM using esmtpsa (TLSv1:DES-CBC3-SHA:168) id 1M4s6S-0000mv-EW; Fri, 15 May 2009 09:45:12 +0200 From: Thilo Bangert To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted Date: Fri, 15 May 2009 09:43:52 +0200 User-Agent: KMail/1.11.3 (Linux/2.6.28-gentoo-r5; KDE/4.2.3; i686; ; ) References: <1242261133.23088.82.camel@localhost> <4A0B738F.3030000@allenjb.me.uk> <4A0C2E6B.1040107@gentoo.org> In-Reply-To: <4A0C2E6B.1040107@gentoo.org> Organization: Gentoo 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: multipart/signed; boundary="nextPart1285683.qUDu4k32l2"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200905150943.57830.bangert@gentoo.org> X-bounce-key: webpack.hosteurope.de;bangert@gentoo.org;1242373513;443cc671; X-Archives-Salt: ab2057e3-694f-4335-a759-3fe312170ace X-Archives-Hash: 044dd37c547c422b07bf32245dfb3eba --nextPart1285683.qUDu4k32l2 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Richard Freeman said: > AllenJB wrote: > > All that's going to happen is Gentoo will have many many buggy and > > out of date packages in the MAIN TREE. Exactly where they shouldn't > > be. You claim quality won't be sacrificed, but I simply can't see > > this without any attempt to solve the manpower issues first. > > > > Isn't the purpose of this project already somewhat covered by > > Sunrise? > > I have to agree with your points. We need to have quality standards > for packages. Currently we have a couple of tiers: > > 1. Main tree - every ebuild has an official maintainer and gets prompt > security updates/etc. New features might get a little more stale, but > you aren't going to be running at risk if you only use the main tree > and routinely emerge -u world. If a package falls behind on security > it gets masked and booted. > > 2. Overlays - you're on your own and at the general mercy of the > overlay maintainer. > > 3. Sunrise (just a special case of an overlay) - somewhere in-between. > Again, you have to opt-in. > AFAIK, we have never explicitly made this distinction clear. if we had, we= =20 would have to remove stuff from portage which doesnt live up to the=20 standards. it is also not true from a more real world perspective: there are many=20 packages in portage that have a standard which is much lower than what is=20 in some overlays. and there are many packages in overlays which live up to= =20 a quality standard way above portage's average. if you want to exaggerate a bit, we have roughly 500 ebuilds in portage=20 which are maintainer-needed and have only a few users and thats why you=20 want to keep popular packages out of the tree? its weird, how this whole thing started with wanting to accomodate our=20 users better and then other people come around and argue against it in=20 order to protect our users... user who want protection run stable arch! given the current state of the tree, its hypocritical to be against this=20 proposal, IMHO. however, one could try to implement the above quality standards, possibly=20 by splitting up the tree. this issue, as well as some others very similar to this one, have come up=20 many times before. I suggest we do something about it... (splitting the=20 tree or moving more stuff wholesale into portage and have a better rating=20 system... whatever) =46edora is a much more current distribution than Gentoo - and has been for= =20 a couple of years... regards Thilo > I think that we still need to have defined levels of quality, so if we > start putting unmaintained stuff in the main tree then we absolutely > need to preserve a mechanism for users to indicate what level of > quality they desire. Users running a typical install shouldn't > inadvertently have dependencies pulled in which aren't fully controlled > for security issues. > > Could something like sunrise be integrated into the main tree? Sure. > However, there would need to be lots of rules and QA checks like > non-sunrise packages not depending on sunrise packages and the sunrise > packages are somehow clearly marked. Maybe even an ACCEPT_QUALITY =3D > "good-luck-with-that" setting or something like that in make.conf. We > might also need tiered levels of security in cvs. I'm not convinced > that in the end it will be any better than just having those who are > interested add an overlay to their tree. > > Maybe a better option would be a way to make overlays more seamless. > Additionally we could have rating categories for overlays like > "security responsiveness," "currency with upstream," etc. The gentoo > project would ask overlays to declare their policies as a condition of > being accessible via the seamless interface, and would drop overlays if > they don't follow their policies. It would still be easy for users to > pick non-standard overlays but it would be clear that they are > venturing off on their own if they do this (just as is the case with > layman today). > > Sure, I'd love to see an extra 1000 supported packages in portage, but > the key is "supported", not just shoveled-in. --nextPart1285683.qUDu4k32l2 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEABECAAYFAkoNHT0ACgkQxRElEoA5AncwiwCeLpsY8e6xUb5gtq+/dn2TCdqc iL8AoLzpwBhAtjIuKrz6h89RsCoI+mKO =9em2 -----END PGP SIGNATURE----- --nextPart1285683.qUDu4k32l2--