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 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.
Kind regards
T.
P.S.: I'll not necessarily need CCs for all mails of this thread to read them.
--
Thomas Viehmann, http://thomas.viehmann.net/
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
