Re: binary-alpha and binary-sparc directories
Ian Jackson wrote:
> As Matt Bailey suggests, I think separate Incoming directories is a
> better solution.
I'm from the m68k section, and although it's kind of you to set up the
directories for our uploads, I believe the main development of Debian/m68k
is going to be done with the german ftp server at Mainz. I can't speak for
the other sites here in Europe, but at least from Oldenburg (where I am)
ftp.debian.org is almost unreachable (have been up to 30 hops).
Also, most active developers seem to come from Europe, so they will probably
agree with me. Of course this does not mean the entire tree won't get
mirrored to ftp.debian.org once we have something usable. But for now I guess
ftp.uni-mainz.de is the better choice for us (especially when seeing this
message at ftp.debian.org all the time:
530-You are currently user 150 out of a possible 150 in your class.
530 User ftp access denied.
(which, btw, is funny - the count is off by one :-)
> > It seems to me that packages will need a primary maintainer, who
> > would be responsible for the source package, and an architecture
> > specific maintainer for each supported binary package. One person
> > could act in all capacities, of course, but I'd expect that at least
> > some packages would have different maintainers for the different
> > architectures.
Ok, so what should we do? I made a few attempts at just unpacking some
packages from base/ and blindly doing make -f debian.rules binaryon my
Amiga, and only very few packages ran out of the box.
I hope the changes will only be minor in most cases, and so it would be
best for us (m68k) if we could just contact the current "x86" maintainer
of a package if it needs changes. That would mean digging out his name/E-Mail
out of the Packages file, right? Are there any serious reasons why this
cannot be done? (except, of course, for more work for the primary
> > The way I see this working, architecture-specific maintainers with
> > the ability to address architecture-specific bug reports and do
> > architecture-specific testing would feed architecture-specific
> > fixes and patches to the primary package maintainer. Primary
> > package maintainers having, say, a sparc would install alpha
> > or i386 patches blindly, relying on the testing done by the
> > alpha and i386 maintainers, and issue a package revision update.
Sounds ok to me. Architecture-specific bugs for m68k will be discussed
in our own debian-m68k mailing list, and if a package maintainer discovers
a real problem that is architecture-independent, he would have to cooperate
with the primary maintainer (where I'd like to see the corresponding person
from the x86 staff to take this over).