Things Every Rom Release Ought To Do

[stbrock]

Over the past several months I've installed various Cacko, pdaXrom, and OZ ROMs, as well as XQt and pocketworkstation. Based on my experiences, here are some basics that I suggest developers provide with these releases to help new users and expand their user base.

1.  Release notes with installation instructions, key mapping table, change log, known bugs, links to resources, etc. [Users shouldn't have to google or search forum posts for scattered and incomplete bits of such basic information. For example, it shouldn't take more than a few minutes to add a text file with a table showing Ctrl, Alt, Fn and other special character mappings different from the Sharp keyboard labels.]

2.  A simple script for each supported version of the Z which could be run upon installation and included in a profile that would get the necessary keys on the keyboard working--and any other suitable platform specific adaptations. [These ROMs are for a small number of platforms with non-standard keyboards. It's vastly more efficient for a developer to fix the key mapping than for individuals users to do it one at a time.]

3.  A simple editor that can reliably manage basic configuration tasks. [Sometimes I've found the only editor included has significant limitations. It's frustrating to find you can't enter a colon in vi or a slash at the command line, or open a hidden file, or save a file to some directory even when you are root and the directory is not read-only.]  

4.  A package manager that is correctly configured for the developer's feed and works on most all of the packages that are in that feed as part of the official release. [I know writing a small package manager that will handle all or most .deb and .ipk packages out there is very tough. I know that the developer can't check all the contributed packages. But the packages at the developer's site that are offered as optional additions for installation should work.]  

I understand that releases are works-in-progress and that some bugs are best fixed as they crop up after a release--e.g., recognizing network cards or fixing apps that crash in some contexts but not others. But it seems to me that the above basics could be supplied with relatively little effort for the developer. Or if not that the developer should make it clear in the release notes. It doesn't make sense for hundreds of individual users less familiar with the ROM each to have to diagnose and fix the same problem when the developer could have done it once for everyone in a few minutes.  

These may seem obvious suggestions, but every release I've tried so far falls significantly short of meeting them, though some have come closer than others. I mean them to be constructive for the future, not complaining. I'd like to encourage developers to remember potential new users as the release date approaches rather than squeezing in one or two last (probably buggy) features. What do others think?

[bgsfh]

I agree wholeheartedly.  I haven't taken the plunge with any of the more interesting Roms because of all the workarounds that grow the threads immediately after release.  I make this statement from the best vantage point for making sweeping statements, that of complete ignorance.  (I do chemistry, not linux.)  Some of the Rom projects are more enthusiast oriented.  I can understand having some problems when you fall off the bleeding edge of development.  But the bigger projects designed for wide audiences could use more polish IMHO.  As an alternate idea, the workarounds for the initial stumbling blocks could be rolled into a package and incorporated into a minor rev of the Rom or as a hotfix and posted a week or a month after initial release.  Malvoski appears to do this with the hotfixes for the Cxxx version of Cacko.  I am not as familiar with some of the other projects to know if this happens there as well.  If this is being done, it could be posted in a more visible manner.  

That said, I don't think this will change anytime soon.  There is not that much motivation for the (much appreciated) people who work on this stuff to make it easy for linux dolts like myself to implement these alternate Roms automagically.  They don't have to worry about stuff like market share or peer reviewed grant funding.  "They live in the land of do as you please", to misquote Alan Moore.

[lardman]

That said, I don't think this will change anytime soon. There is not that much motivation for the (much appreciated) people who work on this stuff to make it easy for linux dolts like myself to implement these alternate Roms automagically. They don't have to worry about stuff like market share or peer reviewed grant funding. "They live in the land of do as you please", to misquote Alan Moore.

For me, it's more a case of having done things for so long (using the command line to do stuff for example) and knowing (pretty much ;-) what I'm doing, which means that I don't remember how difficult it was for people who are new to a ROM to get started.

This is obviously an issue, as it's only those who are familiar with a ROM who know how to make the changes, and by that time they've forgotten what the issues were (or they've discovered what they see as more important ones).

This is the way of Open Source software, unless some of the developers specifically set out to make it easy to use for newbies while ignoring the (probably) more interesting issues involved in furthering development.


Si

[chrget]

This is the way of Open Source software, unless some of the developers specifically set out to make it easy to use for newbies while ignoring the (probably) more interesting issues involved in furthering development.

Unfortunately.

Creeping featuritis and the missing insight that the age-old KISS rule (not only) of IT (Keep it simple, stupid!) should be followed are the major diseases of Open Source development. Add to that the fact that very often the severity of bugs is viewed quite differently by users and developers (and sometimes even amongst developers!) and you have a rather explosive mixture that will usually explode in the face of developers in the form of people that build up a religious hate towards either a specific project or, in some cases, even the whole of the Open Source community.

On top of that, even seasoned developers are often annoyed by the high entry level needed to join a certain development effort due to the fact of missing documentation and/or highly complex and specialized development environments that are needed. So the initial 'cost' (time- and effortwise) of setting things up are simply too high and thus these people just turn away and do their own thing -- I'm one of those.

By this time I have tried three times to 'get warm' with OZ -- 3.2, 3.3.6 and 3.5.1 -- and simply gave up (more or less in disgust -- yes, I'll admit to that, knowing full well that I'm going to be stoned for saying so) every time after only several hours or, in the 'best' case, a couple of days.

And no, I'm certainly not a n00b -- after 20 years of UN*X experience, I do know my way around. But there always was certainly one showstopper that I couldn't accept. On top of that I don't share many of the philosophies followed by the OZ developers (which, in some cases, I actually find disgusting -- while I can understand the motivation, I find breaking floating point compatibility completely unacceptable. I doubt that the developers realize that doing so is more or less the equivalent of saying !%&$*# you! to the face of people using Hancom Sheet and the like).

Software development is, in many ways, like sexuality -- there is an immense bandwidth between masturbation and prostitution. The hard part is to find an acceptable place in that spectrum, one that ideally satisfies both sides -- the user and the developers. Frankly, I don't see OZ really being there yet.

Getting into OZ myself just to fix things the way I would like them -- see above. I just don't see the effort of setting up an OE buildroot giving me enough return on investment. So I stay with my (nicely patched up) 2.38G on my SL5500G and tinker with that. And, what can I say -- it more or less does most things I want it to do.

Even though it may not sound that way to some people, this is not at all against the OZ development community. I certainly know the amount of effort these people are putting in, and applaud them for it. Kudos (and more power!) to you. Just trying to point out where some of the problems may arise from and where things could possibly be improved.

Best regards,
Chris.

[Mickeyl]

These are all good and valid points which would work if the team was large enough. Some folks would prefer working on newbie issues, some would prefer working on stuff for more experienced developers, some would focus on polishing, some on Q/A etc.

But since we are hardly five people interested in actually doing the necessary work to improve this distribution, we (of course) just follow our own priorities. If we wouldn't, we would've quit working on OZ somewhere in 2003 - where only two of us were left. After all, although I find participating in a software project where people are actually using my software nice, in the end it is just the personal motivation of the working people which keeps a project running. Things like polishing releases and making the distribution working better for less experienced users are much more time consuming than you would think. And to be honest, personally I find those things totally uninteresting. I have to do uninteresting things in my day job and I get paid for those things - but there's a tight limit of uninteresting things I'm willing to do in my precious spare time.

You see, we are not just a few altruistic guys with too much free time on their hands. We are a couple of people who love to develop linux stuff on embedded devices. We make releases to let other people benefit from our work, but it's really not a priority. Things would be great if we would were like 20 or 30 people developing, but alas, it isn't so.

We really enjoy being a part of the very nice Linux PDA community, but we also share the viewpoint that open source means that if you want to get something done, there's no other way than to just do it.

In open source, waiting for things to get fixed is waiting for Godot.

[CoreDump]

@stbrock

1. Release notes with installation instructions,

Installation instructions are available on the (partly broken) oz.org webite.
They were there right from the beginning. If someone wants to use OZ,
one would think he takes the time to check the website for docs.
If he doesn't, then he is just lazy.

key mapping table,

That's a good point. If you know of any such document, you may want to add it to the OZ.org Wiki.

change log, known bugs, links to resources, etc.

As you may have noticed (or maybe not), handhelds.org (where oz.org is hosted) suffered a total
hardware failure. At the time of release, it just wasn't possible to add any kind of release notes to oz.org. It took almost a month(!!) to restore basic hh.org functionality.

[Users shouldn't have to google or search forum posts for scattered and incomplete bits of such basic information. For example, it shouldn't take more than a few minutes to add a text file with a table showing Ctrl, Alt, Fn and other special character mappings different from the Sharp keyboard labels.]

There is a lot of information and knowledge in the OZ.org and OPIE wikis. You checked them, right?
If something is missing, you are more than welcome to add it. But I agree, that the release notes should at least point the user to the wikis.

2. A simple script for each supported version of the Z which could be run upon installation and included in a profile that would get the necessary keys on the keyboard working
--and any other suitable platform specific adaptations. [These ROMs are for a small number of platforms with non-standard keyboards. It's vastly more efficient for a developer to fix the key mapping than for individuals users to do it one at a time.]

These machine specific settings are implemented at compile time with OE magic.
What kind of problem on which machine did you experience?

3. A simple editor that can reliably manage basic configuration tasks. [Sometimes I've found the only editor included has significant limitations. It's frustrating to find you can't enter a colon in vi or a slash at the command line, or open a hidden file, or save a file to some directory even when you are root and the directory is not read-only.]

Agreed, but I have had no problems using vi in the past. Though "vi" is ot an acceptable editor for newbies. If you know an editor the size of vi (or smaller) which is more userfriendly, please feel free to add it to OE. If it is better than vi, I'll do my very best to get it added. Just keep in mind that size is the most important thing.

4. A package manager that is correctly configured for the developer's feed and works on most all of the packages that are in that feed as part of the official release. [I know writing a small package manager that will handle all or most .deb and .ipk packages out there is very tough. I know that the developer can't check all the contributed packages. But the packages at the developer's site that are offered as optional additions for installation should work.]

You did install the service release, right? The "devel" feed was simply forgotten. Yep, that happens.
We don't have a QA team which would very likely have spotted the problem.
Apart from that, opie-aqpkg does everything you ask. You may want to try it over opie-packagemanager for the time beeing.

If you find broken packages in the official feed, please open a bug report. Or join #openzaurus @ freenode.net. If noone reports these things, they will never get fixed.

I understand that releases are works-in-progress and that some bugs are best fixed as they crop up after a release--e.g., recognizing network cards

Patches or suggestions for a specific card are welcome. I.e. if you own a card which is not listed in
/e/pcmcia/config, I don't see a reason why it shouldn't be added to a release. Again, if noone reports these things, they won't get fixed.

or fixing apps that crash in some contexts but not others. But it seems to me that the above basics could be supplied with relatively little effort for the developer. Or if not that the developer should make it clear in the release notes.

90% off all release-specific problems are found after the release.

It doesn't make sense for hundreds of individual users less familiar with the ROM each to have to diagnose and fix the same problem when the developer could have done it once for everyone in a few minutes.

You are welcome to add such information to the OZ.org wiki. Many users would benefit from it.

...but the bigger projects designed for wide audiences could use more polish IMHO. As an alternate idea, the workarounds for the initial stumbling blocks could be rolled into a package and incorporated into a minor rev of the Rom or as a hotfix and posted a week or a month after initial release

There is a service release in the upgrade feed. You installed it, right?
Just for your information:
- The three initrd.bin take 4+ hours to compile from scratch (on a fast non-SMP box w/ tons of RAM) - for *one* Z modell
- How many models are out there again?
- The complete feed takes 3+ days to compile from scratch (IIRC it was done on a dual Xenon)
- The feed alone is > 250Mb in size. Uploading takes ages and is a total PITA.

It takes days to organize a release.

There's no way in hell that we will see "bugfix" ROMs. It just isn't doable for such a small team, sorry.

[ev1l]

If you know an editor the size of vi (or smaller) which is more userfriendly, please feel free to add it to OE. If it is better than vi, I'll do my very best to get it added. Just keep in mind that size is the most important thing.

Joe is very nice. It annouces how to get help whenever you start it (in the status bar, so it stays out of the way), and all shortcuts are fairly straight forward. You can extend it quite a bit, but the base is very lightweight.
Also, since the cacko team seems to be closed, I'd gladly give a hand with bug testing and QA. I'm already doing that for the KDE/Pimpi suite (at least for Korganiser and Kaddressbook), and I wouldn't mind doing it for a whole ROM *if* you can show some progress on the stuff I do report. If you're half as responsive as Zautrix is (that man is a mean bugfixing machine), I wouldn't mind at all.
I think it's a shame to have people reporting bugs and not getting any feedback on one side, and developpers on the other telling them that stuff isn't interesting to work on. Not saying that's what's going on with OZ (I truely have no idea), but I've seen it before, and no-one ends up happier in the end (users get nothing they can use, and devs get no recognition/cookies/love)

[Mickeyl]

It's getting offtopic, but vi more or less comes for free since it's included in busybox. Personally, I like nano.

[stupkid]

stbrock,

You have good criticism, but as MickeyL noted these things do take people power.  We are trying to get Cacko 1.22 to a "It just works" status, which I think is the essence of your request.  This is an enourmous pain in the keister though as we must test and tweak every package many times.  With Cacko we do very little coding unlike pdaxrom or OE.  So, we spend a much larger part of our time testing.  There is a polished result, however, very little new ground is broken.

It is very easy to make criticisms, but if you don't like something, please do something about.  Participate in a project, you won't regret it.  This is OpenSource, not Microsoft.  You have the power to change anything that you don't like.  This is what I'm doing.  I saw a need and so I decided to start helping any way I could.

Keep the spiral going out and out.  

"We'll ride the spiral to the end and may just go where no one's been. Spiral out. Keep going..." - Tool

[mussi]

I think the main issue is we need a real QA department, not forcibly staffed with hard-core programmers (unlike you count disasters like ABAP/4 or COBOL as programming languages in my case), but very well-versed users which are able to find out where the actual problem is and have access to a oe build root on some publicly available system, together with a ticketing system.

Actually, Drupal has some facilities to have a ticketing and issue application, as well as project management.

What I'm still thinking about is an app where we have managers for single packages, and once we need to change something on a package, we check out the source code, modify it (maybe with a web-based solution, somehow like SAP R/3), check it back in and click on a button in the web interface to rebuild the app. Such apps, of course, would be marked 'testing' so the potential tester knows what he/she's up to. The key is that we need some sort of collaborative cvs which we could - in extremis - even use from a Z. And then, maybe, attached to that development server, we'd need a real Z or two.

This way, we could have users test the app, fill in information into the ticketing system and lots of people could help to improve. Other folks then build a distro, with nice apps in a big pre-packaged file like CoreDump did.

[guylhem]

This QA thing only works when there's a developper interested in his app *AND* someone willing to do the boring thing. TimW implemented a lot of my feedback in opie-reader. I don't know if it actually helped making it better for other people, but I know I just couldn't live without it now and it surpasses any reader I've seen on any other platform.

We need more applications- high quality, easy to use applications, before anything  else. Any working free html browser? No I don't mean konqueror on the Z - slow and leaking memory.

As Mickey said, ppl just don't like to do boring stuff. Our luck is that "boring" depends on the person. I think usability reviews, details and documentation are the most interesting. Weird me. Someone else will prefer coding. That's fine. "E pluribus unum !" Yet I really hope someone will find porting a free software browser interesting.

Sidenote - critics shouldn't always be considered whining. When one takes some time to write up how exactly things cause a problem, that's constructive and interesting.

BTW my own critics on the Opie, Palm move etc. are on http://www.externe.net/zaurus/modules.php?...order=0&thold=0

[Mickeyl]

http://www.externe.net/zaurus/modules.php?...r=0&thold=0

Very well written, guylhem. I wholeheartedly agree with all of your points.

[mussi]

And, MickeyL - who's gonna got to go?  

[Mickeyl]

Disclaimer: Personal Opinion following, this does not necessarily reflect a common opinion of the Opie team nor does it necessarily reflect the majority of personal opinions

When looking at Opie 1 In its present form - being a conglomerat based on QPE 1.4, Qtopia 1.5, 1.6, and 1.7 merges and original contributions of mixed quality - I don't see a very bright future for around 75% of the Opie codebase.

After having played with Qtopia 2.1, I have to say that Qtopia isn't the answer either. What it does it does on a solid base, but their launcher and most apps are really boring and include just rudimentary functionality. The library situation with qtopia, qtopia1, qtopia2, etc. looks also pretty unstructured.

My conclusion as a developer is that neither Opie 1 nor Qtopia 2.x offer any interesting perspectives for the future. Opie 1 is more or less too messy and complicated for John Doe part time developer to join and quickly improve it. Qtopia 2.x on the other hand has a closed development model. There is more or less no way for the community to get any improvements into Qtopia and we have to wait very long to access the latest code - which happens to be outdated at that moment.

Yes, albeit just released as GPL, Qtopia 2.x is obsolete. It's in bugfixing mode because all development now goes into Qtopia 4. I'm pretty sure we will get to see this code not before months after its commercial release. Which means, it is years away.

So, what's left for a couple of innovation-hungry developers who have fun producing software for embedded systems and who won't limit themselves to be just application producers on a foreign framework they have no control and no rights to improve?

The answer could be just to stop developing for Opie/Qtopia and accept that Open Source on Linux PDAs failed and to embrace PalmOS or WinCE.

Another option could be to join raster (head master of Enlightenment) who has a bright vision for an EFL-based Palmtop Environment.

Then again, the answer could also be Opie 2. An Open Source Palmtop Environment rewritten from scratch basing on Qt/4 Embedded or Qt4/X11. No more hassles and fights with TrollTech over Qtopia issues. LGPLed to allow commercial software linking against our libraries.

Anyway the Opie team decides, it is clear that it has to stop playing catch-up with TrollTech. This just burns out developers and scares both developers and users (and some of them happen to be potential developers) away. The only future for Opie is to decide as soon as possible - better early than late - and then follow that decision whole heartedly.

The alternatives are i) stopping with core work and just providing applications or ii) restarting from scratch and doing an own thing, no matter if that will be based on Qt/E, Qt/X11, or something else like EFL.

[lpotter]

mickey, it sounds like you need to develop your own system from scratch. Qtopia was designed as a base so people could customize it. Which is exactly what opie has done with it. I think we need to leverage Trolltechs developers and code. Trolltech gives it away for free as open source. I think its a big mistake to disregard Qtopia code. Opie is based off Qtopia, and you dont like that and have always fought against compatibility with Qtopia.
If you think you can write a better system, go ahead. I'd like to see it.
Compatibility to Qtopia is important because it ships on devices, and will ship on devices you wont be able to flash.
The problems in opie are not going to be fixed by starting over. That will simply fragment it further and water down both users as well as developers.
There are ways to contribute to qtopia. Qtopia 2.1 is not obsolete, just because we start working on qtopia 4.