[PATCH 0/2] new gconv modules for digital TV encodings

[Carlos O'Donell]

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?

Cheers,
Carlos.