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

[Matt Welsh]

Fair enough, though I'm still unclear on what changes to TinyOS  
require a corresponding TEP (along with the associated review/comment/ 
revision process).
In this case, did David Moss' change to the CC2420 radio stack  
necessitate a TEP update, and why or why not? Where do we draw the  
line between folks hacking on the code as they please and having to go  
through the TEP review to get a change okayed by the community?



On Feb 9, 2008, at 2:35 PM, Philip Levis wrote:

>
> 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
> _______________________________________________
> Tinyos-devel mailing list
> Tinyos-devel at millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel