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

[Steve Langasek]

Hi folks,

It's with some regret that I have to confirm that m68k is not going to be a
release architecture for etch. I don't expect that this comes as any great
surprise; m68k's shortfalls with regards to the release standards have been
documented for some time, and in spite of what I know has been a diligent
effort on the part of all the m68k porters, this status has not improved
over the past months. Indeed, the status regarding archive coverage has
remained constant, at a level below the other architectures and too low for
us to consider releasing.

From <http://release.debian.org/etch_arch_qualify.html>, here's a brief
recap of where m68k fell short:

archive coverage: 92%
This indicates that m68k is generally not able to keep up with necessary
porting work for new software entering the archive, with 8% of all
packages not available.
Loading Image...

up-to-date: 95%
This indicates that, due either to regressions in support for the
architecture or inability of the autobuilder network to keep up, 5% of the
packages previously built for m68k are not up to date. This adds up to
228 source packages in unstable for which m68k would currently prevent
updates in testing (if m68k were not being ignored), 562 packages in
testing that are out-of-date on m68k, and 221 packages in testing that are
uninstallable on m68k.
Loading Image...

buildds: 19
There are 19 buildds actively uploading packages for m68k (Aug 20 to
present). This indicates that individual buildds are roughly an order of
magnitude slower than those for other architectures, which makes m68k a
limiting factor for time-critical builds such as security updates.

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.

[Frans Pop]

Post by Steve Langasek
It's with some regret that I have to confirm that m68k is not going to
be a release architecture for etch.

Firstly my condolences to the m68k porters. I know it is not for lack of
good intentions and hard work. In my experience the m68k port is one of
the more active in Debian.


Practically, what does this mean for the website, the Release Notes,
Debian Installer and the Installation Guide? Some ideas below.
Any issues I've missed in this list?

* Website
m68k should probably get a special mention on the ports page [1]. Maybe a
new section "Ports that are no longer supported"?
The short description should probably mention that m68k is still available
in unstable and may become supported again in the future.
The detailed port page [2] should reflect the new status as well.

Of course these changes should only become visible after the release.

* Release Notes
I guess m68k will need to be removed from the list of supported arches. We
should probably include a para about the removal and the reasons for it.

IMO we should not generate an m68k-variant of the Release Notes.

* Debian Installer
Should probably be treated as any other package: continue building it,
continue uploading it, but ignore issues and don't migrate to testing.
So, daily images should

One problem is CD images as these are all generated from testing. So, if
m68k is removed from testing, it will have to be disabled. This will need
further discussion when "another solution" is designed and implemented.

* Installation Guide
Add note in the introduction that m68k is not officially supported.
Otherwise the same as d-i: continue building and uploading into unstable.
I'd suggest to just keep the development version available on alioth [3].

Cheers,
FJP

[1] http://www.debian.org/ports/
[2] http://www.debian.org/ports/m68k/
[3] http://d-i.alioth.debian.org/manual/

[Michael Schmitz]

Post by Steve Langasek
It's with some regret that I have to confirm that m68k is not going to be a
release architecture for etch. I don't expect that this comes as any great

Well, I actually expected this to happen a lot sooner. When did we first
discuss the new release criteria? Back then, I thought being mostly
ignored for bug reports would kill the port dead within half a year.
Thanks for proving my point, albeit belatedly so.

Kudos for working so hard on gcc and difficult build problems to Roman
Zippel - we'd have been in much worse shape otherwise. Kudos to all the
other buildd admins and port hackers as well.

Future plans? Well, given the sorry state of affairs _overall_ over the
last year (that's talking about ix86 or powerpc, not m68k) or so, I say
I'll advocate everybody here in the lab to move on. Ubuntu looked good for
a while at least. Debian has apparently grown too brittle now.

Let's look at the bright side - we won't have to bother with building for
testing anymore, and may skip stable-security soon. Spare cycles for
unstable, and a spare machine for kernel hacking.

Michael

P.S.: Many Thanks to Frans for his oh-so-quick obit. !

[Andreas Barth]

Post by Michael Schmitz

Post by Steve Langasek
It's with some regret that I have to confirm that m68k is not going to be a
release architecture for etch. I don't expect that this comes as any great

Well, I actually expected this to happen a lot sooner. When did we first
discuss the new release criteria? Back then, I thought being mostly
ignored for bug reports would kill the port dead within half a year.
Thanks for proving my point, albeit belatedly so.

I doubt that has anything to do with making bug reports no longer RC.

Post by Michael Schmitz
Future plans? Well, given the sorry state of affairs _overall_ over the
last year (that's talking about ix86 or powerpc, not m68k) or so, I say
I'll advocate everybody here in the lab to move on. Ubuntu looked good for
a while at least. Debian has apparently grown too brittle now.

Eh, what are you talking about? Debian is getting way better than it
used to be, at least that's the impression I have. If you have another
opinion, please share that one with me (but that's off-topic for
debian-release as well as debian-m68k).

Cheers,
Andi

[Brian Morris]

i have not been using debian/linux for very long
(less than a year), however i was involved with
unix and with several kinds of 68k based machines
when they were new.

my impression of the current situation is that there
is some fairly heavy politicking goings on here. one
the action is not consistent with debian's published
values of inclusiveness.

competitiveness as a philosophy of more or mightier
is better is to me also inconsistent with the values of
free software.

there should be some provision in the Rules for lighter
form of the distribution. It makes no sense to build KDE
for an arch where nobody could use it because of the
hardware limitations. that was not always the case.
so it would make more sense to me to require kde to
come up with a light version that would run on smaller
more limited platforms and could be useful both for
embedded and older machines rather than to require
68k to keep up with a meta package they have no
use for.

perhaps the action is for the best if it makes such
development easier.

please don't take this in too limited or literal terms.

there are other possibilities, such as improving the
source code distribution system to make it more like
the binary system. it is better really to have it to be
truly free software, if the burden of compiling as in
other tasks is distributed.

in recent years there has been a growing differential
between hardware capabilities and those of the total
system -- that is some bloating and inefficiencies are
obvious, as well as slowdowns in fundamental capabilities.

it is really nice to have an older machine that has been
renovated with linux, abandoned by its makers years before.

also it is inherent to smaller devices that they will have
more limited capabilities, that applies to handheld and
to laptops too, as well as perhaps specialized machines
one might re-build for a specific dedicated purpose.

i learn more the more limited the hardware.

here i am listing reasons why a need for some structure
to carry on with the inclusiveness that debian has publicized.
if we are doing this for our own self integrity, that is some
thing we represent here, as well as other things of course.

also to give people the freedom to participate in future
developments, let us assume it is not always going to be
organized around simply quantity.

Post by Andreas Barth

Post by Michael Schmitz

Post by Steve Langasek
It's with some regret that I have to confirm that m68k is not going to

be a

Post by Michael Schmitz

Post by Steve Langasek
release architecture for etch. I don't expect that this comes as any

great

Post by Michael Schmitz
Well, I actually expected this to happen a lot sooner. When did we first
discuss the new release criteria? Back then, I thought being mostly
ignored for bug reports would kill the port dead within half a year.
Thanks for proving my point, albeit belatedly so.

I doubt that has anything to do with making bug reports no longer RC.

Post by Michael Schmitz
Future plans? Well, given the sorry state of affairs _overall_ over the
last year (that's talking about ix86 or powerpc, not m68k) or so, I say
I'll advocate everybody here in the lab to move on. Ubuntu looked good for
a while at least. Debian has apparently grown too brittle now.

Eh, what are you talking about? Debian is getting way better than it
used to be, at least that's the impression I have. If you have another
opinion, please share that one with me (but that's off-topic for
debian-release as well as debian-m68k).
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
--
with a subject of "unsubscribe". Trouble? Contact

[Andreas Barth]

I think we do need to have a discussion about ports that don't build the
full archive, but otherwise can make a stable release and get security
support.

Agreed.

I'd still like a stable, security-supported, m68k port. It doesn't need
all of kde or gnome or openoffice. I don't know that anyone will ever try
to run gnucash or gnuradio on it. I know there is interest in running X,
web and mail servers, and irc clients. Anything less will make it hard to
support the port and two years to another release is a long time.

Perhaps we can do something like amd64.d.n for m68k as well for etch?


Cheers,
Andi

[Andreas Barth]

Post by Andreas Barth

I'd still like a stable, security-supported, m68k port. It doesn't need
all of kde or gnome or openoffice. I don't know that anyone will ever try
to run gnucash or gnuradio on it. I know there is interest in running X,
web and mail servers, and irc clients. Anything less will make it hard to
support the port and two years to another release is a long time.

Perhaps we can do something like amd64.d.n for m68k as well for etch?

Just to put it a bit more obvious: In case m68k people like it, they
could use the dak on wp.debian.net (which was installed for different
reasons).


Cheers,
Andi

[Stephen R Marenka]

Post by Brian Morris
my impression of the current situation is that there
is some fairly heavy politicking goings on here. one
the action is not consistent with debian's published
values of inclusiveness.
also to give people the freedom to participate in future
developments, let us assume it is not always going to be
organized around simply quantity.

I'm not saying quantity isn't a problem or that politics isn't annoying,
but the m68k port's biggest problem since gcc-4.0 rolled out has been
the toolchain.

Roman Zippel has done some serious and great work fixing our toolchain
over the past two months or so. We're down to about 16 packages blocking
146 or so and a total of 72 packages failed due to m68k-specific problems.
The largest blocker is gjdoc with 60 packages, which moved from arch all
and neatly exposed our java problems.

If Roman keeps fixing bugs at this rate, I wouldn't be surprised if we
cleared that backlog before the end of the year. Although I doubt the
toolchain is going to get revved everytime he fixes a bug, since it
should be headed for freeze.

But that doesn't mean the RM's should give us special treatment. These
aren't new problems and some of those packages haven't built for something
like two years.

I think we do need to have a discussion about ports that don't build the
full archive, but otherwise can make a stable release and get security
support. Certainly m68k and likely arm users won't be running all the
latest bloatware and thus don't need to be building it (how long would
it take to load openoffice under kde on my m68k mac or even the fastest
ataris?). But drawing that line can be tricky because of dependencies.
I don't think anyone who really cares about the issue has come up with a
good way to frame the discussion or draw those lines yet.

I'd still like a stable, security-supported, m68k port. It doesn't need
all of kde or gnome or openoffice. I don't know that anyone will ever try
to run gnucash or gnuradio on it. I know there is interest in running X,
web and mail servers, and irc clients. Anything less will make it hard to
support the port and two years to another release is a long time.

Okay, that's more than I intended to write.

Peace,

Stephen

[Thomas Bushnell BSG]

Post by Stephen R Marenka
I'm not saying quantity isn't a problem or that politics isn't annoying,
but the m68k port's biggest problem since gcc-4.0 rolled out has been
the toolchain.

I don't think this is the only thing, however.

Notice that guile-1.6 has not built on m68k since 1.6.7-1.1. None of
the m68k porters have filed a bug, nor has the buildd team.

Moreover, it would be *entirely* reasonable for guile upstream to say
"I'm sorry, we don't support m68k and don't intend to."

There are a number of such language processors, not just the
GCC-related toolchain.

The m68k team will need to be the do-it-all porters of *all* such
toolchainy software, not just GCC. You'll need to work on guile and
scm, and plenty of other stuff.

Are you ready?

Thomas

[Stephen R Marenka]

Post by Thomas Bushnell BSG

Post by Stephen R Marenka
I'm not saying quantity isn't a problem or that politics isn't annoying,
but the m68k port's biggest problem since gcc-4.0 rolled out has been
the toolchain.

I don't think this is the only thing, however.
Notice that guile-1.6 has not built on m68k since 1.6.7-1.1. None of
the m68k porters have filed a bug, nor has the buildd team.

True, but I've filed a number of such bugs only to find they were gcc
toolchain problems. Many others were ignored out right, since we're
not RC. I hadn't intended to file that bug until I had ruled out the
compiler and maybe could file an intelligent bug report.

Post by Thomas Bushnell BSG
Moreover, it would be *entirely* reasonable for guile upstream to say
"I'm sorry, we don't support m68k and don't intend to."

As clisp has already done.

Post by Thomas Bushnell BSG
There are a number of such language processors, not just the
GCC-related toolchain.

Absolutely. The gcj toolchain seems to be almost as important as the
gcc toolchain. We have another 24 packages currently waiting on gch6
to build (once the toolchain bug was fixed we started running into
timeouts) and 12 on emacs21.

Post by Thomas Bushnell BSG
The m68k team will need to be the do-it-all porters of *all* such
toolchainy software, not just GCC. You'll need to work on guile and
scm, and plenty of other stuff.
Are you ready?

I'm really not sure how that's different from today.

[Thomas Bushnell BSG]

Post by Stephen R Marenka
True, but I've filed a number of such bugs only to find they were gcc
toolchain problems. Many others were ignored out right, since we're
not RC. I hadn't intended to file that bug until I had ruled out the
compiler and maybe could file an intelligent bug report.

Fair enough. My preference for packages that I maintain is that
people would file bugs right away, including in the bug report such
information as "this might really be caused by the toolchain". But
this isn't a package I maintain, and I can't speak for the
maintainer's preferences in this matter.

Thomas

[Steve Langasek]

Post by Stephen R Marenka
Roman Zippel has done some serious and great work fixing our toolchain
over the past two months or so. We're down to about 16 packages blocking
146 or so and a total of 72 packages failed due to m68k-specific problems.
The largest blocker is gjdoc with 60 packages, which moved from arch all
and neatly exposed our java problems.
If Roman keeps fixing bugs at this rate, I wouldn't be surprised if we
cleared that backlog before the end of the year. Although I doubt the
toolchain is going to get revved everytime he fixes a bug, since it
should be headed for freeze.

Moreover, there's the matter that this leaves no time for an archive-wide
check for toolchain /regressions/. As we enter the freeze, i386 and amd64
will most likely do whole-archive rebuilds as a consistency check; if m68k's
toolchain is changing right up to the end, this isn't even remotely
possible, leaving the security team to find these regressions on their own
when it comes time for a security update. :/

Post by Stephen R Marenka
I think we do need to have a discussion about ports that don't build the
full archive, but otherwise can make a stable release and get security
support. Certainly m68k and likely arm users won't be running all the
latest bloatware and thus don't need to be building it (how long would
it take to load openoffice under kde on my m68k mac or even the fastest
ataris?). But drawing that line can be tricky because of dependencies.
I don't think anyone who really cares about the issue has come up with a
good way to frame the discussion or draw those lines yet.

I agree that subsetting the archive seems like the most sensible solution
for m68k, but all previous attempts have run aground on the interdependency
problem. Perhaps you could suggest a few guidelines you would like to see
used, as a starting point for such a discussion?

[Stephen R Marenka]

Post by Steve Langasek

I think we do need to have a discussion about ports that don't build the
full archive, but otherwise can make a stable release and get security
support. Certainly m68k and likely arm users won't be running all the
latest bloatware and thus don't need to be building it (how long would
it take to load openoffice under kde on my m68k mac or even the fastest
ataris?). But drawing that line can be tricky because of dependencies.
I don't think anyone who really cares about the issue has come up with a
good way to frame the discussion or draw those lines yet.

