This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Kill libc-ports?
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Fri, 6 Sep 2013 12:38:05 +0000
- 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>
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