Re: Kill libc-ports?

[Siddhesh Poyarekar <siddhesh at redhat dot com>]

On Fri, Sep 06, 2013 at 07:32:35PM +0000, Joseph S. Myers wrote:
> > A maximum of a couple of dozen emails a day doesn't count as high
> > volume IMO.  Heck, there are days when the mailing list is deserted.
> 
> It's been twice that rate this week.

The average for the entire year has been about 27 emails per day.
Twice that rate is still not high volume.  I got 292 emails in just 3
days from gcc-patches.  *That* is high volume.

> > I definitely did not mean to try and push a proposal behind anyone's
> > backs.  I assumed that all arch maintainers read libc-alpha - it's
> > unfortunate if someone doesn't because it implies that they do not
> > accept any accountability for the generic bits in glibc.
> 
> Architecture maintainers are meant to be responsible for their 
> architectures, only for generic pieces to the extent that problems with 
> them show up on their architectures.

That still doesn't mean that they should not be following generic
bits.  I don't think any arch maintainer has come up yet claiming that
they are not signed up to libc-alpha and only care about stuff that
comes up on libc-ports.  Posting on libc-alpha with a proposal to kill
libc-ports is not 'posting behind their backs'.

> I don't think that reflects the reality of most architecture maintainers.  
> I would expect them to have plenty of responsibilities (relating in one 
> way or another to their architecture) besides glibc, and glibc 
> responsibilities largely for trees other than the upstream one, with 
> reading upstream mailing lists at all a long way down their priorities.  
> I know plenty of toolchain developers who don't routinely read the 
> relevant upstream mailing lists and to the extent they do often have 
> backlogs of weeks or months, or who would skim threads at high speed and 
> very likely miss anything not unambiguously marked in the subject of the 
> first message in a thread so it's obvious it's relevant to them.  (That's 
> basically what I do with linux-kernel - junk threads at high speed, often 
> with a latency of weeks.  If it isn't obvious from the subject of the 
> first message in a thread that's it's relevant to the kernel-userspace 
> interface and glibc, I'll probably miss that the discussion occurs at all; 
> even if it is obvious, I may well miss it unless it was CC:ed to linux-api 

LKML is not a valid comparison.  The traffic there is multiple times
more than libc-alpha can ever hope to achieve even with everyone
sending each other holiday greetings on list.

> which exists for that purpose.)  And I'd also like to see architecture 
> updates generally go in promptly - which means the limited number of 
> people doing significant amounts of architecture-independent work (we 
> still have bugs being filed a lot faster than they are fixed) should be 
> trying to make things easier for architecture maintainers and casual 
> contributors.

The real bottleneck for casual contributors is arcane ChangeLog
nonsense and FSF copyright assignment, one of which is slightly
useful.  I still don't see how putting architecture maintainers in a
silo makes it easier for them to make prompt architecture updates
where required.

Siddhesh