Re: Kill libc-ports?

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Fri, 6 Sep 2013, Siddhesh Poyarekar wrote:

> On 6 September 2013 18:08, Joseph S. Myers <joseph@codesourcery.com> wrote:
> > I suggest that libc-alpha is much too high-volume for most architecture
> > maintainers to follow it in a low-latency manner to update their ports for
> > global changes.
> 
> 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.

> 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.

> > Certainly when the mechanism was to follow glibc-cvs and reverse-engineer
> > all the commits to work out what needed architecture maintainer action, I
> > know other architecture maintainers found it useful when I identified and
> > described on libc-ports what the changes needed were, and the results of
> > that reverse-engineering.
> 
> Again, I would expect arch maintainers to at least keep a passive eye
> on libc-alpha to gauge if there are changes that could be relevant to
> their architecture, so that if someone fails to inform them of the
> change, they could spot it themselves.

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 
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.

-- 
Joseph S. Myers
joseph@codesourcery.com