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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
