[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [aspell-devel] Aspell core dump
From: |
Jose Da Silva |
Subject: |
Re: [aspell-devel] Aspell core dump |
Date: |
Fri, 17 Dec 2004 03:49:51 -0800 |
User-agent: |
KMail/1.6.1 |
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. :-)
- Re: [aspell-devel] Aspell core dump, (continued)
- Re: [aspell-devel] Aspell core dump, Gary Setter, 2004/12/13
- Re: [aspell-devel] Aspell core dump, Gary Setter, 2004/12/15
- Re: [aspell-devel] Aspell core dump, Kevin Atkinson, 2004/12/15
- Re: [aspell-devel] Aspell core dump, Kevin Atkinson, 2004/12/16
- Re: [aspell-devel] Aspell core dump, Gary Setter, 2004/12/16
- Re: [aspell-devel] Aspell core dump, Kevin Atkinson, 2004/12/16
- Re: [aspell-devel] Aspell core dump, Jose Da Silva, 2004/12/17
- Re: [aspell-devel] Aspell core dump, Kevin Atkinson, 2004/12/17
- Re: [aspell-devel] Aspell core dump, Gary Setter, 2004/12/17
- Re: [aspell-devel] Aspell core dump, Kevin Atkinson, 2004/12/17
- Re: [aspell-devel] Aspell core dump,
Jose Da Silva <=
- Re: [aspell-devel] Aspell core dump, Gary Setter, 2004/12/17
- Re: [aspell-devel] Aspell core dump, Jose Da Silva, 2004/12/17
- Re: [aspell-devel] Aspell core dump, James Lee, 2004/12/20
- Re: [aspell-devel] Aspell core dump, Gary Setter, 2004/12/20
- Re: [aspell-devel] Aspell core dump, Kevin Atkinson, 2004/12/21
- Re: [aspell-devel] Aspell core dump, Kevin Atkinson, 2004/12/21