On Jan 31, 2008 1:31 PM, Peter Rasmussen <[EMAIL PROTECTED]> 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 responcibilities. > > 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. actually DOESN'T have a set direction in terms of userspace apps. If 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. > > Peter > >
