This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin 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: rfp: libiconv


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/


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