[Tinyos-alliance] below Quorum

[Matt Welsh]

>
> (1) I wanted to get a sesne from the WG of what matters the BoF put  
> on out plate.  The most obvious one to me is to formalize
> the process of code moving from contrib to "the main branch".

For those that were not at the BoF at Sensys let me summarize the  
issue and the discussion.

I raised the question of how the TEP process relates to the source  
code release process. In particular, how does code get contributed to  
the TinyOS tree?  Under TinyOS 2.x, the model is that anyone can  
contribute code to the 'contrib' tree, but only certain users can  
check code into the 'main' tree. However, there is no strong binding  
between the two: the set of users that can checkin to the main tree  
are under no obligation (currently) to ensure that code is related to  
a finalized TEP. As a result we have a situation where the core is  
just whatever people choose to checkin; and the code you find in the  
tree may not look at all like the TEPs that documented the original  
design.

Phil L. and I discussed this for a while and we were in agreement  
about the following proposal. (Phil, please chime in if there's  
something I am missing...)

In order for code to be part of the main tree, it should be  
associated with a finalized TEP. For example, the Timer subsystem or  
the networking subsystem in the main tree should be the  
implementation related to a TEP that has been finalized (that is,  
gone through all of the cycles of revision, community review, and  
shepherding).

The critical point is this: If someone wants to make major changes to  
code in the mainline codebase, *they must go through another TEP in  
order to do so*. An example would be changing something fundamental  
about the routing protocol or the timer system. The original  
developer (despite having CVS commit access) should not simply change  
the code without having a TEP to get feedback and review from the  
community.

One question that comes up is what constitutes a "major change".  
Small bugfixes and even minor performance enhancements should not  
require a TEP. So, we need to rely on the developers' good judgement  
to decide which new features need TEP approval and which do not.  It  
would be helpful to have some documented guidelines.

Of course, this model is not without its challenges. In particular I  
fear it will slow the development and release cycle considerably. Of  
course, users can always prototype and push new code out quickly via  
contrib. But we don't want to erect so many barriers that users  
prefer not to go through the process. This might be balanced out by  
the observation that those developers that want their code included  
in the main tree have an incentive for going through the TEP process.  
I would really like to hear comments from folks on this. I think we  
need to bring this proposal to the developer community to get their  
reaction as well.

Matt