Assembling our next brickOS Release

We are working on this release because we enjoy using brickOS 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 brickOS 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.

NEWS

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

We are working on our next major release: brickos-1.0.0

Desires

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 brickOS API reference automatically, let's release this. And last but not least this will be our first release under our new name.

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

Functional Desires

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

• We need to move to our new name brickOS
• Support for the simplified messaging RCX to RCX that was in the earlier releases of legOS
• Support for the Universal Remote. It's an invaluable construction test aid
• Faster interrupt servicing with less interrupt loss
• Support for some of our favorite 3rd party sensors/mux's, etc.
• C++ support for any new equip. we support in C (let's not leave our C++ users behind) and vice versa.
• Richer programming examples (working examples from projects we've built from the LEGO Mindstorms(™) books, multi-tasking examples in C and some in C++, etc.)
• C only legOS library (API) reference (extracted from source code using Doxygen)
• C/C++ legOS library (API) reference (extracted from source code using Doxygen)
• Revised distribution shape appropriate to our two forms of users: (1) those who want to hack/enhance the kernel, and (2) those who simply want to program the RCX. (read this as we should have 'make distrib' target's and 'make install' targets. For a number of reasons one of which is that we are closer to normal Linux projects)

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

Constraints

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:

• This release should build and run with our existing gcc/g++ (egcs) and binutils. Let's take on a newer compiler next release. Maybe the next release is tiny in content (bugfixes?) so that we can concentrate on testing against the next version of the compiler and adjusting legOS to work with it.
• Let's use as much of what's already written (offered as patches) so that we suffer as little waiting on new development as possible.
• We should roll to the new name for all legOS site content but we'll probably defer the site change (sourceforge project change), if we need to do this, until after this release
• (I can't stress this enough ;-) We have serious physical constraints. Any memory we absorb for use by the OS we remove from program download space. Let's be careful in what we choose to do.
• Let's keep our code base clean. Watch how we add code, keep the style in which you are writing as similar as you can to what's already there. Clean up around the area, continue to move toward our Doxygen comments where ever we still need to (whenever what you commenting needs to show up in the API reference), etc.

OPEN Issues

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

• We need to choose a new name. I'm thinking:
  • one more round of name gathering (period TBD, two weeks?)
  • a simple email vote for each persons top three
  • then sum of the votes tells the winner.
  • --> Any counter proposals?
• So far I've only identified what I know to need attention or which exists. There's other great work out there, we need to identify it to each other in order to consider it for inclusion.  I'm thinking:
  • We have a period of open submissions (Period TBD, week or month?)
  • Then we decide?
• The priority interrupt patch will take some effort to apply to 0.2.5
  • This needs to be studied in some depth
  • Is this a couple of us or how should we handle it?
  • At the very least we need to read the document they wrote (9 pages or so) which describes the benefits and kernel size differences and then build a version and try it and then we can decide more fairly?
• We need to quickly identify first sources of contribution so that it can all be merged into CVS (carefully) so most of our release preparation will happed directly in CVS
  • This is one of our most looming early concerns.
• We've had a request to try to solve the build-a-kernel to create unique ID for LNP issue. Let's get this in this release.
• Where do we look for news? How do we communicate with each other? Should our developer communication be on lugnet legOS news group? -- we've a number of communications concerns:
  • IMHO I think we should use all the sourceforge services we have available when we have a need for them. When it comes to public questions / feedback / announcements then we should post to the lugnet legOS group.
  • To date, we have four posting mechanisms: (1) Bugs, (2) Support Requests, (3) Patches and (4) Feature Requests. We also have a email list archive/repeater. We can and should communicate to all of us developers simply by
    sending email to 'brickos-devel@lists.sourceforge.net'.
• {more ???}

RESOLVED Issues

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

• The TCP patch will take some time to restructure as build-time option
  • I've already received an important vote that this be left out as it is not central to legOS in order to drive the RCX and communicate with it. It is a fun effort and some important work in terms of tiny code implementing a TCP stack but may not be right for us
  • RESOLUTION: This patch will not be included in a brickOS release.

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 (.deb's) and the Red Hat package manager (.rpm's).

Documentation

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

Volunteers

To date I've received offers to help from the following people:

• Stephen Moraco (myself :) - release coordinator, project member/admin (stephmo)
• Mark Falco - project member (mfalco)
• Joseph Woolley - project member (jawoolley)
• Ed Manlove - project member to be (emanlove)
• Paolo Masetti - project member/admin (paolom)
• Ted Hess - project member (thess)

(If I missed anybody please let me know...)

ChangeLog

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.

Aug18

This page activated at brickOS site.

May11

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

Mar29

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

Mar25

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

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.

Hosted by: