daily-feed vs. SRCREV

[Rod Whitby]

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