1 |
On Fri, 11 Dec 2009 12:30:22 -0800 |
2 |
Brian Harring <ferringb@×××××.com> wrote: |
3 |
> > No, if a large project such as, say, the Gentoo KDE project, had |
4 |
> > asked you for support for a well documented EAPI and you had |
5 |
> > provided it, I would have also implemented that EAPI in Paludis. |
6 |
> > |
7 |
> > kdebuild-1 was not done without consultation. It was the result of a |
8 |
> > considerable amount of work from an official Gentoo project, and it |
9 |
> > was a well defined, published standard. It was in no way an |
10 |
> > experiment. |
11 |
> |
12 |
> And if gnome decides they want their own format, is PMS/eapi stuck w/ |
13 |
> the bill? |
14 |
|
15 |
If the Gentoo Gnome project produces their own documented format, then |
16 |
yes, I'd expect the Gentoo PMS project to do everything it can to help |
17 |
them with that if that was their desire. I would not expect the Gentoo |
18 |
PMS project to say to the Gentoo Gnome project "no, go away, we're not |
19 |
helping you". |
20 |
|
21 |
> > > Regardless, if you didn't plan for phasing out an experimental |
22 |
> > > eapi, it's not the mainstream eapi's problem- it's your mess to |
23 |
> > > clean up. |
24 |
> > |
25 |
> > kdebuild-1 was not experimental. |
26 |
> |
27 |
> It wasn't official, thus *you* can view it was non-experimental w/in |
28 |
> the paludis realm, but it's experimental to gentoo as a whole- the |
29 |
> primary pkg manager, the official manager specifically, didn't even |
30 |
> support it. |
31 |
> |
32 |
> It was experimental. |
33 |
|
34 |
No, it was a published standard. |
35 |
|
36 |
> PMS was irresponsible for allowing it into the official eapis in the |
37 |
> first place. If KDE intended it to be supported long term (which I |
38 |
> strongly doubt, it was an overlay of unstable ebuilds after all), |
39 |
> then they too were irresponsible. |
40 |
|
41 |
It is not the place of the Gentoo PMS project to tell Gentoo developers |
42 |
to sod off when they ask for help. |
43 |
|
44 |
> > Writing a converter is more work than a simple phased removal. |
45 |
> |
46 |
> I didn't imply a full format converter. I implied a converter that |
47 |
> tweak it enough the thing could be uninstalled by *any* package |
48 |
> manager supporting eapi2. I'd expect that would cover a significant |
49 |
> majority of any remaining (if even there are remaining) installed |
50 |
> pkgs. |
51 |
|
52 |
Again, more work than a simple phased removal. |
53 |
|
54 |
> > > That solves it technically, rather then just ignoring it and |
55 |
> > > pretending we won't have this exact discussion a year later w/ |
56 |
> > > the same claims as to why it can't be removed. |
57 |
> > |
58 |
> > A year later, we can easily have had kdebuild-1 removed in a |
59 |
> > responsible manner. |
60 |
> |
61 |
> You have zero stats now to backup that statement- basically your |
62 |
> prediction of when it'll be fine to remove it is based on opinion. |
63 |
> |
64 |
> Via the same rules, my opinion is that it's fine to remove it now. 1 |
65 |
> -1 = 0. |
66 |
> |
67 |
> Back this up w/ stats please in the future. |
68 |
|
69 |
My proposed phasing out will take two Paludis major releases. That's |
70 |
considerably less than a year. |
71 |
|
72 |
> > More work than just doing it properly. |
73 |
> |
74 |
> Depends on your definition of 'properly'. I presume what you mean is |
75 |
> that it requires you to maintain a kdebuild pms pdf somewhere- more |
76 |
> work for you. |
77 |
|
78 |
No, it requires just not removing anything for a bit longer. |
79 |
|
80 |
> My stance, it's more work for the rest of us coding around the ifdef |
81 |
> mess (most recent bitchfest from it was grobian doing the prefix |
82 |
> patch). |
83 |
|
84 |
Then ask the Council to let us just leave it in without ifdefs until |
85 |
the phased removal is complete. Simple. |
86 |
|
87 |
> Properly to me means using the dvcs's capabilities, and making it |
88 |
> easier for folks to do *official* eapi work w/out having to maintain |
89 |
> dross someone shoved into it. Move the effort of maintaining |
90 |
> kdebuild bits to those who are responsible for it, effectively. |
91 |
|
92 |
Using git's capabilities is something you do if and only if you can't |
93 |
use native capabilities. You don't see a million different versions of |
94 |
the Linux kernel, each containing different configuration settings with |
95 |
all the #ifdefs removed... |
96 |
|
97 |
> > kdebuild-1 was not experimental. It was an official Gentoo KDE |
98 |
> > project EAPI. |
99 |
> |
100 |
> Goodie on them. Note that it's "official gentoo kde project", not |
101 |
> "official eapi". |
102 |
|
103 |
Are you saying that the Gentoo PMS project should tell other Gentoo |
104 |
developers to go away when they ask for help? |
105 |
|
106 |
> > And at the time, the Gentoo KDE project considered kdebuild-1 to be |
107 |
> > an official EAPI. |
108 |
> |
109 |
> And they have zero ability to define what is an official EAPI. |
110 |
> Misunderstanding reality bluntly, is their problem. |
111 |
|
112 |
Are you saying that the Gentoo PMS project should overrule GLEP 39? |
113 |
|
114 |
> Further, note prefix- that is a far more widespread deployment of an |
115 |
> experimental eapi, longer lived (and still living even). PMS ain't |
116 |
> on the hook for their experimental work- they went and got it |
117 |
> approved as an EAPI, for the new EAPI pms is *now* on the hook. |
118 |
|
119 |
Prefix never had an official, stable specification, which was all that |
120 |
kept it out of PMS. |
121 |
|
122 |
Again, you still haven't said what's wrong with doing a clean, phased |
123 |
withdrawal. This looks a lot like you're jumping on the "let's try to |
124 |
cause trouble and disrupt things" bandwagon here. |
125 |
|
126 |
-- |
127 |
Ciaran McCreesh |