Hi Danny, On 3/23/06, Danny van Dyk <[EMAIL PROTECTED]> 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/<project>/ instead :) > Like above: use http://o.g.o/proj/<project-name>/ for the information content > and http://o.g.o/proj/<project-name>/svn/ for the overlay. Could do. I always preferred separate paths to ensure no clash with any other content under /proj/<project-name>/. > 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
