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.54) id 1FMMnT-0004YS-VR for garchives@archives.gentoo.org; Thu, 23 Mar 2006 10:12:04 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.6/8.13.5) with SMTP id k2NABT1C025122; Thu, 23 Mar 2006 10:11:29 GMT Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.201]) by robin.gentoo.org (8.13.6/8.13.5) with ESMTP id k2NA9coh010956 for ; Thu, 23 Mar 2006 10:09:39 GMT Received: by wproxy.gmail.com with SMTP id 37so598560wra for ; Thu, 23 Mar 2006 02:09:37 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=cEyabJxC166tEzx2W+/6S8AomFRoivyoVRCgt7vvrWxn+WUIUCLMEteRylkMt0/XYk1IBOVyZ3XpkeK/F2/kFw9MG8bTBmu07vzct4Fi0iy53fi8ig1veRhqHJQ1aVDYizRQwbHUIoAcPxwzG1WIjnEcAAKZsaOhd93YOGNpFRk= Received: by 10.54.91.9 with SMTP id o9mr1243002wrb; Thu, 23 Mar 2006 02:09:37 -0800 (PST) Received: by 10.54.157.1 with HTTP; Thu, 23 Mar 2006 02:09:37 -0800 (PST) Message-ID: <623652d50603230209i1f915562v@mail.gmail.com> Date: Thu, 23 Mar 2006 10:09:37 +0000 From: "Chris Bainbridge" To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Official overlay support In-Reply-To: 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: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <441F35B9.8000406@gentoo.org> <4421836A.8040000@gentoo.org> <200603230910.00496.kugelfang@gentoo.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by robin.gentoo.org id k2NA9coh010956 X-Archives-Salt: 8dd1a328-9d88-4889-97f3-5664f663ad3d X-Archives-Hash: 8bb850841a86805fc510605dcf8adda9 On 23/03/06, Stuart Herbert wrote: > > > The vision I have for overlays.g.o is one official home for all Gentoo > > > overlays run by projects and by individual Gentoo devs. I see the > > Also for Arch/Herd Testers? The discussion seems to have moved from the original "how can we become more open to enable our users to contribute?" to "how to provide testing overlays for existing gentoo devs". I think that the use of overlays is more a symptom of a problem with portage. Overlay problems: They remove ebuilds from the tree Users have to add yet another overlay / retrieve the ebuilds somehow Conflicts between overlays Increases time to moving packages into the tree Overlay becomes a developers "personal space" making it difficult to contribute if package is neglected (though that is also a problem now...) Lose repository metadata moving a package from overlay to tree Reduced responsibility for package QA (I expect "we don't care about overlays" to become a standard response on bugs.g.o) And what do we gain: Eases testing - can push in alpha quality ebuilds Developers feel safer because they can't break the tree Surely the solution is to provide that safety net within the tree? Rather than pushing changes into a live tree, push them into a testing tree, then after they pass repoman/QA checks, and a build check, apply the changes to the live tree, otherwise email a rejection. And allow developers to add their own testing ebuilds to the tree (for a start, they will be more widely tested). The current system of overlay usage is very annoying for users, particularly when bugs are hanging around with packages in the tree, and after filing bug reports the user is told that the bug is already fixed in the overlay. Or when new packages are added to overlays instead of the tree. How are users expected to find them? Another thing that needs fixing is the massive number of packages that aren't really maintained. Either the maintainer doesn't respond to bugs, or the package is maintained by a herd and so no one feels it's actually their responsibility to deal with the boring bugs, and when some developer outside of the herd comes across it, they feel like they can't fix the bug without stepping on someone's toes. What's worse is that in a lot of these cases there will be a user on bugs.g.o posting fixes and new ebuilds, and yet they never make it into the tree. A system where developer ebuilds are kept in the tree, and users have a way to automatically contribute ebuilds, either human reviewed, or in some reputation based system, would be very useful. Users also need feedback - how many times does a user submit an ebuild via bugzilla to be told that it doesn't meet QA standards? Why isn't there a system in place to run repoman/QA/build checks on user ebuilds/patches to make sure they are fixed *before* being submitted for inclusion into the tree? And if this could be linked to a bug reporting system where people report/fix individual ebuilds or packages, and I can just type 'gbugs -l pkgname' and get a list of problems and fixes that other people have proposed, even better. I'm not sure whether the answer is more openness of the existing system, some custom submission flow system, or a distributed SCM, but I do think there's a lot that could be changed to make things better. -- gentoo-dev@gentoo.org mailing list