* Adam D. Barratt ([email protected]) [120528 14:22]: > hurd-i386 > --------- > > Is there time to add it to testing and get it out of > {break,fucked}_arches? Would it make sense to release if it was still > in break_ and/or fucked_arches?
Depending on the number of issues that pop up, it might still be technical possible. However, as a non-linux arch, I have my doubts. Also, as soon as we consider it a full release architecture, any bugs relevant to only hurd-i386 are considered RC. I don't think there is any (technical) harm in adding it to testing as long as it's in both break and fuck archs - however, from the feedback I got from different people, it might be felt different, so if we add it, we need to deliver a very clear message. We can't release if it still is in any of break/fucked arches (at least that would be my recommendation, due to technical and legal issues, e.g. we might need to preserve multiple source code versions if we have different binary versions within a stable release). All in all, my recommendation for hurd-i386 would be that (as long as this is agreed by all involved, and communicated clearly to the developers at large before doing it) we add hurd-i386 to testing with break/fucked, but we don't expect it to make the release. I.e. bugs for hurd-i386 are not RC. We don't do unblocks for hurd-i386. Etc. But also I think keeping at as part of proper Debian would be good for the open source community at large, so we keep it even after the next stable release in testing and unstable. Andi -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
