From: Dom Lachowicz (domlachowicz@yahoo.com)
Date: Tue May 20 2003 - 12:13:12 EDT
Hi folks,
Unfortunately, the tagline of the AbiWord 2.0 release
"Wrath of Dom" might all too likely come true.
I want to start by saying that I'm not angry at anyone
or anything. I'm merely concerned about the current
state of affairs, and wish to ackowledge that I am at
also responsible for many of them. Please don't look
at this from me now as hypocricy; rather, try to see
it as hindsight and foresight.
I don't wish to pick on any particular person or
people. Do not take what follows as a personal attack
on anyone or their work to date. Please use what
follows as a motive to tie up these loose ends instead
of getting angry. I don't want to scare off
developers. I don't want to belittle people's efforts
- they've been nothing short of outstanding. I realize
that everyone is acting with nothing but the best of
intentions in an effort to make AbiWord a better
product. Please realize that I have my release-manager
hat on right now, and that I want nothing but to make
AbiWord a better product too.
That said, the state of the tree lately is simply
unacceptable for a close precursor to our 2.0 release.
1) It is wrong to break the build in any non-trivial
way (i.e. makefile typo, cast conflicts with someone's
compiler that you couldn't test on, MSVC's broken
variable scoping rule, etc...), even if it helps your
own cause and refactors XP code. Let it be known that
we should all make ourselves aware of those above
classes of errors and make every effort to avoid them.
Regarding any change that might be viewed as
controversial, please send patches to the list. We
will work on them collaboratively and commit ONLY when
Unix, MacOS, Win32, and QNX are all finished.
2) It is wrong to add a new dependancy to the mainline
build of AbiWord before discussing it on-list. It is
*unthinkable* that this happened so late in the
development cycle. For example, I personally want us
to use LibGSF in all of our import/export filters.
There are about 5000 good reasons to do so. However,
you will never see me make first mention of it on-list
in a commit message. I don't care how hashed-out the
discussion is on IRC. I don't care if you think I'm in
favor of it. Some smart and exceptionally important
people in this community don't hang out on IRC. Others
aren't around when you are. Use IRC and bugzilla as a
way to develop ideas, to get a feel for "how warm the
waters are." Then bring it to the list.
3) Many commits in the past months fall into the
"half-assed" category. I don't think that even I am
above this assessment, unfortunately, and I apologize
by not best leading through example. This includes:
3.a) Poorly coordinated XP features/changes, with said
changes only being immediately beneficial to one
platform. Again, this list of offenders includes
myself with my recent mail merge work, and I
apologize.
Some things I'd like to see happen in order to remedy
the current situation:
1) Font mess gets cleaned up. I think that the damage
has been already done here. We need to move our
platform-specific code and adapt it to Hub's XP
design, altering said XP design if/when needed.
2) Win32 Keyboard mess gets cleaned up. The keyboard
*finally* worked properly for me in my en_US locale on
WinXP just a few weeks ago. If the new Unicows dll is
to be kept, we must:
a) Choose a way for it to be redistributed
developer-wise, possibly including if/when/where it
gets put in CVS
b) Integrate it with our installers, including
b.i) Ensure it doesn't get installed on NT based OSes
or
b.ii) Have a download page where our users can get it
from, if it's decided that we don't want the installer
to include it
c) Update the build texts accordingly
d) Document the cases in which it isn't working
3) No more casting commits until after 2.0. We cannot
afford build breakage, even if it's only on schurro's
gcc .0001
4) The Win32 color toolbar combo box needs to be
redesigned or reverted to the old behavior. I'll file
a bugzilla bug for it. Its behavior is
counter-intuitive, and pretty much the exact opposite
of MS Office's behavior. This will only serve to
confuse our users, I'm afraid.
5) The mail merge dialog needs to be implemented on
the non-GTK+ platforms. I'm to blame for this, and I
apologize for creating the extra work for you. The
dialog is intentionally simple, and is hopefully easy
to implement. Please contact me for any and all
questions of comments regarding it.
6) If possible (RFE, not a requirement), the GDA and
OLE2 mail-merge plugins should coordinate efforts.
Jordi and I should work together on the file format
and automation process, in order that the Win32 folks
can take advantage of the new mail merge capabilities
of AbiWord.
This is a subset of the issues that remain for 2.0.
I'll start another thread with other things that I
think need doing/fixing before 2.0 comes out.
Again, I want to commend you all for your great work
to date. I don't mean to scold you, and I blame myself
more than I blame any other individual or group. I'd
just like to see these issues get resolved, and
quickly. I appreciate all of your hard work. We all
mean the best.
Thanks again,
Dom
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
This archive was generated by hypermail 2.1.4 : Tue May 20 2003 - 12:27:09 EDT