-----BEGIN PGP SIGNED MESSAGE----- Hi.
[ I've Bcc:ed debian-devel. Please answer only to debian-policy. Thanks ]. The "new upload procedure", approved some time ago, is already in the bug list for ftp.debian.org (#17525), so I hope it will be implemented some day and this procedure will allow us not to have to send announcements to debian-devel-changes by hand anymore. In the meantime, I think we should start thinking about the splitting of debian-devel-changes, creating lists for every architecture (we have already seven). We could even do this now, without having to wait for the upload procedure to be implemented. Several ways were proposed to split the lists, and I don't remember them exactly. I would like to propose the most simple one I can think: [ This is only a suggestion. I will be happy with *whatever* reasonable way to split the list ]. debian-devel-changes: aliased to debian-devel-changes-i386 (or viceversa, does not matter). debian-devel-changes-m68k: Binary-only uploads for the m68k arch, as well as source and binary uploads for the m68k if the source is arch-specific. debian-devel-changes-sparc: Binary-only uploads for the sparc arch, as well as source and binary uploads for the sparc if the source is arch-specific. etc. and finally: debian-devel-changes-i386: Whatever is left. This includes: * Binary-only uploads for the i386 arch, when the source maintainer does not usually work with the i386 architecture. * "Source and i386" uploads. * "Source and all" uploads. ( And "source-only" uploads, if any). I am aware that this approach is somewhat i386-centric, but since i386 is still the main architecture for most developers (and users), I would not consider it a great problem. The slightly i386-centric approach has some benefits: This would allow i386 users not to receive any annoucements about foo-only packages, where "foo" is any other arch different than i386. So, most users will only need to subscribe to *one* list, as now. Also, people working on the port for the "foo" arch would not have to subscribe to more than *one* list either (i.e. the current debian-devel-changes) to know which source packages have to be recompiled. For this reason I think this is the most simple solution for the problem of the split, but whatever way we decide which is also reasonable will also serve. So: Could we split the debian-devel-changes list some of these days? Thanks. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 iQCVAgUBNcyLJSqK7IlOjMLFAQErTwQAtCNPV700sQjpAJ0mjMK1dGE1Bpk1Pgzm ic/a4/2ZJD8QR7Ei75VHC0CvD9kRhJiK1aB2e3MfBlEzD7NGTHXNBygHYQYq2Uq5 zwUYPfNOMfa7/9tAAOeTEiTFyDligWTQX6GalggO3Zc1aLfQeKNvQDo9M36VP119 d2lxv4/HVZA= =r44V -----END PGP SIGNATURE-----
