rfp: libiconv

rfp: libiconv

[Gerrit P. Haase]

Hallo Charles Wilson,

> Any volunteers?
> 
> --Chuck
> 
> (*) okay, *one* more -- pkgconfig -- is in the works.  but that's it.  I 
> mean it. ;-)

Come on Charles,

you have a complete version of libiconv, ready for upload,
what should the volunteer do?  Repackage it to install in
/usr instead of /usr/local ?

And also libungif is ready.  You are already the grafic libs
specialist;)  Why not put one more up to the mirrors?

Tell me, how much support jobs do you have with libtiff?
Or with jbig?  Is it really too much if there is one more of
these packages?  E.g. libungif will need an update probably
every three years!



Gerrit
-- 
=^..^=


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: rfp: libiconv

[Charles Wilson]

Gerrit P. Haase wrote:


> Come on Charles,
> 
> you have a complete version of libiconv, ready for upload,
> what should the volunteer do?  Repackage it to install in
> /usr instead of /usr/local ?


Yes.  Advocate its adoption.  And, once it is part of the official 
distribution, monitor the mailing list for problems with that package 
and correct them.  Serve as a central organizer to vet, test, and apply 
patches that people send to you for the cygwin version (hah!).

Serve as the primary troubleshooter for the errors people are bound to 
uncover -- especially as the gnome port uses libiconv; so there will be 
tons of people who will try to compile GMissileCommand or GnomeWars or 
somesuch and run into problems.

Determine which patches should be sent on to Bruno Haible for inclusion 
in the upstream version.  Advocate their adoption on that list.  Monitor 
that list for information that may affect the cygwin port.

But most importantly, the maintainer of libiconv should *know something 
about internationalization*.  I'm a dumb American.  I don't know 
anything about alternate keyboards, alternate alphabets, codepages. 
And, even with three years of spanish and a year of latin, I speak no 
other language than English -- to the despair of my HS teachers and 
hispanic friends.  I don't even know enough to *test* libiconv beyond 
running its own built-in test suite.  I'm not qualified to maintain the 
libiconv package.

Then, of course, there's the simple fact that I am trying to get other 
people to adopt my existing packages; not take on new ones.  It's only 
my sense of "parenthood" that's kept me around as long as I have.

My next computer will be a Mac.  I'm now doing most of my development on 
Solaris or Linux.  And, since I use TeX for document creation, I don't 
even need MSOffice anymore.  MS freedom is approaching.  *I will leave 
cygwin* at some point; how many orphaned packages do you want me to 
leave behind?


> And also libungif is ready.  You are already the grafic libs
> specialist;)  Why not put one more up to the mirrors?


See above.  No more packages.  Period.

 
> Tell me, how much support jobs do you have with libtiff?


Funny you should ask; I recently had to reorganize the package and 
include extra headers because someone contacted me about getting 
libgeotiff to work...


> Or with jbig?


Did you follow the recent discussion about netpbm?  That had the 
potential to clobber my jbig package...but it didn't (and won't). 
However, I had to (a) know that, and (b) follow it closely.  Even for a 
package like 'jbig' where upstream development seems to be dead.

>  Is it really too much if there is one more of
> these packages?  E.g. libungif will need an update probably
> every three years!


It's not that each single package takes much time.  It's that there are 
so damn many of them.  And maintaining a package is not just "throw out 
a new version based on upstream code every now and then".

The maintainer is the central point of contact fot the entire cygwin 
community for any and all problems that may crop up with that package. 
She is the primary bughunter.  Half the time, the bug reports are not 
really problems with your package -- but you have to check them out 
anyway, just to be sure.  But even this, may not be a big deal for a 
single package: say jpeg, for instance.

