Re: [gentoo-dev] Nominations open for the Gentoo Council 2007
> Date: Thu, 06 Jul 2006 10:02:45 +0200 > From: Patrick Lauer <[EMAIL PROTECTED]> > Subject: Re: [gentoo-dev] Nominations open for the Gentoo Council 2007 [...] > So here's my nominations: [...] > kosmikus Thank you very much for the nomination. However, I am currently happy whenever time allows me to keep up my regular duties for the Gentoo project. I would not do a good job on the council. Maybe another year ... Cheers, Andres (kosmikus) pgpOg9AL4MyCe.pgp Description: PGP signature
Re: [gentoo-dev] Official overlay support
> On 3/24/06, Andres Loeh <[EMAIL PROTECTED]> wrote: > > Here's a list of things that I think are essential or highly helpful to > > our working process: > > > > * We should be allowed to continue using darcs for our version management. > > If that's not possible on Gentoo infra, we should be allowed to host on > > another machine and just have a pointer or ChangeLog on o.g.o. > > Unless I've missed it, no-one else has spoken up and suggested what > the second VCS should be. I'll have a play with darcs as soon as I > can, and talk with infra about whether we can support it or not. Is > it okay if I come and pick your brains to help with this? Sure. Best place to find any of us is #gentoo-haskell ... > > * It should be possible for us to assign commit permissions to any people > > we think are qualified without any formalities and delay. > > Absolutely. This is one of the corner-stones of the project. Great. > > It would work, of course, and it would help prevent certain complaints, > > but it's not absolutely necessary. If "on request" is chosen, it's also > > important that read access can be given by us without any delay, i.e., > > without going through any formal process. > > The only formallity is that the request will need to come from the > project lead listed on your project's page under > www.g.o/proj///. I need to talk to infra first, but in > principle I don't see a problem with project leads being allowed to > delegate that power. At the moment, Haskell is only a herd and a team, not a project. But this is certainly something that can be addressed, should it be necessary to change that. Cheers, Andres pgp3mMReSqoe7.pgp Description: PGP signature
Re: [gentoo-dev] Official overlay support
> > > If the overlay's changelog is included on o.g.o's front-page, and the > > > wiki / GuideXML site is publically readable, but we just disallow > > > anonymous access to the overlay itself (only if requested, this > > > wouldn't be the default setup) ... how would that work for you? > > > > It would work, of course, and it would help prevent certain complaints, > > but it's not absolutely necessary. If "on request" is chosen, it's also > > important that read access can be given by us without any delay, i.e., > > without going through any formal process. > > See, I have no problem with this. The operation of the overlay *should* > lie completely with the overlay owners. You *should* be able to add > *anyone* that you feel is worth adding to read *or* write access, with > no further process. Ok. > As I've said, my only request is a single policy that before an overlay > can become publicly readable on overlays.gentoo.org (which is Gentoo > infrastructure) that it does not break packages in the main tree that > are not in the overlay. > > If this single policy were in place, then I would fully support > overlays.gentoo.org being created. I see your point. Then I'd suggest to have o.g.o host two classes of overlays: (A) publically readable ones that fulfill basic policies and don't break the main tree, and (B) others where read and write access can be granted on request by the overlay owners, but isn't available automatically. Every overlay would belong to class B at first -- in fact, o.g.o could go online only supporting B. We can take our time and work out goog guidelines for class A repos, and then gradually change some of the overlays to class A status. > My main point is I don't want one of my tree packages to break because > some ricer told some n00b to use some crazy ebuild from some random > overlay that isn't really fit for the general masses. If we take at > least *some* measures to prevent this, then I'm OK with it. Allowing a > free-for-all in the overlays is not acceptable. Yes, as I said, I understand that. Cheers, Andres pgpTGFDDdtMXQ.pgp Description: PGP signature
Re: [gentoo-dev] Official overlay support
Hi Stuart. > > dcoutts has described the current practice we use in the Haskell > > team, but that doesn't necessarily mean that it's the only practice > > that would work for us. I can imagine that if we can come up with > > reasonable policies for o.g.o, we can switch to a slightly different > > (i.e., more public) scheme ... > > I want to thank both you and Duncan for your explaination of how the > Haskell overlay works. I would love to get your overlay onto > overlays.g.o, without disrupting the working practices that you've > found successful. > > Which means we need to take another look at the vision of all overlays > being publically readable, because having a non-public overlay seems > to be a key part of what you're already doing. Not really. I discussed this with Duncan and we're perfectly ok with a publically readable repo. In fact, our overlay is currently publically readable. It's just not very well-known or advertised. If we change the situation, we'll have to write up a few guidelines specific to our repository. Here's a list of things that I think are essential or highly helpful to our working process: * We should be allowed to continue using darcs for our version management. If that's not possible on Gentoo infra, we should be allowed to host on another machine and just have a pointer or ChangeLog on o.g.o. * It should be possible for us to assign commit permissions to any people we think are qualified without any formalities and delay. > If the overlay's changelog is included on o.g.o's front-page, and the > wiki / GuideXML site is publically readable, but we just disallow > anonymous access to the overlay itself (only if requested, this > wouldn't be the default setup) ... how would that work for you? It would work, of course, and it would help prevent certain complaints, but it's not absolutely necessary. If "on request" is chosen, it's also important that read access can be given by us without any delay, i.e., without going through any formal process. Cheers, Andres pgp1gbtnP4HWd.pgp Description: PGP signature
Re: [gentoo-dev] Official overlay support
> As said above, how are you going to get new contributors without people > that are actually using/testing that stuff? We find the via Bugzilla and/or irc and point them at the overlay. That way, we more or less know who's using the overlay and make sure they are briefed a bit before they start using it. dcoutts has described the current practice we use in the Haskell team, but that doesn't necessarily mean that it's the only practice that would work for us. I can imagine that if we can come up with reasonable policies for o.g.o, we can switch to a slightly different (i.e., more public) scheme ... Cheers, Andres pgpfWwY8sU09S.pgp Description: PGP signature
[gentoo-dev] new eclass: haskell-cabal
Hi there. The Haskell team has created a new eclass. It makes building Haskell packages that conform to the Cabal [1] architecture (an effort that aims at easing packaging and distribution of both Haskell libraries and tools) nearly trivial. I wish to use the opportunity to thank Lennart Kolmodin and Henning Günther, who aren't Gentoo developers, but have had significant part in the design and development of the eclass. The eclass has been developed and tested in the inofficial gentoo-haskell darcs [2] overlay [3], where the code is available for inspection [4]. We plan to include the eclass in the main portage tree later this week. The overlay currently also contains ~10 packages using the eclass. These will be added to the tree shortly after the inclusion of the eclass. More packages using the eclass are likely to follow. Cheers, Andres (kosmikus) [1] http://haskell.org/cabal/ [2] http://darcs.net/ [3] http://haskell.org/~gentoo/gentoo-haskell/ [4] http://haskell.org/~gentoo/gentoo-haskell/portage/eclass/haskell-cabal.eclass pgpYWTT87D41g.pgp Description: PGP signature
