1 |
On Fri, 11 Dec 2009 18:34:09 +0100 |
2 |
Ulrich Mueller <ulm@g.o> wrote: |
3 |
> >>>>> On Fri, 11 Dec 2009, Ciaran McCreesh wrote: |
4 |
> >> We can considerably shorten this discussion, because it boils down |
5 |
> >> to the following: PMS is an official Gentoo document, and therefore |
6 |
> >> it's not upon you to make this decision. |
7 |
> |
8 |
> > Alright. We'll escalate this to the Council then. |
9 |
> |
10 |
> No need for that, as it has already been voted on in the 2008-04-10 |
11 |
> council meeting (repeating it, as you've added gentoo-council to CC): |
12 |
> |
13 |
> | The council voted that kdebuild-1 and other unapproved EAPIs could |
14 |
> | not be in an approved PMS document. The spec isn't a place for |
15 |
> | proposals or things that will never be submitted for approval by the |
16 |
> | council. It's a specification, a reference of what is allowed in the |
17 |
> | main tree. |
18 |
|
19 |
And the resolution for that was to make it possible to disable |
20 |
kdebuild-1. That is not the same as deleting it while there are still |
21 |
users who have kdebuild-1 packages installed. |
22 |
|
23 |
I shall remind you, the Council-approved process for PMS changes is to |
24 |
send them to this list, and if unanimous agreement can't be reached, |
25 |
then to escalate the issue to the Council. |
26 |
|
27 |
> > In the mean time, I'll give Christian a day or two to revert every |
28 |
> > patch he's applied recently that didn't follow the Council-mandated |
29 |
> > review process, or I can do the revert for him if he doesn't have |
30 |
> > time himself. |
31 |
> |
32 |
> Don't. |
33 |
|
34 |
Sorry, but the Council-approved procedure is that patches get sent to |
35 |
this list and don't get committed until there aren't objections. We |
36 |
don't commit things until everyone's happy with them. |
37 |
|
38 |
I have objections to several of those patches, and they haven't been |
39 |
addressed. If you'd like to address them now, please do so: |
40 |
|
41 |
* When did it become policy to use the newest EAPI for ebuilds? I |
42 |
must've missed that becoming policy -- last I heard, policy was to |
43 |
use the oldest EAPI that provides everything you need to write a good |
44 |
ebuild. |
45 |
|
46 |
* Since PMS became 'suitable for use', we've never committed works in |
47 |
progress to master. We've always used branches for EAPI definitions |
48 |
that aren't complete, and we've never committed EAPIs that haven't |
49 |
had their wording approved by the Council to master. Why are we |
50 |
changing this policy? Where was this policy change discussed? |
51 |
|
52 |
* Why is disabling kdebuild-1 by default helpful? Why not take the |
53 |
reasonable steps already mentioned first, to ensure that the change |
54 |
does not have adverse impact? |
55 |
|
56 |
-- |
57 |
Ciaran McCreesh |