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?


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

Attachment: pgpbT2kwPb5y6.pgp
Description: PGP signature


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