I agree that subsetting the archive seems like the most sensible solution
for m68k, but all previous attempts have run aground on the interdependency
problem. Perhaps you could suggest a few guidelines you would like to see
used, as a starting point for such a discussion?

I certainly have some ideas. Do we have any good tools for evaluating
depends on such a scale? This is something I've only begun to look at so
I'm not familiar with the scope of the problem yet.

[Steve Langasek]

Post by Steve Langasek
Moreover, there's the matter that this leaves no time for an archive-wide
check for toolchain /regressions/. As we enter the freeze, i386 and amd64
will most likely do whole-archive rebuilds as a consistency check; if m68k's
toolchain is changing right up to the end, this isn't even remotely
possible, leaving the security team to find these regressions on their own
when it comes time for a security update. :/

That's rather unlikely, the m68k patches are already separate, so they
won't affect another port.

Right, but they could affect the security supportability of m68k *itself* by
introducing regressions late in the freeze.

Cheers,

[Roman Zippel]

Hi,

Post by Steve Langasek

That's rather unlikely, the m68k patches are already separate, so they
won't affect another port.

Right, but they could affect the security supportability of m68k *itself* by
introducing regressions late in the freeze.

Well, everything is possible, but the situation is improving, so this
should be a reason to be a bit more optimistic.

bye, Roman

[Roman Zippel]

Hi,

Post by Steve Langasek
Moreover, there's the matter that this leaves no time for an archive-wide
check for toolchain /regressions/. As we enter the freeze, i386 and amd64
will most likely do whole-archive rebuilds as a consistency check; if m68k's
toolchain is changing right up to the end, this isn't even remotely
possible, leaving the security team to find these regressions on their own
when it comes time for a security update. :/

That's rather unlikely, the m68k patches are already separate, so they
won't affect another port.

bye, Roman

[Steve Langasek]

Post by Brian Morris
competitiveness as a philosophy of more or mightier
is better is to me also inconsistent with the values of
free software.

The reason m68k has been disqualified as a release architecture has nothing
to do with competition with other architectures. m68k was disqualified
because it's not able to keep up with the demands placed on it by package
maintainers.

[Bill Allombert]

Post by Andreas Barth
Eh, what are you talking about? Debian is getting way better than it
used to be, at least that's the impression I have. If you have another
opinion, please share that one with me (but that's off-topic for
debian-release as well as debian-m68k).

gcc-4.0 was extremly brittle and should never has been made the default
compiler in sid. It was not working correctly on i386 let alone on
others platforms. I don't remember a similar issue with any other sid
compiler. I spent more working around compiler issues than I ever had
to.

I am quite glad we moved to gcc-4.1, but gcc-4.0 was a total waste of
time and certainly contributed for a great part for the current state
of m68k. Given the porter team are not responsible for the choice of
tool chains version for their architecture, they should not have to bear
the consequences.

So I urge you to give Debian/m68k a fair chance.

Cheers

[Michael Schmitz]

Post by Bill Allombert
gcc-4.0 was extremly brittle and should never has been made the default
compiler in sid. It was not working correctly on i386 let alone on
others platforms. I don't remember a similar issue with any other sid
compiler. I spent more working around compiler issues than I ever had
to.
I am quite glad we moved to gcc-4.1, but gcc-4.0 was a total waste of
time and certainly contributed for a great part for the current state
of m68k. Given the porter team are not responsible for the choice of
tool chains version for their architecture, they should not have to bear
the consequences.
So I urge you to give Debian/m68k a fair chance.

Having been insured that all this is about policy not attitude, I'd say we
have had our chance, m68k users should instead look at Debian for netbsd
instead.

Seriously, "we cannot afford to help you anymore" shows not only is gcc
brittle but so is the whole project.

Michael

[Ron Johnson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Michael Schmitz

Post by Bill Allombert
gcc-4.0 was extremly brittle and should never has been made the default
compiler in sid. It was not working correctly on i386 let alone on
others platforms. I don't remember a similar issue with any other sid
compiler. I spent more working around compiler issues than I ever had
to.
I am quite glad we moved to gcc-4.1, but gcc-4.0 was a total waste of
time and certainly contributed for a great part for the current state
of m68k. Given the porter team are not responsible for the choice of
tool chains version for their architecture, they should not have to bear
the consequences.
So I urge you to give Debian/m68k a fair chance.

Having been insured that all this is about policy not attitude, I'd say we
have had our chance, m68k users should instead look at Debian for netbsd
instead.
Seriously, "we cannot afford to help you anymore" shows not only is gcc
brittle but so is the whole project.

Regarding the project: either it's brittle, or it's just growing and
growing. Now that big projects like X & GNOME release on a rapid
schedule, and the kernel has many point releases, is the workload
just increasing?

- --
Ron Johnson, Jr.
Jefferson LA USA

Is "common sense" really valid?
For example, it is "common sense" to white-power racists that
whites are superior to blacks, and that those with brown skins
are mud people.
However, that "common sense" is obviously wrong.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFFVSCS9HxQb37XmcRAkiWAKDamV66ZHGEGeD/sG+GV9Jhg1oAcQCg05Va
ZGm3zpJ9mX9q+g/WSBYmbeU=
=CbE1
-----END PGP SIGNATURE-----

[Wouter Verhelst]

Hi Steve,

On Sun, Sep 17, 2006 at 11:55:02PM -0700, Steve Langasek wrote:
[...]

Post by Steve Langasek
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.

[Martin Schulze]

Post by Wouter Verhelst
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;

In theory a lot more should be possible. My fear is that even when it
shouldn't be too difficult it can still take a long time until ftpmasters
implement the required changes. I'd rather be sure the code is there
before the release of etch so m68k-etch can be "release" right afterwards.

Post by Wouter Verhelst
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.

Given that

- the differences in packages are only minimal
- it's not problematic if there are packages missing
- there's enough buildd power connected to the archive
to build security updates
- there's a chance to update the stable m68k releases wrt.
point releases

In general, let it be like stable, then it's fine.

Regards,

Joey

[Filipus Klutiero]

Post by Wouter Verhelst
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).

So what to do after the definite period of time? Remove it from testing
on all arches? That's not an option. You're free to search for
alternatives, but there's little to find.

[Wouter Verhelst]

Post by Filipus Klutiero

Post by Wouter Verhelst
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).

So what to do after the definite period of time? Remove it from testing
on all arches? That's not an option.

Could you explain that a bit more? Why is it not an option?

Post by Filipus Klutiero
You're free to search for alternatives, but there's little to find.

I realize that. I also want you to realize that the current way is not
optimal, and will actually make it harder for an architecture to reach
releaseable status again once it's no longer in that status.

Currently, it's a bit like, "once you're there, we don't care about you
anymore". Instead of helping architectures, you push them deeper into
problems with that attitude.

Note that I'm not complaining about this -- the rules were clear, and I
don't think we would've reached it had they been different in the way
that I'm suggesting; however, I do feel that this is something which
needs to be thought about for the next release cycle, because you *will*
run into problems otherwise.

[Filipus Klutiero]

Post by Wouter Verhelst

Post by Filipus Klutiero

Post by Wouter Verhelst
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).

So what to do after the definite period of time? Remove it from testing
on all arches? That's not an option.

Could you explain that a bit more? Why is it not an option?

It's not an option because it does nothing good to Debian to remove the
package for all other architectures, except increasing the lagging
architecture's archive coverage in testing; which is certainly not worth
removing useful software for other archs.

Post by Wouter Verhelst

Post by Filipus Klutiero
You're free to search for alternatives, but there's little to find.

I realize that. I also want you to realize that the current way is not
optimal, and will actually make it harder for an architecture to reach
releaseable status again once it's no longer in that status.

It was clear from the message I was replying to that you considered the
way the release team handles this non-optimal, and this is what makes me
react. If ignoring an arch for testing propagation is not optimal, there
has to be a more optimal way to handle things, between that and manually
approving updates that introduce regressions as is done by default.
There may be possible compromises here, such as adding a constant delay
from the moment where an FTBFS on the problematic arch becomes the only
blocker for testing transition. For example, foo 1-1 is in testing for
m68k and an urgency low 1-2 upload FTBFS on m68k. If 10 days after the
upload nothing else but that FTBFS stops propagation, add the package to
a "recess"(?) DB. If there is no improvement after 5 days and the
package is still otherwise ready for testing propagation, update anyway.
Nevertheless, I expect that even if implemented, such a measure would
only be of little help, for very temporary issues.

Post by Wouter Verhelst
Currently, it's a bit like, "once you're there, we don't care about you
anymore". Instead of helping architectures, you push them deeper into
problems with that attitude.

Or "once you're there, we can't afford to help you anymore". But really,
this is policy, not "attitude".

Post by Wouter Verhelst
Note that I'm not complaining about this -- the rules were clear, and I
don't think we would've reached it had they been different in the way
that I'm suggesting; however, I do feel that this is something which
needs to be thought about for the next release cycle, because you *will*
run into problems otherwise.

Problems such as not officially supporting m68k? Sorry, but I don't
think that's a big deal in 2006/2007. I agree with Steve Langasek that
the effort from m68k porters was diligent, but it's normal that support
is decreasing at this point, and I guess the release team would like
this to be accepted without being called [a bit] aggressive.

[Wouter Verhelst]

