Am Freitag, 27.06.03 um 06:08 Uhr schrieb Mr. Kiwi:
I haven't done much development for Fink in recent months, so I've been a little out of the loop.
Welcome back then.
I came back wishing to mess around again (since I now have some time) but to my surprise, the Fink project seems to be in disarray.
Uh... we are??? Funny, I never noticed :-) Sure some things may not be as I'd wish they were, but I don't follow you here at all.
OK, the following might end up sounding harsher than I mean it. However, please notice that I like many open source developers who sacrifice a lot of their spare time, feel pissed off when people stomp in, and tell me with the sound of absolute confidence, that what I and other do is chaotic and bad and they know how to do everything better. I realize you just want to be supportive, but at least to my ears you didn't convey that really in your mail. I read a bunch of criticism (some of it I actually agree with), and then go on to say how "we" are supposed to do things. Why don't you actually *do* something, so that you have a right to say "we" first? Might make you much more credible in the eyes of the "community" for which you seem to speak (funny how people always know so much better what the "community" wants w/o ever having asked the community via polls etc.).
Constructive criticism is welcome. So are actual contributions. Rants are not.
Here are a few issues I think need to be addressed before they get out of hand:How can you claim to know how has been poorly executed ??? Are you on the metapkg mailing list or participating in our IRC discussions? Did you even read our charter? I don't think so. Go to http://www.metapkg.org and read what it say
Consolidation:
Yes, getting Gentoo and all the other groups working with Fink was a good idea, but so far it has been poorly executed.
There's no organization for the new influx of developers, which makes forums like this almost useless as well as the package tracker, etc.
You are misunderstanding metapkg.org's goals and its impact on Fink. We are *not* merging with Gentoo or anything like that. We also didn't get them to work with us. The three projects DarwinPorts, Fink and Gentoo, as peers, agreed to share resource in the porting effort. That's all. There is no "new influx of developers" caused by this. As such, I also don't see how it makes this forum, which is there to discuss the development of Fink, useless. That's just nonsense, at least in the way you stated if. If you still think, after having read the charter on http://www.metapkg.org/ and thought about what I wrote, that you have a point - please explain it, instead of just slapping it into our face.
We need a darned "spring cleaning" of the entire site because the community environment is getting screwy.
Again I can't follow you. Maybe if you made some concrete suggestions as to what is bad, and how you think it could be changed. I know it's more work to do that than to say outright "you suck", but it's also much more useful. We definitely do want to improve whenever and wherever we can - but clearly this is limited by factors, like, we can only fix problems we know about; and we can only spend resources we have.
Ben & Ben, you two are the big men on site, make some executive orders and get stuff fixed. I'd even be willing to do some website work on the fink homepage, considering it gets stranger and more confusing by the day. I know PHP and Perl :D
Well, you are welcome to help out, we are always glad about contributions, after all this is a community project. For a start, tell us concrete things you'd like to change and in what way.
Reliability: //start # fink selfupdate-cvs sudo /sw/bin/fink/ selfupdate-cvs
Gonna try the cvs server...
su mkiwi login -p:serv...hahahahahahhahhahahahaha you don't have permission to access me!!!!!!!!!!!!!
The cvs server has had incorrect permissions for weeks now, and people are starting to complain. Whoever maintains it needs to fix it already, and fast.
The CVS server had no incorrect permissions. It is however true that the anon CVS server of SF.net has been quite screwy in the past week, but that's not an access problems, it's a load problem. I agree, this is not nice for end users who want to use "selfupdate-cvs", as they have to retry it several times, sometimes a dozen times. Nasty. We've been discussing providing our own anon CVS mirror to avoid this problem.
But I hardly see this as "disarray" - it's one of many technical problems we had to face over the past years, and like all the others, we'll get over it. You can still use Fink, and most users seem to use bindist / point releases. All the others will have to repeatedly run "fink selfupdate-cvs" until we have a permanent solution in place (but latest in August the problem will be fixed anyway, since SourceForge.net gets new hardware to fix the problem on their side then).
A novice user running Fink Commander doesn't know if or why their packages aren't updating.That would be an additional problem in FC, if it doesn't pass on error message of Fink to the user properly (I don't use FC so I can't judge it).
Regular Mac OS X users should be your demographic target, but icky *nix problems get in the way.That's your opinion. However, not everybody shares that opinion. Personally I think we should, if possible, provide an easy to use interface, for no matter who is using Fink. However, if something can't be done in a fashion appealing to a "Regular Mac OS X user" (assuming that means somebody w/o any Unix experience), so be it - if you want to use Fink, you *must* learn some things about Unix. Again, that's my personal opinion.
Maybe it's time to have a Fink Application written with Quartz API's to come along and save the day. With umpteen hundred packages floating around, users need easy access to config settings and other "geeky" parts.
FinkCommander is written in Cocoa (there is no such thing as a the "Quartz API", the closes to that would be CoreGraphics, and you wouldn't want to write an application using that, nor should you). I am sure the people from the FinkCommander project will welcome your source contributions. Although I never use it myself, from the few times I helped people work with it, there are some things in its UI that could be improved. To get that done, make sure to either file detailed feature requests and bug reports, where you describe the shortcomings and how, in your opinion, the situation could be improved. If you just think by yourself "gee this could be done better" or if you just tell us "I don't like it", we can't help you. Even better would be of course to contribute code; but again,constructive contributions on the design level are good, too.
Actually, the bottle neck is the disk I/O, not perl (feel free to run the profiler yourself if you don't believe me). Also storable is slow, using BDB (as David Höhn suggested) or some other DB might help to speed up things there.
Speed:
Plus, unless you have a PowerMac G5, the Perl scripts are getting too slow to be efficient anymore. They were fine when we just had 400 packages to deal with, but we really need a solid, database-driven command-line option OTHER than Debian. Remember, Debian is for Linux, Fink is for Mac OS X.
Reading a bunch of files in a tree is slow (and kinda newbish) work,
It works well actually. If you haven't noticed yet, we actually only read the data in there once, then operate on a database file (which is, as I mentioned above, done with Storable; which is indeed getting near to its limits right now; which is why we plan to switch to another DB solution, probably BDB). Thus, the active storage is in a fast DB already; only the permanent long time storage is in separate files, which works very well, is easy to access, easy to maintain with existing tools.
something not characterized by our community.
Uhm... was that sentence meant to have any meaning? :-) If so, it eludes me, feel free to elaborate on it.
Maybe it's time to use the XML packages and gcc's libraries to do the dirty work that Perl has trouble with.
XML isn't the solution here; our package format works fine, is well defined, and efficient; there is nothing to be gained by using XML (and I have done lots and lots of work with XML, and like it; but I also know that it's not the solution for all and every problem). And using GCC is hardly the solution either, as it can't help the bad disk I/O speed of Mac OS X.
I'll end my ranting with this: I really care about the fink community and I would hate to see a bunch of XFree86-type problems happen later on because of problems. Something needs to be done– perhaps my answers are not the right ones
Perhaps, but I can't judge it - you haven't given any answers yet, but we'll be happy to hear them once you write them down :-) (what you wrote above are some generic remarks about how we are a bunch of chaotic people working on a chaotic project; that we are doing this and that wrong; and that you think Perl is too slow and maybe using XML and gcc would be better). Uhm, not much in the answer category in my opinion :-)
Bye,
Max
------------------------------------------------------- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
