[Tinyos-2.0wg] three proposals

[henri dubois-ferriere]

On 27/07/06, Philip Levis <pal at cs.stanford.edu> wrote:
> In the last teleconference, three concrete proposals for managing the
> code base came out. Does anyone have objections or concerns?
>
> A) contrib
>
> TinyOS 2.0 should soon have a contrib area much like tinyos-1.x.
> After some discussion, the agreement was that this should be a
> separate top-level module, tinyos-2.x-contrib, so that people who do
> a checkout of the TinyOS 2.0 code can distinguish the two. How to
> download contrib should be made very clear to maximize its
> visibility. There are three basic concerns about tinyos-2.x-contrib:
>
>    1) Schema: the organization of the contents therein
>    2) Index: being able to find elements within it
>    3) Bit-rot: what to do about projects that fall on the wayside
>
> The general conclusion was that 3) is very tough to deal with and is
> inevitable. 1) and 2) could be solved by having a person in charge of
> care-taking contrib. The assumption is that this isn't a tremendous
> job: you're not nitpicking individual code, rather the higher-level
> directory structure. Whomever this caretaker is can decide what the
> schema and index are.
>

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.



> B) tinyos-bugs
>
> The sourceforge bug tracker doesn't work very well, partially because
> half of them aren't bugs in TinyOS but rather misconfigurations of
> installations. Making tinyos-help a bug list seems like a bad idea,
> in that developers should not have to sift through help to find bug
> reports. The proposal was two-fold:
>
>    1) Create a tinyos-bugs mailing list, to which all bug reports
> should be sent.
>    2) Make the SF bug tracker only accessible to developers. When
> bugs come into tinyos-bugs, developers filter them, and if they pass
> the filter, put them on the SF bug tracker and assign it to the right
> person.
>

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.]


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...


> C) experimental
>
> TU Berlin commented that the current branching approach is causing a
> headache, because there are multiple development branches and trying
> to keep all of them up to date through merges is tough. The
> observation was that component shadowing (as was often done in 1.x)
> is a much easier way to do this, as you can have two versions
> concurrently. However, we do not have a good place to put shadowing
> code. The proposal is to create a new directory
>
> tinyos-2.x/experimental
>
> which ONLY has branch code on it. People can create directories
> inside experimental, on whatever development branch they want, in
> order to have a place for shadowing components.
>

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


Henri

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 ].

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).

>
> Phil
>
> _______________________________________________
> Tinyos-2.0wg mailing list
> Tinyos-2.0wg at Mail.Millennium.Berkeley.EDU
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-2.0wg
>