Post by Filipus Klutiero

Post by Wouter Verhelst

Post by Filipus Klutiero

Post by Wouter Verhelst
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).

So what to do after the definite period of time? Remove it from testing
on all arches? That's not an option.

Could you explain that a bit more? Why is it not an option?

It's not an option because it does nothing good to Debian to remove the
package for all other architectures, except increasing the lagging
architecture's archive coverage in testing; which is certainly not worth
removing useful software for other archs.

Post by Wouter Verhelst

Post by Filipus Klutiero
You're free to search for alternatives, but there's little to find.

I realize that. I also want you to realize that the current way is not
optimal, and will actually make it harder for an architecture to reach
releaseable status again once it's no longer in that status.

It was clear from the message I was replying to that you considered the
way the release team handles this non-optimal, and this is what makes me
react. If ignoring an arch for testing propagation is not optimal, there
has to be a more optimal way to handle things, between that and manually
approving updates that introduce regressions as is done by default.
There may be possible compromises here, such as adding a constant delay
from the moment where an FTBFS on the problematic arch becomes the only
blocker for testing transition. For example, foo 1-1 is in testing for
m68k and an urgency low 1-2 upload FTBFS on m68k. If 10 days after the
upload nothing else but that FTBFS stops propagation, add the package to
a "recess"(?) DB. If there is no improvement after 5 days and the
package is still otherwise ready for testing propagation, update anyway.
Nevertheless, I expect that even if implemented, such a measure would
only be of little help, for very temporary issues.

Yes, I agree; I'm not convinced this would in fact do any good, and I
would recommend against that.

The main problem isn't even the fact that an architecture isn't
considered for testing migration anymore; the main problem is the fact
that it makes maintainers care less, and the fact that it seriously
degrades the quality of a port's testing distribution, which in turn
makes it hard for people to, err, test it, so you get less bug reports
and it gets even harder to fix bugs (how can you fix bugs you don't even
know about?).

Post by Filipus Klutiero

Post by Wouter Verhelst
Currently, it's a bit like, "once you're there, we don't care about you
anymore". Instead of helping architectures, you push them deeper into
problems with that attitude.

Or "once you're there, we can't afford to help you anymore".

I'm having a hard time believing this. Sure, I understand the release
team wouldn't want to waste time on ports that are lagging behind;
however, it would be nice if there was more for a problematic port to
work with than there is now.

Post by Filipus Klutiero
But really, this is policy, not "attitude".

Can we please not squabble over words?

Post by Filipus Klutiero

Post by Wouter Verhelst
Note that I'm not complaining about this -- the rules were clear, and I
don't think we would've reached it had they been different in the way
that I'm suggesting; however, I do feel that this is something which
needs to be thought about for the next release cycle, because you *will*
run into problems otherwise.

Problems such as not officially supporting m68k?

*sigh*

This is not about me, and this is not about m68k. The above is so far
away from the point I've been trying to make in these last two mails
that I'm starting to think there's something wrong with my English.

Well -- mine, or yours.

Post by Filipus Klutiero
Sorry, but I don't think that's a big deal in 2006/2007. I agree with
Steve Langasek that the effort from m68k porters was diligent, but
it's normal that support is decreasing at this point, and I guess the
release team would like this to be accepted without being called [a
bit] aggressive.

I didn't call anyone aggressive; please don't put any words in my mouth.

What I'm saying is the following: this is the first time a port has been
removed from Debian, and I would expect that you'd evaluate what you've
been doing so as to make the procedure better for the same situation in
the future. Next time, it won't be m68k, but SPARC, s390, or Alpha. If
you make it hard for a port to get out of problems, you turn Debian into
a great i386/amd64 distribution, but little more.

I'm not saying that we would've made it had we been considered for
testing migration at this point; there were other issues that were
holding us back; if this would've been the only thing, I would've been
asking around for ages already.

But it is a fact that not having a decent testing distribution has
slowed us down from time to time; that having to catch up had we been
able to fix all the other problems would have made it much harder for us
to make it at this point. This is a problem, not just for the m68k port,
but for Debian as a whole, and I would like the release team to consider
this. There is more to testing migration than "if it doesn't happen in
time, maintainers might get angry".

If the release team does consider this and decides that they just don't
care, it's their problem. But then don't come complaining that I didn't
warn you when the SPARC or Alpha port maintainers find that they have a
"slight" problem. I won't deny that the m68k port does not have much
value for most people at this point. In fact, IIRC, that's what I opened
the Helsinki meeting about this subject with...

[Filipus Klutiero]

Post by Wouter Verhelst

Post by Filipus Klutiero

Post by Wouter Verhelst

Post by Filipus Klutiero

Post by Wouter Verhelst
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).

So what to do after the definite period of time? Remove it from testing
on all arches? That's not an option.

Could you explain that a bit more? Why is it not an option?

It's not an option because it does nothing good to Debian to remove the
package for all other architectures, except increasing the lagging
architecture's archive coverage in testing; which is certainly not worth
removing useful software for other archs.

Post by Wouter Verhelst

Post by Filipus Klutiero
You're free to search for alternatives, but there's little to find.

I realize that. I also want you to realize that the current way is not
optimal, and will actually make it harder for an architecture to reach
releaseable status again once it's no longer in that status.

It was clear from the message I was replying to that you considered the
way the release team handles this non-optimal, and this is what makes me
react. If ignoring an arch for testing propagation is not optimal, there
has to be a more optimal way to handle things, between that and manually
approving updates that introduce regressions as is done by default.
There may be possible compromises here, such as adding a constant delay
from the moment where an FTBFS on the problematic arch becomes the only
blocker for testing transition. For example, foo 1-1 is in testing for
m68k and an urgency low 1-2 upload FTBFS on m68k. If 10 days after the
upload nothing else but that FTBFS stops propagation, add the package to
a "recess"(?) DB. If there is no improvement after 5 days and the
package is still otherwise ready for testing propagation, update anyway.
Nevertheless, I expect that even if implemented, such a measure would
only be of little help, for very temporary issues.

Yes, I agree; I'm not convinced this would in fact do any good, and I
would recommend against that.
The main problem isn't even the fact that an architecture isn't
considered for testing migration anymore; the main problem is the fact
that it makes maintainers care less,

It's normal that maintainers care less when an arch loses it's canditate
status, since among other reasons fixing things will unlikely make a
difference in "official" Debian. Did you mean that it makes maintainers
care too few?

Post by Wouter Verhelst
and the fact that it seriously
degrades the quality of a port's testing distribution, which in turn
makes it hard for people to, err, test it, so you get less bug reports
and it gets even harder to fix bugs (how can you fix bugs you don't even
know about?).

This is a direct consequence of not considering an arch for testing
migration...I don't see how it could be any different unless one wants
to manage its own testing.

Post by Wouter Verhelst

Post by Filipus Klutiero

Post by Wouter Verhelst
Currently, it's a bit like, "once you're there, we don't care about you
anymore". Instead of helping architectures, you push them deeper into
problems with that attitude.

Or "once you're there, we can't afford to help you anymore".

I'm having a hard time believing this. Sure, I understand the release
team wouldn't want to waste time on ports that are lagging behind;
however, it would be nice if there was more for a problematic port to
work with than there is now.

Sure, but what?

Post by Wouter Verhelst

Post by Filipus Klutiero
But really, this is policy, not "attitude".

Can we please not squabble over words?

Whatever.

Post by Wouter Verhelst

Post by Filipus Klutiero

Post by Wouter Verhelst
Note that I'm not complaining about this -- the rules were clear, and I
don't think we would've reached it had they been different in the way
that I'm suggesting; however, I do feel that this is something which
needs to be thought about for the next release cycle, because you *will*
run into problems otherwise.

Problems such as not officially supporting m68k?

*sigh*
This is not about me, and this is not about m68k. The above is so far
away from the point I've been trying to make in these last two mails
that I'm starting to think there's something wrong with my English.
Well -- mine, or yours.

Post by Filipus Klutiero
Sorry, but I don't think that's a big deal in 2006/2007. I agree with
Steve Langasek that the effort from m68k porters was diligent, but
it's normal that support is decreasing at this point, and I guess the
release team would like this to be accepted without being called [a
bit] aggressive.

I didn't call anyone aggressive; please don't put any words in my mouth.

When rereading myself, it's hard to believe that I simplified
"aggressive with removing an architecture from being considered for
testing" to "aggressive", but I did. Sorry.

Post by Wouter Verhelst
What I'm saying is the following: this is the first time a port has been
removed from Debian, and I would expect that you'd evaluate what you've
been doing so as to make the procedure better for the same situation in
the future. Next time, it won't be m68k, but SPARC, s390, or Alpha. If
you make it hard for a port to get out of problems, you turn Debian into
a great i386/amd64 distribution, but little more.

If one reads popcon to the letter, Debian is *already* little more than
a great i386/amd64 distro, that is about 8% more.

Post by Wouter Verhelst
I'm not saying that we would've made it had we been considered for
testing migration at this point; there were other issues that were
holding us back; if this would've been the only thing, I would've been
asking around for ages already.
But it is a fact that not having a decent testing distribution has
slowed us down from time to time; that having to catch up had we been
able to fix all the other problems would have made it much harder for us
to make it at this point. This is a problem, not just for the m68k port,
but for Debian as a whole, and I would like the release team to consider
this. There is more to testing migration than "if it doesn't happen in
time, maintainers might get angry".

"if it doesn't happen in time, users will be angry"?

Post by Wouter Verhelst
If the release team does consider this and decides that they just don't
care, it's their problem. But then don't come complaining that I didn't
warn you when the SPARC or Alpha port maintainers find that they have a
"slight" problem. I won't deny that the m68k port does not have much
value for most people at this point. In fact, IIRC, that's what I opened
the Helsinki meeting about this subject with...

Seriously now, what should the release team do to both consider and
care? Steve Langasek won't pull a magical "SCC"-friendly trick out his
sleeve now that his m68k enemy is dead [for 4.0]. If nobody has concrete
propositions, the release team will consider, care, and do nothing
particular. If you have concrete proposals, I think that Steve already
welcomed these, so please share. Also, if the release team does nothing
while it should do something, it will be Debian's problem, not just the
release team's. But nobody will complain to you if something happens to
SPARC or alpha. There's only a chance that people are grateful that you
suggested an efficient improvement.

[Moritz Muehlenhoff]

Post by Wouter Verhelst
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.

My spare time is too limited to care about m68k. I'd suggest you prepare
the m68k binary updates from the regular source updates available on
s.d.o on your own.

Cheers,
Moritz

[Stephen R Marenka]

Post by Moritz Muehlenhoff

Post by Wouter Verhelst
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.

My spare time is too limited to care about m68k. I'd suggest you prepare
the m68k binary updates from the regular source updates available on
s.d.o on your own.

Could m68k still do security building out of wanna-build?

Thanks,

Stephen

[Moritz Muehlenhoff]

Post by Stephen R Marenka

Post by Moritz Muehlenhoff
My spare time is too limited to care about m68k. I'd suggest you prepare
the m68k binary updates from the regular source updates available on
s.d.o on your own.

Could m68k still do security building out of wanna-build?

Of course, you could also have continued access to the embargoed issues, but
I think the m68k porters can do a better job at judging which packages to
support security-wise than the Security team.

Cheers,
Moritz

[Bill Allombert]

Post by Steve Langasek
Hi folks,
It's with some regret that I have to confirm that m68k is not going to be a
release architecture for etch.

Time will tell.

Cheers,

[Roman Zippel]

Hi,

Post by Steve Langasek
buildds: 19
There are 19 buildds actively uploading packages for m68k (Aug 20 to
present). This indicates that individual buildds are roughly an order of
magnitude slower than those for other architectures, which makes m68k a
limiting factor for time-critical builds such as security updates.
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.

