On Thursday 16 December 2004 06:50 am, Gary Setter wrote: > > My thoughts: > If the sole purpose of making software free and open was to make > a solution available to all, then I would agree that there is > nothing wrong with how it is coded. > > However, if the purpose is to improve confidence in the software, > and to open it up for improvement, and to make it available to be > adapted to new purposes, then I would disagree.
Hi Gary, I share some of your frustrations here as well, for example, I've made a couple of attempts to convince Kevin in fixing some routines as per sourceforge bug-fixes (yes, Kevin is convinced I'm obsessed with prezip, and I'm starting to find humour in seeing "how many" bug-fixes I can load on just prezip plus how-low a score he can assign on some suggested fixes before the bubble bursts to fix-none OR accept some/all), but we also got to look at it from Kevin's perspective too. Right "now", you, sometimes I, and many other readers/contibutors who come to this forumn to contibute ideas have "abundant" time to look at one or "a" particular problem and even make large patch attempts which from "your/my/others" perspective is as clear as day to "you/me/other". Also, from our perspective, we get thrown these extra obstacles that get in our way, like, go put it on sourceforge, go document your change. :-/ Assuming Aspell doesn't pay Kevin's bills... ...along with whatever day-job Kevin is doing right now, Kevin is dealing with you, me, other people, plus the "aspell-user" forumn (which also yanks him in different directions too), keeping documentation up to date, and trying hard to make sure that whatever patches applied don't break something for hundreds/thousands/millions of users using aspell, plus seeing if projects like debian or other distros accept the changes (sometimes the distros don't accept the changes for whatever reason may be such as too radical a change, or some other reason). When it comes to "time", we really don't know how much time Kevin can afford to look at all the changes "we" all would like to pull this in ASAP. > I would say that the code is difficult to understand. It does not > seem to me to be "solid code". To make a change, like adding a > field to whatever WritableBase::word_lookup holds would involve > exhaustive study of the whole module. Even after much study, you > would never be completely sure if your change broke someone > else's assumption. To just document it as it is would be > something of a cop out. Like you, I also find the code underdocumented, not bullet-proof and not as solid as it may eventually be, so if you figure something, add documentation and hopefully if Kevin adapts the fix, he keeps the documentation too according to his style, not ours. :-/ since you/I/others might not be around later on, while we assume Kevin will be around with whatever wasteland of a disaster we leave behind. ...just view the whole thing as an oil tanker.... they are over-sized, under-powered, and take miles to go before you actually notice that they've changed direction. You can introduce one huge patch all at once, sort of like taking a huge sledgehammer to the side of the ship and hope the force of the hammer doesn't rupture the side of the ship, or you can attempt to use a bunch of small hammers to eventually bang the ship in the right direction. It may not be the crystal clear solution you presented many moons ago, but you will hopefully be pushing the ship in the right direction. Eventually. Two other things that are a "positive" in introducing tiny fixes versus one big patch..... 1)A tiny change hopefully gets introduced quicker since hopefully Kevin is going to be able to see the reason for the change quicker. 2)As much as "we" like to think we are programmer-gurus, and like to program, and hate documentation... if you look at all the patent-crazy political/business things happening right now, if you were to introduce one large patch without explainig why you obviously did it what you obviously did, it only takes some weird patent to come along and unravel what you did... on the other hand, if you introduce something small, and make it obvious, it is unlikely going to get pulled out because you've documented something "obvious" .... so sure... go ahead and introduce the big picture so he knows the lay-of-the-land, then afterwards, go introduce the fix in small bite-sized pieces so that some/most/all of it eventually gets thrown in. The above is "my thoughts" and like you, I to can find the wait sometimes frustrating, but hopefully the above helps you see why you want to wait too. Be patient, break it down, document why, and "hopefully" the ship eventually turns. :-) _______________________________________________ Aspell-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/aspell-devel
