Assembling our next legOS Release

NEWS: made a number of page updates

Last update: 11 May 2002 13:19 MST

[Desires] [Constraints] [Issues] [Numbering] [Documentation] [Packaging] [Volunteers] [ChangeLog]

We are working on this release because we enjoy using legOS and wish to help it to continue to be improved. We want to have fun putting together this release. We are working on the next level of *fun* for all legOS users. To this end we are stating the following Desires so we know what we are signing up for. We are stating the Constraints so we know what we are not doing and we state the Issues so we can make a first determination for each of them so we are enabled to work towards delivering a successful release.


We've released 0.2.6 - a tiny interim release which served to formalize the CVS content which contained a number of bugfixes against 0.2.5.

We are working on our next major release:
  It will likely be a number change but we are calling it 0.2.7 for now.
  It will be a project name change.


There are some things that we immediately, as users of 0.2.5, wished we had. Let's address these wishes. Likewise, we have the benefit of University-level study and experimentation against the legOS interrupt handling/servicing. We should seriously evaluate and then apply (if it meets our goals/constraints) the interrupt servicing mechanism patches. We need to freshen our existing documentation. We also have been working on internal comment styles so that we can use Doxygen to generate the legOS API reference automatically, let's release this. And last but not least is our need to accomplish our pending name change

With all of this we have to remember that this is an embedded system, so we have serious physical constraints. Any memory we absorb for use by the OS we remove from program download space, we have to be deliberate in our growth of legOS.

Functional Desires

In more specific terms here is our first cut as what we think this next release is:

Sources of material under consideration

We have 10 patches that I have found, We need more examples, we have new content in CVS not yet released, we have bugs reported at sourceforge site - some at lugnet site, and there is probably more desirable content we have not yet identified.

Here's the list of patches I know of and the current status:

  1. 403527 - LNP checksum optimizations - (dibbe) Bernardo Dal Seno
    • this patch DID NOT apply cleanly to the released 0.2.5
    • affects 2 files
    • looking into the problem, Sending email to author.
    • ACCEPTED into release 0.2.7
  2. 403728 - LNP optimizations versus CVS - (bodnar42) Ryan Cumming
    • patch applied OK
    • affects 1 file
    • Question: How do 403527/403728 relate to each other?
    • ACCEPTED into release 0.2.7
  3. 404053 - Remote control patch for legOS 0.2.4 - 0.2.5 - (roscohead) Ross Crawford
    • patch applied OK
    • affects 6 files
    • ACCEPTED into release 0.2.7
  4. 475185 - Remote Control and Standard Message Patch for legOS 0.2.5 - (mikezang) Zhengrong Zang
    • patch applied OK
    • affects 13 files
    • ACCEPTED into release 0.2.7
  5. 552135 - RCX Remote control support and misc. fixes (thess) Ted Hess
    • patch applied OK
    • affects 3 files, has readme
    • What other 3rd party sensor/control devices do we want to consider?
    • ACCEPTED into release 0.2.7
  6. 515185 - Active multiplexer driver for 0.2.5 (mfalco) Mark Falco
    • patch applied OK
    • affects 3 files, has readme
    • What other 3rd party sensor/control devices do we want to consider?
    • ACCEPTED into release 0.2.7
  7. 544524 - Switch multiplexer driver (mfalco) Mark Falco
    • patch applied ????
    • affects ...
    • ACCEPTANCE into release 0.2.7 pending review of patch
  8. 544526 - dual ir proximity detector driver (mfalco) Mark Falco
    • patch applied ????
    • affects ...
    • ACCEPTANCE into release 0.2.7 pending review of patch
  9. Priority Interrupt Patch: 3 Students in Computer Science at University of Aalborg
    • Patch fails to apply, (RCS) .diff file is not recognized by patch utility
    • Affects 23 files
    • This appears to be deltas against an older release 0.2.3 (per their docs).
    • Found at Dat4 Project Site
    • We need to apply lessons learned but not specifically in this form...
  10. The TCP Patch... (not sourceforge user) Olaf Christ
    • IS NOT distributed as patch but as collection of files with installation instructions
    • this is an alternative form (to LNP) which may be lesser used and it consumes significant memory
    • Question: should we structure this as a kernel build time configuration parameter?
    • [See more info in "Issues" section below]
    • Determined to not meet our criteria, this not entering release
