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 :-)
signature.asc
Description: OpenPGP digital signature
