Hi Steve, On Sun, Sep 17, 2006 at 11:55:02PM -0700, Steve Langasek wrote: [...] > So with three months remaining until the scheduled release of etch, the > release team does not believe it's possible for m68k to close the gap on > these issues. > > As a result, the bts is already ignoring m68k in calculating a bug's > applicability for the testing distribution, at the release team's request. > We have also asked about removing m68k from testing since it is not > currently a release candidate; Anthony Towns has indicated his preference > to defer this until another solution can be implemented for m68k's needs. > This raises the question again of what such a structure should look like; I > think it would be a good idea for us to begin to tackle this question, so > that the m68k team might, e.g., be able to do their own partial release for > etch similar to what amd64 did for sarge. Or, perhaps this is a good time > to focus on ColdFire support, so that m68k can come back with as strong a > port as possible for etch+1? > > Please let the release team know how we can be of assistance to you in > setting and meeting goals for an m68k release, be it for a separate etch > release or for a re-integrated etch+1 release.
I expected this to happen; and, like Michael, expected it to happen a lot sooner, actually. It's a pity we've reached this point, but I can live with it -- the rules were clear, and (at least IMO) they were applied fairly and (mostly) with human judgement rather than just machined checking. So, were to go from here? Personally, I'd very much prefer to be able to see this just as a temporary necessity; a necessary evil, if you like. I would like to see Debian/m68k be back at least as strong as before with etch+1. I think the best way forward at this point in time is to create our own release, as you suggest, very much like what amd64 did for sarge. On the August 16 birthday party in Breda, I discussed this with Jeroen Van Wolffelaar who told me that in theory, it should not be very hard to create a suite in dak to allow us to have a mostly-etch distribution; one that is only slightly different from the 'real' etch. Given their track record, I suspect (though I haven't asked) that the security team would not object to supporting such a release. As for etch+1, I would like to make one request: that you be a bit less aggressive with removing an architecture from being considered for testing. While I understand the effect it has on the rest of Debian, it is also true that having testing around means you get to have a set of packages that "mostly" works, and to which you can downgrade packages if a build fails; it means people can try a safer version of the development distribution. By having a working testing distribution around, you're not immediately fucked if something breaks in unstable. There, I have to agree with Michael: removing m68k from consideration for the testing scripts for about a year (IIRC) did have some negative influence on unstable, too; one that I did not foresee back then. Even if you still think that doing this early rather than late is necessary from your point of view, I would still like to search for alternatives, a compromise; say, that you create a stage in between 'not considered' and 'fully considered', where e.g. a package could move from unstable to testing even if it's broken on a not-fully-uptodate architecture, but not remain there indefinitely and certainly not release like that (unless the architecture is eventually fully dropped). This will obviously have to be fleshed out a bit more, but you get the point. -- Fun will now commence -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