This will always be a killer argument against supporting slower ports. :-(

Post by Steve Langasek
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.

As someone who has recently looked at and fixed many problems, I must say
the release team has done m68k no service by doing this and actually
sabotaged m68k in its ability to catch up again.
Fixes for problems are too often simply stuck in the BTS now, because in
many cases maintainer simply don't care about m68k support. I often have
to bug people to get them to release a fixed package.
It's one thing to expect from m68k not to hold up other ports, but it's a
different thing to take from m68k the means to catch up again.

Post by Steve Langasek
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.

So the situation is now that m68k gets kicked out without no alternative
in place? Once the current building frenzy calms down, the situation
shouldn't look too bad and if bugs for which fixes exists in the BTS where
actually fixed, m68k could be released with just a few packages less.
Not releasing m68k could have far worse consequences and should be
absolutely the last resort, e.g. it makes it difficult to upgrade between
stable releases, which might become a real issue, as m68k is likely to
need an ABI change for TLS support.

What are the alternatives for m68k _now_? To me it looks like the release
team is expecting a miracle. It's a fact that m68k is a slow port and as
long as the release team is insisting on "fixing" this, m68k is doomed. :-(

bye, Roman

[Roman Zippel]

Hi,

I suggest you read section 5.10 of the developers reference, and do
porter/non-maintainer source uploads if you think it's holding up things
and the maintainer isn't very responsive.

I'm not a Debian developer, I'm "only" a user, who'd like to support
Debian, but it's not exactly easy.

bye, Roman

[Thomas Bushnell BSG]

Post by Roman Zippel
Fixes for problems are too often simply stuck in the BTS now, because in
many cases maintainer simply don't care about m68k support. I often have
to bug people to get them to release a fixed package.

Does this explain why guile-1.6 is still not compiled for m68k?

Thomas

[Roman Zippel]

Hi,

Post by Thomas Bushnell BSG

Post by Roman Zippel
Fixes for problems are too often simply stuck in the BTS now, because in
many cases maintainer simply don't care about m68k support. I often have
to bug people to get them to release a fixed package.

Does this explain why guile-1.6 is still not compiled for m68k?

I'm not sure what you intent with this question. The patch is not that
old yet, but it's there:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=326905

bye, Roman

[Thomas Bushnell BSG]

Post by Roman Zippel

Post by Thomas Bushnell BSG

Post by Roman Zippel
Fixes for problems are too often simply stuck in the BTS now, because in
many cases maintainer simply don't care about m68k support. I often have
to bug people to get them to release a fixed package.

Does this explain why guile-1.6 is still not compiled for m68k?

I'm not sure what you intent with this question. The patch is not that
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=326905

Wow, that's rich. The patch was posted to the bug log all of THIRTY
MINUTES before your message here, and AFTER my email.

So this nonsense of "fixes are just stuck in the BTS" is still
nonsense.

Thomas

[Roman Zippel]

Hi,

Post by Thomas Bushnell BSG

Post by Roman Zippel
I'm not sure what you intent with this question. The patch is not that
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=326905

Wow, that's rich. The patch was posted to the bug log all of THIRTY
MINUTES before your message here, and AFTER my email.
So this nonsense of "fixes are just stuck in the BTS" is still
nonsense.

Look closer, so your whole intention was to distract from the real issues
and just insult whose who want to help? Indeed, that's rich. :-(

bye, Roman

[Thomas Bushnell BSG]

Post by Roman Zippel

Post by Thomas Bushnell BSG

Post by Roman Zippel
I'm not sure what you intent with this question. The patch is not that
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=326905

Wow, that's rich. The patch was posted to the bug log all of THIRTY
MINUTES before your message here, and AFTER my email.
So this nonsense of "fixes are just stuck in the BTS" is still
nonsense.

Look closer, so your whole intention was to distract from the real issues
and just insult whose who want to help? Indeed, that's rich. :-(

You claimed that it's a bad idea to drop m68k as a release candidate,
because the only way bugs will get fixed is if maintainers are forced
to include patches.

In fact, the one m68k porting problem that affects packages I am
concerned with has lied dormant for a year, until today.

Your message was deliberately misleading, designed to suggest that
there had been a fix in for a while (even if "not that old yet"), when
in fact, the patch was posted *after* my message.

Thomas

[Roman Zippel]

Hi,

Post by Thomas Bushnell BSG
You claimed that it's a bad idea to drop m68k as a release candidate,
because the only way bugs will get fixed is if maintainers are forced
to include patches.

I didn't say anything about "forcing", that's your conclusion.

Post by Thomas Bushnell BSG
In fact, the one m68k porting problem that affects packages I am
concerned with has lied dormant for a year, until today.

You pick a single example and draw general conclusions from it and you
accuse me of "deliberately misleading"?

Post by Thomas Bushnell BSG
Your message was deliberately misleading, designed to suggest that
there had been a fix in for a while (even if "not that old yet"), when
in fact, the patch was posted *after* my message.

What the hell is your problem? Yes, the patch is _one_ day old and instead
of thanking me for finally fixing this problem, I get this?

bye, Roman

[Thomas Bushnell BSG]

Post by Roman Zippel

Post by Thomas Bushnell BSG
Your message was deliberately misleading, designed to suggest that
there had been a fix in for a while (even if "not that old yet"), when
in fact, the patch was posted *after* my message.

What the hell is your problem? Yes, the patch is _one_ day old and instead
of thanking me for finally fixing this problem, I get this?

I have no idea if you have fixed the problem or not; I'm not the
package maintainer and I haven't examined the patch.

But you attempted to trick people, by pretending that the patch was
already there before my email. You wanted to make me look bad, as if
I was bringing up an example where there was a patch in the bug-log.
Since your claim is that m68k suffers because maintainers ignore
patches in the bug logs, you concocted an example right away.

Your message gave no hint that you in fact posted the patch in
*response* to my message, and indeed, since you're trying to blame
maintainers for ignoring m68k patches, it fits right in line with your
general attack to concoct just such a case, when in fact, the opposite
was the case.

Thomas

[Roman Zippel]

Hi,

Post by Thomas Bushnell BSG
But you attempted to trick people, by pretending that the patch was
already there before my email. You wanted to make me look bad, as if
I was bringing up an example where there was a patch in the bug-log.
Since your claim is that m68k suffers because maintainers ignore
patches in the bug logs, you concocted an example right away.

You're the one who mentioned guile-1.6, it's not my example.

Post by Thomas Bushnell BSG
Your message gave no hint that you in fact posted the patch in
*response* to my message, and indeed, since you're trying to blame
maintainers for ignoring m68k patches, it fits right in line with your
general attack to concoct just such a case, when in fact, the opposite
was the case.

Get your facts straight, I posted the patch _yesterday_ night, _before_
you mentioned it.

You're still distracting from the real issue by running a personal attack
based on incorrect conclusions. :-( Do you even have any interest in
discussing the status of the m68k port or was your initial phrase 'Please
let the release team know how we can be of assistance to you in setting
and meeting goals for an m68k release' just a hollow phrase, hoping m68k
could never fix many of the remaining bugs? I may have missed something,
but I haven't seen anything from you, which might indicate something
otherwise...

bye, Roman

[Thomas Bushnell BSG]

Post by Roman Zippel
was your initial phrase 'Please
let the release team know how we can be of assistance to you in setting
and meeting goals for an m68k release' just a hollow phrase...

I never said anything of the kind.

If the m68k team can make the port happen without messing up the rest
of Debian, great. But from my perspective the huge delays on the
autobuilders are a disaster. Without actually fixing this, we cannot
permit an architecture that is unable to keep up with autobuilds to
slow everything else down.

For example, the inattention of the porting team to the guile-1.6 bug
means that gnucash is at 2.0.2 on every architecture except m68k,
where it is version *1.8.10*.

Thomas

[Roman Zippel]

Hi,

Post by Thomas Bushnell BSG

Post by Roman Zippel
was your initial phrase 'Please
let the release team know how we can be of assistance to you in setting
and meeting goals for an m68k release' just a hollow phrase...

I never said anything of the kind.

The way you reacted to my mail, I assumed you were part of the release
team and were somehow offended by it, I apologize for the confusion.

Post by Thomas Bushnell BSG
If the m68k team can make the port happen without messing up the rest
of Debian, great. But from my perspective the huge delays on the
autobuilders are a disaster. Without actually fixing this, we cannot
permit an architecture that is unable to keep up with autobuilds to
slow everything else down.
For example, the inattention of the porting team to the guile-1.6 bug
means that gnucash is at 2.0.2 on every architecture except m68k,
where it is version *1.8.10*.

This could mean as well, that gnucash won't be part of the m68k release,
although now that guile is fixed this could look as well quite different.
It's still quite a leap in conclusion here to get from problems with a few
packages to declaring m68k not releaseable at all.

bye, Roman

[Bill Allombert]

Post by Thomas Bushnell BSG

Post by Roman Zippel

Post by Thomas Bushnell BSG

Post by Roman Zippel
Fixes for problems are too often simply stuck in the BTS now, because in
many cases maintainer simply don't care about m68k support. I often have
to bug people to get them to release a fixed package.

Does this explain why guile-1.6 is still not compiled for m68k?

I'm not sure what you intent with this question. The patch is not that
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=326905

Wow, that's rich. The patch was posted to the bug log all of THIRTY
MINUTES before your message here, and AFTER my email.

Thirty minutes to fix that bug ? Roman you rock!

Post by Thomas Bushnell BSG
So this nonsense of "fixes are just stuck in the BTS" is still
nonsense.

You did not ask Roman to provide examples of "fixes are just stuck in the
BTS", you picked your own bug and then complains it is not a good example
? Is not that non-sense ?

Cheers,

[Thomas Bushnell BSG]

Post by Bill Allombert
You did not ask Roman to provide examples of "fixes are just stuck in the
BTS", you picked your own bug and then complains it is not a good example
? Is not that non-sense ?

No, what I did was I asked how his claim relates to a particular bug
in a package affecting me, and he responded by saying that the bug was
an example of his claim, when, in fact, it wasn't.

Thomas

[Ingo Juergensmann]

Post by Thomas Bushnell BSG

Post by Bill Allombert
You did not ask Roman to provide examples of "fixes are just stuck in the
BTS", you picked your own bug and then complains it is not a good example
? Is not that non-sense ?

No, what I did was I asked how his claim relates to a particular bug
in a package affecting me, and he responded by saying that the bug was
an example of his claim, when, in fact, it wasn't.

You asked:

| Does this explain why guile-1.6 is still not compiled for m68k?

Maybe you just wanted to know if the bug is solved in the meanwhile, but
your way to ask is very, uhm, bad, because it includes some sort of attack.
Your question can be understood as "Why the fsckin hell didn't you managed
to get *MY* beloved package guile-1.6 on your fsckin slow arch, you
morons!?"
This is of course an exaggeration of the slight aggressive undertone in your
question to make it clear how your question can be understood by others.
A probably better way to get your problem solved would have been:

"Oh, great... Do you think that the bug which keeps guile-1.6 failing on
m68k will be solved soon? Is there anything I can help or do?"

Anyway, Roman wrote about a general issue and you forced him into a specific
package discussion (not to say flame war). I don't think that either Roman
nor you are happy about the way the discussion went. Do you?
--
Ciao... // Fon: 0381-2744150
Ingo \X/ SIP: ***@sipgate.de

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

[Thomas Bushnell BSG]

Post by Ingo Juergensmann
| Does this explain why guile-1.6 is still not compiled for m68k?
Maybe you just wanted to know if the bug is solved in the meanwhile, but
your way to ask is very, uhm, bad, because it includes some sort of attack.
Your question can be understood as "Why the fsckin hell didn't you managed
to get *MY* beloved package guile-1.6 on your fsckin slow arch, you
morons!?"

Um, You'll note that g-wrap also has not been built, another
dependency of gnucash. Version 1.9.6-3.1 was uploaded on September 7,
and gnucash depends on that version.

It's not like I hunted around for problems, I simply looked at the
cases closest to the packages I maintain, asking "why don't they work
on m68k?"

Thomas

[Bill Allombert]

Post by Thomas Bushnell BSG
It's not like I hunted around for problems, I simply looked at the
cases closest to the packages I maintain, asking "why don't they work
on m68k?"

I expected you would have realised by that time that you maintain some
of the most problematic packages in Debian (seriously).

Cheers,

[Thomas Bushnell BSG]

Post by Bill Allombert

Post by Thomas Bushnell BSG
It's not like I hunted around for problems, I simply looked at the
cases closest to the packages I maintain, asking "why don't they work
on m68k?"

I expected you would have realised by that time that you maintain some
of the most problematic packages in Debian (seriously).

Riiiight. I don't maintain guile or g-wrap, you know.

[Aurélien GÉRÔME]

Post by Thomas Bushnell BSG

Post by Bill Allombert

Post by Thomas Bushnell BSG
It's not like I hunted around for problems, I simply looked at the
cases closest to the packages I maintain, asking "why don't they work
on m68k?"

I expected you would have realised by that time that you maintain some
of the most problematic packages in Debian (seriously).

Riiiight. I don't maintain guile or g-wrap, you know.

Yes, true. However, you are supposed to maintain lilypond, but it
is a different story here... Anway, why are you bashing m68k folks
who help, instead of being helpful yourself? m68k porters are doing
a lot of work to keep the port alive which is admirable.

Cheers,

[Ingo Juergensmann]

Post by Thomas Bushnell BSG
Um, You'll note that g-wrap also has not been built, another
dependency of gnucash. Version 1.9.6-3.1 was uploaded on September 7,
and gnucash depends on that version.
It's not like I hunted around for problems, I simply looked at the
cases closest to the packages I maintain, asking "why don't they work
on m68k?"

Oh well... you already know that m68k suffered from serious toolchain
problems, which are fixed now thanks to Roman, Stephen Marenka and others,
and that the w-b queueing algorithm is not known to be very intelligent,
i.e. it doesn't queue in order of required build-deps nor what's long
waiting for building. Instead some packages are built rather frequently, and
others are going to get stucked in the queue.
M68k would keeping up better, when there wouldn't be that much waste on CPU
cycles...

But that's another story and not the topic of this discussion, neither the
reasons why specific packages are unbuilt is.
--
Ciao... // Fon: 0381-2744150
Ingo \X/ SIP: ***@sipgate.de

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

[Thomas Bushnell BSG]

Post by Ingo Juergensmann
Oh well... you already know that m68k suffered from serious toolchain
problems, which are fixed now thanks to Roman, Stephen Marenka and others,
and that the w-b queueing algorithm is not known to be very intelligent,
i.e. it doesn't queue in order of required build-deps nor what's long
waiting for building. Instead some packages are built rather frequently, and
others are going to get stucked in the queue.

And that's why g-wrap hasn't been built, or is it irrelevant?

thomas

[Thomas Bushnell BSG]

Post by Ingo Juergensmann
Oh well... you already know that m68k suffered from serious toolchain
problems, which are fixed now thanks to Roman, Stephen Marenka and others,
and that the w-b queueing algorithm is not known to be very intelligent,
i.e. it doesn't queue in order of required build-deps nor what's long
waiting for building. Instead some packages are built rather frequently, and
others are going to get stucked in the queue.

And that's why g-wrap hasn't been built, or is it irrelevant?

thomas

[Ingo Juergensmann]

Post by Thomas Bushnell BSG
And that's why g-wrap hasn't been built, or is it irrelevant?

Yes, this is irrelevant for this thread as the topic of this thread is "m68k
not a release arch for etch; status in testing, future plans?" and not
"Thomas Bushnell would like to see his packages being built on m68k". Maybe
that's disappointing for you know, but I'm more interested in the big
picture of getting m68k released with Etch.
So, be welcomed to discuss the on-topic questions with us. :-)
--
Ciao... // Fon: 0381-2744150
Ingo \X/ SIP: ***@sipgate.de

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

[Thomas Bushnell BSG]

Post by Ingo Juergensmann
Yes, this is irrelevant for this thread as the topic of this thread is "m68k
not a release arch for etch; status in testing, future plans?" and not
"Thomas Bushnell would like to see his packages being built on m68k". Maybe
that's disappointing for you know, but I'm more interested in the big
picture of getting m68k released with Etch.

I don't care either way whether m68k is released in etch. But I do
care that etch isn't screwed because of a desperate attempt to support
m68k in it.

m68k does not keep up. It doesn't. Eventually it will be impossible
for it to keep up, no matter how many Amigas people still have.

My packages are not unique. The accusation was that it is developers
at large who are to blame for m68k not keeping up, because patches
languish and don't get uploaded. (Never mind that porters can NMU the
packages.) I was pointing out that, in the cases I know of, it has
*not* been slow developers that were the problem.

The reason that m68k is not keeping up is *not* that developers at
large are uncooperative, and I was bothered greatly (and still am) by
the suggestion that it's everyone else's job and problem to support
m68k, while the actual porting team manifestly does not have the
personnel or the time to do the job.

Thomas

[Wouter Verhelst]

Post by Thomas Bushnell BSG
I don't care either way whether m68k is released in etch. But I do
care that etch isn't screwed because of a desperate attempt to support
m68k in it.

[...]

Post by Thomas Bushnell BSG
m68k, while the actual porting team manifestly does not have the
personnel or the time to do the job.

If you have no fucking clue as to what the current state of things is
and why the architecture has been thrown out, I suggest you keep your
petty comments to yourself.
* Etch isn't screwed because of a desperate attempt to support m68k in
it, never has been, and never will be. In fact, m68k is screwed
(partially) because of a (desperate or not) attempt to preserve etch.
* The problem that made us not make etch involves much, much more than
either personnel or time.

[Thomas Bushnell BSG]

Post by Wouter Verhelst
If you have no fucking clue as to what the current state of things is
and why the architecture has been thrown out, I suggest you keep your
petty comments to yourself.
* Etch isn't screwed because of a desperate attempt to support m68k in
it, never has been, and never will be. In fact, m68k is screwed
(partially) because of a (desperate or not) attempt to preserve etch.

There are four packages of importance to me whose upgrades would be
excluded from etch if working on m68k was a release criterion. There
are hundreds more in the same position.

It was said by Roman that the Release Team's decision would be a
disaster for m68k, because the architecture depends on forcing
developers to comply with patches, and said that the main problem is
that developers don't upload them. (Never mind that the porting team
can NMU them directly in such cases.)

