[Tinyos Core WG] TinyOS 2.x release RPMs are BROKEN for eyesIFX,

[Vlado Handziski]

Hi all,

On October 28th, after the code freeze, the repository was tagged with
tinyos-2-0-0-release-candidate all platform owners were asked to make
extensive tests before the release.

One day later, on October 29th, we have reported the test results for the
eyesIFX platform to the list. Apart from some small issues all the tests
Passed. With this, the testing for eyesIFX has been considered completed.

According to the agreement, only SMALL BUGFIXES were allowed at this point
of time since the code was frozen.

With regret I have to inform you that after tinyos-2-0-0-release-candidate
and tinyos-2-0-0-release substantial errors were introduced in the tree
during the attempted merging. Old files were introduces, new ones were
removed, etc.

As a consequence, in contrast to tinyos-2-0-0-release-candidate,
tinyos-2-0-0-release is BROKEN for eyesIFX, but also for msp430 in general
although the number of affected applications for telosb is smaller then for
eyesIFX.

Since the released RPM is based on the tinyos-2-0-0-release tag, the errors
are propagated to the final users.

I take part of the responsibility for the error because I was not able to
test the proposed RPM in time due to SPOTS paper submission stress. But we
can not expect from the platform owners to repeat the whole bunch or tests
after every commit in the repository. We agreed that release-candidate is
the tag for testing, and we reasonably assumed that if eyesIFX passed those
tests, that it would do so in the final RPM also.


Now, there are two important questions that I like to put to the group:

1. How should we proceed to detangle the mess and bring the repository  in a
sane state as it was during the tinyos-2-0-0-release-candidate tag? The
introduced errors are intermixed with LOTS of small and useful fixes that
were committed in the same period. A new RPM should be made available on the
www.tinyos.net site ASAP.

2. What changes should we introduce in our release testing cycle so that
major errors like this don't happen in the future?

As for 1, I see two alternatives. One is that we roll back to
release-candidate and then try to hand merge the "useful changes" made
since. The other is to start from the current state and manually weed out
all erroneous files, hoping that we fish out all mismatches.

As for 2, I think it is high time that we introduce some automatization in
the testing process. Although we can not test the correctness of the actual
execution of the applications, we can at least automate the
testing/reporting of compilation errors. If we had such a system in place,
monitoring the successful compilation of ~ 10 standard test applications, we
would not have been in the situation we are now. BuildBot (
http://buildbot.sourceforge.net/) seems to be a n appropriate tool for our
needs.


Vlado
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.millennium.berkeley.edu/pipermail/tinyos-2.0wg/attachments/20061116/e7e8ddb9/attachment.html