[plt-dev] a common collection for utility modules

Eli Barzilay wrote:
> On Nov  6, Carl Eastlund wrote:
> [...]
>> I see, mostly, the reduction in stuff that needs to be tidied up and
>> removed, because there are more eyes on this code, more people
>> picking it up and using it, more people who might keep it in good
>> shape.  Any that stays in bad shape, well, would have anyway.
> 
> Why does it have to be this way?  This is like claiming that most of
> the tree is closed source.  What's preventing you from going over
> other people's code and fixing things?  Or pointing out things that
> should be shared?  Or telling them that something is so useful that if
> they just generalize that one bit and put it in a more general
> library, you'll volunteer to document, write tests, and maintain it?
> This lack of shared workload is something that exist now, and
> `unstable' is just putting a new label on it.
> 
> 
>> The fact of the matter is, we each currently treat our internal code
>> as our personal code.  And this is not realistic.
> 
> Yes -- fix that!  And it can be fixed regardless of a new toplevel
> label and a new kind of a "not really organized collection of code"
> tool.

The fact is, we tend not to interfere in other people's collections 
much. I've been talking about this phenomenon with various people around 
the Northeastern lab for years. After many discussions, I still don't 
have a good idea of how to fix it. So I'm attacking a related problem 
with a different approach.

Rather than encouraging developers to wander around in other people's 
territory, I'm encouraging them to put more of their work into a common 
space. Why should you go hunting through my code for useful bits when I 
have a much better idea of what is generally useful and what is specific 
to my particular needs? And a collection is a very useful label to hang 
on the common space, one that interacts well with other needs such as 
documentation.

(Infamous Ryan-Analogy: There are two ways to increase social 
interaction. Encourage people to barge into others' personal spaces, or 
encourage everyone to spend more time in public spaces. I'm going for 
the latter.)

If you want to fix the other problem, go for it. But shouting "Be it 
so!" doesn't seem to work.


> On Nov  6, Ryan Culpepper wrote:
>> Eli Barzilay wrote:
>>> (Leaving beind an unstable library that I'm using, and nobody
>>> owns.  A major point that I failed to make initially is that such
>>> code should never, IMO, become permanent.)
>> If you're using an unstable library and nobody owns it... you own
>> it.  Unless you can foist it off on someone else. If no one else
>> owns it you can, of course, start assimilating the parts you want
>> and junking the rest.
> 
> See above.  What needs fixing is for people to start looking beyond
> their collections -- regardless of a new collection.  (And you can
> summarize my above concern as: if this is not fixed, then we haven't
> done anything besides shuffle some code around -- so now people still
> don't care, and the code is messier.)

Shuffling code around, when done carefully, is called *organizing*. I 
think people are more likely to care once the code becomes better organized.

I'll volunteer to watch over the unstable collection to make sure it 
doesn't degenerate into long-term chaos. (I make no promises about 
short-term chaos.)


>> If no one depends on it and no one owns it or wants to, it can be
>> junked immediately. And yes, we should periodically review the
>> unstable collection and eliminate dead libraries. We should probably
>> do the same for all collections, but there's a higher risk of
>> breaking code in planet or in some other project when we do that.
> 
> So why not do that??  Everyone's jumping up and down about adding new
> stuff, but when it comes to improving existing code then we get these
> "should probably"s.

Just because there's work to be done in maintaining existing collections 
doesn't mean that it isn't worth adding another one. The movement of 
code might even indirectly help the existing collections.

Ryan