[Tinyos-help] Re: [Tinyos-devel] CTP + LPL

[Philip Levis]

On Feb 9, 2008, at 5:11 AM, Matt Welsh wrote:

> The problem with this approach is that folks generally won't update  
> all of the TEPs for each release so I expect there will be a lot of  
> drift. Also, the TEP approval process is currently very lengthy. As  
> a result the code will inevitably be released before the TEP has  
> been finalized, and indeed during the TEP review there may be  
> issues raised which cause the TEP to be changed and require changes  
> to the corresponding code as well.
>
> As I understand it, the point was that you're supposed to get  
> things approved in TEPs *first* (so everyone agrees on the  
> interfaces and functionality) and *then* go write the code. Usually  
> we do it the other way around and the TEP approval ends up being a  
> rubber stamp on whatever happens to be in the code.
>
> Of course, documentary TEPs may be different than "regular" TEPs,  
> but I don't quite understand the difference.
>
> It is clear that there is a tension between wanting to innovate  
> rapidly on one hand and maintain a formal procedure for vetting of  
> interfaces and code on the other. I'm not sure how to resolve this.  
> It would be unfortunate if we allowed the TEP process to slow down  
> progress on the code. At the same time with increased user base we  
> need some way of maintaining stability. Personally, I've never been  
> convinced that a heavyweight TEP process is the right way to do  
> this given the small size and relatively tight-knit nature of the  
> TinyOS community. The Java Specification Request (JSR) process is  
> similar to TEPs but I think we would all agree that the Java  
> community is much larger and has many, many more players with  
> competing interests. We should be able to be much more agile.

There's also a difference between the historical and present-day  
approach. Historically (e.g., TEP 1-119), T2 was an alpha-stage  
project that a few developers were working on. Now, there's a user base.

TEP first, code later is a non-starter. You can reach consensus on an  
interface that looks great, but as soon as you try to write it, it  
becomes clear that it's terrible.

So far, TEP authors have been pretty cautious in proposing TEPs to  
the community. For example, TEP 118 has been in use for over a year,  
and its authors were actively discussing, developing, testing, and  
exploring approaches for many months before that. It's only recently  
that someone has pointed out the ambiguity (and issue) on the  
semantics of whether changes signal local updates. That's really the  
kind of insight and observation the TEP review process seeks.

So far, in practice, a documentary TEP describes something that a  
working group has worked on and developed for some time. It's not a  
rough idea riddled with terrible holes. That being said, before  
setting it in stone, the working group appreciates the perspective  
and input of the community to find issues that the WG may have missed.

Phil