[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Bugfixes and Features
From:       Thomas Zander <zander () kde ! org>
Date:       2009-10-27 14:26:49
Message-ID: 200910271526.53826.zander () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Tuesday 27. October 2009 14.18.15 ext C. Boemann wrote:
> Let me ask you about this case then:
> in word documents text can be divided into sections. This is
> currently not implemented in kword meaning we loose data.
>
> However implementing it will make the documents look different
> . Ok maybe a hack could be devised that would make it look like
> before, but that would just be even more code.
>
> So would that me considered a bugfix or a feature?

This is the risk when talking about bugs vs. features and thats why I don't 
personally think its the way to go.  its a slippery slope to define what is a 
bug and what is a feature.
Btw, I agree with Cyrille on all the examples given.

In Qt there are a couple of rules that may be useful here too; first is that 
behavior changes are not allowed in a frozen branch. Even if it would make 
more sense. The only exception is when its a behavioral regression against a 
previously released version.

Patches that are not already disqualified by the above are then looked at from 
the point of view of userpain. A technique that takes 3 completely orthogonal 
metrics that can be judged completely independently.
* how easy is the bug hit by users. So how many users are impacted by it.
* what is the cost of hitting the issue. Dataloss at the top, user can work 
around it at the bottom.
* what is the cost of fixing it. Which essentially means; what is the risk of 
introducing new bugs and/or regressions.

The last point is easily described, but much harder to define. In practice, 
people don't define it.
The chance of regressions is generally speaking a judgment call by the people 
that know the code best. If more code is touched, or even assumptions changed 
in code thats a clear indication that its too involved for a stable branch.
As a recent example; if you have the experience that a class is fragile, you 
don't touch it (I challenge anyone to fix a bug in QRegion, nobody does that, 
its too fragile).

Lets end with a quote from kde-core-devel.  "There is always life after this 
release".
Which essentially means that we don't loose a lot by being cautious with 
bugfixes, while introducing regressions is a sure way to loose users.
-- 
Thomas Zander

["signature.asc" (application/pgp-signature)]

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel


[prev in list] [next in list] [prev in thread] [next in thread]