This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Kill libc-ports?
- From: Siddhesh Poyarekar <siddhesh at redhat dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 10 Sep 2013 21:40:45 +0530
- 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>
On Tue, Sep 10, 2013 at 11:26:51AM -0400, Carlos O'Donell wrote:
> It is my opinion that rationale about list volume are not
> relevant to this discussion. As the glibc community we should
> listen to our maintainer requests and attempt to build a
> community that meets their needs and workflows.
List volume is relevant since that is cited as a possible problem that
is being solved. It is easy to gain attention of arch maintainers by
using subject tags. If maintainers wish to see those emails in a
separate mail directory then they can use email filters.
> What do we gain from merging libc-ports that we loose by
> making Joseph or Chris need to filter through more email?
It gets rid of the artificial divide between ports and mainline.
> I argue that the prime directive is violated. Chris and
> Joseph as core maintainers have expressed a desire to
> simplify the workflow and reduce their wasted time. I
> can't disagree with them. I would also like such a list
> for hppa work :-)
Fair enough. I'm not going to pursue this since it does not affect my
workflow much - most of the architectures I have to care about are
responsive on mainline.
Siddhesh