Social processes are good. Participants should try to find
mutually-agreeable balances between proactive and reactive in their
interdependencies.
Some people (myself included) are likely to be scared if some third
party on whom we depend seems to take *too much* of an attitude of "it's
OK if I don't put seem to put much effort into not breaking your stuff,
since you can just file a bug when I break something, and I'll fix it
immediately". I'd be much more comfortable about that philosophy
*within the same project team*; less so, across teams, organizations,
and time. (Although there are ways that I have seen that go very bad
even within the same project team, with one cavalier cowboy leaving a
path of destruction through many other people's schedules and morale.)
We all try to be conscientious of who uses our code (since people who do
not tend to get removed from the gene pool), but it's good to find the
right proactive/reactive balances in the things we produce, and to know
what what the balances are in things on which we depend.
Neil V.
Matthias Felleisen wrote at 11/18/2013 12:10 PM:
I am with you on the scenario but I think 'early failure' is good because a
mostly compatible upgrade (widening the API) may have introduced other small
changes and all packages between yours and the modified one may suffer. So I
would love to see that our social processes push people to repair against
'widened' APIs as soon as possible i.e. you'd file a but report against one of
these packages. -- Matthias
____________________
Racket Users list:
http://lists.racket-lang.org/users
