Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <3CD0A8D3.2070407@ece.gatech.edu> Date: Wed, 01 May 2002 22:47:47 -0400 From: Charles Wilson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: "Gerrit P. Haase" CC: cygwin AT cygwin DOT com Subject: Re: rfp: libiconv References: <645049681 DOT 20020502011535 AT familiehaase DOT de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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/-/ 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/