1 |
On 07/10/2010 10:34 AM, Brian Harring wrote: |
2 |
> If people want to allow eclasses to have fluid APIs (specifically |
3 |
> removal of functionality), that's a discussion that needs to start on |
4 |
> the dev level. |
5 |
> |
6 |
> Anyone got strong opinions on this one? |
7 |
|
8 |
The argument was presented a long time before: we can't care about |
9 |
things not in our tree, there might be thousands of twisted ways our |
10 |
eclasses are used we can't control. If nothing is broken in gentoo-x86, |
11 |
we as developers should be allowed to make the change. To ensure the |
12 |
change is indeed not breaking stuff, RFCs to -dev are a requirement. |
13 |
|
14 |
Everybody who copied and re-used our eclasses should be reading -dev (or |
15 |
at least -dev-announce), anyway. Not our fault if they run an open |
16 |
system (as in, I've not nailed all my versions down and use a static |
17 |
tree) and do not keep up with it. |
18 |
|
19 |
Now, I'm aware that RFC and implementation periods should depend on the |
20 |
impact of the change - if I'm proposing to alter eutils, I better wait |
21 |
some time AFTER a conclusion has been reached, so everybody can adapt. |
22 |
|
23 |
That 'should' above is intentional - prescribing a fixed time period for |
24 |
every possible change does not give devs enough flexibility and |
25 |
implementation time may be a subject during RFC anyway. To continue the |
26 |
eutils example: if I keep a custom overlay which depends on the removed |
27 |
functionality, I will speak up and ask you defer the change 14 days so I |
28 |
can fix my overlay. |
29 |
|
30 |
Similarly, if somebody still uses the php4 bits in depend.php eclass, |
31 |
please speak up and allow me to convince you of the php5 ways :-) |