[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: m68k not a release arch for etch; status in testing, future plans?



On Tue, Oct 17, 2006 at 01:42:07PM +1000, Anthony Towns wrote:
> On Sun, Sep 17, 2006 at 11:55:02PM -0700, Steve Langasek wrote:
> > It's with some regret that I have to confirm that m68k is not going to be a
> > release architecture for etch. 
> > 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,
> It's just short of a month since Steve posted this, with, as far as
> I've seen, no concrete suggestions on what the m68k porters want to do
> about this.

What are the porters wanted to say? "We want to release with Etch?" I think
that's obvious and the porters are doing their best to keep the port going
and keeping up as much as possible. 

> I expect we'll be dropping m68k from etch fairly shortly,
> unless someone comes up with a plan for supporting a "Debian 4.0-m68k"
> release in the next few days.

Ok, here's my proposal:

Release m68k with Etch by:
- allowing migration of packages to Etch as far as they've been built and
uptodate. 
- concentrate on important packages (admin, base, ...)
- m68k can live without gcj-4.1 for some time, I think, so omit those from
the release
- allow "new", previously unreleased m68k Etch packages for point release
(like gcj-4.1 or OpenGL related apps)

This is of course just a quick shot. We can elaborate details in the next
days when you're agreeing that a partial release is better for m68k than no
release at all. How about an IRC meeting about that issue on Saturday 6:00
p.m. UTC on #debian-68k?
 
> I'm not sure if that's necessarily a good idea though -- from what I've
> seen it might be more useful just to come up with a plan for supporting
> a "Debian testing-m68k" variant instead; in which case it won't much
> matter if m68k gets dropped from etch; testing can get reconstructed
> from unstable relatively easily.

Hmmm, I doubt that this work out well. It's just a feeling. 
Most m68k users are using stable, I'd say, so a stable release would fit
best the needs of our users. Forcing them to use testing might be a bad
idea. 

Anyway, when m68k would be allowed to rejoin Etch with point release, things
might be ok, but it would be better to have a reduced m68k for the main Etch
release, though. 

If any plan to release m68k with Etch needs some additional mirror space, I
will donate disk space and bandwidth for that reason.

-- 
Ciao...                //        Fon: 0381-2744150 
      Ingo           \X/         SIP: 2744150@sipgate.de

gpg pubkey: http://www.juergensmann.de/ij/public_key.asc



Reply to: