Hi, 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 maintainer). > > 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. > > Yes. 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). Comments? Frank
