Subject: Re: more vs. better (was Re: morning hack...)
From: Joaquin Cuenca Abela (cuenca@celium.net)
Date: Wed Apr 18 2001 - 09:29:25 CDT
On 17 Apr 2001 13:39:14 -0700, Paul Rohr wrote:
> At 11:22 AM 4/13/01 +0200, Joaquín Cuenca Abela wrote:
> >Paul Rohr wrote:
> >> There's no getting around the fact that *this* work still needs to be done,
> >> one way or the other. I'd love to see us focusing our efforts on making
> >> interesting subsets of the feature/UI/locale matrices *totally* green,
> >> instead of adding more red and orange rows and columns.
> >
> >Agreed. I want to add that the 2 features in which I've been working
> >started only to boostrap us to 1.0.
> >I mean, the "macros" support born as "something to log user activity
> >until a segfault".
> >The "perl bindings" born as "something to bring us a test suite".
>
> Absolutely. Those two developer-focused features are very, very useful, and
> I don't want to stop your efforts to that end. I just want to stick to that
> original goal of yours.
>
> To be clear. There's a huge difference in time and effort between:
>
> - a cool hack that's useful to developers
> - a polished, rock-solid feature that Church Secretaries can rely on
of course. Actually, I don't think that church secretaries will use
directly the script stuff, even if it's rock-solid.
Anyway, in the same sense that I (and many users that don't have a clue
about perl, scheme, or python) use third party perl scripts in (for
instance) the gimp, I think that our "church secretaries" can benefit of
"third party" scripts.
By "third-party" I don't mean that the user should download it from some
exhotic ftp... we can build abi executables with "third party" scripts
in the pack, and "church secretaries" should not see any difference at
all between a perl script and a hardcoded feature (they just click in
"Generate table of contents" in the menu foo, and they don't know if
executes foo.pl or if it calls native code).
Well, I only want to say that I see a bright future for this feature.
Now, the question is it will be so polished in time for 1.0. I don't
think so [1] (but I may be wrong by a long shot), and by *no* means I
will not ask for a delay in the 1.0 release to finish this feature.
[1]: it really depends on:
1) how many will the current bugs/basic features delay the 1.0 release?
and
2) how many time Paolo/me/somebody else will be able to spend in that
stuff.
I'm heavelly overworked right now, and Paolo is far far more skilled
than me to do the work (but I think that he is too overworked). Luckily
enough, Paolo has already solved all the "hard" problems (at least, he
has solved all the problems that I had no clues on how to solve them),
and the work that remains to be done, while still very important, is
relatively easy to do.
There is still another work that remains to be done until scripting can
be considered "to just work". We should be able to bind a menu/toolbar
item to a perl script, and a system to add items to the menu/toolbar at
execution time. I think that it will not take many time, we'll see :-)
Anyway, focus is (at least to me):
1) bugs
2) speed
3) features
> I just don't want to see our 1.0 release held up for any more new features,
> no matter *how* cool. And yours does sound really, really cool. :-)
I agree.
Cheers,
-- Joaquín Cuenca Abela cuenca@celium.net
This archive was generated by hypermail 2b25 : Wed Apr 18 2001 - 09:30:47 CDT