Daily Snapshot Reviews
kevin at foreverdean.info
Thu Jan 31 19:56:33 CET 2008
On Jan 31, 2008 1:31 PM, Peter Rasmussen <plr at udgaard.com> wrote:
> John Lee wrote:
> > First of all, thanks for the great idea of testing the daily build.
> > Help like this is just great because we're so short of developers.
> > The daily build is replaced everyday because I make it build from
> > scratch everyday and the TMPDIR is so huge that I cannot keep every
> > copies. I'll try to work on that.
> > Cheers,
> > John
> 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.
> 2. A way to see what the present focus is of developers.
As a gross over-generalization, the focus right now is on getting
GTA02 "ready" for release. That said, I agree here. I think being
transparent is OpenMoko's biggest strength AND greatest weakness.
There's a ton of transparency, perhaps so transparent that the
developers and management don't think any kind of organization is
truly needed because you can see "everything" - you don't walk into a
room and get an up-to-the-minute handout explaining what's happened,
you're expected to observe and learn yourself.
> 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. :(
> 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".
> 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.
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.
> However, all this would make testing more productive, and as resources
> are apparently lacking we'll need to do something :-)
> Would it be possible to have a thicker information way between testers
> and the developers, and if not directly, then to a liason?
I may be interested in doing this, but my experience with OpenMoko Inc
aside from a few very active developers has been iffy at best. Several
developers join in the IRC chat daily and discuss what's on their
plates, and the development lists are open to the public. I'm also
hesitant to take on "another project" since I'm spread thin... That
said OpenMoko, in whatever capacity I can manage, is pretty high on my
list of favorite projects so I might ditch some of my other
> I may be missing information about what is going on, but to me it still
> seems very like an ad-hoc type of developing the Neo/OpenMoko platform,
> and that is a pity.
I agree, I think there's a horrific lack of cohesiveness since theres
no single "project manager" that we ever see. But again, this may be
real or imagined since OpenMoko isn't yet anything but an evolving
glob of code. We're not even at a 0.0.1 release yet, so it's possible
that until the underlying hardware issues are dealt with, OM Inc.
something in hardware changes, it could affect the very foundation on
which several apps are built - and this is understandable - but if
that IS the case it would be useful to hear it directly.
More information about the device-owners