Bugfixes and Features

[Inge Wallin-3]

KOffice 2.1 just branched and we all know that from now on only bugfixes are
allowed on the branch.  What I would like to get some consensus on, and
perhaps get a policy for, is what constitutes a bugfix.

There is a large gray area between the obvious new feature, like a new dialog,
and the obvious bugfix like fixing a crash.  I have searched both the Koffice
wiki and KDE techbase and found nothing except this short notice on
http://techbase.kde.org/Policies/SVN_Commit_Policy :

> Backport bugfixes
>
> If you commit bugfixes, consider porting the fixes to other branches.
> Use the same comment for both the original fix and the backport, that
> way it is easy to see which fixes have been backported already.

So, I'm going to post a few scenarios here and let you decide whether you
think it's a bugfix or new feature.  Note that none of the scenarios
introduces any new strings, or other GUI elements.

1.  I make the msword filter read a new property that wasn't covered before
and write the appropriate odf.  Not handling the property wasn't bug reported
on b.k.o.

2. Same as 1 but a user has bugreported it and insists that not handling this
property is a bug and destroys his ability to use the application.

3. I implement reading a new ODF attribute for a tag, and save it back.  This
means that roundtripping is improved (i.e. data loss is lessened).  The
attribute isn't visible in the UI at all.

4. Same as 3, but now the attribute is shown in the document View.  By doing
this, the layout is improved but there is no way for the user to edit it (that
would be an obvious new feature).  An example of this could be that kword
currently reads the margin attributes, but not the padding ones. This leads to
errors in how large the text area is on a page compared to OOo and, I suppose,
to how the spec was intended.

5. Same as 3, but now it's a new visible feature that wasn't visible before.  
An example of this could be page borders.  Still no way for the user to edit,
of course.

6. I implement reading, storing and showing a new ODF element (here I suppose
there still are unimplemented XML elements in the standard). It shows
something visible on the screen that is a larger change than just a somewhat
different formatting or so. Still no editing for the user.

OK, let's stop there.  Now, obviously everybody can have an opinion, but the
interesting part of the exercise is to use your opinion and form a policy.
Please try to write down how the policy could be worded.

That's what I hope will come out of this: a clear policy for what is a bugfix
and what is not. Hopefully it will reduce the discussions and even flames.  
I'm aware that it will be somewhat arbitrary since it's probably not  possible
to create something that everybody agrees upon, but let's at least make a try.

My own opinion?  I think that we could treat 1-5 as bugfixes. Point 6 not so
easily. Our goal is to follow OpenDocument, and if we handle OpenDocument
documents wrong or miss certain attributes, it's to be considered a bug.  To
draw the line somewhere, I draw it between 5 and 6.

So my policy for KOffice of what is a bug or not is drawn from the
OpenDocument specification and new strings and editing features. Just showing
something new on the screen doesn't make it a new feature unless it's a
completely new structure.

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

[C. Boemann]

On Tuesday 27 October 2009 13:06:11 Inge Wallin wrote:

> KOffice 2.1 just branched and we all know that from now on only bugfixes
>  are allowed on the branch.  What I would like to get some consensus on,
>  and perhaps get a policy for, is what constitutes a bugfix.
>
> There is a large gray area between the obvious new feature, like a new
>  dialog, and the obvious bugfix like fixing a crash.  I have searched both
>  the Koffice wiki and KDE techbase and found nothing except this short
>  notice on
>
> http://techbase.kde.org/Policies/SVN_Commit_Policy :
> > Backport bugfixes
> >
> > If you commit bugfixes, consider porting the fixes to other branches.
> > Use the same comment for both the original fix and the backport, that
> > way it is easy to see which fixes have been backported already.
>
> So, I'm going to post a few scenarios here and let you decide whether

you
> think it's a bugfix or new feature.  Note that none of the scenarios
> introduces any new strings, or other GUI elements.
>
> 1.  I make the msword filter read a new property that wasn't covered
before

> and write the appropriate odf.  Not handling the property wasn't bug
>  reported on b.k.o.
>
> 2. Same as 1 but a user has bugreported it and insists that not handling
>  this property is a bug and destroys his ability to use the application.
>
> 3. I implement reading a new ODF attribute for a tag, and save it back.
>  This means that roundtripping is improved (i.e. data loss is lessened).
>  The attribute isn't visible in the UI at all.
>
> 4. Same as 3, but now the attribute is shown in the document View.  By
>  doing this, the layout is improved but there is no way for the user to
>  edit it (that would be an obvious new feature).  An example of this could
>  be that kword currently reads the margin attributes, but not the padding
>  ones. This leads to errors in how large the text area is on a page
>  compared to OOo and, I suppose, to how the spec was intended.
>
> 5. Same as 3, but now it's a new visible feature that wasn't visible
>  before. An example of this could be page borders.  Still no way for the
>  user to edit, of course.
>
> 6. I implement reading, storing and showing a new ODF element (here I
>  suppose there still are unimplemented XML elements in the standard). It
>  shows something visible on the screen that is a larger change than just a
>  somewhat different formatting or so. Still no editing for the user.
>
> OK, let's stop there.  Now, obviously everybody can have an opinion, but
>  the interesting part of the exercise is to use your opinion and form a
>  policy. Please try to write down how the policy could be worded.
>
> That's what I hope will come out of this: a clear policy for what is a
>  bugfix and what is not. Hopefully it will reduce the discussions and even
>  flames. I'm aware that it will be somewhat arbitrary since it's probably
>  not  possible to create something that everybody agrees upon, but let's

