This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH 0/2] new gconv modules for digital TV encodings
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: tskd08 at gmail dot com, libc-help at sourceware dot org, carlos at systemhalted dot org
- Date: Fri, 13 Mar 2015 10:02:23 -0400
- Subject: Re: [PATCH 0/2] new gconv modules for digital TV encodings
- Authentication-results: sourceware.org; auth=none
- References: <20150305223255 dot GD19311 at vapier> <1425654747-6213-1-git-send-email-tskd08 at gmail dot com> <20150313060322 dot GK877 at vapier>
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
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?