Holger Freyther wrote: > On Wednesday 30 July 2008 16:27:17 Rod Whitby wrote: >> Julian Chu wrote: > >>> Actually, the buildhost didn't build ASU branch at all. >>> We did that work on another machine in Taipei. >> Hmm - so you *don't* want the public to be testing ASU yet? > > Tough. We want testing, we didn't want people running around and saying this > is ASU when it was/is not ready and subject to change. The compromise (AFAIK) > was to make everything for ASU publically available, even the feed, but not > the images (to make it a bit harder). At least this is how I understood the > decision and I'm confident we will review it after the release of ASU which > is going to happen soon.
OK, so ASU as a configuration is not released by Openmoko yet. What then is the currently supported Openmoko configuration that people should be building and testing if they most want to assist the drive for reproducibility and stability of operation? >> All my opinion, of course, but I do this on the same sort of scale (5 >> firmware distros three of which are based on OE, over 20K people on the >> mailing list, millions of firmware and package downloads) for the >> nslu2-linux.org project ... > > Do you have any documentation on when you create images, how you test them > before a release, how to handle your feeds (with upgraded packages), how to > test upgrading is possible? What we do is the following: 1) All sources and recipes are available to the public (you do that already). 2) A single standard reproducible build Makefile is available to the public (I do that for you :-)) This reproducibility is absolutely essential. 3) The autobuilder builds the images and packages using that single standard build Makefile on a known host configuration (in our case, Ubuntu 7.10 server install with no packages added, and then run the "make setup-host-ubuntu" with the standard Makefile to automatically install all host packages required for the build system. This allows anyone in the public to completely and unambiguously reproduce the exact configuration of the official build system. No more arguments over why the image doesn't build on some obscure Gentoo installation - if you don't use the officially supported build system, then you're on your own. 4) We only release a binary image after three external parties have confirmed that they can build and boot that binary image on a machine other than the autobuilder. This guarantees that anyone in the public can reproduce the binary images, and also makes sure that our build system works for people other than the core developers. 5) The binary image has versioned feed configurations that fork off of the unstable feeds at the point of binary image release. See http://ipkg.nslu2-linux.org/feeds/slugosbe/cross/ for an example. We test the ability to upgrade from one binary release to the next. 6) The complete build system (images and packages) for that binary release is moved onto a branch, where minor patches to that release can be made in isolation of the main development trunk. See http://svn.nslu2-linux.org/svnroot/slugos/releases/ for an example. We identify a stable release maintainer, and they are allowed to cherry pick fixes from the trunk and apply them to the image and packages in the stable release repository. 7) Builds from trunk reference the unstable unversioned feeds, whereas binary images only reference stable versioned feeds. This means that people who are not able to build the image themselves (or don't have the time or inclination to do so) are automatically sent to the stable feeds, where they can report bugs against known stable packages and are not subjected to the turbulence of the unstable feeds. People who are able to build the image themselves are assumed to know what they are doing and are subjected to the turbulence of the unstable feeds. If someone running a binary image wants access to the bleeding edge latest packages, then they either need to learn how to build an image or at least learn how to change their ipkg.conf files (in which case they also know how to change it back if things get too unstable for their comfort). 8) Profit (over $10K in donations in the last 4 years, but all has gone into server and development hardware for the project, so no actual profit for the people involved other than the satisfaction of a well-running non-arguing community). -- Rod Whitby -- NSLU2-Linux and Optware Project Lead _______________________________________________ devel mailing list [email protected] https://lists.openmoko.org/mailman/listinfo/devel