But in fact, this is *NOT TRUE*. The problem is that there is a lot
of work, and it will be steadily more and more, and eventually it will
swamp anyone's ability to keep up with it.

m68k's buildd situation is a disaster and has been for a year. There
are ways of making it keep up in theory, but they have not been
implemented, and it would be a ludicrous mistake to force the entire
project to wait while it takes months to build even a package as
simple as ifhp.

Thomas

[Stephen R Marenka]

Post by Thomas Bushnell BSG
m68k's buildd situation is a disaster and has been for a year. There

Actually our toolchain has been a disaster since gcc-4.0. Roman has done
a fantastic job of correcting that.

Calling the autobuilder network a disaster is simply incorrect. The
buildds have periodically caught up, but we've had trouble with key
packages that ftbfs due to toolchain problems. Hopefully now that the
toolchain is fixed, the rest will sort itself out.

g-wrap hasn't been built because it is dep-waited on guile-1.6, which as
you've already pointed out, hasn't built in ages.

[Kurt Roeckx]

Post by Roman Zippel

Post by Steve Langasek
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.

As someone who has recently looked at and fixed many problems, I must say
the release team has done m68k no service by doing this and actually
sabotaged m68k in its ability to catch up again.
Fixes for problems are too often simply stuck in the BTS now, because in
many cases maintainer simply don't care about m68k support. I often have
to bug people to get them to release a fixed package.

I suggest you read section 5.10 of the developers reference, and do
porter/non-maintainer source uploads if you think it's holding up things
and the maintainer isn't very responsive.


Kurt

[Bill Allombert]

Post by Roman Zippel

Post by Steve Langasek
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.

As someone who has recently looked at and fixed many problems, I must say
the release team has done m68k no service by doing this and actually
sabotaged m68k in its ability to catch up again.
Fixes for problems are too often simply stuck in the BTS now, because in
many cases maintainer simply don't care about m68k support. I often have
to bug people to get them to release a fixed package.

I suggest you read section 5.10 of the developers reference, and do
porter/non-maintainer source uploads if you think it's holding up things
and the maintainer isn't very responsive.

Would the 0 day NMU policy apply to m68k specific bugs ? At least this
would allow porter/non-maintainer source uploads.

Cheers,

[Thiemo Seufer]

Post by Bill Allombert

Post by Roman Zippel

Post by Steve Langasek
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.

As someone who has recently looked at and fixed many problems, I must say
the release team has done m68k no service by doing this and actually
sabotaged m68k in its ability to catch up again.
Fixes for problems are too often simply stuck in the BTS now, because in
many cases maintainer simply don't care about m68k support. I often have
to bug people to get them to release a fixed package.

I suggest you read section 5.10 of the developers reference, and do
porter/non-maintainer source uploads if you think it's holding up things
and the maintainer isn't very responsive.

Would the 0 day NMU policy apply to m68k specific bugs ? At least this
would allow porter/non-maintainer source uploads.

FWIW, a 10 day NMU policy allows this too.


Thiemo

[Steve Langasek]

Post by Bill Allombert

Post by Roman Zippel

Post by Steve Langasek
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.

As someone who has recently looked at and fixed many problems, I must say
the release team has done m68k no service by doing this and actually
sabotaged m68k in its ability to catch up again.
Fixes for problems are too often simply stuck in the BTS now, because in
many cases maintainer simply don't care about m68k support. I often have
to bug people to get them to release a fixed package.

I suggest you read section 5.10 of the developers reference, and do
porter/non-maintainer source uploads if you think it's holding up things
and the maintainer isn't very responsive.

Would the 0 day NMU policy apply to m68k specific bugs ? At least this
would allow porter/non-maintainer source uploads.

The 0-day NMU policy promulgated by the release team has as its express
purpose to improve the release-readiness of testing, so m68k-specific fixes
wouldn't be covered by this. But porters are allowed to do NMUs on their
own authority, and I know that some porters have done 0-day NMUs when they
considered it necessary.

[Bill Allombert]

Post by Roman Zippel
Hi,

Post by Steve Langasek
buildds: 19
There are 19 buildds actively uploading packages for m68k (Aug 20 to
present). This indicates that individual buildds are roughly an order of
magnitude slower than those for other architectures, which makes m68k a
limiting factor for time-critical builds such as security updates.
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.

s/release team/release-minus-m68k team/ then.

