Re: How frozen? (Re: Patch: use std::string)

> To be blunt: releasing 2.6.0 in one month would be completely insane.
> I know 2.5.0 took over a year to be released, but let's not forget that
> saving, printing, and rendering were each broken for months during that
> period (i.e. AbiWord 2.5.0 wasn't being continuously improved during
> those months - it was pretty much struggling to regain the
> functionality of 2.4). Now, if everyone thinks a release in one month
> makes the most sense (it doesn't), I'm not going to get in your way;
> but do realize that every major release of AbiWord seems to completely
> ignore the state of Bugzilla in favor of these month-based timetables
> that have little connection with the true state of the product (yes,
> the same argument was made before 2.4:
> http://www.abisource.com/mailinglists/abiword-dev/2005/Jul/0046.html).

If we waited until there were no non-enhancement bugs in bugzilla,
we'd never release the product. Bugs are a fact of life, and
determining when to release involves weighing the value of those bugs
vs. the value of getting your product to market (which presumably
occasionally contains fixes for past bugs in addition to new features
and new bugs).

Our resources are limited. For instance, Win32 printing bugs in 2.4
will likely be present in 2.5 too. But that's a fact of life - unless
someone with the time, domain-specific knowledge, and a Win32 machine
steps up to the plate, this is just something that we'll have to live
with. The same argument applies to our MacOS port. Clearly with our
50,000+ downloads of 2.5.0 on Win32, what we have now is at least
interesting - if not outright useful - to some large number of users,
despite our myriad flaws.

I also think that you sell short the work we've done in 2.5. No doubt
we've introduced plenty of new bugs, but we've fixed a *lot* of old
and new bugs, as the bug graph clearly shows. We've seen major
advancements in our file filters, independent of whatever other gains
and regressions libgsf brought. We handle international file names on
Windows finally. We've seen improvements to the GTK+ front-end. We've
removed our dependency on a DISPLAY. Command-line printing works
better on Unix. Using the Pango renderer on Unix worries me a little,
but my tests have shown that it works at least as well as the old
UnixGraphics one for Western European languages. And for the first
time since I can't remember, my printed output on Unix is WYSIWYG.

The question that's ripe in my mind is "Is HEAD as good as or better
than the last STABLE release?" That is, does it beat 2.4.latest in a
variety of quantifiable, useful benchmarks. I think that we're close
to that point, though not there yet. Certainly we need to kick the
tires, dust out the cobwebs and etc. Certainly, 2.5.x could use more
of a road test, and 1 month probably isn't enough time to do it in.

So I'll ask - what are the known unknowns and unknown unknowns?
*ducks* What do we need to fix before we can be happy stamping this as
2.6? I don't think that all the bugs targeted at 2.6 qualify, and I'll
be updating that list. And there are of course other bugs not targeted
at 2.6 that should be. That's why I asked for folks to help out with
bug triage last weekend, but the time was mostly spent on OLPC-related
features.

Like I said in my original email, I may be deluded or overly
optimistic. But unwarranted optimism is in a programmer's nature,
which is one reason why it's really nice to have you around :)

Rather than saying that we're ignoring or repeating history (a
statement I disagree with, FWIW), instead we should be a bit more
constructive and outline what it is that needs to happen before 2.6.

Sum1, you know bugzilla better than anyone, and that you wrote this
email because you care about Abi, as we all do. We're honored to have
such a proficient and dedicated bugmaster. So, what tests do we have
to pass? What bugs do we have to fix? Above all else, what do we need
to do to get your seal of approval?

Cheers,
Dom

--
Counting bodies like sheep to the rhythm of the war drums.