Kill libc-ports?
Thomas Schwinge
thomas@codesourcery.com
Fri Sep 6 08:41:00 GMT 2013
Hi!
On Fri, 6 Sep 2013 10:51:50 +0530, Siddhesh Poyarekar <siddhesh@redhat.com> 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]
That also seems more reasonable to me.
I'd also suggest (but do not insist) to not rename the libc-alpha list,
as that just brings infrastructure work (list configuration, archiving,
new Gmane setup, every subscriber changing their filters, remember new
address, etc.). I smile a little bit everytime I come across a *-cvs
mailing list that has for years seen nothing but Git commit messages, so
I think carrying some historical baggage is fine. (That said, I don't
know the history about the libc-alpha mailing list's name. Probably set
up when glibc was alpha quality for Linux kernel?)
> The ports distinction is artificial, in that the 'primary'
> architectures are still discussed on the main list.
Yes, that needs to go, as discussed some time ago (when merging in the
glibc-ports Git repository?), if I remember correctly.
Also, there was talking about keeping the ports sysdeps machanism alive
-- but frankly I don't see the point to keep that mechanism alive if it
doesn't see meaningful usage. And with today's Git usage, everyone doing
a port can just do it in their private Git repository in the main
sysdeps/ hierarchy, and is no longer required to be easily able to bolt
it into glibc proper by means of the ports sysdeps mechanism.
> > 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.
Agreed.
Grüße,
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20130906/7eec95cb/attachment.sig>
More information about the Libc-alpha
mailing list