Hi,
No comments at all about this cool proposal ?
I can do builds for a few architecture, if hardware is the problem.

On Fri, Jun 15, 2001 at 04:01:19PM +0100, David Brownlee wrote:
> 	Updated proposal
> 
> 	Problems
> 	^^^^^^^^
> 	   i) Binary packages are not available for many platforms,
> 	      and building of such is not coordinated.
> 
> 	  ii) Binary packages for a given arch/osrev on ftp.netbsd.org
> 	      can be built against different depends, or depends
> 	      updated, resulting in mismatched packages which will
> 	      not install.
> 
> 	 iii) New versions of binary packages are uploaded which
> 	      will not install against a user's existing set of
> 	      installed depends.
> 
> 	The proposal attempts to cover i) and ii). It does not
> 	directly address iii), though having a consistent set of
> 	binary packages on ftp.netbsd.org will obviously mitigate
> 	somewhat.  (*)
> 
> 	Proposal
> 	^^^^^^^^
> 	    - Create a 'bulk-package' list. Developers signup to
> 	      handle any given arch/osrev. When they can no longer
> 	      handle that arch/osrev they pass the 'token' back to
> 	      the list for someone else to pick up.
> 
> 	    - When uploading packages developers will upload/rsync
> 	      their entire set of bulk built packages, and delete
> 	      any other packages for that arch/osrev on ftp.netbsd.org
> 
> 	    - When taking over an arch/osrev combination a developer
> 	      will either start bulk building from scratch, or
> 	      download the current set of binary packages from
> 	      ftp.netbsd.org to 'pre seed' their build process
> 	      (most useful for slower architectures).
> 
> 	    - Any developer can upload updated/new/security-fix
> 	      packages to ftp.netbsd.org, but they _must_ be built
> 	      against the set of binary packages already present
> 	      for that os/arch.
> 
> 	    - Developers should run the latest minor release, or
> 	      (recommended) track the release branch.
> 
> 	(*) Addressing iii) either involves freezing binary packages
> 	    at tagged values, or having multiple binary package
> 	    trees per arch/osrev.  The former reduces significantly
> 	    reduces the utility of the binary packages, and the
> 	    latter is not worth considering until we can get _one_
> 	    consistent tree per arch/osrev.
> 
> -- 
> 		David/absolute		-- www.netbsd.org: No hype required --
--
Manuel Bouyer <bouyer@antioche.eu.org>
     {Net,Free}BSD: 22 ans d'experience feront toujours la difference
--