From koffice-devel  Tue Oct 27 14:26:49 2009
From: Thomas Zander <zander () kde ! org>
Date: Tue, 27 Oct 2009 14:26:49 +0000
To: koffice-devel
Subject: Re: Bugfixes and Features
Message-Id: <200910271526.53826.zander () kde ! org>
X-MARC-Message: https://marc.info/?l=koffice-devel&m=125665369800558
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--===============1215152377=="

--===============1215152377==
Content-Type: multipart/signed;
  boundary="nextPart1430268.ReLmOX5Yf0";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart1430268.ReLmOX5Yf0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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=
=20
personally think its the way to go.  its a slippery slope to define what is=
 a=20
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 tha=
t=20
behavior changes are not allowed in a frozen branch. Even if it would make=
=20
more sense. The only exception is when its a behavioral regression against =
a=20
previously released version.

Patches that are not already disqualified by the above are then looked at f=
rom=20
the point of view of userpain. A technique that takes 3 completely orthogon=
al=20
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=
=20
around it at the bottom.
* what is the cost of fixing it. Which essentially means; what is the risk =
of=20
introducing new bugs and/or regressions.

The last point is easily described, but much harder to define. In practice,=
=20
people don't define it.
The chance of regressions is generally speaking a judgment call by the peop=
le=20
that know the code best. If more code is touched, or even assumptions chang=
ed=20
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, yo=
u=20
don't touch it (I challenge anyone to fix a bug in QRegion, nobody does tha=
t,=20
its too fragile).

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

--nextPart1430268.ReLmOX5Yf0
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAkrnAyoACgkQCojCW6H2z/RELQCfUpJ2jwFqVdfW5QL4d2/iJUCO
LBkAoOArvmakgKqPhi+Nu/K7tpiULR6Y
=iJeE
-----END PGP SIGNATURE-----

--nextPart1430268.ReLmOX5Yf0--

--===============1215152377==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1215152377==--