[Tinyos-2.0wg] three proposals

[Philip Levis]

On Jul 27, 2006, at 12:52 AM, henri dubois-ferriere wrote:

>
> about bit-rot: i agree that it is inevitable.
> but i still propose that the caretaker should be allowed to remove
> rotten code from contrib, if:
>
> a) It is _really_ rotten (*)
> b) It is not fixed after some number of weeks/months, despite repeated
> requests from the caretaker(s) to the module owner(s). This delay
> could  be quite large, e.g. 2-3 months - the aim is not that all
> contrib is perfect at any point, but rather to avoid long-term cruft
> accumulation.
>
> (*) My idea of "really rotten" is simply that it does not build. a
> first-order criterion of course, but at least it is objective and very
> easy to verify.
>

Martin raised an interesting point here: it can be good to have the  
code there, even if it doesn't work, as some kind of historical  
record. Even if the code doesn't work, people can pick it up to tweak  
it and make it work.


>>
>
> While we're at it, I think we should also add some bug-related
> policy/requirements for releases. I think it would be highly
> beneficial for the project as a whole to have a clear policy of
> cleaning out bugs before a release.
>
> I'm not proposing to add heavy rules and process, btw. But it would
> already be a great improvement at least have a real code freeze and
> bug-scrubbing period of 1-2 weeks, with someone (Phil? ;)) exhorting
> the troops to clean out as many bugs as possible.
>
> This is not just about code quality. It's also about the image we
> project to the outside world, and, ultimately, adoption of the system.
> Tinyos is not (yet?) a very industry-oriented project, and even less a
> commercial product, but we would gain a lot in credibility by showing
> that bugs are not only fixed depending on the whims and availability
> of developers.
> [ I can say from prior experience that users are not encouraged to
> stick with a system if they file easy, legitimate bug reports (with
> patches!) and these are ignored by developers. That happened in 1.x,
> and we should make sure 2.x improves in this respect as well.]
>
>

Agreed. One issue that always came up was bugs being assigned and  
then ignored. With the newer proposed approach of removing  
unsupported code that's rotting, this might stop being an issue.


> Q: When you say above that developers "filter" bugs, does that mean
> tinyos-bugs is moderated? Moderating is a pain of course, but
> otherwise i am pretty sure tinyos-bugs will start to be inundated with
> messages that rightly belong to tinyos-help...
>

Ah, no, -bugs is not moderated. Rather, developers filter the  
submissions to -bugs and decide which should be in the actual bug  
tracker.



>
> Could you clarify the role of experimental/ with regards to something
> like beta/ in 1.x? Is it the basically the same thing?
>

If anything, it's closer to broken/experimental; it's intended to be  
a place where people can develop alternative implementations and  
easily shadow components. One of the things in beta/ was an  
assumption of eventual inclusion into the core, which was initially  
followed but not after the first few months. As all code in  
experimental/ is on a branch, we won't run into this kind of issue  
with checkouts.



>
> PS: If you are looking for people to do the contrib caretaking, I can
> volunteer to start doing this and propose an schema/index [ i will be
> out of my thesis writing black hole within 10 days ].
>

That would be great. If you would like to be the first contrib/  
caretaker, that would be an excellent step forward.


> PPS: Same goes for bug filtering (if this is to be done by specific
> people rather than collectively; I am guessing in the latter case bugs
> are more likely to be left un-entered into the database).

The hope is that this is something *all* developers do, or at least  
participate in. If you are interested in being a large participant,  
that would also be wonderful.

Phil