Sven Luther wrote:
Did you mean "vast"?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
I think I agree with you now.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.
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.