Subject: Re: Upcoming releases
From: Paul Rohr (paul@abisource.com)
Date: Mon Feb 12 2001 - 13:05:34 CST
Dom,
Thanks for taking the lead on driving the release process to closure.
At 01:06 AM 2/12/01 -0500, Dom Lachowicz wrote:
>What I'd like to do is release a CVS snapshot of AbiWord in about 2 days.
>Call it a 0.9.0 pre-release if you will. There's no need to build any
>binaries, but if you'd like to, please do. I'll be providing a number of
>builds for GTK+ and Gnome on RH7, for instance. I'll be uploading all
>recieved binaries to our Sourceforge site for distribution and making
>notices on Gnotices, LWN, freshmeat, etc...
OK, I'm a heretic. Since you're going through almost all of the usual
release process anyhow, why not call this 0.7.13, and mention that it's
"really" a pre-release of 0.9.0 in the announcements?
>As for the future (0.9.0 and beyond), what's happening? Well, we need a
>styles dialog and the new lists dialog before 0.9.0 is out. Work is underway
>on both. I'm also working on a few very small dialogs that I'd like to add
>too, but they'll be in RSN (tomorrow?).
Yet another reason to not call this week's release 0.9.0-pre*. That's too
much work to get done in a few days, and "pre" releases should get quickly
followed by the "real" thing.
>The early stages of 0.9.x will represent a soft feature-freeze. We can
>change around the look and feel of toolbars, dialogs, menus, etc... and even
>add some new functionality.
Excellent. Could you post a list of any dialogs which will _not_ make the
0.9.0 (and thus 1.0) release under your plan? That way, anyone who really
cares about those features has had fair warning.
>New file filters will be generally accepted
>during this phase as well, if people want to hack on them. I'll probably be
>doing some work on Word export and OpenOffice filters, and maybe even KWord
>too.
Definitely. Having a soft freeze on the feature set should really simplify
life for anyone interested in completing various file filters so they Just
Work for that *entire* feature set:
http://www.abisource.com/mailinglists/abiword-dev/01/February/0369.html
This is a prime time to be recruiting people to get that work done.
>Other new features will probably be added, but I'm hoping that people
>post new feature-related patches to the list for peer-review.
An interesting addition to our current process. To date, we've trusted
anyone with commit access to make any changes they're willing to stand
behind (and finish, if need be).
This would be a very public way to maintain release discipline, and is
probably necessary for anyone who'll need help from others to make sure a
new feature Just Works on all platforms.
>By the middle of 0.9.x there will be a hard freeze on new strings. A call to
>translators will be made. Everyone in our CREDITS.txt under translators will
>recieve an email from me. An announcement will also be made on gnome.org's
>i18n mailing list to get these people to contribute too. They're damn good
>and fast at what they do.
Awesome. Do you want to do this all yourself, or would you be willing to
accept help from someone else who'd be willing to own this task?
IIRC, some of the translators have been silently coordinating and commiting
other translations, and perhaps someone's ready to step up and start
handling things at this level.
If so, I'm sure you can find other ways to stay productive. ;-)
>At some arbitrary point, the tree will be frozen and I will accept only bug
>fixes into the tree (and possibly a new feature or two *if there is
>overwhelming demand and it does not produce new bugs*).
Cool. Sounds like you're formally claiming ownership of this release
process, no?
>By 1.0, we would ideally have 0 bugs in our software. This is ideal, but it
>may not be feasible or even possible. We should attempt to get the known bug
>count down to a (subjectively) *very low* number. Of course, some bugs are
>more important to fix than others. Also, lots of entries in bugzilla are
>RFEs and things that we might not be able to (or even want to) fix. For
>example see #305 (flashing on 8 bit displays). Most importantly, there
>should be *0* known crash-causing bugs in 1.0.
Yep. As we close in on 1.0, I expect to start seeing more and more traffic
about specific bug clusters, debating who'll handle which ones, and which
others should be deferred.
>Comments and suggestions are welcome. Get your ideas and opinions out before
>it's too late.
Yep, chime in everyone!
Paul
PS: Sorry for not splitting this out into separate threads.
This archive was generated by hypermail 2b25 : Mon Feb 12 2001 - 16:55:12 CST