I think what you propose is a pretty decent and standard approach. I dont expect all bugs, beyond critical ones, to be fixed before a release of any open source projects, and I am always moderately suprised if I get a bug free commercial product.

Tim Sutton wrote:

Its quite common to release software with known issues. Especially
when projects release on a time based release shchedule e.g. gnome.
KDE also ships with not closed established bugs. We will try our best
to resolve them. But we need to get this release out. We will continue
to release maintenance versions until 0.9 is released. I think this is
in keeping with many projects out there and will open up development
for people who think its `not fair` to have qgis stuck in such a long
feature freeze.

If a bug remains for a long time it means either no one is able or
interested to fix it. We have Martin on the 'payrole' from the QGIS
donations but he is not able to work on this full time and no other
develoeprs have applied to be paid for bug squashing work. So we have
a difficult situation - some users shouting 'why havent we released?',
some shouting ''dont release!' and less and less new development and
new developers because of the long feature freeze. Maybe you have some
suggestion on how to keep everyone happy?



On 12/13/06, Maciej Sieczka <[EMAIL PROTECTED]> wrote:
Gary Sherman wrote:

> On Dec 11, 2006, at 10:19 PM, Paolo Cavallini wrote:

>>> Six critical bugs seem squashable before the end of the year, but what >>> about the other 16? Are you going to release qgis 0.8 with known (even
>>> if not critical) bugs, or are you confident that they can be fixed in
>>> time?

> We will do our best to close as many bugs as possible, however it is
> inevitable that there will be some remaining issues in the release. I
> think this is true with all software, its just more obvious in the open
> development model.

This rule should apply only to not-yet-reported bugs (or very fresh
ones, eg. reported a day or two before the release). It is not fair to
apply it to bugs which have been known for a long time, and release the
software anyway, although they remain.

> All past releases have had some unresolved issues and
> while we would like to release perfect software, its a matter of
> time/benefit ratio.

But you are not going to release 0.8 with *known* bugs not fixed and
call it stable, are you?

I don't want to be considered not trustworthy when I advertise QGIS 0.8
to my colleagues and folks at Polish GIS and GPS mailing lists. If QGIS
is released with known bugs not foxed on purpose, I will hesitate to
promote it.

Qgis-user mailing list

This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Qgis-user mailing list

Reply via email to