Gentoo Archives: gentoo-dev

From: Pacho Ramos <pacho@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] My wishlist for EAPI 5
Date: Sat, 23 Jun 2012 08:02:07
Message-Id: 1340438461.5979.18.camel@belkin4
In Reply to: Re: [gentoo-dev] My wishlist for EAPI 5 by Patrick Lauer
1 El jue, 21-06-2012 a las 19:15 +0800, Patrick Lauer escribió:
2 > On 06/21/12 15:25, Pacho Ramos wrote:
3 > > El jue, 21-06-2012 a las 08:00 +0100, Ciaran McCreesh escribió:
4 > >> On Thu, 21 Jun 2012 08:08:55 +0200
5 > >> Pacho Ramos <pacho@g.o> wrote:
6 > >>> Also, if I remember correctly, Tommy asked for this some months ago,
7 > >>> you asked for what he sent some days ago and now you require more and
8 > >>> more work to delay things to be implemented.
9 > >> I still haven't seen a clear description of exactly what should be
10 > >> changed and why. I've also not seen a description of exactly what
11 > >> problem is being solved, nor a discussion of the relative merits of
12 > >> implementing a solution to whatever that problem is. All I've seen is a
13 > >> mess of code that "gets it working" in Portage (which isn't the same as
14 > >> "implements it for Portage") and a big wall of text that contains lots
15 > >> that no-one needs to know and little of what's important. This needs to
16 > >> go through the GLEP process, and it needs a PMS diff.
17 > >>
18 > >> In case you're not aware, the first time Gentoo did multilib, it was
19 > >> done as a series of random changes to Portage that no-one really
20 > >> thought through or understood. As you can see, that didn't work...
21 > >>
22 > > Then, looks clear to me that the way to get things approved in newer
23 > > EAPIs is not clear enough as looks like a lot of devs (like me) don't
24 > > know them (for example, when things to be added to EAPI need also a GLEP
25 > > and a PMS diff, also the needing to get an implementation for any
26 > > package manager). Is this documented in some place?
27 > No, and this is a rather random ad-hoc requirement that hasn't been
28 > specified before.
29 >
30 > All previous EAPI processes went through some debate with dev-portage@
31 > and the other involved people (mostly pkgcore/ferringb and
32 > paludis/ciaranm), then the proposal got handed to council to vote on,
33 > and if council was happy that proposal was hammered into PMS and the new
34 > EAPI published. Most of the time new features had a crude approximation
35 > of a patch for PMS available so that the documentation updates were done
36 > in a timely manner.
37 >
38 > I have no idea why Ciaran is trying to redefine the process now suddenly
39 > and why people are taking this nonsense seriously.
40
41 I take it seriously because looks like, effectively, this is blocking
42 things. I remember when I first asked for an "easy" way of trying to
43 allow administrator of Gentoo machines to easily handling all that
44 needed rebuilds after updating:
45 https://bugs.gentoo.org/show_bug.cgi?id=413619
46
47 Zac kindly pointed me to original bug:
48 https://bugs.gentoo.org/show_bug.cgi?id=192319
49
50 I knew about that bug report but, as it was still pending after years, I
51 thought there were technical issues making it hard to fix and, then, I
52 tried to propose and easier solution at least until best one can be
53 implemented. Then, if you remember the thread I opened here some weeks
54 ago about this issue, you will see how things moved, even when Zac is
55 already working on getting an implementation I am really worried about,
56 even after Zac offering his work and time to get an implementation, when
57 he offers it, Ciaran will reject it with some other excuse :(
58
59 >
60 > > If not, I think it
61 > > should be documented and, of course, it should be done by PMS team if
62 > > possible as they clearly know what they expect to get for approval if
63 > > needed since, I discussed some days ago, council will simply accept some
64 > > specific features to be included in next eapi once they are accepted by
65 > > PMS team. That way, we could save a lot of time, know what steps are
66 > > pending, try to ask for help for some specific steps and, finally, get
67 > > it discussed in PMS people providing all what is needed.
68 > I would say PMS team accepts what council signs off ... or am I seeing
69 > the order wrong here?
70 >
71 >
72 > So, the normal way to get a feature into the next EAPI is ... write a
73 > specification to the best of your capabilities, present it here, when
74 > people are done bashing it ask PMS people to help you prepare a PMS
75 > patch so that you can suggest it to Council, and then it's mostly a
76 > matter of waiting until the next EAPI is finalized (which currently runs
77 > at a glacial pace of about one EAPI a year as far as I remember)
78 >
79 >
80 > Take care,
81 >
82 > Patrick
83 >
84 >

Attachments

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