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

List:       koffice-devel
Subject:    Bugfixes and Features
From:       Inge Wallin <inge () lysator ! liu ! se>
Date:       2009-10-27 12:06:11
Message-ID: 200910271306.11186.inge () lysator ! liu ! se
[Download RAW message or body]

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@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]