Re: m68k not a release arch for etch; status in testing, future plans?
Hi,
On Wed, 18 Oct 2006, Steve Langasek wrote:
> Insisting that m68k could never meet the architecture release requirements
> doesn't make me think we're being unfair to m68k, it reinforces my belief
> that cutting m68k from the full release was the correct decision. The
> arch criteria weren't just pulled out of a hat, they were written to address
> specific ways in which an architecture can pull down the release process or
> cause support problems post-release.
The point is that these release criteria have practically enforced a black
and white scheme - either you're with us or you're on your own.
It's not just about this release. The problems are well known and they
won't go away, the question is what place m68k still has within Debian.
What can m68k expect besides "Here is some disk space, do what you want as
long as you don't bother us."
We certainly don't want to be a burden on the other ports, but what kind
of help can the m68k still expect? That's also a question the release team
should answer, instead I basically only see demands, that m68k should
figure it out by itself what it wants to do now, but only the release team
can answer what the m68k team could do to be releaseable _despite_ its
problems.
Something I'm concerned about in this area is the bug handling. IMO it was
a mistake how bugs were downgraded (note that I'm not talking about that
they got downgraded). Let's take guile-1.6, the BTS has only a single
comment from the maintainer, I didn't find any request for help on a
debian list, but a few months later the bug was downgraded for him and was
ignored ever since (even with patch now available). As it turns out this
problem was not caused by the compiler problems and IMO someone familiar
with package and access to a m68k machine could have fixed that. What I'd
like to see is that such request for a downgrade should come from the
maintainer, where he should explain the reasons. The point is that the
maintainer should know better how to deal with the problem, whether it
makes sense at all for the port to support the package or whether he has
any information, which could help to fix the problem. Once a fix is
available the priority should be increased again. This way it would
encourage the maintainer to deal with the problem properly and avoids a
NMU, currently he only has to wait long enough and the problem
"disappears".
> > We had indeed problems during development, but isn't the purpose of a
> > development stage to find and fix such issues? I really don't understand
> > that now at the end of the development stage there is absolutely no
> > intention to even look at the current situation and figure out what would
> > be needed for proper m68k release. Instead there is only hiding behind
> > release criteria and anonymous decisions.
>
> I don't believe it's realistic for a port to get back up to speed for
> release during a freeze if it hasn't been keeping up or hasn't caught up
> before that point. There will be other bugs found that will need to be
> fixed in the process of trying to build those packages that were held up by
> the previous toolchain issues, and I would expect a fair number of those
> newly-discovered bugs to require freeze-exceptions to address. Which means
> the freeze time would be eaten up trying to get m68k in shape for release,
> instead of on fixing up the "few" remaining RC bugs as intended.
I didn't say anything about that the release should wait for m68k, but why
can't the time that is available also be used to help m68k? If only bugs
where the necessary information to fix them is available were dealt with
(*), it would help m68k already a lot or are NMU now the only way that
m68k gets its bugs fixed? At the very least it would keep the difference
between whatever the m68k team releases close to the official release.
I actually looked at many of these problems and it's of course possible
new problems pop up, but I don't expect that many and could also be dealt
with via NFU. The important point is that packages with large reverse
dependencies are at this point dealt with.
(*) 391898 393754 384565 393601 198075 326905 390516
> And the condition of m68k with respect to the release criteria has declined
> since the decision was made, with the arch further lagging by a full 5% of
> the archive.
With the current release rate that's hardly suprising, even arm has its
problems keeping up.
bye, Roman
Reply to: