On 06/21/12 15:25, Pacho Ramos wrote: > El jue, 21-06-2012 a las 08:00 +0100, Ciaran McCreesh escribió: >> On Thu, 21 Jun 2012 08:08:55 +0200 >> Pacho Ramos <pa...@gentoo.org> wrote: >>> Also, if I remember correctly, Tommy asked for this some months ago, >>> you asked for what he sent some days ago and now you require more and >>> more work to delay things to be implemented. >> I still haven't seen a clear description of exactly what should be >> changed and why. I've also not seen a description of exactly what >> problem is being solved, nor a discussion of the relative merits of >> implementing a solution to whatever that problem is. All I've seen is a >> mess of code that "gets it working" in Portage (which isn't the same as >> "implements it for Portage") and a big wall of text that contains lots >> that no-one needs to know and little of what's important. This needs to >> go through the GLEP process, and it needs a PMS diff. >> >> In case you're not aware, the first time Gentoo did multilib, it was >> done as a series of random changes to Portage that no-one really >> thought through or understood. As you can see, that didn't work... >> > 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.
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. I have no idea why Ciaran is trying to redefine the process now suddenly and why people are taking this nonsense seriously. > If not, I think it > should be documented and, of course, it should be done by PMS team if > possible as they clearly know what they expect to get for approval if > needed since, I discussed some days ago, council will simply accept some > specific features to be included in next eapi once they are accepted by > PMS team. That way, we could save a lot of time, know what steps are > pending, try to ask for help for some specific steps and, finally, get > it discussed in PMS people providing all what is needed. I would say PMS team accepts what council signs off ... or am I seeing the order wrong here? 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, 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) Take care, Patrick
