Re: [Fink-devel] leaving fink
Am 11.09.2009 um 00:56 schrieb Jack Howarth: Hi Jack, all Jack, good luck for you, and I hope for both you and the MacPorts folks that you'll get along better with them. Cheers, Max Max, Nice back biting slap on the way out. You just can't help yourself can you? Jack ps Other than yourself, Benjamin Reed and Daniel Macks, I would love to hear from this mythical legion of fink developers who detest me. Nobody from us detests you, at least I for sure don't. We just never were able to get along, because certain things that were important to some (many?) of us (like, talking to people instead of just modifying their stuff, or asking whether to do something, then just do it without waiting for a reply or decision) just never showed up your radar as being an issue, and despite being repeatedly asked to not do them, you kept doing that. That I view it that way doesn't mean I detest you; it just means that I feel we don't get along in a team, and hence it's better to not work in one. Bye, Max -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] leaving fink
2009/9/10 Jack Howarth howa...@bromo.med.uc.edu: Daniel and Benjamin, I've been pondering switching my efforts over to MacPorts for awhile now since it is obvious that the X11 Xquartz situation is going to be very problematic for fink in the absence of manpower to maintain a proper set of X11 packages in fink. It has also become clear I am wondering for some time already if cooperation between fink and macports could be improved. I eventually end up installing both because neither has all the packages I want. sections of the fink developers are more interested in the form of the development than the results of the Form and purpose should be balanced. development. Note on MacPorts a package becomes unmaintained if the developer doesn't respond too emails within three weeks. I suspect you will find the current model less tenable as time goes on without major some adjustments to cope with less active maintainers being a drag on the process. Good luck with your project in the future. Jack Thanks Michal -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] leaving fink
On Fri, Sep 11, 2009 at 08:55:04AM +0200, Max Horn wrote: Am 11.09.2009 um 00:56 schrieb Jack Howarth: Hi Jack, all Jack, good luck for you, and I hope for both you and the MacPorts folks that you'll get along better with them. Cheers, Max Max, Nice back biting slap on the way out. You just can't help yourself can you? Jack ps Other than yourself, Benjamin Reed and Daniel Macks, I would love to hear from this mythical legion of fink developers who detest me. Nobody from us detests you, at least I for sure don't. We just never were able to get along, because certain things that were important to some (many?) of us (like, talking to people instead of just modifying their stuff, or asking whether to do something, then just do it without waiting for a reply or decision) just never showed up your radar as being an issue, and despite being repeatedly asked to not do them, you kept doing that. That I view it that way doesn't mean I detest you; it just means that I feel we don't get along in a team, and hence it's better to not work in one. Bye, Max Max, My main objection is the appearance of one of the least attractive features of the Debian development model. The abusive gang attack of a small subset of developers, invoking the authority of the group, on another when in actually they speak for no one but themselves. This often is accompanied by the rest of the developer community remaining silent because oh, well those guys are just like that. It is a very destructive force. Jack ps And yes it is often accompanied by statements about how the offender is unable to work as part of a team when only the subgroup is making that judgement for the whole group. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] leaving fink
Jack Howarth wrote: Daniel and Benjamin, I've been pondering switching my efforts over to MacPorts for awhile now since it is obvious that the X11 Xquartz situation is going to be very problematic for fink in the absence of manpower to maintain a proper set of X11 packages in fink. I shall not comment on the personal animosity part of this discussion (I actually understand both sides, with slightly more sympathy for Jack's points). But as to X11 on Snow Leopard: Once the transition is really over (and this is far from done yet!), I think we can safely forget about xquartz and possible Fink X11 packages, at least until Apple starts doing crazy things again. I won't bet on how long this will take, but we should be safe at least for a couple of months. Xquartz had two purposes that for a while went hand in hand: First it was simply a bug fix release for Apple's rather botched X11 release on Leopard. Second, it was interesting for people who wanted the bleeding edge Xorg X11 on their Mac. As of the latest declarations about the role and structure of X11 on SL, the second role is the only one that will remain. On the other hand, for the large majority of people, it was the first role that was interesting. And the same thing holds for Fink users. On SL, most of the bugs of Leopard X11 are fixed, thanks to the xquartz project. So we should concentrate on a future with Apple's SL X11. Let Macports spend their energy on bleeding edge X11 packages. -- Martin -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] my transgressions
Benjamin, Again, my complaint is the berating was always coached in the royal 'we' when there were (as far as can demonstrated publicly) few complaints outside of a troika of developers. If my behavior was so outside of the bounds, why did Dave Morrison never once mention it? For you information, I have privately sent most of those emails you claim were never sent (and in Sebastien Maret case...the maintainer of scipy-core-py...which set you off on your tirade in the first place...I have yet to hear back). It is you have often jumped to conclusions and been extremely rude in public, not I. Jack -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] my transgressions
A couple more comments before I go. One recent episode that stuck in my craw was the breakage of the unzip 3.0 package on 10.4. I would mention that... 1) I posted the proposed packaging on fink tracking. 2) At least one core maintainer had no objections to the concept of upgrading those. 3) I tested the packaging on all systems I had available (ppc 10.5/i386 10.5/x86_64 10.5/i386 10.6/x86_64 10.6). 4) I emailed the current maintainer at all the addresses I could find and have yet to hear back weeks later. After upgrading the packages in unstable, I discovered through a snide cvs log entry (rather than an email) that the unzip package had issues building on 10.4. I immediately proposed a fix which user shortly tested on 10.4 and posted so on the list. Now if there was less concern about the trappings of maintaining a project than the actual output, one would think that package would have been updated. No...that would make too much sense. Better leave it regressed to make the point that I create broken packages. Lastly, whenever the subject of non-maintainer updates has arisen, even to only move the current unstable packaging (which builds on x86_64 and 10.6) to stable, the immediate reaction of our fine troika is to attack and condemn without first asking had I emailed the maintainer privately. And I am the one accused of persistent rude behavior...please. Jack -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] my transgressions
On Sep 11, 2009, at 7:52 AM, Jack Howarth wrote: 2) At least one core maintainer had no objections to the concept of upgrading those. Jack, Perhaps you misread the message in question, but in fact there WAS an objection to the upgrade you proposed, but you went ahead and did it anyway. This caused much work by other people to clean up after you. -- Dave -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] X11 on Snow Leopard
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Costabel wrote: Jack Howarth wrote: Daniel and Benjamin, I've been pondering switching my efforts over to MacPorts for awhile now since it is obvious that the X11 Xquartz situation is going to be very problematic for fink in the absence of manpower to maintain a proper set of X11 packages in fink. I shall not comment on the personal animosity part of this discussion (I actually understand both sides, with slightly more sympathy for Jack's points). But as to X11 on Snow Leopard: Once the transition is really over (and this is far from done yet!), I think we can safely forget about xquartz and possible Fink X11 packages, at least until Apple starts doing crazy things again. I won't bet on how long this will take, but we should be safe at least for a couple of months. Xquartz had two purposes that for a while went hand in hand: First it was simply a bug fix release for Apple's rather botched X11 release on Leopard. Second, it was interesting for people who wanted the bleeding edge Xorg X11 on their Mac. As of the latest declarations about the role and structure of X11 on SL, the second role is the only one that will remain. On the other hand, for the large majority of people, it was the first role that was interesting. And the same thing holds for Fink users. On SL, most of the bugs of Leopard X11 are fixed, thanks to the xquartz project. So we should concentrate on a future with Apple's SL X11. Let Macports spend their energy on bleeding edge X11 packages. Agreed. We'll have some users that carp about this, of course, but they're free to tweak their package descriptions and rebuild against whatever X11 they want, locally. - -- Alexander Hansen Fink User Liaison -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqqcXUACgkQB8UpO3rKjQ9PlwCfTe7frA6DJLyiubI8RzYtOcXA CFsAmwWih6DNXEsgfguHKrxkOZ/R1+PJ =COwO -END PGP SIGNATURE- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] my transgressions
On Fri, Sep 11, 2009 at 08:16:55AM -0700, David R. Morrison wrote: On Sep 11, 2009, at 7:52 AM, Jack Howarth wrote: 2) At least one core maintainer had no objections to the concept of upgrading those. Jack, Perhaps you misread the message in question, but in fact there WAS an objection to the upgrade you proposed, but you went ahead and did it anyway. This caused much work by other people to clean up after you. -- Dave Dave, If you are referring to the BuildDepends on bzip2-dev that had absolutely nothing to do with the observed breakage. Also, the package (as I explained later on fink-devel never looks at the fink directories during the build so the bzip2-dev dependency can be dropped without concern). The only other option is to disable the bzip2 support entirely. My cardinal sin here is to be at all interested to with actual progress of this project which seems to be quite tangential to the internal politics. Sorry for wasting all of your and mine time over the last few years. Won't repeat the mistake. Jack -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] my transgressions
The time wasn't wasted. You did many good things here, and you will be missed. -- Dave On Sep 11, 2009, at 8:52 AM, Jack Howarth howa...@bromo.med.uc.edu wrote: On Fri, Sep 11, 2009 at 08:16:55AM -0700, David R. Morrison wrote: On Sep 11, 2009, at 7:52 AM, Jack Howarth wrote: 2) At least one core maintainer had no objections to the concept of upgrading those. Jack, Perhaps you misread the message in question, but in fact there WAS an objection to the upgrade you proposed, but you went ahead and did it anyway. This caused much work by other people to clean up after you. -- Dave Dave, If you are referring to the BuildDepends on bzip2-dev that had absolutely nothing to do with the observed breakage. Also, the package (as I explained later on fink-devel never looks at the fink directories during the build so the bzip2-dev dependency can be dropped without concern). The only other option is to disable the bzip2 support entirely. My cardinal sin here is to be at all interested to with actual progress of this project which seems to be quite tangential to the internal politics. Sorry for wasting all of your and mine time over the last few years. Won't repeat the mistake. Jack -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] X11 on Snow Leopard
On Sep 11, 2009, at 8:49 AM, Alexander Hansen alexanderk.han...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Costabel wrote: Jack Howarth wrote: Daniel and Benjamin, I've been pondering switching my efforts over to MacPorts for awhile now since it is obvious that the X11 Xquartz situation is going to be very problematic for fink in the absence of manpower to maintain a proper set of X11 packages in fink. I shall not comment on the personal animosity part of this discussion (I actually understand both sides, with slightly more sympathy for Jack's points). But as to X11 on Snow Leopard: Once the transition is really over (and this is far from done yet!), I think we can safely forget about xquartz and possible Fink X11 packages, at least until Apple starts doing crazy things again. I won't bet on how long this will take, but we should be safe at least for a couple of months. Xquartz had two purposes that for a while went hand in hand: First it was simply a bug fix release for Apple's rather botched X11 release on Leopard. Second, it was interesting for people who wanted the bleeding edge Xorg X11 on their Mac. As of the latest declarations about the role and structure of X11 on SL, the second role is the only one that will remain. On the other hand, for the large majority of people, it was the first role that was interesting. And the same thing holds for Fink users. On SL, most of the bugs of Leopard X11 are fixed, thanks to the xquartz project. So we should concentrate on a future with Apple's SL X11. Let Macports spend their energy on bleeding edge X11 packages. Agreed. We'll have some users that carp about this, of course, but they're free to tweak their package descriptions and rebuild against whatever X11 they want, locally. Actually, they won't be able to do that so easily, if xqusrtz doesn't use /usr/X11. But that may be for the best. -- Dave -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] my transgressions
David, Not according the obscene email that I just got from one of your Japanese developers. Should have forwarded that one to the list ;) You've got one very disfunctional crew under you. Jack On Fri, Sep 11, 2009 at 09:13:43AM -0700, David R. Morrison wrote: The time wasn't wasted. You did many good things here, and you will be missed. -- Dave On Sep 11, 2009, at 8:52 AM, Jack Howarth howa...@bromo.med.uc.edu wrote: On Fri, Sep 11, 2009 at 08:16:55AM -0700, David R. Morrison wrote: On Sep 11, 2009, at 7:52 AM, Jack Howarth wrote: 2) At least one core maintainer had no objections to the concept of upgrading those. Jack, Perhaps you misread the message in question, but in fact there WAS an objection to the upgrade you proposed, but you went ahead and did it anyway. This caused much work by other people to clean up after you. -- Dave Dave, If you are referring to the BuildDepends on bzip2-dev that had absolutely nothing to do with the observed breakage. Also, the package (as I explained later on fink-devel never looks at the fink directories during the build so the bzip2-dev dependency can be dropped without concern). The only other option is to disable the bzip2 support entirely. My cardinal sin here is to be at all interested to with actual progress of this project which seems to be quite tangential to the internal politics. Sorry for wasting all of your and mine time over the last few years. Won't repeat the mistake. Jack -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] X11 on Snow Leopard
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David R. Morrison wrote: So we should concentrate on a future with Apple's SL X11. Let Macports spend their energy on bleeding edge X11 packages. Agreed. We'll have some users that carp about this, of course, but they're free to tweak their package descriptions and rebuild against whatever X11 they want, locally. Actually, they won't be able to do that so easily, if xqusrtz doesn't use /usr/X11. But that may be for the best. -- Dave I never claimed it would be *easy*. :-) Just possible via configure flags and the like. We'd be under no obligation to support such efforts other than providing helpful suggestions, of course. - -- Alexander Hansen Fink User Liaison -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqqe1EACgkQB8UpO3rKjQ9AVwCfeVrOqgro26N2YjERbWMGVQWA tiYAnjQsoSWe/GaT/PGu1Kxx59rwDMtl =Xg4H -END PGP SIGNATURE- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] my transgressions
Am 11.09.2009 um 18:24 schrieb Jack Howarth: David, Not according the obscene email that I just got from one of your Japanese developers. Should have forwarded that one to the list ;) If people do something like that, it's of course sad. But I am glad you did the right thing and did not forward a private email to a public place, something that's quite obscene (or rather immoral?), too, at least in my eyes. Good. You've got one very disfunctional crew under you. Nonsense. Most people here are very sane, functional and helpful. I understand that you are upset, but let's not distort things out of proportion. BTW, you accused me of a biting slap on the way out, when all I did was wishing you good luck in the future. Yet at the same time you apparently cannot stop the biting punches on the way out... Who is rude here? Bye, Max -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] my transgressions
On Fri, Sep 11, 2009 at 06:53:58PM +0200, Max Horn wrote: Am 11.09.2009 um 18:24 schrieb Jack Howarth: David, Not according the obscene email that I just got from one of your Japanese developers. Should have forwarded that one to the list ;) If people do something like that, it's of course sad. But I am glad you did the right thing and did not forward a private email to a public place, something that's quite obscene (or rather immoral?), too, at least in my eyes. Good. You've got one very disfunctional crew under you. Nonsense. Most people here are very sane, functional and helpful. I understand that you are upset, but let's not distort things out of proportion. BTW, you accused me of a biting slap on the way out, when all I did was wishing you good luck in the future. Yet at the same time you apparently cannot stop the biting punches on the way out... Who is rude here? Bye, Max Max, The tone of the comment I hope for both you and the MacPorts and folks that you'll get along better with them. could be read as having a subtext (which perhaps doesn't exist in German). As for the filthy email, I hope for fink's sake that he codes better than he swears. Jack -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] If everyone would just shut up and listen to me ...
Dear Fink community: Since my computer skills and diplomatic skills are both quite rudimentary (an assessment based on reality, not modesty), I've been reluctant to say much (apart from accepting the blame for suggesting the latest scipy-core be updated, which I based on some mistaken assumptions). Just as there are core members of fink, there are people like me who are very peripheral in the sense that all of the packages I maintain are at most dependencies for other packages I maintain. So if I mess something up, I am probably the only one who suffers the consequences (along with the end-users). This gives me something of an outsider's perspective. Hence I hope you might permit me a few observations from that perspective (with my full advanced acknowledgment of its limitations). 1. X11.app Like many end-users, I have been updating to the latest X11.app from Xquartz, not because I crave the bleeding edge, but simply because I understood this to be the best way to have as few bugs in X11 as possible, and also because I (wrongly) assumed that the latest (2.4.0) would be what came out with OS X 10.6. I got burned, and got into a typically unpleasant discussion on the X11 mailing list. The net result is I learned I should have stopped at or before X11 2.3.3.2, but more importantly, that the X11 in /etc/X11 that came with 10.6 would remain untouched, except for Apple bug-fixes, and future Xquartz releases would install elsewhere (presumably /opt/X11) to avoid clobbering the officially distributed Apple X11. I think this is a Good Thing, assuming all fink packages work with the SL X11. We should just assume it is there, and not concern ourselves at all with what gets installed in /opt, or support it. What the end-user does is out of our control, but in principle there is no reason we would have to worry about this one way or the other, as long as we can rely on the current contents of /etc/X11 being in place. 2. Stable vs. Unstable I tell people to translate the word unstable as current when they express shyness about using it. With the SL upgrade, we have, at least initially, an inversion, where packages in Unstable may work when packages in Stable do not, or are obsolete, etc. I wonder if it might be worth changing this demarcation to Core and Peripheral or some such designation, the main point being to have the talents and energy of the core fink team focused on the most important packages, and to keep people with limited abilities, like me, out. 2.1 Core branch Put packages including all the core fink packages, gcc44, fftw, tcltk and friends, gtk+2, gnome libraries, python, guile, and all the other packages that tend to get built primarily as dependencies for other packages into this branch. These are the ones that are by far the most critical for end-users, would be of the most use to have available as a stable, binary distribution that mainly got updated only for bug fixes, and would benefit the most from having the fink core maintainers maintaining them. Then allow the core maintainers themselves to decide on whatever policy they think is best for keeping the core packages of fink up and running smoothly. Because maintaining these packages would be the highest priority, it would be best to focus the talents and energy of the best and most capable people on these packages to ensure they all work together to form a seamless infrastructure. 2.2 Peripheral branch Put packages that are of use to a subset of end-users (e.g.: my crystallography packages come to mind) here. Mistakes in these packages are more easily tolerated, because they do not cripple the core infrastructure of fink, and so these can be entrusted to peripheral maintainers who possess more limited skills like me. Distributing these as binaries is a much less compelling concern. To decide where a package goes, just ask what would happen if the package were to be deleted from fink. If the answer is that the presence isn't critical, then assign it to the Peripheral branch. 3. Let's all take a deep breath I had the good fortune to have a former Apple VP (who was responsible for much of Xcode) as a graduate student in a class last spring. I asked him what it was like, and he described his erstwhile job as helping highly creative autistic people to have productive careers. I know it is a bit of a stereotype, but computer people often aren't qualified to be Japanese diplomats, and it is also very hard for even the most socially adept individuals to infer intent from a pile of ascii text characters. We all need to give each other the benefit of the doubt when interpreting each other's words and actions. We all want the same thing, after all: a viable, fully-functional and up-to- date fink. Peace and joy, Bill -- Let Crystal Reports handle
Re: [Fink-devel] If everyone would just shut up and listen to me ...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/11/09 2:13 PM, William G. Scott wrote: I think this is a Good Thing, assuming all fink packages work with the SL X11. We should just assume it is there, and not concern ourselves at all with what gets installed in /opt, or support it. What the end-user does is out of our control, but in principle there is no reason we would have to worry about this one way or the other, as long as we can rely on the current contents of /etc/X11 being in place. I agree. While the growing pains in X11 have been, well, painful, in the end, I think X11 in OSX has reached a stability where it's reasonable to expect it will work like this From This Point On(TM). We'll have to adjust once more to the new situation on the ground, but hopefully this'll be the last of major upheavals. (Famous last words.) 2. Stable vs. Unstable I tell people to translate the word unstable as current when they express shyness about using it. With the SL upgrade, we have, at least initially, an inversion, where packages in Unstable may work when packages in Stable do not, or are obsolete, etc. I wonder if it might be worth changing this demarcation to Core and Peripheral or some such designation, the main point being to have the talents and energy of the core fink team focused on the most important packages, and to keep people with limited abilities, like me, out. I don't think there's a problem with everyone who's a committer having access to stable, I think it's more that we need a couple of folks to sit down, spend a month or two completely ignoring updates, and work on finally putting together the infrastructure we've said we didn't have time to work on and just make it happen. Once we have automated builds of any kind, we can start promoting packages from unstable - stable automatically or semi-automatically, because we'll really know how info files and the state of binaries map, and we can solicit and receive feedback on packages from end-users more easily. I intend to work on this as soon as I can, although right now is a bad time for me because of huge amounts of work commitments. I hope to make the time anyways. :) I had the good fortune to have a former Apple VP (who was responsible for much of Xcode) as a graduate student in a class last spring. I asked him what it was like, and he described his erstwhile job as helping highly creative autistic people to have productive careers. I know it is a bit of a stereotype, but computer people often aren't qualified to be Japanese diplomats, and it is also very hard for even the most socially adept individuals to infer intent from a pile of ascii text characters. We all need to give each other the benefit of the doubt when interpreting each other's words and actions. We all want the same thing, after all: a viable, fully-functional and up-to- date fink. Agreed. I've said what I needed to at this point, it can be accepted or not. I've avoided commenting any more on the drama that continues to unfold, as hard as it's been to resist. ;) I slipped a little by being snarky in a commit, and I regret that. Otherwise, I'm just staying out of it from here on out. - -- Benjamin Reed a.k.a. Ranger Rick Fink, KDE, and Mac OS X development Blog: http://www.raccoonfink.com/ Music: http://music.raccoonfink.com/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.12 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFKqplkUu+jZtP2Zf4RAsxQAJ0bA365U9pu+VNkpu0N8cTxZ0U94gCggrvg Rl8nxrw36Q7wpf2zFe/BP8Q= =DCWu -END PGP SIGNATURE- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] If everyone would just shut up and listen to me ...
Benjamin Reed wrote: Once we have automated builds of any kind, we can start promoting packages from unstable - stable automatically or semi-automatically, because we'll really know how info files and the state of binaries map, and we can solicit and receive feedback on packages from end-users more easily. I intend to work on this as soon as I can, although right now is a bad time for me because of huge amounts of work commitments. I hope to make the time anyways. :) That's great to hear. One thing I'm wondering if would be possible to do as part of this semi-automation is a dependency engine that better knows what packages are available and is used to parse the output of 'fink list'. I wondered about this as drm did his 10.6/x86_64 trimming. Currently, one of the more common errors that is reported is a missing dep because a package has a (versioned) dependency that is no longer in the database. So if I maintain $user-package which requires $libs, I need to keep aware of its happenings, especially if I ever want to move it to stable. For example, SDL originally failed to build on 10.6 and was marked as 10.4, 10.5. This meant that any package that depended on SDL (which are many), then also had to be marked as 10.4, 10.5, otherwise, errors about missing dependencies would occur to people trying to install $sdl-dependent. And when SDL was fixed, all those packages also had to be marked as available. This takes a lot of manual effort, and could lead to errors because $sdl-dependent might have been marked as !10.6 for other reasons, and an automated scanner/fixer would not know that. But if 'fink list/install' knew about dependencies, it would not show non-restricted $sdl-dependent as available unless all of its dependencies down the tree were available. So if SDL is restricted, SDL-net (and even deeper dependents) would not need to be marked as restricted. 'fink list wormux' (eg) would check the tree, see that wormux needs SDL-net, see that SDL-net depends on SDL and since SDL is restricted, it would not even list wormux (or SDL-net) in the list of available packages. The big benefit of this system is that once SDL becomes unrestricted (or just available), SDL-net and wormux (assuming they work of course), would immediately become available to the end user without $maintainer having to do anything. This would also help $maintainer deal with arch/dist combos to which s/he has no access for testing. And finally $user would not get errors about missing dependencies. I think the biggest impediment to this becoming reality is that the _entire_ dependency tree will then need to be stored somewhere after its creation by 'fink index', rather than a limited and specific subtree rooted on $user-package created and destroyed from scratch at every 'fink install'. Hanspeter -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] my transgressions
On Fri, Sep 11, 2009 at 09:13:43AM -0700, David R. Morrison wrote:
The time wasn't wasted. You did many good things here, and you will be
missed.
-- Dave
Dave,
Sorry for the separate replies but I recalled one last thing that will
impact everyone here. Ben Elliston (who maintains config.guess) is reviewing
my current submission to the config-patches mailing list. The change (against
current config.guess) is...
@@ -1247,6 +1247,18 @@
*:Darwin:*:*)
UNAME_PROCESSOR=`uname -p` || UNAME_PROCESSOR=unknown
case $UNAME_PROCESSOR in
+ i386)
+ eval $set_cc_for_build
+ sed 's/^//' EOF $dummy.c
+ #if defined(__LP64__)
+ main()
+ {
+ }
+ #endif
+EOF
+ if test `$CC_FOR_BUILD -E $dummy.c 2/dev/null | grep -c main`
= 1 ; then
+ UNAME_PROCESSOR=x86_64
+ fi ;;
unknown) UNAME_PROCESSOR=powerpc ;;
esac
echo ${UNAME_PROCESSOR}-apple-darwin${UNAME_RELEASE}
which will ensure that config.guess always reports on intel Darwin the
architecture based on the code generation of the compiler. I had a more concise
version that the gcc developers perferred but because it requires -dM,
which is a gcc extension, is non-portable. Once this patch goes into the
config.guess
cvs, I'll ping fink-devel so that interested fink developers can ping their
upstream
to update config.guess where appropriate.
Jack
ps Of course the aim of this is to eliminate the need to pass...
--build=%m-apple-darwin`uname -r|cut -f1 -d.` --host=%m-apple-darwin`uname
-r|cut -f1 -d.`
...to configure.
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
