This is the mail archive of the 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: [PATCH 0/2] new gconv modules for digital TV encodings

On 13 Mar 2015 10:02, Carlos O'Donell wrote:
> On 03/13/2015 02:03 AM, Mike Frysinger wrote:
> > thanks, they look largely straight forward.  unfortunately, i think most likely 
> > we're going to pass on them.  it's nothing personal ... we most likely won't 
> > accept any more gconv modules unless it's computing related (as vague as that 
> > sounds) and makes a strong case as being relevant.  a quick scan of our current 
> > modules shows they're all focused on encodings that were used historically 
> > (IBM/DOS/Windows/etc...) or active today (UTF8/etc...).  encodings used in 
> > broadcast tv don't really fall into these buckets.
> > 
> > my limited understanding of gconv is that the API isn't formalized either for 
> > external users.  since this area of glibc has settled down now, it might be 
> > nice to clean it up a bit and actually formalize it.  that'd allow people such 
> > as yourself to build and distribute gconv modules independently so others could 
> > at least benefit.  of course, we'd need someone to champion that work :).
> > 
> > i might mention the add-on route, but realistically no one builds glibc 
> > themselves anymore (they get it from their distro), so that wouldn't help.
> > 
> > the only other thought that comes to mind would be a "contrib" sort of thing, 
> > but i don't think the project wants that either.  if it's source included in the 
> > repo, then people are going to expect us to maintain it :(.
> > 
> > i'm sorry i don't have better news.
> Given the lack of interest in adding more encodings I think
> making the gconv API stable would be a lot of work with little
> benefit.
> Given also that this is first new encoding in what seems like
> 10 years, I'm inclined to simply accept the patch given that
> it's a standardized encoding.
> Mike, Do we really see this encoding being a maintenance problem?

i have no problem accepting it (pending a fuller review), i just assumed no one 
else would care ;)

Attachment: signature.asc
Description: Digital signature

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