at
>  least make a try.
>
> My own opinion?  I think that we could treat 1-5 as bugfixes. Point 6 not
>  so easily. Our goal is to follow OpenDocument, and if we handle
>  OpenDocument documents wrong or miss certain attributes, it's to be
>  considered a bug.  To draw the line somewhere, I draw it between 5 and
6.
>
> So my policy for KOffice of what is a bug or not is drawn from the
> OpenDocument specification and new strings and editing features. Just
>  showing something new on the screen doesn't make it a new feature
unless
>  it's a completely new structure.
>
> -Inge
> _______________________________________________
> koffice-devel mailing list
> koffice-devel@...
> https://mail.kde.org/mailman/listinfo/koffice-devel
>
I agree, but will also say that the size and complexity of the needed
patches is important. Maybe only as to the needed review and testing time.

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

[Cyrille Berger]

It's rather easy, actually. Data loss are obvious bug fixes, and fixing the
round trip fix a data loss. While displaying on screen increase the
functionnalities of KOffice, hence is a new feature.

In any case, unless the patch is a two liners (and branch/2.1 isn't frozen),
bug fix for data loss are ok in the branch. Otherwise, post the patch for
review here, and then we can decide if it is safe to apply or not.

On Tuesday 27 October 2009, Inge Wallin wrote:
> 1.  I make the msword filter read a new property that wasn't covered before
> and write the appropriate odf.  Not handling the property wasn't bug
>  reported on b.k.o.
>
> 2. Same as 1 but a user has bugreported it and insists that not handling
>  this property is a bug and destroys his ability to use the application.
I don't see a difference between 1 and 2. You can give the user a patch to use
at his own risk that solve the problem.

> 3. I implement reading a new ODF attribute for a tag, and save it back.
>  This means that roundtripping is improved (i.e. data loss is lessened).
>  The attribute isn't visible in the UI at all.
bug fix

> 4. Same as 3, but now the attribute is shown in the document View.  By
>  doing this, the layout is improved but there is no way for the user to
>  edit it (that would be an obvious new feature).  An example of this could
>  be that kword currently reads the margin attributes, but not the padding
>  ones. This leads to errors in how large the text area is on a page
>  compared to OOo and, I suppose, to how the spec was intended.
User visible => new feature

> 5. Same as 3, but now it's a new visible feature that wasn't visible
>  before. An example of this could be page borders.  Still no way for the
>  user to edit, of course.
User visible => new feature

> 6. I implement reading, storing and showing a new ODF element (here I
>  suppose there still are unimplemented XML elements in the standard). It
>  shows something visible on the screen that is a larger change than just a
>  somewhat different formatting or so. Still no editing for the user.
User visible => new feature

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

[C. Boemann]

On Tuesday 27 October 2009 13:23:45 Cyrille Berger wrote:
> It's rather easy, actually. Data loss are obvious bug fixes, and
fixing the
> round trip fix a data loss. While displaying on screen increase
the
> functionnalities of KOffice, hence is a new feature.
>
> In any case, unless the patch is a two liners (and branch/2.1
isn't
>  frozen), bug fix for data loss are ok in the branch. Otherwise,
post the
>  patch for review here, and then we can decide if it is safe to
apply or
>  not.
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?

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

[Cyrille Berger]

On Tuesday 27 October 2009, C. Boemann wrote:
> So would that me considered a bugfix or a feature?
what about warning the user ? "This document use a feature that is not
supported at the moment, opening the file might result in loss of
formating/data".

kword can't import what it can't handle. Otherwise, you can never set a limit
to adding feature. Going further on your example, how would you handle non-
editable sections ?

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

[C. Boemann]

On Tuesday 27 October 2009 14:26:07 Cyrille Berger wrote:

> On Tuesday 27 October 2009, C. Boemann wrote:
> > So would that me considered a bugfix or a feature?
>
> what about warning the user ? "This document use a feature that is not
> supported at the moment, opening the file might result in loss of
> formating/data".
>
> kword can't import what it can't handle. Otherwise, you can never set a
>  limit to adding feature. Going further on your example, how would you
>  handle non- editable sections ?
>

i understand your question as to how i would avoid making new stuff
editable?

well mostly like we have done with tables, which (apart from a creation
dialog) doesn't allow editing of the tables. It does allow editing of the text
within the tables.

In the same manner I foresee that we would not allow the user to add
sections. We would however probably allow the user to set the number of
columns within that sections.

To be precise I think that "setting number of columns" would just shift from
acting on the document as a whole to acting on the current section.

Note: I've not delved too deeply into how this would be done, so this is just
a thought example. I'm sure Thomas would have some specific
suggestions when it comes to actual implementation. But for now lets just
think of this as discussing about when it's a bug or a feature.
_______________________________________________
koffice-devel mailing list
koffice-devel@...
https://mail.kde.org/mailman/listinfo/koffice-devel

[Cyrille Berger]

On Tuesday 27 October 2009, C. Boemann wrote:
> Note: I've not delved too deeply into how this would be done, so this is
>  just a thought example. I'm sure Thomas would have some specific
> suggestions when it comes to actual implementation. But for now lets just
> think of this as discussing about when it's a bug or a feature.
And from your description, it seems like a big change :) So I am still in
favor of communicating to the user about the loss of information.

This would debate is also why I am in favor of a 4-monthes cycle, that would
reduces to 6 monthes the maximum time for features addition (instead of the
current 8 monthes), and if we are well behaved, it could even be reduced to 5
monthes. But that require DVCS features ;)

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

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


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