Maybe it's time to split debian-devel-changes
-----BEGIN PGP SIGNED MESSAGE-----
[ 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
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
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
So: Could we split the debian-devel-changes list some of these days?
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----