Re: *** SPAM *** Re: A new arch support proposal, hopefully consensual (?)

[Sven Luther <sven.luther@wanadoo.fr>]

On Mon, Mar 21, 2005 at 04:31:44PM -0800, Mike Fedyk wrote:
> Sven Luther wrote:
> 
> >Ok, this is the easy part, and also what the vancouver-proposal included, 
> >the
> >difference comes in how the minority-arches are handled, and my proposal 
> >is a
> >'including' proposal, while the vancouver-proposal was 'excluding'.
> >
> >4) each non-tier1 arches will have its own testing infrastructure, which
> >would take both unstable and testing in account.
> >
> >5) packages are built out of unstable into an arch-specific unstable binary
> >repository on a separate machine (altough many minority arches may share 
> >this
> >infrastructure).
> > 
> >
> This allows for source package version skew on a per arch level.  In the 
> worst case, each non-tier1 arch could have a different source package 
> version when compared to tier1 and all of the other non-tier1 arches.
> 
> To have the least possibility for source package version skew, the 
> non-tier1 arches should branch off of tier1-testing instead of 
> tier1-unstable.

That was my first proposal, but i am not sure if it makes sense. The version
skew may happen, but i feel it will be minimal. All these arches will build
from unstable, the packages will go into arch-unstable instead of arch. Here
we have our first chance of source skew :

  A) source skew due to the delay due to the build lag of the arches in question

this will be limited to a couple of days in the best case, and to one version,
and only for packages recently uploaded and not yet built. It is a function of
the upload rate and time for build of the packages.

The second version skew happens when there is a package in arch-unstable which
has migrated to testing in the tier1 archive, but failed to do so in the
arch-testing because of arch-specific breakage :

  B) source skew due to arch-specific RC bugs.

This is also something transitory and easily quantifiable. Furthermore, since
the waste majority of packages build correctly, it is also a rather small and
something that is supposed to resorb itself, in particular since the fix will
be uploaded to tier1-unstable too.

On the contrary building from tier1-testing has the problem that an individual
package or even arch fix may be withold from the tier2 arches for a longer
period of time, as we have seen, and thus that the porting effort if needed
may well start only later.

So, after reflexion, i believe that the build-from-unstable, with
per-arch-testing scripts slaved to the main testing for migration is a better
solution than building-from-testing as i first proposed.

Friendly,

Sven Luther