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