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

List:       koffice-devel
Subject:    Re: Bugfixes and Features
From:       "C. Boemann" <cbo () boemann ! dk>
Date:       2009-10-27 12:17:56
Message-ID: 200910271317.56552.cbo () boemann ! dk
[Download RAW message or body]

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