Hi Stuart, I'd like to comment on some of your plans for overlays.g.o.
Am Mittwoch, 22. März 2006 23:03 schrieb Stuart Herbert: > 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 Also for Arch/Herd Testers? > 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. 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? 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. > > http://overlays.g.o/proj/<project-name>/ for overlays run by herds > listed in herds.xml > http://overlays.g.o/svn/<project-name>/ for the SVN repos > > and 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. > http://overlays.g.o/dev/<developer>/ for overlays run by individual > developers http://overlays.g.o/svn/<developer>/ for the SVN repos same as above :-) > 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). Another reason for dropping the wiki > > 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. In case we use wiki, why _two_ wiki engines? > 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. Please consider also to let QA and Security have commit access to all overlays (If they're so inclined). > 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 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. Stuart: Overall, i like your proposal. I would suggest to turn it into a GLEP and I'm willing to help you with this. Danny -- Danny van Dyk <[EMAIL PROTECTED]> Gentoo/AMD64 Project, Gentoo Scientific Project -- [email protected] mailing list
