On Sun, Mar 20, 2005 at 06:24:23PM +0100, Thomas Viehmann wrote: > Sven Luther wrote: > >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 :) > > Well, you'll at most get "classic" Security-Support for those sources > that match the "regular ones" and I doubt that the policy for point > release will - or should - be weakened to allow arch-fixes. My
Why not ? the aim is to provide stable releases for those arches, not to drop them and let them handle of their own, so some arrangement needs to be made. This is i think the price we have to pay for letting these arches get out of sync with testing. > impression was that a split into supported / less supported (yeah, > reminiscent of a popular derivative) of the ports would reduce the total > amount of work while not overburdening the general process. Yes, but without dropping support. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
