El jue, 21-06-2012 a las 19:15 +0800, Patrick Lauer escribió: > 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.
I take it seriously because looks like, effectively, this is blocking things. I remember when I first asked for an "easy" way of trying to allow administrator of Gentoo machines to easily handling all that needed rebuilds after updating: https://bugs.gentoo.org/show_bug.cgi?id=413619 Zac kindly pointed me to original bug: https://bugs.gentoo.org/show_bug.cgi?id=192319 I knew about that bug report but, as it was still pending after years, I thought there were technical issues making it hard to fix and, then, I tried to propose and easier solution at least until best one can be implemented. Then, if you remember the thread I opened here some weeks ago about this issue, you will see how things moved, even when Zac is already working on getting an implementation I am really worried about, even after Zac offering his work and time to get an implementation, when he offers it, Ciaran will reject it with some other excuse :( > > > 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 > >
signature.asc
Description: This is a digitally signed message part
