Re: scalable event scheduling

On 01/30/2013 06:30 PM, Amos Jeffries wrote:

> I've kind of gone off the idea of leaving old code using a wrapper API
> with the old behaviour. All that we have got out of that approach is
> added technical debt for others whoc have to ome along afterwards and
> learn two API interfaces then decide which ne to remove

I agree that adding a conflicting API is bad, so I would like to add a
fourth step to my sketch:

4. Upgrade all users of eventDelete(f,a) API that currently supply a
non-NULL second argument to use new eventDelete() that supplies an async
call (from step #1). If possible, convert all other eventDelete users to
the new eventDelete(). If not possible, rename the old two-argument
eventDelete(f,NULL) to a single-argument eventDeleteAll(f) call.

This fourth step will eliminate or, in the worst case, minimize doubts
and conflicts for future API users.

> It is far better, easier, simpler, safer to have the one person who
> understands the change properly, replace all the existing API fuctions
> in one polish patch. This will also teach them if there is some weird
> caller hidden somewhere that breaks under the new design. AND, will
> assist with portage by causing build errors when the API from newer code
> is not converted to the older versions required API.

Agreed. Unfortunately, it is often the case that the "one person who
understands the change properly" is nowhere to be found, too busy, is
viewed as disrupting attempts to fix something by others, and/or
multiple people think they understand the change properly, but their
understanding differs :-).

If we had more long-term contributors, we could probably solve this by
officially designating people to be permanently responsible for code
areas they know best. For now, we all have to modify and review code we
do not fully understand and deal with the consequences. I hope we can
continue to do that in a civil way.

Cheers,

Alex.
Received on Thu Jan 31 2013 - 05:45:03 MST