octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Willing to work for octave.


From: John W. Eaton
Subject: Re: Willing to work for octave.
Date: Fri, 10 Jan 2014 10:27:31 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131005 Icedove/17.0.9

On 01/09/2014 10:07 PM, Jordi Gutiérrez Hermoso wrote:
On Fri, 2014-01-10 at 00:58 -0200, Felipe G. Nievinski wrote:

On Fri, Jan 10, 2014 at 12:31 AM, Jordi Gutiérrez Hermoso
<address@hidden> wrote:

On Thu, 2014-01-09 at 17:12 -0800, fgnievinski wrote:

Python offers an "easy" tag for bug reports:
<http://docs.python.org/devguide/fixingissues.html> How about
doing the same for Octave?

Sure, this hardly is a novel idea. Want to do it?

Sure.  Though now that I tried it, I can't seem to find a tags field
in the bug tracker -- am I missing it?

There's no tags field. Sadly, only project admin can manipulate bug
metadata after it's been created. But if you go and compile a list of
bugs you think that are easy, that's a good step.

Apart from whether it can be edited by non-admins, Savannah does allow
us to create an effort field.  It's a single line text box that's
intended to be an estimate of the time required but doesn't force you
to actually write particular text like "1 hour", so anything could go
there.

It's also possible to create a custom select box.  I assume that means
you get to choose the label that is displayed in the tracker along
with a set of custom menu items.  If so, then we could create one that
has options like "trivial" (fix a typo), "easy" (modify a function or
two), "difficult" (requires refactoring), "impossible" (requires
rewriting everything).

If there's interest, I'll add it.  But I think estimating effort for
any non-trivial tasks is complicated and I suspect that most trivial
or even easy bug reports have been dealt with.  But feel free to prove
me wrong.  There are 500 to select from, but I'd guess that you'll
find no more than 25 or so that could be classified as "easy".

In my experience, the proper fix for the "easy" ones is often somewhat
complex.  Sure, there may be an "easy" fix, but it can sometimes just
make things worse in terms of overall code quality and future
maintenance cost.

jwe


reply via email to

[Prev in Thread] Current Thread [Next in Thread]