Post by Roman Zippel
This will always be a killer argument against supporting slower ports. :-(

We could build packages on eight aranym instances running on amd64
octocores with 24Gb of RAM.

Cheers,

[Anthony Towns]

Post by Steve Langasek
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. 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.

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.

Cheers,
aj

[Ingo Juergensmann]

Post by Anthony Towns

Post by Steve Langasek
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.

Post by Anthony Towns
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?

Post by Anthony Towns
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: ***@sipgate.de

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

[Thomas Bushnell BSG]

Post by Ingo Juergensmann
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.

Why is the most recent g-wrap still not compiled for m68k?

I have been criticized for focusing on specific cases. The
generalities also point to an arch that simply cannot keep up. I
thought I'd add some specifics, which are that the m68k team is simply
not doing what is necessary. As the rest of the computing world
continues to advance, and the m68k does not, the porters will have to
do more, and more, and more.

Thomas

[Roman Zippel]

Hi,

Post by Thomas Bushnell BSG
Why is the most recent g-wrap still not compiled for m68k?

Because it's waiting for guile-1.6? How about instead of only complaining
you contact the maintainer and ask him to check out the patch and release
a fixed package?

bye, Roman

[Roman Zippel]

Hi,

Post by Ingo Juergensmann
- m68k can live without gcj-4.1 for some time, I think, so omit those from
the release

Actually gcj-4.1 is not an issue anymore (besides current build
dependencies), according to the test results it works for us now even
better than for arm or mips.
The toolchain looks to be in pretty good shape right now and with the
next gcc update every reported problem will be fixed, so while we had
toolchain issues until a few months back, it's not an issue anymore and
thus no reason anymore for not releasing m68k.

Part of the reason I looked through many packages is to find any remaining
compiler problems, but what I found are simply broken packages and with
m68k not a RC anymore, barely anyone looks seriously at these problems.
The problem here is without upstream support any port is in serious
trouble, so IMO it would better to simply drop unsupported packages, if
there are not that important for the port.

The major remaining problem is that m68k is slow and can not always keep
during _development_, but is this really an issue for a _release_? It's
fair to expect that m68k should not hold up the other ports, but is the
only possible answer to drop m68k completely?

bye, Roman

[Martin Michlmayr]

Post by Roman Zippel
The toolchain looks to be in pretty good shape right now and with
the next gcc update every reported problem will be fixed

This is slightly off-topic here, but I have not seen any of your m68k
GCC fixes been submitted and incorporated upstream. It would be great
if you could do that too.

[Roman Zippel]

Hi,

Post by Martin Michlmayr

Post by Roman Zippel
The toolchain looks to be in pretty good shape right now and with
the next gcc update every reported problem will be fixed

This is slightly off-topic here, but I have not seen any of your m68k
GCC fixes been submitted and incorporated upstream. It would be great
if you could do that too.

I know and it's on my todo list. :)
So far my attention has been concentrated on fixing the bugs, but now
that nothing is left, I'll try to get to it as soon as possible.

bye, Roman

[Filipus Klutiero]

Post by Ingo Juergensmann

Post by Anthony Towns

Post by Steve Langasek
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.

Assuming "We want to release with Etch" means "as an official Debian
arch", I don't think that's obvious at all. I don't remember any reply
to vorlon's mail which suggested that.

[Anthony Towns]

Post by Ingo Juergensmann
What are the porters wanted to say? "We want to release with Etch?"

No, releasing with etch is out of the question -- m68k doesn't meet the
release criteria.

The question is what to do _instead_.

Options are:

* drop m68k entirely
+ no work required
+ saves space
- arch is officially dead

* just have m68k in unstable, same as hurd-i386 has been
+ no work required
- installability etc not guaranteed
- pretty much makes m68k a "dead arch"

* have m68k be in unstable, and have it have its own "testing-like"
suite of some description
+ keeps the arch alive
- some work to keep m68k-testing in sync with real testing needed
- doesn't have real releases
- may not have security support

* have m68k be in unstable and have an "etch-like" release, same as
amd64 did
+ arch is alive, even if not releasable
- someone needs to do release management for it, which means
fixing at least the 700 uninstallable packages, etc
- someone needs to do security support for it on an ongoing basis

We'll be defaulting to "just have m68k in unstable" fairly soon unless someone
comes up with a plan to manage the testing-like or etch-like stuff on an ongoing
basis.

Note that since m68k is *not* meeting the release criteria, having the
release team or the security team do release management or security
updates is not an option. Someone from the m68k team will need to those
things themselves, and be committed to keeping transitions in sync on
m68k, doing security rebuilds and updates as necessary, and so forth.
That's no longer an option. You need to think outside that box.

Sorry, I know we're talking somewhat at cross-purposes here because
I've been staring at dak behaviour for years and y'all haven't. You
need to come up with a way of managing your own testing/stable release
yourselves, leveraging the work of the release managers/security team,
but not relying on them to assist you at all.

That might involve having a different package selection to what's in
official etch, eg; but if so, that will be a divergance that will create
more work for you, and you'll need to have a plan to deal with that.

Post by Ingo Juergensmann
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.

No release at all is better than a release that isn't supported on an
ongoing basis and drags down Debian's overall quality. No release at all
is better than a release that requires support work from the release or
security team, and thus detracts from our support of the official stable
and testing releases.

Post by Ingo Juergensmann
How about an IRC meeting about that issue on Saturday 6:00
p.m. UTC on #debian-68k?

(I won't be able to make any IRC meetings reliably 'til next week; you shouldn't
let that stop you from having one though)

Post by Ingo Juergensmann
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.

Having it be a "stable" release means handling security updates for 1.5
years or more, which can be a significant amount of work, since it has
to be in addition to the ongoing effort to maintain testing/unstable.

Post by Ingo Juergensmann
Anyway, when m68k would be allowed to rejoin Etch with point release, things
might be ok,

I wouldn't expect this to happen, anymore than amd64 joined sarge during
any point release.

Post by Ingo Juergensmann
If any plan to release m68k with Etch needs some additional mirror space,

Archive/mirror space isn't the concern. (Well, up to a point)

Cheers,
aj

[Roman Zippel]

Hi,

Post by Anthony Towns

Post by Ingo Juergensmann
What are the porters wanted to say? "We want to release with Etch?"

No, releasing with etch is out of the question -- m68k doesn't meet the
release criteria.

Well, this means the release criteria have been designed in a way that
m68k never could have met them anyway, m68k was practically fucked either
way from the very beginning. This whole process is a charade and was
pretty much designed to kick out slower ports. :-(

Post by Anthony Towns
The question is what to do _instead_.

The point is that m68k gets kicked out _before_ any alternative has been
implemented. _Any_ m68k work has been in vain from the very beginning and
the question is now only how some of it can be salvaged...

Post by Anthony Towns
That's no longer an option. You need to think outside that box.
Sorry, I know we're talking somewhat at cross-purposes here because
I've been staring at dak behaviour for years and y'all haven't. You
need to come up with a way of managing your own testing/stable release
yourselves, leveraging the work of the release managers/security team,
but not relying on them to assist you at all.

You are practically declaring that Debian is now a Desktop only
distribution which will only support GHz machines. Debian has become a
special purpose distribution and any of the slower ports is doomed in the
longer term, m68k is just the first victim. Theoretical "release criteria"
have become more important than its users. If Debian keeps up this
attitude then there this simply no room anymore for smaller ports.
Outside of the m68k team I have unfortunately not seen any serious effort
to actually accommodate the needs the smaller ports. Debian has been the
home for a wide range of users, but that's unfortunately not true any
longer and Debian should be honest enough to tell its users to go look for
a new home as they are no longer welcome.
Maybe you should stare at a few other things for a change? I'm not a
Debian developer, so I'm having a somewhat outside perspective and I'm sad
to see how Debian has been alienating some of its developers, it seems
that the developer egoism has become more important than its users and
some egoisms have outgrown anything else, so they don't leave much room
for any variety anymore.
Just to be clear, I don't want to pinpoint all the problems or put all the
blame on you, it's just general rant of the Debian situation from an
outside perspective and a comment like "That's no longer an option."
simply pisses me off.

Post by Anthony Towns

Post by Ingo Juergensmann
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.

Having it be a "stable" release means handling security updates for 1.5
years or more, which can be a significant amount of work, since it has
to be in addition to the ongoing effort to maintain testing/unstable.

No doubt of that, but how how does a theoretical set of "release criteria"
automatically ensure this work is done in the future? The only problem
right now is that m68k is slow and that can't be fixed magically,
unfortunately I don't see any serious effort to accommodate for these
needs.

bye, Roman

[Anthony Towns]

Post by Roman Zippel

Post by Anthony Towns
The question is what to do _instead_.

The point is that m68k gets kicked out _before_ any alternative has been
implemented.

m68k has not been kicked out -- it's still in etch at the moment. It's
not going to stay there though, and it's already been a month since
that's been decided with no alternative implemented yet. It'd be nice
if there was an alternative before it gets kicked out, but there's not
a lot of time left.

And if that's just going to get spent on complaining...

Cheers,
aj

[Roman Zippel]

Hi,

Post by Anthony Towns

Post by Roman Zippel

Post by Anthony Towns
The question is what to do _instead_.

The point is that m68k gets kicked out _before_ any alternative has been
implemented.

m68k has not been kicked out -- it's still in etch at the moment. It's
not going to stay there though, and it's already been a month since
that's been decided with no alternative implemented yet. It'd be nice
if there was an alternative before it gets kicked out, but there's not
a lot of time left.
And if that's just going to get spent on complaining...

Well, I did my share that m68k could be released just fine, I think I
earned the right to "complain". It's now in the hands of those who made
this decision.
It's rather disappointing to see how anonymously to those decisions
constantly are refered to. This kind of behaviour I expect from some
shareholder corporation, where profit is everything and where employees
get told "it" has been decided, that they are not met their quota and get
kicked out.
I was kind of hoping that Debian would be different, that mutual support
had still some value. Since m68k has lost its release status, I have not
seen many offers to help in regaining that status. Once bugs lose the RC
critical status they lose a lot of attention. What makes this worse that
now that m68k could very well be in a releasable state, there is still no
helping hand and instead there is only insisting on release criteria,
which were unrealistic in the first place.

bye, Roman

[Filipus Klutiero]

Roman Zippel a écrit :
[Skip]

Post by Roman Zippel

Post by Anthony Towns

Post by Ingo Juergensmann
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.

Having it be a "stable" release means handling security updates for 1.5
years or more, which can be a significant amount of work, since it has
to be in addition to the ongoing effort to maintain testing/unstable.

No doubt of that, but how how does a theoretical set of "release criteria"
automatically ensure this work is done in the future?

I wouldn't call the release criteria "theoretical" (they're even
starting to get applied), but they don't automatically ensure that the
security work is done. They should help to limit the work though.

[Ingo Juergensmann]

Post by Filipus Klutiero

Post by Roman Zippel
No doubt of that, but how how does a theoretical set of "release criteria"
automatically ensure this work is done in the future?

I wouldn't call the release criteria "theoretical" (they're even
starting to get applied), but they don't automatically ensure that the
security work is done. They should help to limit the work though.

Limit whose work?
--
Ciao... // Fon: 0381-2744150
Ingo \X/ SIP: ***@sipgate.de

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

[Frans Pop]

Post by Roman Zippel

Post by Anthony Towns
No, releasing with etch is out of the question -- m68k doesn't meet
the release criteria.

Well, this means the release criteria have been designed in a way that
m68k never could have met them anyway, m68k was practically fucked
either way from the very beginning. This whole process is a charade and
was pretty much designed to kick out slower ports. :-(

Post by Anthony Towns
The question is what to do _instead_.

The point is that m68k gets kicked out _before_ any alternative has
been implemented. _Any_ m68k work has been in vain from the very
beginning and the question is now only how some of it can be
salvaged...

Come on. This attitude is not going to lead anywhere.

I can understand you are disappointed, but please try to be constructive
and help create the best support for m68k possible given the decision
that was made and work to get m68k to be a fully supported arch again for
etch+1.
It is a fact that some arches, but especially m68k and m68k most
constantly and structurally, have caused loads of extra work for RMs, FTP
masters, security team, etc, for a large part because it is slow when
compared with others. This has delayed important migrations, security
updates, etc.

I think most people, including RMs, would be happy to welcome m68k back if
these issues could be addressed and have deep respect for the m68k
porters. In my experience m68k is one of the most active ports withing
Debian, but that does not change the facts.

Post by Roman Zippel
You are practically declaring that Debian is now a Desktop only
distribution which will only support GHz machines.

The fact that m68k is the only arch that was eventually not considered to
be release quality makes this untrue.

Please try to be more constructive as your current attitude is only going
to make people less inclined to work with you to create alternative
solutions.

Post by Roman Zippel
The only problem right now is that m68k is slow and that can't be fixed
magically,

Which was not the case when the decision needed to be made and was made.
IMO the RMs delayed it as long as possible to give m68k a chance.
Maybe, in retrospect, the should have made the decision earlier so there
would have been more time to work on an alternative solution?

Post by Roman Zippel
unfortunately I don't see any serious effort to accommodate for these
needs.

And I have not seen any serious work or proposals from m68k porters in
this direction either. ATM everybody is busy with the release. As always,
the initiative has to come from those most involved: the porters.

For what it's worth, the installer will keep supporting m68k. (Although it
would be good if we could have an updated daily build; the last one was
Oct 10.)

Cheers,
FJP

[Frans Pop]

Post by Frans Pop
And I have not seen any serious work or proposals from m68k porters
in this direction either.

Not?
Especially Roman has put great effort into fixing bugs and making the
toolchain stable again during the last weeks.

That is about getting back release status, which is a station that has
been passed. I was talking about work on an alternative solution: how
best to make the m68k port available to users *given that it is not a
release arch for Etch*.

[Ingo Juergensmann]

Post by Frans Pop

Post by Roman Zippel

Post by Anthony Towns
The question is what to do _instead_.

The point is that m68k gets kicked out _before_ any alternative has
been implemented. _Any_ m68k work has been in vain from the very
beginning and the question is now only how some of it can be
salvaged...

Come on. This attitude is not going to lead anywhere.

True, but the whole story is quite discouraging...

Post by Frans Pop
I can understand you are disappointed, but please try to be constructive
and help create the best support for m68k possible given the decision
that was made and work to get m68k to be a fully supported arch again for
etch+1.
It is a fact that some arches, but especially m68k and m68k most
constantly and structurally, have caused loads of extra work for RMs, FTP
masters, security team, etc, for a large part because it is slow when
compared with others. This has delayed important migrations, security
updates, etc.

