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 1FMBX9-0005PP-B7 for garchives@archives.gentoo.org; Wed, 22 Mar 2006 22:10:27 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.6/8.13.5) with SMTP id k2MM90aI030107; Wed, 22 Mar 2006 22:09:00 GMT Received: from nproxy.gmail.com (nproxy.gmail.com [64.233.182.203]) by robin.gentoo.org (8.13.6/8.13.5) with ESMTP id k2MM3mxg001960 for ; Wed, 22 Mar 2006 22:03:48 GMT Received: by nproxy.gmail.com with SMTP id o25so198953nfa for ; Wed, 22 Mar 2006 14:03:48 -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=m4muKxDP0ZwimShyXZ+kZXTdWeCp399x/of7E0tX4u6sqdjdGiA6uo5571i6E27+eQKLMKcqdR3qsdoPuAEckLKhhoywwjytcV35MVIsOFIkqnsOoG3RfaGLcL90xywUS5kWFLduKCOXUhY+459oQMu/ZiIoaGsMmwlcOABkaCo= Received: by 10.48.42.16 with SMTP id p16mr345225nfp; Wed, 22 Mar 2006 14:03:47 -0800 (PST) Received: by 10.48.211.12 with HTTP; Wed, 22 Mar 2006 14:03:47 -0800 (PST) Message-ID: Date: Wed, 22 Mar 2006 22:03:47 +0000 From: "Stuart Herbert" To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Official overlay support In-Reply-To: <4421836A.8040000@gentoo.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: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <441F35B9.8000406@gentoo.org> <4421836A.8040000@gentoo.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by robin.gentoo.org id k2MM3mxg001960 X-Archives-Salt: c9b151f8-108b-450b-b4ce-ac59994b0373 X-Archives-Hash: 1f24eedd86efc98cd31bc41a0232bbd6 > This definitely sounds like a fun idea. It would be even cooler if we > were using a distributed SCM on both ends that allowed for easy merging. > > Donnie It's probably the right time for me to flesh out what I've been planning for overlays.g.o. 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 homepage itself running Planet (just like planet.g.o), using the RSS feeds from the overlays to display the changelogs from all the overlays. The links down the left hand side of the page go to the homepage for each of the overlays. The homepages are separate wiki instances. http://overlays.g.o/proj// for overlays run by herds listed in herds.xml http://overlays.g.o/svn// for the SVN repos and http://overlays.g.o/dev// for overlays run by individual developers http://overlays.g.o/svn// for the SVN repos There's a practical limit to the amount of software we can support on overlays.g.o. The less we install, the less the overhead of administrating this system for infra and the overlays admin team (I'm looking for responsible volunteers to join that team, if you're interested). I'd like to offer two wiki engines and two version control systems on overlays.g.o. I believe that gives us enough choice without us loading the box with too much software for us to keep on top of. One thing that was never planned was any form of shell access to this box, except for the team creating/destroying overlays. It looks like this will be necessary to support a distributed vcs. I'll talk to infra and see what we could do about providing some form of ssh access to help us support a distributed vcs. Trac and SVN would be my first choice. MoinMoin would be my recommendation for the second wiki engine. What should the second version control system be? I don't use them, I have no experience with them, and so I have no preference of what this should be. To answer Daniel's question about "official" ... the overlays hosted on overlays.g.o would be "official". The "overlays" project will be accountable for overlays.g.o overall. It would make sense for the "overlays" project to be a sub-project of infra. To ensure "officialness" and (what I personally care more about) accountability, project overlays will be created for projects that meet the description of a project in the metastructure [1]. The overlays team will have to be strict on this, to ensure "officialness". The overlay must be requested by one of the leads of the project. The lead(s) would be jointly accountable for the overlay and all its contents. Leads will be able to ask for commit / wiki edit access for non-devs. Developer overlays would only be created for active Gentoo developers, and they would be accountable for its contents. Non-developers will not be given write access to developer overlays. By default - working on the same principle of trust that governs all developers w.r.t. the Portage tree - all developers will be able to commit to all overlays. If we can't trust you to respect other people's overlays, then we can't trust you with commit access to the Portage tree, and you're not fit to be a Gentoo dev in the first place :P The only "restriction" will be that you'll need to ask the overlay project team to setup your access the very first time. Anyone wanting a "secret" overlay needs to make their own hosting arrangements. To answer Daniel's other question, about bugs.g.o ... trac on overlays.g.o will have its bug tracking system disabled. We already have one bug tracking system - bugs.g.o - and that's sufficient. [1] http://www.gentoo.org/proj/en/glep/glep-0039.html Best regards, Stu -- gentoo-dev@gentoo.org mailing list