Tosa Development Plan, where should dev effort go Options

[xjqian]

As most of your know the 6000L is an odd breed compared to other Zauri, esp the clamshells, where availability and dev activities are high. Hence Tosa ROM version is behind others except for OZ/Angstrom where the key dev. Hrw has the device.

Current Tosa ROM status in the other popular rom is pretty disappointing

PdaXrom: beta1
Cacko: None

I've been whining for a long time without contributing. Part of the reason is that I don't know where should my effort go. I have to admit that I'm not even close to software engineer in trade and pretty inexperienced in the whole thing. But I'm pretty confident in my learning ability to get some Tosa dev going.

For a starter, I'm interested to advance PdaXrom to a stable/usable 2.4 kernel, similar to what Meanie did for pdaXii. (weed out bugs, etc. ) Who else is interested and have time to contribute? We probably need some sort of infrastructure (svn, emaillist, bugtracker, etc.) Could we borrow what's available in the PdaXrom site? Should we get together and form a team?

Btw, anybody interested in a Cacko ROM for Tosa?

I can probably commit half an hour per day for the project after my thesis defense.

[xjqian]

That's actually not true, since OZ (and OE) doesn't have any active developers with a tosa device, so we have to rely on people like you to test things and report (or even fix) bugs.

And talking about bugs: see rule #5 at http://www.angstrom-distribution.org/

I think Hrw has a tosa. But I understand he is probably bogged down by various other projects (e.g. openmoko). And the tosa is just sitting as a compiling druid. Talking about bugs, most of them are already in the bug tracker. I just added comments to all the pertinent bugs I experience on tosa (wait to see what hrw has to say). I don't think I could help much at this stage (still learning to catch up with the developers), but yes at least I could help testing. As I said, the fact that OE code base prefers maintainability to usability doesn't imply a negative sense (well, depends on how you slice this fact...). Frankly, the tidiness and well-documented/maintained OE is very attractive, at least to me.

I really think we'd need a separate project just to bring tosa to the level where it could share SVN with pdaxrom.  Any chance of someone setting up a bugtracker and mailing list in this regard?

I'm fine with that too. Do you think I should register a project on sourceforge? The potential problem is forking from pdaxrom source tree, which is not desirable. Maybe we should only checkin and maintain Tosa patches with hope to merge back with pdaxrom later.

We can use this thread and the OESF forum to discuss about the plan for as long as necessary.

So what we are really looking at is either a tidied up 2.4 based pdaxrom

The following is my vision of the future for Tosa

2.4 kernel based:
easily achievable: cleaned up pdaXrom beta1
achievable: a fast kernel (e.g. tetsu kernel) + Cacko ROM

2.6 kernel based: (still fairly long way to go)
substantial testing and bug-fixing: Angstrom (since the latest OZ 3.5.5 will be very similar to Angstrom (kernel almost identical) I'm not distinguishing Angstrom with OZ)
nonexistent yet (needs uboot): pdaXrom rXXX

PdaXQT and PWS breathe some life into it, but that's fairly cleaned up already I'd think isn't it? 

I guess *all* of the distros could use some help and development/testing. Sorry if this isn't helpful.  Just my two cents.  I'd really like to help, however.  I was somewhat thinking that we could agree on a distro and form a team, but that may be asking too much.  They're all going to make progress.  Even Sharp ROM, although that would be very slow progress from my point of view.

Agreed. PdaXQT and PWS is pretty clean.

I partly agree with the statement that Sharp ROM is dead. But the fact every hardware function correctly in Sharp rom still has value for the user. Btw, why we can't do hardware button rotation/record/backlight in pdaXrom or OE? This always puzzles me, is it because poor documentation of the hardware?

I would pick Tetsu-kernel + Cacko rom, if it's availabe on Tosa, over any other rom for my daily pda use.

U -boot seems to flash properly on the tosa. I say *seems* because I don't really know what it's supposed to be doing.  Now as to the next step of loading the 2.6 pdaxrom, I haven't gotten this to work yet.  (Almost every time I reflash,  my palms get a little sweaty, and I'm afraid I've bricked my Z.) 

An additional issue with the 2.6 kernel series of pdaxrom is that I haven't been able to restore from NAND backups on my 3200, without first doing a NAND backup to Sharp ROM.  Yet another bonus point for Sharp ROM.  This  seems to be the case for me on Tosa also.  So I'm currently back to Sharp ROM, debating whether to NAND restore back to pdaxrom beta1 or not.

Thanks for the update. Looking forward to a 2.6 pdaXrom

I can agree to a distro...any distro.  The thing is I'm really not a developer. The point I was making is that to put serious effort into tosa development/polishing, especially looking at using it like a real computer, seems to imply that some 2.6 version. Simply having 4 gigs of cheap sd to put a system on is a tremendous improvement, nevermind the speed and futureproofing that should come with 2.6
Basically, for 2.4, I'll likely stick with sharp/xqt.  That is in part due to the need for my tosa to be easy to use as a light browser/mobile media player.. with the ability to do a bit more, if slowly.  A useable X/gtk system would be better..but I don't really see that living up to my uses in 2.4

Agreed. As I thought more about my Tosa usage senario, 2.4 kernel pdaXrom developement is ironic in a sense that it defeats the purpose of the existence of pdaXrom in the first place. So we don't have to do more than clean-up or customization for pdaXrom beta1.
But I want to stress it again (to see if anybody agree with me), some development effort towards 2.4 kernel sharp bases (e.g. cacko) rom does make sense to me.