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

--- Dominic Lachowicz <domlachowicz@gmail.com> wrote:

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

I don't disagree with this at all. I do, however, wonder how much the
proposal to release in one month takes these factors into account.

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

Yes, I know that we're all volunteers. I can't force someone to fix a
bug nor can I tell them to stop working on a new feature, but I can
propose a better solution for determining when to release.

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

If one month isn't enough time, why was it proposed in the first place?
:)

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

By turning each release into a crapshoot, we are ignoring history.

>
> 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?

It's not about getting my seal of approval, but rather about coming to
a consensus about what will and won't be fixed for the release, as
determined by our work in Bugzilla. How is it that Rob can propose a
May release and then back your one month proposal an hour later?
Similarly, how can you now say that one month isn't enough time when
you clearly thought so earlier today?

We need to take this sort of guesswork out of releases and be honest
about what's going to happen for each one. Right now, there are 463
bugs with a target of 2.4.x or 2.6; obviously, these bugs won't all be
fixed before the release nor do they have to be. Instead, they should
be re-targeted and prioritized, as the assignee sees fit (with some
input from others, if necessary), so they're not just punted en masse
after 2.6.0 is released (i.e. let's not repeat the mistakes of 2.4.0).
Likewise, we should find bugs that ought to be fixed for the release
and re-target those, just as you proposed in the bug squad email. When
this work is done, the decision to release will have already been made
(for the most part). This method makes a heck of a lot more sense than
rushing 2.6.0 to work on new features or whatever other reasons people
are using to decide the date of release.

 
____________________________________________________________________________________
The fish are biting.
Get more visitors on your site using Yahoo! Search Marketing.
http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php
Received on Thu Jan 18 02:38:07 2007