Sven Luther wrote:
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
Did you mean "vast"?
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.
I think I agree with you now.
Also if the tier2 arches are branch off of testing, they will never be
able to prove that they are able to keep up with sid.
As long as tier2-testing does not migrate a package before
tier1-testing does, then I have no arguments so far.
Mike
|