This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Kill libc-ports?
- From: Roland McGrath <roland at hack dot frob dot com>
- To: Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: "Carlos O'Donell" <carlos at redhat dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 23 Sep 2013 15:41:20 -0700 (PDT)
- Subject: Re: Kill libc-ports?
- Authentication-results: sourceware.org; auth=none
- References: <20130905121121 dot GN4306 at spoyarek dot pnq dot redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1309051534260 dot 28271 at digraph dot polyomino dot org dot uk> <20130906052150 dot GS4306 at spoyarek dot pnq dot redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1309061227310 dot 3054 at digraph dot polyomino dot org dot uk> <CAAHN_R0uRerwkXEay9Ogr_J+xOeV+cOxrjyeCfjGM24uJP34eg at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1309061919120 dot 11925 at digraph dot polyomino dot org dot uk> <20130910121107 dot GF4306 at spoyarek dot pnq dot redhat dot com> <522F3A3B dot 3000605 at redhat dot com> <20130910161045 dot GG4306 at spoyarek dot pnq dot redhat dot com>
I don't think having two mailing lists is useful. It just complicates life.
My preference (as I've said in the past) would be that libc-alpha be
renamed to something less random, such as libc-devel. But I can't argue
with the concerns about gratuitous legwork on sourceware, bifurcating the
list archives, etc. So let's worry about possible renaming separately and
later, not now.
libc-ports per se is no longer useful and should go away.
I sympathize with the need of machine maintainers to have an easier way
than filtering libc-alpha to keep track of their pending work. Repurposing
the historical libc-ports list is not the way to do that. Possibly a new
mailing list could make sense, but I doubt it. My suggestion is a new
protocol using a wiki page that machine maintainers are expected to put a
wiki watch on. That would also be the way to keep track of the doneness
state of a given issue for each machine. People who are quite active doing
something to keep track of machine maintainers' timeliness in updating that
wiki page could be a good way to assess the ongoing level of responsiveness
of each machine maintainer.
Thanks,
Roland