[Tinyos-2.0wg] three proposals

[Philip Levis]

In the last teleconference, three concrete proposals for managing the  
code base came out. Does anyone have objections or concerns?

A) contrib

TinyOS 2.0 should soon have a contrib area much like tinyos-1.x.  
After some discussion, the agreement was that this should be a  
separate top-level module, tinyos-2.x-contrib, so that people who do  
a checkout of the TinyOS 2.0 code can distinguish the two. How to  
download contrib should be made very clear to maximize its  
visibility. There are three basic concerns about tinyos-2.x-contrib:

   1) Schema: the organization of the contents therein
   2) Index: being able to find elements within it
   3) Bit-rot: what to do about projects that fall on the wayside

The general conclusion was that 3) is very tough to deal with and is  
inevitable. 1) and 2) could be solved by having a person in charge of  
care-taking contrib. The assumption is that this isn't a tremendous  
job: you're not nitpicking individual code, rather the higher-level  
directory structure. Whomever this caretaker is can decide what the  
schema and index are.

B) tinyos-bugs

The sourceforge bug tracker doesn't work very well, partially because  
half of them aren't bugs in TinyOS but rather misconfigurations of  
installations. Making tinyos-help a bug list seems like a bad idea,  
in that developers should not have to sift through help to find bug  
reports. The proposal was two-fold:

   1) Create a tinyos-bugs mailing list, to which all bug reports  
should be sent.
   2) Make the SF bug tracker only accessible to developers. When  
bugs come into tinyos-bugs, developers filter them, and if they pass  
the filter, put them on the SF bug tracker and assign it to the right  
person.

C) experimental

TU Berlin commented that the current branching approach is causing a  
headache, because there are multiple development branches and trying  
to keep all of them up to date through merges is tough. The  
observation was that component shadowing (as was often done in 1.x)  
is a much easier way to do this, as you can have two versions  
concurrently. However, we do not have a good place to put shadowing  
code. The proposal is to create a new directory

tinyos-2.x/experimental

which ONLY has branch code on it. People can create directories  
inside experimental, on whatever development branch they want, in  
order to have a place for shadowing components.


Phil