On Sun, Mar 20, 2005 at 04:59:57PM +0100, Thomas Viehmann wrote: > Sven Luther wrote: > > Problems with many arches: > > - same for the security team. > Hmm. I only saw Joey's message on the subject, which basically seemed to > say "as long as it's only one source compiling on all arches, it's OK"
Yep, i read it only after having posted this email though, and it came as a surprise to me, since the vancouver team claimed to have had input from Joey prior to the meeting, even though he could not come. > > 7) the porter team has the possibility to providing arch-specific > > overrides > > to solve the issue of a package not passing from unstable into testing > > due to > > a tier1-specific RC bug or whatever. Should be used sparingly though. > This seems problematic in this respect. Well, the idea is that you always upload arch-specific patches to unstable, but that when these patches get blocked for some random reason (like making KDE uninstallable on x86 because of some unrelated other fix), then you can either choose to make a arch-specific override, or go for a arch-testing-proposed-updates upload. You seem to say that the second is preferable, but it probably depends on the circunstances. In any way, the fix will be uploaded to unstable. Notice that if we had all packages in a common revision control system, and that we where able to say we would apply one patch, momentatily backup all others since the last version in testing, and redo a build against the packages in testing, this would make things a whole lot easier. > I might have missed the previous suggestions or the obvious flaws of the > idea, but why not have something along the lines of "releasing all > 'tier2' arches with the packages they have", i.e. agressive per-arch > removal for uninstallable/unusable/not-up-to-date packages. Those arches > that have something worth releasing at release time (installer, all > priority >= important, x% of optional in usual release quality) do that. The idea is that we don't want to hold up release, but we still want to allow for a future release at a later point, in a stable point release. Especially now that we are told that security is not an issue. > This way, the security support of the additional arches would stay > largely the same. One could have the present testing rules up to some > point and switch to "if arch-specific RC bugs/testing delays pop up, > stuff get removed" for release. Not sure if this is a good idea. The main point will be for the arch-specific fix to get in in a timely fashion, and it being blocked by unrelated tier1-breakage, not to remove the package and thus remove the fix. If you are saying that we should in this case remove the tier1 packages from testing though :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
