Gentoo Archives: gentoo-dev

From: Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] My wishlist for EAPI 5
Date: Thu, 21 Jun 2012 11:37:58
Message-Id: 20120621123701.3b515176@snowbell
In Reply to: Re: [gentoo-dev] My wishlist for EAPI 5 by Patrick Lauer
On Thu, 21 Jun 2012 19:15:02 +0800
Patrick Lauer <patrick@g.o> wrote:
> > Then, looks clear to me that the way to get things approved in newer > > EAPIs is not clear enough as looks like a lot of devs (like me) > > don't know them (for example, when things to be added to EAPI need > > also a GLEP and a PMS diff, also the needing to get an > > implementation for any package manager). Is this documented in some > > place? > No, and this is a rather random ad-hoc requirement that hasn't been > specified before.
It's dependent upon the level of complexity of the work, and whether or not anyone on the PMS team understands it enough to be able to do the work themselves. As far as I know, none of us do on this one, so it's down to whoever wants it to educate us enough that we can get it done...
> All previous EAPI processes went through some debate with dev-portage@ > and the other involved people (mostly pkgcore/ferringb and > paludis/ciaranm), then the proposal got handed to council to vote on, > and if council was happy that proposal was hammered into PMS and the > new EAPI published. Most of the time new features had a crude > approximation of a patch for PMS available so that the documentation > updates were done in a timely manner.
Actually, we've been passing pretty much final PMS patches to the Council to vote on.
> I have no idea why Ciaran is trying to redefine the process now > suddenly and why people are taking this nonsense seriously.
I'm not.
> I would say PMS team accepts what council signs off ... or am I seeing > the order wrong here?
The PMS team makes suggestions to the Council, and the Council accepts a subset of those. The Council can also suggest that the PMS team looks at a particular feature, but as Gentoo has no mechanism in place for forcing work to get done, that only works if there's someone with both the time and the knowledge to figure it out.
> So, the normal way to get a feature into the next EAPI is ... write a > specification to the best of your capabilities, present it here, when > people are done bashing it ask PMS people to help you prepare a PMS > patch so that you can suggest it to Council
Yup, and for difficult cases like the ones under discussion, a part of presenting it is to demo a working implementation on real packages so that we gain real world experience of the feature. It's also important to note that "the best of your capabilities" may not be anywhere near enough for the PMS people or the package mangler people to do the remainder of the work.
> and then it's mostly a > matter of waiting until the next EAPI is finalized (which currently > runs at a glacial pace of about one EAPI a year as far as I remember)
I like how you simultaneously troll both sides of that issue. Weren't you previously claiming there were too many EAPIs and that we shouldn't have lots of new ones? -- Ciaran McCreesh


File name MIME type
signature.asc application/pgp-signature