Re: [aspell-devel] Aspell core dump

[Jose Da Silva]

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.  :-)