On 07/10/2010 10:34 AM, Brian Harring wrote:
> If people want to allow eclasses to have fluid APIs (specifically
> removal of functionality), that's a discussion that needs to start on
> the dev level.
>
> Anyone got strong opinions on this one?

The argument was presented a long time before: we can't care about
things not in our tree, there might be thousands of twisted ways our
eclasses are used we can't control. If nothing is broken in gentoo-x86,
we as developers should be allowed to make the change. To ensure the
change is indeed not breaking stuff, RFCs to -dev are a requirement.

Everybody who copied and re-used our eclasses should be reading -dev (or
at least -dev-announce), anyway. Not our fault if they run an open
system (as in, I've not nailed all my versions down and use a static
tree) and do not keep up with it.

Now, I'm aware that RFC and implementation periods should depend on the
impact of the change - if I'm proposing to alter eutils, I better wait
some time AFTER a conclusion has been reached, so everybody can adapt.

That 'should' above is intentional - prescribing a fixed time period for
every possible change does not give devs enough flexibility and
implementation time may be a subject during RFC anyway. To continue the
eutils example: if I keep a custom overlay which depends on the removed
functionality, I will speak up and ask you defer the change 14 days so I
can fix my overlay.

Similarly, if somebody still uses the php4 bits in depend.php eclass,
please speak up and allow me to convince you of the php5 ways :-)