Migrations are an issue, whereas I think security can delayed for m68k by a
few days, so that security fixes for other archs don't need to be delayed.
This happens already from time to time.

Post by Frans Pop

Post by Roman Zippel
You are practically declaring that Debian is now a Desktop only
distribution which will only support GHz machines.

The fact that m68k is the only arch that was eventually not considered to
be release quality makes this untrue.

Other DDs were already wondering why/how the arm port made it in... so, this
makes the drop of m68k just a case of bad luck with gcc-4.0 and toolchain.
Making gcc-4.0 the default compiler was really not a good choice for
m68k.

Post by Frans Pop

Post by Roman Zippel
The only problem right now is that m68k is slow and that can't be fixed
magically,

Which was not the case when the decision needed to be made and was made.
IMO the RMs delayed it as long as possible to give m68k a chance.
Maybe, in retrospect, the should have made the decision earlier so there
would have been more time to work on an alternative solution?

I think alternative solutions should have been provided by the Vancouver
proposal already.

Post by Frans Pop

Post by Roman Zippel
unfortunately I don't see any serious effort to accommodate for these
needs.

And I have not seen any serious work or proposals from m68k porters in
this direction either.

Not?
Especially Roman has put great effort into fixing bugs and making the
toolchain stable again during the last weeks.

Post by Frans Pop
ATM everybody is busy with the release. As always,
the initiative has to come from those most involved: the porters.
For what it's worth, the installer will keep supporting m68k. (Although it
would be good if we could have an updated daily build; the last one was
Oct 10.)

Hmmm, was it around that time when Stephen went on holiday? It seems he's
back, so that might change soon then... ;)
--
Ciao... // Fon: 0381-2744150
Ingo \X/ SIP: ***@sipgate.de

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

[Roman Zippel]

Hi,

Post by Frans Pop

Post by Roman Zippel
The point is that m68k gets kicked out _before_ any alternative has
been implemented. _Any_ m68k work has been in vain from the very
beginning and the question is now only how some of it can be
salvaged...

Come on. This attitude is not going to lead anywhere.
I can understand you are disappointed, but please try to be constructive
and help create the best support for m68k possible given the decision
that was made and work to get m68k to be a fully supported arch again for
etch+1.

If the decision has already been made, does my attitude really matter?
I'm only trying to be realistic and based on the current situation, m68k
is unlikely to ever get its release status back, so I'm seriously asking
myself why I should even bother.

Post by Frans Pop
It is a fact that some arches, but especially m68k and m68k most
constantly and structurally, have caused loads of extra work for RMs, FTP
masters, security team, etc, for a large part because it is slow when
compared with others. This has delayed important migrations, security
updates, etc.

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.

Post by Frans Pop

Post by Roman Zippel
You are practically declaring that Debian is now a Desktop only
distribution which will only support GHz machines.

The fact that m68k is the only arch that was eventually not considered to
be release quality makes this untrue.

Actuallly arm is considered as well (at least it was threatened in one of
the announcements) and strictly speaking arm doesn't meet the release
criteria either...

bye, Roman

[Riccardo]

Hello,

Post by Roman Zippel
Outside of the m68k team I have unfortunately not seen any serious effort
to actually accommodate the needs the smaller ports. Debian has been the
home for a wide range of users, but that's unfortunately not true any
longer and Debian should be honest enough to tell its users to go look for
a new home as they are no longer welcome.

the things you are saying here are very sad, but I true felt that in
the past year "Debian changed". And in a way I don't like.
In my personal opinon I think it has to do with Ubuntu and competition
with it and other platforms... debian used to be much more than a
"desktop" (also in the fact that it hwas always been a desktop only for
more experienced users, since others just choose ubuntu or similar
distirbutions, for reasons I do not want to discuss here, it is just a
fact), I have used it and seen it used in servers and also other
stranger applications. I hope we don't drop this.
Debian has always been also one of the linux distributions which
supported more architectures, I have used it a bit as "netbsd of
linux". Just think of the long-standing efforts in 68k, hurd or sparc.
We shouldn't loose our roots.
We are out of the kinky bells-n-whistles desktop arena anyway. People
there seek different features than debian provides.

Just my 2 cents of course,

-R

[Steve Langasek]

Post by Riccardo
Debian has always been also one of the linux distributions which
supported more architectures, I have used it a bit as "netbsd of
linux". Just think of the long-standing efforts in 68k, hurd or sparc.
We shouldn't loose our roots.

So given that you are concerned about the consequences that dropping m68k
from the release will have on our roots, when can we expect that you will be
doing your part to get m68k back into a releasable state by fixing the kaffe
build failure there?

http://buildd.debian.org/fetch.cgi?pkg=kaffe;ver=2%3A1.1.7-3;arch=m68k;stamp=1153832010

[Riccardo]

Hi,

Post by Steve Langasek
So given that you are concerned about the consequences that dropping m68k
from the release will have on our roots, when can we expect that you will be
doing your part to get m68k back into a releasable state by fixing the kaffe
build failure there?
http://buildd.debian.org/fetch.cgi?pkg=kaffe;ver=2%3A1.1.7-
3;arch=m68k;stamp=1153832010

well, yes, testing kaffe on linux/68k again is one of my goals for
updating my 68k macs. I will test if current CVS head works, if not if
it can be fixed and if a patch for 1.1.7 can be generated.
Unfortunately when 1.1.7 was released, I was already not able to test
linux/68k, but IIRC correctly, netbsd/68k worked, so I suspect more a
build problem.
I notice from your buildlog that the classpath build is done using ecj.
I personally use jikes on any platform I test. Furthermore, on slow
architectures, I use a prebuild classpath jar, but I don't know if that
can be easily done in a package build system. Jikes requires for a
current classpath > 256MB of ram and plenty of swap space and it can
consume a big part of the build time, thus slowing down the testing
cycle considerably.
Gcj could be attemtped too and afaik it has means in the classpath
build to split up the compiation and thus require less resources, I
have never tried it either but now that gcc 4.1 is working on 68k, I
suppose gcj is usable too?

Cheers,
Riccardo

[Stephen R Marenka]

Post by Riccardo
Gcj could be attemtped too and afaik it has means in the classpath
build to split up the compiation and thus require less resources, I

Which would be great.

Post by Riccardo
have never tried it either but now that gcc 4.1 is working on 68k, I
suppose gcj is usable too?

Yes, we now have excellent gcj-4.1 support.

[Roman Zippel]

Hi,

Post by Steve Langasek

Post by Riccardo
Debian has always been also one of the linux distributions which
supported more architectures, I have used it a bit as "netbsd of
linux". Just think of the long-standing efforts in 68k, hurd or sparc.
We shouldn't loose our roots.

So given that you are concerned about the consequences that dropping m68k
from the release will have on our roots, when can we expect that you will be
doing your part to get m68k back into a releasable state by fixing the kaffe
build failure there?
http://buildd.debian.org/fetch.cgi?pkg=kaffe;ver=2%3A1.1.7-3;arch=m68k;stamp=1153832010

This build attempt is from before gcj was fixed and once the buildd gets
to it, it will build fine.
What's the point of this? arm fails to build this currently, do they get
kicked out now because of this?

bye, Roman

[Loïc Minier]

Post by Anthony Towns
* have m68k be in unstable, and have it have its own "testing-like"
suite of some description
+ keeps the arch alive
- some work to keep m68k-testing in sync with real testing needed
- doesn't have real releases
- may not have security support

Is it possible to run britney multiple times, the first time for all
releasable arches, and the following runs for each other arch, but
commit changes to etch/$arch?

For example, this would permit releasing an etch/m68k without a
separate archive.

Perhaps the maintenance of the testing propagation of m68k alone should
then be made by m68k porters instead of the *release* team.

[Ingo Juergensmann]

Post by Loïc Minier

Post by Anthony Towns
* have m68k be in unstable, and have it have its own "testing-like"
suite of some description
+ keeps the arch alive
- some work to keep m68k-testing in sync with real testing needed
- doesn't have real releases
- may not have security support

Is it possible to run britney multiple times, the first time for all
releasable arches, and the following runs for each other arch, but
commit changes to etch/$arch?
For example, this would permit releasing an etch/m68k without a
separate archive.
Perhaps the maintenance of the testing propagation of m68k alone should
then be made by m68k porters instead of the *release* team.

Finally a good proposal... thx! :)
--
Ciao... // Fon: 0381-2744150
Ingo \X/ SIP: ***@sipgate.de

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

[Raphael Hertzog]

Post by Ingo Juergensmann

Post by Loïc Minier

Post by Anthony Towns
* have m68k be in unstable, and have it have its own "testing-like"
suite of some description
+ keeps the arch alive
- some work to keep m68k-testing in sync with real testing needed
- doesn't have real releases
- may not have security support

Is it possible to run britney multiple times, the first time for all
releasable arches, and the following runs for each other arch, but
commit changes to etch/$arch?
For example, this would permit releasing an etch/m68k without a
separate archive.
Perhaps the maintenance of the testing propagation of m68k alone should
then be made by m68k porters instead of the *release* team.

Finally a good proposal... thx! :)

I believe there are some problems because we don't want to have too many
versions of the same source package, that's why this is not generalized
and why we try to keep all arches in sync.

But in essence, this proposal is the same as Anthony's with its separate
"m68k-testing" suite ! I don't understand how you can be happy this time
and be unhappy before... ;-)

Cheers,
--
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/

[Ingo Juergensmann]

Post by Raphael Hertzog

Post by Ingo Juergensmann

Post by Loïc Minier

Post by Anthony Towns
* have m68k be in unstable, and have it have its own "testing-like"
suite of some description
+ keeps the arch alive
- some work to keep m68k-testing in sync with real testing needed
- doesn't have real releases
- may not have security support

Is it possible to run britney multiple times, the first time for all
releasable arches, and the following runs for each other arch, but
commit changes to etch/$arch?
For example, this would permit releasing an etch/m68k without a
separate archive.
Perhaps the maintenance of the testing propagation of m68k alone should
then be made by m68k porters instead of the *release* team.

Finally a good proposal... thx! :)

I believe there are some problems because we don't want to have too many
versions of the same source package, that's why this is not generalized
and why we try to keep all arches in sync.
But in essence, this proposal is the same as Anthony's with its separate
"m68k-testing" suite ! I don't understand how you can be happy this time
and be unhappy before... ;-)

Because of the wording and the more elaborated details. It's more something
we can work on, although it's still not my preferred solution.
--
Ciao... // Fon: 0381-2744150
Ingo \X/ SIP: ***@sipgate.de

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

[Loïc Minier]

Post by Raphael Hertzog
I believe there are some problems because we don't want to have too many
versions of the same source package, that's why this is not generalized
and why we try to keep all arches in sync.

It would be nice to know whether these problems are show stoppers or
whether the option would make sense, perhaps with some efforts.

Post by Raphael Hertzog
But in essence, this proposal is the same as Anthony's with its separate
"m68k-testing" suite ! I don't understand how you can be happy this time
and be unhappy before... ;-)

Yes, I realized it was relatively close to aj's proposal, but aj's
proposal seemed to be slightly inconvenient. It sounded like there
would some rupture, some big move from the current etch archive to a
new m68k-testing archive.
In other words, it would be nice if the switch could be transparent
to m68k users so that they do not have to change setups or tweak an
unstable snapshot.

I think it would be interesting if someone could confirm that it would
be technically feasible to split the etch/testing setup (britney I
suppose) and to delegate handling of anything relevant to m68k to m68k
folks.
This would have the advantage of putting the quality of the resulting
archive in the hands of the porters, and I hope it would also abstract
this difference technically from all archive wide tools / users /
operations.

[Frans Pop]

