MobileRead Forums - View Single Post

jharker · 11-03-2008, 01:50 AM

Hey, hansel,

The goal for the iLiad OS project is to have a complete Linux distribution that is specific to the iLiad. Probably at first it will be distributed as individual upgrades for a few programs, then later as a single filesystem suitable for flashing to the iLiad. In the long run our goal is to introduce changes that will allow you to download new upgrades easily from community iDS servers by pushing the Connect button, just as you used to get upgrades from iRex.

We will release new versions following the convention and sequence of the iRex releases. So the first "official" community release will be 2.13, followed by 2.14, etc. (If iRex continues to release new versions then we may change our convention to avoid confusion, but my impression is that iRex is winding down development except for possibly bug fixes and a few minor features.) My ideal is to avoid having parallel development branches, unless for some reason it is strictly necessary. The iLiad OS project will be focused on achieving community-designed goals for UI, features, etc.

So iLiad OS will effectively become the new "official" version.

The "official" source code will be stored in the iLiad OS svn server, freely available for anyone to check out and edit. As community members create patches that implement new features, they will be submitted to the administrators (currently myself and Adam B.), who will proof them, test them, and then merge them into svn. This is how ongoing development efforts will be handled.

I don't really know exactly how source code documentation works. But assuming it takes the form of either a) comments within the source files, or b) additional files that are distributed with the source, then it seems like you could follow the standard process as for any other patch:

Check out the latest trunk source from svn.
Make your changes (i.e. add comments & documentation).
Submit patches containing the changes to an admin, who will merge them back into svn.

Documentation and development efforts are two sides of the same coin. They can and should happen at the same time.

Does that make sense? I'm fairly new to project administration, so advice and suggestions are happily welcomed!

11-03-2008, 01:50 AM	#10
jharker Developer Posts: 345 Karma: 3473 Join Date: Apr 2007 Location: Brooklyn, NY, USA Device: iRex iLiad v1, Blackberry Tour, Kindle DX, iPad.	Hey, hansel, The goal for the iLiad OS project is to have a complete Linux distribution that is specific to the iLiad. Probably at first it will be distributed as individual upgrades for a few programs, then later as a single filesystem suitable for flashing to the iLiad. In the long run our goal is to introduce changes that will allow you to download new upgrades easily from community iDS servers by pushing the Connect button, just as you used to get upgrades from iRex. We will release new versions following the convention and sequence of the iRex releases. So the first "official" community release will be 2.13, followed by 2.14, etc. (If iRex continues to release new versions then we may change our convention to avoid confusion, but my impression is that iRex is winding down development except for possibly bug fixes and a few minor features.) My ideal is to avoid having parallel development branches, unless for some reason it is strictly necessary. The iLiad OS project will be focused on achieving community-designed goals for UI, features, etc. So iLiad OS will effectively become the new "official" version. The "official" source code will be stored in the iLiad OS svn server, freely available for anyone to check out and edit. As community members create patches that implement new features, they will be submitted to the administrators (currently myself and Adam B.), who will proof them, test them, and then merge them into svn. This is how ongoing development efforts will be handled. I don't really know exactly how source code documentation works. But assuming it takes the form of either a) comments within the source files, or b) additional files that are distributed with the source, then it seems like you could follow the standard process as for any other patch: Check out the latest trunk source from svn. Make your changes (i.e. add comments & documentation). Submit patches containing the changes to an admin, who will merge them back into svn. Documentation and development efforts are two sides of the same coin. They can and should happen at the same time. Does that make sense? I'm fairly new to project administration, so advice and suggestions are happily welcomed!