Mail Archives: cygwin/2002/05/01/22:47:48
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/
- Raw text -