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 1FMLpF-0005aP-Iv for garchives@archives.gentoo.org; Thu, 23 Mar 2006 09:09:50 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.6/8.13.5) with SMTP id k2N99JE1011530; Thu, 23 Mar 2006 09:09:19 GMT Received: from nproxy.gmail.com (nproxy.gmail.com [64.233.182.190] (may be forged)) by robin.gentoo.org (8.13.6/8.13.5) with ESMTP id k2N97Pmv027386 for ; Thu, 23 Mar 2006 09:07:26 GMT Received: by nproxy.gmail.com with SMTP id o60so279550nfa for ; Thu, 23 Mar 2006 01:07:25 -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=uKbunVVLfUsoqCcscEYNy9izYFwdlgoe6R70KYKv8L5RMxqYfE1uDRF5kKuL+pfaOlVn1Z1RzTtgH7K9+rLtBPcCDd5hxGX9jZdJtqSnjB6u5qxlhueMSzIHh1z1iYM0H/Ky3wPFvU1uul9g2Is4MCr5vM9sr7anbivse2xEqho= Received: by 10.48.237.15 with SMTP id k15mr475116nfh; Thu, 23 Mar 2006 01:07:25 -0800 (PST) Received: by 10.48.211.12 with HTTP; Thu, 23 Mar 2006 01:07:25 -0800 (PST) Message-ID: Date: Thu, 23 Mar 2006 09:07:25 +0000 From: "Stuart Herbert" To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Official overlay support In-Reply-To: <200603230910.00496.kugelfang@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> <200603230910.00496.kugelfang@gentoo.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by robin.gentoo.org id k2N97Pmv027386 X-Archives-Salt: 2beb74e4-490f-402d-b842-95eeb5f9968c X-Archives-Hash: 80fa86f159231264f26934918a83e568 Hi Danny, On 3/23/06, Danny van Dyk wrote: > Hi Stuart, > > I'd like to comment on some of your plans 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 > Also for Arch/Herd Testers? Sure. > Well, there is a couple of Gentoo devs who are not particularly comfortable > with wikis (including myself). Why change things the way they are currently? Because previous threads here on -dev asking for a wiki prove that not everyone is comfortable / happy with how things currently are ... myself included. Wikis are a much lower barrier to entry than GuideXML ... and they have advantages over GuideXML. There's no reason why you can't create GuideXML and store / publish it via the overlay, even if there is a wiki. We do that with the PHP overlay. > I'd suggest to use one repository per project and to add a 'website' or 'site' > directory. In this case we could use the good ol' GuideXML/SCM combination. That's easy enough. We can establish a 'known location' in the VCS tree where GuideXML will be stored, and run a simple cron script to extract it and put it into the website directory for public viewing. Or you could just publish it on www.g.o/proj/en// instead :) > Like above: use http://o.g.o/proj// for the information content > and http://o.g.o/proj//svn/ for the overlay. Could do. I always preferred separate paths to ensure no clash with any other content under /proj//. > Another reason for dropping the wiki No. We can make the wiki optional, but not offering a wiki at all makes it impossible for existing successful, externally hosted overlays to move to overlays.g.o. > In case we use wiki, why _two_ wiki engines? Because different people have different preferences, and I don't believe in 'one size fits all'. Adding a little bit of flexibility in the right places will make o.g.o more successful. > Please consider also to let QA and Security have commit access to all overlays > (If they're so inclined). That's already covered under the principle that QA and Security are staffed by devs. > I would say this should be clarified some more. Surely anybody with an access > to an overlay can commit, but the projects should be the keepers of the keys. > Overlays are not the tree, they are probably very experimental. I could > imagine that i wouldn't want anyone to modify say an experimental gcc ebuild > from toolchain's overlay for example. I want to operate the overlays on the same principles that we use to manage the Portage tree. We tell developers that they have to respect other people's packages, and can't go around changing what they feel like. The same should hold true for the overlays. > Stuart: Overall, i like your proposal. I would suggest to turn it into a GLEP > and I'm willing to help you with this. I already have Infra's agreement and active support to deliver this (I can't thank Lance and Kurt enough for their help to date on this). It's a new service - one that no-one is required to use (although I ferverently hope that it proves very popular). I don't believe that it needs a GLEP. What it does need is a successful overlay project team, to administer the service and help it evolve over the coming years. Best regards, Stu -- -- gentoo-dev@gentoo.org mailing list