TL;DR: I think that we should have a discussion about the respective
roles & responsibilities of maintainers and porters with regard to
porting.
Release team, there's a question for you regarding ruby1.9.1 in the last
paragraph.
------------
Hi,
First, I'd like to say that I'm very proud of the fact that Debian
supports so many architectures, and even non-linux ports like kfreebsd.
And that Debian infrastructure is used to support unofficial
architectures such as Debian GNU/Hurd.
However, I'm the maintainer of Ruby. It's kind of special, because:
(1) it uses threads intensively (Ruby threads are mapped to pthreads,
and are routinely used in Ruby programs)
(2) it has a rather huge test suite, that is run at build time
As a result, building ruby1.9.1 tends to detect bugs in the toolchain,
the libc or the kernel, especially on architectures such as hppa or
kfreebsd-* which are a bit "different". I spent my week-end
investigating ruby1.9.1 issues on kfreebsd, sparc, and ia64.
My problem is that I have the impression that some ports are a bit on
the 'experimental' side. For some ports, we use compiler defaults that
are not supported by upstream (sparc), or are the sole users+maintainers
of key packages (it was the case with hppa, which was not using NPTL
when all others architectures were using it, and it is the case for the
libc with Debian GNU/kFreeBSD).
While it's nice that Debian supports such experiments, and while it
generally helps making Debian better by detecting and fixing bugs that
could eventually affect key architectures, I think that we have a
problem when it gets in the way of progress on the architectures that
95%+ of our uses use.
I have the impression that in many cases, maintainers are totally fine
with ports as long as they don't interfere with their work. The
toolchain on ports is generally able to generate code, and when it fails
to do so (ICEs!), toolchain maintainers are usually quick to react.
However, for most of the packages, there's no proof that the generated
code (and the generated packages) actually work.
However, issues such as miscompilation or broken syscall or libc
semantics are largely undetected. To illustrate this, you can have a
look at #635126 (miscompilation on armel and sparc) and #639658
(forks+threads fun on kFreeBSD, derived from #593139).
With the push for more testing (think autopkgtest), it's likely that we
will run into more bugs. Once an architecture is accepted as an official
architecture in Debian, 'experimental' architectures start blocking
packages migration to testing, and it becomes a problem for the
maintainer. I sometimes have the impression that I'm 'taken as hostage'
by porting issues, because it seems that if I don't fix porting issues
myself, nobody will do, and my package won't migrate to testing.
I think that we should clarify roles and responsibilities. I
know that manpower is scarse for some ports, but if it's up to
maintainers to do the porting work on their own, maybe we should instead
find a way that allows Debian to support those ports, without putting
them in a position to block or slow down other development tasks.
I'd like to reinforce the fact that it's the porters' responsibility
to investigate porters issues, and propose the following
responsibilities:
(1) It is the responsibility of porters to:
- track architecture-specific bugs (build failures, toolchain
issues, etc)
- investigate and solve such bugs
(2) It is the responsibility of maintainers to help porters as much
as possible
(3) When porters are failing to do (1), we should investigate ways to
continue to support these ports without releasing them as stable
architectures.
Question for the release team:
We might chose to make ruby1.9.1 the default ruby implementation for
wheezy (instead of ruby1.8). I still hope that all porting issues
affecting ruby1.9.1 will be resolved.
But if it's down to those four choices, what should I do in a couple of
weeks, when the new upstream release will be available?
(1) not upload the next ruby release to unstable until porting issues
are fixed
(2) disable the test suite on architectures where it fails, so that the
package can build and migrate to testing (but it will be completely
broken, which might annoy DSA, e.g because of puppet)
(3) request removal of ruby binaries on architectures where it fails to
build
(4) orphan ruby1.9.1 ;)
Thanks,
- Lucas
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110829065834.gb27...@xanadu.blop.info
