This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Kill libc-ports?


On Fri, 6 Sep 2013, Siddhesh Poyarekar wrote:

> On Thu, Sep 05, 2013 at 03:40:03PM +0000, Joseph S. Myers wrote:
> > On Thu, 5 Sep 2013, Siddhesh Poyarekar wrote:
> > 
> > > Do we still need the libc-ports mailing list?  I figured we could all
> > > just work on libc-alpha.  We're aiming at getting rid of the ports
> > > directory anyway, and this seems like an easy step.
> > 
> > I believe it is still useful to have a lower-volume list for drawing 
> > architecture maintainers' attention to cases where a patch has only 
> > updated some architectures and they need to make corresponding updates to 
> > their architectures.
> 
> Couldn't we just do this with tags in the email subject:
> 
> [all-arch]
> [s390][ppc]

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.

Of course, your choice of audience for your proposal excludes all the 
people for whom libc-ports is most useful.  It would be more polite to ask 
the people on libc-ports *first* rather than proposing behind their backs 
to eliminate their mailing list.

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.

> The ports distinction is artificial, in that the 'primary'
> architectures are still discussed on the main list.

My suggestion is that libc-ports would be for all architectures (where 
architecture maintainer action is needed) rather than just for some 
subset.

> > Maybe if we move all ports directly into libc (well, remove am33 first, 
> > given that the person who volunteered to maintain it never posted revised 
> > patches after 
> > <https://sourceware.org/ml/libc-ports/2012-06/msg00066.html>), leaving the 
> > ports directory containing only old ChangeLogs, we could then establish a 
> > policy that routine mechanical changes do update all architectures and 
> > that most architecture changes do go on libc-alpha, leaving libc-ports as 
> 
> I don't see why the mailing list policy has to depend on this.  I
> agree that we need to get rid of the ports directory, but that could
> be a separate change.

The presence of the separate ports directory actually causes problems - 
encouraging people to patch only a subset of architectures, confusing 
people looking for particular architectures and expecting them in sysdeps.  
The mailing list is much less problematic.

(Actually, I'd consider more significant than either the process described 
on <https://sourceware.org/glibc/wiki/Development_Todo/Master> under "libc 
architectures should be more like ports architectures regarding putting 
configuration information in sysdeps files instead of 
architecture-independent files" - although there's no actual dependence 
between eliminating the ports directory and those changes to libc, and for 
all architectures to appear equal in the tree you need both sets of 
changes.)

-- 
Joseph S. Myers
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]