Subject: rfc: bulk-build mail list and binary packages
To: None <tech-pkg@netbsd.org>
From: David Brownlee <abs@netbsd.org>
List: tech-pkg
Date: 06/15/2001 16:01:19
	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 --