However, multiply by 20.  Then, take into account that many of my 
packages are very "core": ncurses. readline. cvs. autoconf(scripts, plus 
coordinating with Corinna's autoconf-stable and autoconf-devel). 
automake(diitto).  libtool(scripts AND -stable AND -devel).

libiconv will also be 'core' -- it will be used by gnome, gcc-3.x, ...

Besides, would you rather have me (badly) support yet another package, 
or actually get busy with the interminable cvs.exe bugs I've been 
avoiding for months now?

No, I will not be pressured on this.

----------------

There is already a volunteer for libungif, and for Berkeley DB (I'm not 
sure the volunteer wants to go public yet).  Several people have 
wondered aloud about libiconv (Paul Miller, Soren Andersen, others) -- 
but as yet no-one cares enough to just take the already-ported package 
and adopt it.

Now, I think it might be a good idea if there were a parallel tree to 
'release' -- call it 'unsupported' -- where the packages follow the same 
setup.exe-compatible standards as regular packages, except:

    --prefix=/usr/local
    --sysconfdir=/usr/local/etc
    documents go into
      /usr/local/doc/<PKG>-<VER>/ and
      /usr/local/doc/Cygwin/

Official 'release' packages MUST NOT EVER depend on 'unsupported' packages.

The 'unsupported' repository would serve as a place where people (like 
me) who port a package, can make it "officially" available to users via 
the cygwin mirror system -- BUT with the attitude of:
   "it works for me.  if it works for you, great.  otherwise, don't bug me"

'unsupported' packages could be adopted for migration to the "release" 
tree by any sufficiently motivated volunteer maintainer.  Or, if the 
original submitter flakes out, anybody else could also submit an updated 
replacement package...but leave their contribution in the 'unsupported' 
tree too.

If there were a tree like that, then I would submit my "other" packages 
there.

--Chuck


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: rfp: libiconv

[Gerrit P. Haase]

Charles schrieb:

[...]

> Determine which patches should be sent on to Bruno Haible for inclusion
> in the upstream version.  Advocate their adoption on that list.  Monitor 
> that list for information that may affect the cygwin port.

That is easy...(monitoring), the other point, we both tried to contact
Haible, he ignores it.  Maybe the next release will introduce some
changes, but I don't believe it.

> But most importantly, the maintainer of libiconv should *know something 
> about internationalization*.  I'm a dumb American.

[...]

I am a stupid Kraut.
I'm not qualified too...

> Then, of course, there's the simple fact that I am trying to get other 
> people to adopt my existing packages; not take on new ones.  It's only 
> my sense of "parenthood" that's kept me around as long as I have.

:-)

> My next computer will be a Mac.  I'm now doing most of my development on 
> Solaris or Linux.  And, since I use TeX for document creation, I don't 
> even need MSOffice anymore.  MS freedom is approaching.  *I will leave 
> cygwin* at some point; how many orphaned packages do you want me to 
> leave behind?

There will be someone to take it over then.
(& MAC users are weenies...)

>> And also libungif is ready.  You are already the grafic libs
>> specialist;)  Why not put one more up to the mirrors?


> See above.  No more packages.  Period.

Ok. I understand.

[....]

> No, I will not be pressured on this.

I didn't want to bug you.

> There is already a volunteer for libungif, and for Berkeley DB (I'm not 
> sure the volunteer wants to go public yet).  Several people have 
> wondered aloud about libiconv (Paul Miller, Soren Andersen, others) -- 
> but as yet no-one cares enough to just take the already-ported package 
> and adopt it.

Oh yeah, I hope Berkeley DB will get out soon.
I really need it for Perl.

> Now, I think it might be a good idea if there were a parallel tree to 
> 'release' -- call it 'unsupported' -- where the packages follow the same 
> setup.exe-compatible standards as regular packages, except:

>     --prefix=/usr/local
>     --sysconfdir=/usr/local/etc
>     documents go into
>       /usr/local/doc/<PKG>-<VER>/ and
>       /usr/local/doc/Cygwin/

> Official 'release' packages MUST NOT EVER depend on 'unsupported' packages.

> The 'unsupported' repository would serve as a place where people (like 
> me) who port a package, can make it "officially" available to users via 
> the cygwin mirror system -- BUT with the attitude of:
>    "it works for me.  if it works for you, great.  otherwise, don't bug me"

> 'unsupported' packages could be adopted for migration to the "release" 
> tree by any sufficiently motivated volunteer maintainer.  Or, if the 
> original submitter flakes out, anybody else could also submit an updated 
> replacement package...but leave their contribution in the 'unsupported' 
> tree too.

> If there were a tree like that, then I would submit my "other" packages 
> there.

Well, actually there is, they all fetch libiconv from your site and use it,
just because some packages ask for it.  It worked for me since you loaded up
the first binary to ftp.uni-erlangen.de and before the shared version I
used a static, selfcompiled one.

I like the idea of having unsupported packages.  I have also some
binaries at my webserver, 'joe' gets fetched really often and I get
about one question about joe per month.  I wanted it to be included
in the dist, but it wasn't heard/uploaded...

So I keep it at my site.  Just like some other packages.
E.G. I have a Berkeley-DB binary of 4.0.14: http://62.138.63.18/cywgin/db/
And Expat 1.95.2 (shared): http://62.138.63.18/cywgin/expat/


Gerrit
-- 
=^..^=


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/