(dropping all individual CCs; please don't CC me)

Post by Loïc Minier
In other words, it would be nice if the switch could be transparent
to m68k users so that they do not have to change setups or tweak an
unstable snapshot.

Note that a separate archive means a change will be needed in D-I's
choose-mirror so that the default for m68k is set to that mirror.

[Ingo Juergensmann]

Post by Anthony Towns

Post by Ingo Juergensmann
What are the porters wanted to say? "We want to release with Etch?"

No, releasing with etch is out of the question -- m68k doesn't meet the
release criteria.

Oh well...
It doesn't meet the release criteria because of the toolchain problems, that
have now been solved. With a little time and adding some still failing
packages to N-F-U, I'm quite confident to fulfill the release criteria.

Post by Anthony Towns
The question is what to do _instead_.
* have m68k be in unstable, and have it have its own "testing-like"
suite of some description

Who's managing that suite then?

Post by Anthony Towns
+ keeps the arch alive
- some work to keep m68k-testing in sync with real testing needed

Who's doing that work then?

Post by Anthony Towns
- doesn't have real releases
- may not have security support

I don't think security is a real issue. See below.

Post by Anthony Towns
* have m68k be in unstable and have an "etch-like" release, same as
amd64 did
+ arch is alive, even if not releasable
- someone needs to do release management for it, which means
fixing at least the 700 uninstallable packages, etc

With the fixed toolchain issue the number of uninstallable packages will
significantly drop in the next time, I'm sure.

Post by Anthony Towns
- someone needs to do security support for it on an ongoing basis
We'll be defaulting to "just have m68k in unstable" fairly soon unless someone
comes up with a plan to manage the testing-like or etch-like stuff on an ongoing
basis.

Well, we have offers for ftp-master roles out of Debian. Still, I think it
is better for everyone to have a (maybe) reduced set of packages being
released with etch.

Post by Anthony Towns
Note that since m68k is *not* meeting the release criteria, having the
release team or the security team do release management or security
updates is not an option. Someone from the m68k team will need to those
things themselves, and be committed to keeping transitions in sync on
m68k, doing security rebuilds and updates as necessary, and so forth.

How likely is it, in your opinion, that someone from the porters team can do
that, besides of dealing with porter tasks, buildd admin stuff and
implementing coldfire support to the m68k port?
If you want to kill the m68k port, please say it straight out!

Post by Anthony Towns
That's no longer an option. You need to think outside that box.

You still keep refusing to give arguments why it's no longer an option. For
me it *is* still an option when we bring down our backlog and add some
packages to N-F-U. Even some RMs would considering this option if the count
of uninstallable packages drops <100 packages. So, why isn't this an option
for you? Who is "you" anyway now? Ftp-master or DPL? I'm just curious...

Post by Anthony Towns
Sorry, I know we're talking somewhat at cross-purposes here because
I've been staring at dak behaviour for years and y'all haven't. You
need to come up with a way of managing your own testing/stable release
yourselves, leveraging the work of the release managers/security team,
but not relying on them to assist you at all.
That might involve having a different package selection to what's in
official etch, eg; but if so, that will be a divergance that will create
more work for you, and you'll need to have a plan to deal with that.

I believe adding problematic packages to N-F-U is actually a nice plan. So
far you haven't brought up arguments why this can't be done - except "m68k
is not matching the release criteria" - whereas I try to find a way how it
can match them again.

Post by Anthony Towns

Post by Ingo Juergensmann
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.

No release at all is better than a release that isn't supported on an
ongoing basis and drags down Debian's overall quality. No release at all
is better than a release that requires support work from the release or
security team, and thus detracts from our support of the official stable
and testing releases.

Uh?
You proposed a amd64 release above and now you're saying that no release is
better for our userbase? Strange argueing...

Post by Anthony Towns

Post by Ingo Juergensmann
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.

Having it be a "stable" release means handling security updates for 1.5
years or more, which can be a significant amount of work, since it has
to be in addition to the ongoing effort to maintain testing/unstable.

Again... I don't think that security updates are an issue, as Joey stated
repeatedly in the past that this doesn't matter much, if the security teams
builds on m68k or not.
I've even offered the security team the former buildd akire, which the
wanna-build admins failed to add its ssh key to the w-b access again after a
dead disk for *over* a year now, which is partly a reason for our current
backlog. So, if you want to help the m68k port instead of stating "it
doesn't meet the release criteria", a way to do so would be to ask for its
ssh key inclusion with your DPL hat on.
Otherwise the offer to the security team of using akire as a security buildd
still stands. I can't do much if the security team don't want it, but then
again I interpret that as a matter of fact that the security team has enough
m68k buildd power already.

Post by Anthony Towns

Post by Ingo Juergensmann
Anyway, when m68k would be allowed to rejoin Etch with point release, things
might be ok,

I wouldn't expect this to happen, anymore than amd64 joined sarge during
any point release.

Post by Ingo Juergensmann
If any plan to release m68k with Etch needs some additional mirror space,

Archive/mirror space isn't the concern. (Well, up to a point)

At least mirror space was an issue for amd64...
--
Ciao... // Fon: 0381-2744150
Ingo \X/ SIP: ***@sipgate.de

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

[Anthony Towns]

Post by Ingo Juergensmann
Oh well...
It doesn't meet the release criteria because of the toolchain problems, that
have now been solved.

No, it hasn't. You need to be reliably abouve 95% for the entirety of:

http://buildd.debian.org/stats/graph2-quarter-big.png

before you can reasonably be considered for release.

Even if you fixed _every single problem affecting m68k_ you won't be
able to do that for etch at this point. That's out of the question. For
etch+1, it might be a different story of course.

Post by Ingo Juergensmann

Post by Anthony Towns
The question is what to do _instead_.
* have m68k be in unstable, and have it have its own "testing-like"
suite of some description

Who's managing that suite then?

The suite itself? ftpmaster would make it, and a britney script would
be cronned to handle it. That shouldn't require any particular attention
though.

Post by Ingo Juergensmann

Post by Anthony Towns
+ keeps the arch alive
- some work to keep m68k-testing in sync with real testing needed

Who's doing that work then?

Hinting a new britney instance appropriately does require some time
though, and since m68k doesn't meet the release criteria, the release
team won't do that. If there's no one interested in doing it specifically
for m68k (and able to), no one will.

Post by Ingo Juergensmann

Post by Anthony Towns
We'll be defaulting to "just have m68k in unstable" fairly soon unless someone
comes up with a plan to manage the testing-like or etch-like stuff on an ongoing
basis.

Well, we have offers for ftp-master roles out of Debian. Still, I think it
is better for everyone to have a (maybe) reduced set of packages being
released with etch.

It's not the ftpmaster stuff that needs to be done, it's the RM and
security stuff. Security stuff for *sarge* is already a problem, with
the xfree86 update currently blocking the release of r4, due to lack of
an m68k build, eg.

Post by Ingo Juergensmann

Post by Anthony Towns
Note that since m68k is *not* meeting the release criteria, having the
release team or the security team do release management or security
updates is not an option. Someone from the m68k team will need to those
things themselves, and be committed to keeping transitions in sync on
m68k, doing security rebuilds and updates as necessary, and so forth.

How likely is it, in your opinion, that someone from the porters team can do
that, besides of dealing with porter tasks, buildd admin stuff and
implementing coldfire support to the m68k port?

I have no idea. In essence that's what I'm asking.

Post by Ingo Juergensmann
If you want to kill the m68k port, please say it straight out!

Personally, I'm not fussed either way. If someone wants to support m68k, I'm
all for it staying. If no one does, I'm all for it going.

Post by Ingo Juergensmann
I believe adding problematic packages to N-F-U is actually a nice plan.

It would probably be worth having a separate list of "unsupportable"
packages, and having them be REJECTed if uploaded -- that way it doesn't
cause problems if someone builds them by hand and tries uploading, eg.

But these things need to be more than just "I believe ... could work";
they need to be "I'm think ... will work because ... and I'm willing to
do ... to make it work."

Post by Ingo Juergensmann

Post by Anthony Towns

Post by Ingo Juergensmann
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.

No release at all is better than a release that isn't supported on an
ongoing basis and drags down Debian's overall quality. No release at all
is better than a release that requires support work from the release or
security team, and thus detracts from our support of the official stable
and testing releases.

Uh?
You proposed a amd64 release above and now you're saying that no release is
better for our userbase? Strange argueing...

The amd64-sarge release was supported on an ongoing basis, didn't drag
down Debian's overall quality, didn't require support from the release
team, and only had security support after the security team reviewed
it and decided it wouldn't detract from our support of official stable
releases.

Post by Ingo Juergensmann

Post by Anthony Towns

Post by Ingo Juergensmann
If any plan to release m68k with Etch needs some additional mirror space,

Archive/mirror space isn't the concern. (Well, up to a point)

At least mirror space was an issue for amd64...

Since then we've managed to get arch criteria and the mirror split, however.

Cheers,
aj

[Michael Schmitz]

Post by Anthony Towns

Post by Ingo Juergensmann
Well, we have offers for ftp-master roles out of Debian. Still, I think it
is better for everyone to have a (maybe) reduced set of packages being
released with etch.

It's not the ftpmaster stuff that needs to be done, it's the RM and
security stuff. Security stuff for *sarge* is already a problem, with
the xfree86 update currently blocking the release of r4, due to lack of
an m68k build, eg.

Well, xfree has been built some days ago but no attempt has been made to
get it uploaded yet.

This has been complicated by the fact that I've asked for access to
the security archive for hobbes but no response of any kind has been
forthcoming.

If you seriously think m68k is the main problem for the etch release
quality, I wish you all the luck you need indeed.

Regarding a solution for m68k beyond etch - I'd prefer to keep m68k
snapshots on a basis like you mentioned:

* have m68k be in unstable, and have it have its own "testing-like"
suite of some description
+ keeps the arch alive
- some work to keep m68k-testing in sync with real testing needed
- doesn't have real releases
- may not have security support

Snapshots off that testing-like thing should then be kept somewhere off
.debian.org machines to avoid confusion with a real release, I guess.

Since I don't have a clue how the release management and archive scripts
work, I'd need to get help from those in the know to set it up. At the
current stage, with toolchain issues largely sorted, I'd expect the
backlog to clear up as soon as a few buildds have been restarted or DNS
problems fixed (cts going on vacation usually means his buildds crash the
next few days, no idea why that is).

The main reason not to shoot for the larger goal is security support. I
positively hate it to spend days on a security build (manually queued
because someone cannot be bothered to add yet another m68k security
account) and then see it headed for the drain. I'd rather cut that right
out.

So, if someone could give me a brief intro as to how testing migration of
packages works, and what would be needed to modify britney, I'd welcome
it.

Michael

[Bill Allombert]

Post by Anthony Towns

Post by Steve Langasek
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. 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.

What is the point of removing Etch from testing given it is ignored for
testing propagation anyway ? There is plenty of time for debian-m68k to
catch up during the freeze.

Cheers,

[Wouter Verhelst]

Post by Anthony Towns

Post by Steve Langasek
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.

I *have* asked about the possibility to maintain our own
slightly-different m68k distribution (similar to how amd64 works for
sarge) on debian.org servers, but have not heard anything about that.

Currently, our priority is to get the 300-packages backlog done, though.
At least that's mine.

[Andreas Barth]

Post by Wouter Verhelst

Post by Anthony Towns

Post by Steve Langasek
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.

I *have* asked about the possibility to maintain our own
slightly-different m68k distribution (similar to how amd64 works for
sarge) on debian.org servers, but have not heard anything about that.

If it turns out to not be possible on debian.org-servers, it is
definitly possible on debian.net-machines :)

Be welcome to be our guest.


Cheers,
Andi

[Anthony Towns]

Post by Wouter Verhelst

Post by Anthony Towns
I've seen, no concrete suggestions on what the m68k porters want to do
about this.

I *have* asked about the possibility to maintain our own
slightly-different m68k distribution (similar to how amd64 works for
sarge) on debian.org servers, but have not heard anything about that.

Right, I haven't seen that request.

I don't think there's any need to have that separate from ftp-master.d.o
at this point, but see my other mail for other concerns.

Cheers,
aj

[Michael Schmitz]

Post by Wouter Verhelst
I *have* asked about the possibility to maintain our own
slightly-different m68k distribution (similar to how amd64 works for
sarge) on debian.org servers, but have not heard anything about that.

I recall hearing a response much along the lines 'we could do that, but
that would require changes to the archive maitainance scripts and we don't
feel like expending that effort'.

Post by Wouter Verhelst
Currently, our priority is to get the 300-packages backlog done, though.
At least that's mine.

Seconded.

Michael