Net2WG/Notes/20080718

From TinyOS Wiki
Revision as of 09:32, 1 August 2012 by Gnawali (talk | contribs) (New page: ---------- = Meeting Notes = ---------- = Agenda = ---------- * 2.1 Release Plan * TEP 119 * ZigBee/15.4 WG = Participants = ---------- * Om, USC * Razvan, JHU * Phil, Stanford * ...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Meeting Notes


Agenda


* 2.1 Release Plan
* TEP 119
* ZigBee/15.4 WG

Participants


* Om, USC
* Razvan, JHU
* Phil, Stanford
* Mike, JHU

Discussion Notes


2.1 Release Plan

Phil: RC3 just went out, and I think we are ok. Hopefully the testing will be done by next Wednesday.

Om: Do you know how FTSP was tested? Is it tested in real multi-hop network?

Phil: There are test applications. I am actually responsible for testing on MicaZ. I tested in a single-hop network. You can't really test in a 100-node test bed.

Om: I am also planning to test FTSP.

TEP 119 Comments

Om: Most of the comments seem reasonable, including the ones about the wording.

Phil: You might want to make the necessary changes in the TEP, and tell the shepherd what you did or didn't do (and why).

Om: Phil, please address the comments that we are not going to change on the Wiki. I think we will have this done in a week or two. Does that mean it will be included with the release?

Phil: Documentations are separate.

Razvan: There is one comment about the collection "may"/"should" signal receive event on the root node. Phil, why do you think it should be "may", not "should"?

Phil: When I was writting the TEP, the decision was between "may" and "must". "Should" basically says that you generally want to do it, unless there is some compelling reason. I didn't think it should be "must". You could have a special base station where receive doesn't work as an interface. It could be storing packets, forwarding it to serial, and etc.

ZigBee/15.4 WG

Phil: My only concern is that a working group should represent multiple interests. Basically, a way to bring in different groups.

Om: My main concern is that we should have some admission control. And, having people from multiple institutes is one way to achieve that.

Razvan: What about support for code released by the WG?

Phil: Technically, each WG is responsible for sub-sets of the tree. And, if the WG is no longer active, it should be removed.

Om: What should our recommendations be?

Phil: One thing we should make clear is that net2 doesn't consider that all networking protocols are under its umbrella. And it is up to the developers. Whatever the environment they feel is best for the development. That being said, the goal of WG is bring different people and ideas. As the WG proposals says, new WG need to have representatives from different institutes.

Razvan: What if people run away after checking in the code?

Phil: If the code maintainer runs away, then the question to WG is if there is someone else that will support the code. If not, then it is out.

Mike: I think there is a rule saying that the maintainer must support for one year.

Phil: True, that's the policy that Core takes. The observations is that one year is long enough for users to use the code, and also to find someone to step up if the maintainer decides not to support it. A good example is iMote 2.

Om: I will send out net2's official recommendation.