[Tinyos Core WG] Instructions for contributing code

[Philip Levis]

On Dec 1, 2006, at 7:23 AM, Kevin Klues wrote:

>
> 1) We as caretakers create the top level directories for people and
> restrict write access to them based on the requests of someone
> designated as the maintainer of that directory.

I think this sounds reasonable, but in practice it was never a big  
issue in tinyos-1.x/contrib. CVS logs mean you can always see who's  
made modifications. The major reason to do this would be to prevent  
innocent mistakes. But I don't know of any such mistakes occurring in  
tinyos-1.x/contrib. Therefore this might just be a bit more procedure/ 
bureaucracy/work that has no real benefit. I didn't reinstitute the  
branch access controls on 2.x until the release, when innocent  
mistakes in where to check in what caused a minor nightmare in coming  
up with the correct set of files to release.

However, if it does become an issue, then by all means instituting it  
would be a good idea.

> 2) There is no restriction on how to name top level directories (or
> how to organize code underneath it for that matter).  If the first
> person from UCLA comes along and thinks that ucla should be the name
> of their folder, then they get to take it.  If someone else from UCLA
> comes along and doesn't want to work within the same namespace as the
> others already within the ucla folder, they can have a folder created
> for them with a different name and can work underneath that.

This makes sense. Assuming developers are reasonable people who can  
work these things out is a good thing to do. I might suggest that "no  
restriction" is perhaps a little stronger than what you mean, though.  
For example, I'd think that developers at Berkeley couldn't create a  
directory named MIT. But if they wanted to name it berkeley, ucb,  
berkeley-cs, berkeley-sna, sna, nest, soda-hall, would be up to the,.


> 3) We can suggest that each directory follows a structure similar to
> what the core does, but ultimately it can be organized in any way
> desired.

That makes sense. A SHOULD is probably appropriate. Break from it if  
you need to, but the advice is that generally following it will make  
everything easier for users.


> 4) The index file is where to go to look for projects.  Remove the
> notion of an unsupported project and only have stable and experimental
> ones.  It is up to the contributors to let the caretakers know that
> they would like their code included in the index (in either one of the
> two categories), and the only restriction for getting in is that they
> have some documentation somewhere that the index can point to that
> tells users how to use their code.  If the contributors say that they
> want their code to be categorised as stable when it really isn't then
> that's their loss because users will get frustrated with trying to use
> it.

I think that maintaining a list of unsupported codes is worthwhile.  
It might not be stuff that works, but it's stuff that you can look  
at, learn from, and adapt for your own purposes. You might want it at  
the bottom of the list, or with BIG RED WARNING SIGNS, but that does  
not mean it has zero value.

Phil