Re: m68k not a release arch for etch; status in testing, future plans?
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
Reply to: