[racket] Should we _always_ use `only-in` or `prefix-in` when `require`-ing packages?

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
>