[Tinyos Core WG] Instructions for contributing code

[Philip Levis]

On Dec 1, 2006, at 12:00 AM, Prabal Dutta wrote:

>
>
> By management, do you mean a convention for managing the directory
> namespace?  Since there's no connection between directory structure
> and namespace, I don't see the benefit of this organization from a
> management perspective.  Who within, say "UCB", will help "manage" the
> UCB namespace?  Will the caretakers do it?  Will the first one who has
> write access?

It would be those who want to contribute under the UCB namespace. I  
assume that if group A from UCB creates the UCB entry and later group  
B from UCB wants to also use the UCB entry, then the two can work it  
out. Worst case, the caretakers lend a hand to figure things out. But  
I really think this is a rare event.

>
> I also question whether this would actually "keep related things
> close."  The only relation that is kept close is that the authors all
> labor under the same organizational umbrella or are co-located
> geographically.

You're telling me that all of the code written for 1.x at Berkeley is  
completely independent? DSN builds on SP; Flush uses MintRoute; Maté  
uses MultihopLQI. It happens to be that some of these things are in  
tos/, but that's mostly an artifact of the Berkeley-centric development.


>
>> > e.g., "a routing protocol." Levels of indirection considered  
>> helpful.
>> >
>>
>> I understand that such a directory structure certainly isnt to make
>> searching and browsing easier.
>
> I would argue that the proposed structure neither makes management
> easier nor keeps related things close in a dimension that is relevant
> to the codebase.  But, something organized around functionality, like
> Henri suggests, does make searching and browsing easier and more
> intuitive.

Yes. But the problem with tying classifications -- browsing and  
searching -- to directory structure is that if you want to change  
your taxonomy you have to change the directory structure (read:  
management is hard). You want to tie the directory structure to  
something that does not change much, if at all, then provide an index  
which can be changed easily. Hence, the HTML index.

For example, should the code stability -- supported, experimental,  
and unsupported -- be in the directory structure? I'd think that  
*this* is even more important than routing vs. sensors, etc. But then  
whenever code changes in status, you have to move whole directories  
around.

The basic premise with all of this, which I don't think people have  
quite understood yet, is that the goal is you browse and search using  
the associated HTML (maintained by the caretakers) rather than  
wandering around directories in a shell. Maybe this is not exactly  
what hardcore developers want, but I'd love to hear a compelling  
argument that

$ cd lib/routing
$ ls
MintRoute
BVR
CTP
NoGeo
GEM
Drain

is a better way to know what's available and what it can do than a  
simple web page (which has, for example, brief descriptions).

Ultimately, I think these decisions are up to the caretakers; they're  
the ones who have to do the work.

Phil