Kevin Dean wrote:
I would the like to ask if it is then possible to structure this testing
even more, and have the following would be great:
1. A way to see what actually changes between builds.
Subscribing to openmoko-commits will notify you whenever a new
revision is checked in. I get daily digested logs. I think to have all
of the developers (some of whom are not emplyed by OpenMoko Inc.) do
daily changelogs OUTSIDE of the source itself is kind of an unfair
requirement, but if you look at commits you'll see from a birds-eye
view what's happening.
Thanks for the pointer.
It is however, an ever returning issue where software development takes
place, and it has to be balanced, with who should do what to get
somebody else become more efficient.
3. Not on a personal level, but I would like to know if feature-A is
being worked on, and feature-B is on standby, while bug-A will have to
wait for bug-B to be fixed, etc.
In general, a roadmap would be nice, I agree. Or even more than that,
a list of who is actually doing development, so that people interested
in hacking can contact the people to discuss and submit to. I think a
bunch of people have good ideas and aren't willing to write them for
fear that 13 days into a 14 day project that feature will appear in
the builds. :( I am, however, unsure how we (as the community) could
actually organize that in any decent manner without input from OM Inc
and it's affiliates or at the very least developers. The problem is,
any dev who takes that project on is now coding less. :(
It isn't just the volume of coding that is important. And it doesn't
have to be an actual coder that implements stuff that has to do it. With
a true open environment other people should be able to contribute. With
that mindset, coders shouldn't go to conferences or show off the devices
at meetings either, should they?
4. Request for the following features that will help testing:
A. A way to see the release version of both u-boot, kernel and
rootfs, on a running system. If I need to open a terminal and issue a
command, that will be fine.
To see a u-Boot version, hold AUX and power on the device. You'll see
at the top of the screen the version number. If it times out for you,
consider connecting from your computer and issuing "setenv
boot_menu_timeout 65000" to extend the time uBoot stays "awake".
Yes, then I can see the u-boot version, but I still have to reboot to
get to that screen, and that is what I want to avoid. And after loading
the kernel and the rootfs, I still don't have a way to see the release
of what is actually loaded.
B. An update (probably) to u-boot that will accept multiple kernel
and rootfs on the same SD/SDHC card.
C. An update (probably) to u-boot that will accept upload of a tar
file or some other prepared image, directly to the SD/SDHC card, while
in bootloader more, and be able to specify the root directory from where
to unpack.
I prefer to have rootfs images put on the SD/SDHC card, as that is one I
can change when it is worn out, whereas I can't change the one inside
the Neo. Technically I would have designed the Neo (or any other mobile
that has flash-card capability) so all flash was on the removable card.
It should make production cheaper as update to units were only dependent
on exchanging the flash card.
As a developer oriented device, I can see how that would have merit
but as a consumer device I'd imagine very few people will EVER exceed
the number of writes to the NAND considering the typical life of a
mobile device. Also, my current uBoot snapshot has the capacity to
boot from SD once an image is put on the card. You have to specific
manually where this image resides but again, as a consumer device, and
not a developer device, very few people will ever do more than boot
their standard, pre-installed image, let alone need multiple kernel
options, different rootfs and the ability to swap them around.
The Neo *is* a developer's device, and I would like everyone to admit
and recognize that. And as far as I remember, that is also what it says
on the openmoko.com pages.
We can start polishing it up for the masses when it is ready for them,
but why not make it easier for the rest of us while it is in the present
state?
It would make testing easier, if I could for example set up the boot
loader to have "System 1", "System 2", "System 3", etc. to boot from the
SD/SDHC card, and when I want to upload a new image, I then specify
where to put it. From the root of the mounted card, it could be
/system1, /system2, system3.
Presently I can get an 8GB SDHC card for just $100USD, and that will
contain many images at once. Being able to switch back and forth without
having to also upload them again would be a nice feature for testing.
On another note, putting the rootfs on the SD card adds the burden on
the user. How do you advertise a device as "expandable" of expanding
it requires the user to copy their rootfs over to the new (higher
capacity) card just to be able to store more music? I think FIC and
OM's decision to leave the SD card as storage, and have the OS "on the
device" makes more sense considering over all intent.
Yes, when it becomes a mass user device, it may be limited in what can
be used where, in order not to confuse regular users.
Peter
