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 <firstname.lastname@example.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:
Zac kindly pointed me to original bug:
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,