We need more examples and sample code. I'm thinking we each have favorites we would like to see added. Let's all email our suggestions. This can be suggestions for example's you feel we need and it can be examples you feel you can contribute. Where we have duplicate offers of contribution the people offering the duplicates will decide who's should be submitted.

I'm thinking that existing CVS content should be made ready for release and then it along with any patches we select should be merged together to produce the latest new code in CVS. I will probably do this merge outside of CVS using commercial tools available to me but then will version the results in CVS so we can work to test and repair issues found in CVS from this point forward. Lastly, we'll release only from CVS.

What else should we add? [See the related item under the heading "Issues"]


Prior to 0.2.6 we've been without a release for about a year and a half. IMHO I think we need to keep this focused so we can get this release out quickly and then work on the next. So here's a proposal to keep us moving:

OPEN Issues

I'm sure there are more (please tell me and I'll add them) but here's what I see so far:


The following issues have been resolved for one reason or another as indicated by each issue.

Test Version Numbering

Our current numbering scheme was started when legOS was started. We have a problem, now, in that we would like create minor releases but the field is already in use as our current releases are all minor (our major number is zero). So, to keep this simple we'll number by adding another minor digit to the right with a thought to maybe we reset the numbering (go to 1.0.0?) when we move to our new name.

We are building semi-public test releases of what will eventually be called 0.2.6 followed by 0.2.7. To this end we will number these early versions as offshoots of the prior release 0.2.5 or 0.2.6 as appropriate by using 0.2.5.x numbering (or 0.2.6.x numbering) where the 'x' will be incremented with each test release. I thought about using .alphaX or .testingX but i then thought we should keep this as simple as possible.

Our goal in addressing this is to ensure that all of our public releases increase in number so various installers will know that each release replaces the earlier release. Installers that react to this today are: Debian GNU/Linux package manager and the Red Hat package manager.


Our current HOWTO (sgml) needs to remain the cornerstone of our documentation. It, however, does need to be freshened. We also have a newer HOWTO-cygwin (sgml) which needs to be released. Likewise, we want to add the generated API documentation.

Not all of this is in our current source tree (CVS) it needs to be added. Make rules need to be added to generate the HTML docs from the source as well as to generate a doc-only distribution tarball. This would allow our users to install legOS and optionally install the supporting documentation.

Packaging Desires

Certainly our final release will be packaged in at least the forms we've used to date. That is a source tarball. Red Hat RPMs and a Debian GNU/Linux package. I have no experience with the windows version but if we created a package/tarball for it we will do that for this release as well.

We should also package in a couple of these forms for each testing release so that will will be able to install and test a rapidly as we can.


To date I've received offers to help from the following people: (If I missed anybody please let me know...)


As I alter content of this page I'll update this ChangeLog with what I've done. This way one can obtain a quick overview of changes since the document was last viewed.
Updated page to reflect that 0.2.6 is released and that we are now working on 0.2.7
Updated patch list and acceptance status
Added new team members
Added colored status entry for patch list. Some accepted, some not going into release.
Added statement of intent to release 0.2.6 followed by a 0.2.7 (with name change)
Added new "RESOLVED Issues" section
Added NEWS section at top of page
Updated version numbering to reflect two releases
Added this section.
Add member sourceforge name,
Updated numbering description,
Set intent to use sourceforge tracker as new item in "Issues" above
Added text in Documentation section (final sentence.)

See Also: [effort] [install-RFC]

For details on legOS at sourceforge, try the development page.
For discussion on legOS, try the newsgroup at lugnet: lugnet.robotics.rcx.legos. This is definitely the best place to get legOS questions answered ASAP.
Most of all, remember: Have fun.

Hosted by:

SourceForge Logo