[Nut-upsdev] Re: [nut-Patches][304310] IP v6 support

[Peter Selinger]

I have always taken "patch" to mean "something that can be applied
with the Unix program 'patch'". It is a way for people to submit code
without SVN write access.

The distinction between "new features" and "feature requests" will not
make it very clear to the users where they should submit their stuff.
At least it is not self-evident to me which is which, without having
read the accompanying discussion.

On the other hand, the distinction between "Bugs", "Feature Requests",
and "Patches" is common in many projects (e.g. it is the default
setting on sourceforge and alioth), and therefore easily recognized by
most people.

How about using Categories to distinguish between different types of
patches in the Patch tracker? Currently, the only defined categories
are "None" and "Widget (example)", but I am sure one could define
"Bug" or "Feature".

Alternatively, if there are to be 4 trackers, they should be named
transparently. How about:

1) "Bug Reports"
2) "Feature Requests"
3) "Patches (Bug Fixes)"
4) "Patches (New Features)"

-- Peter


Arjen de Korte wrote:
> 
> 
> >> For me, it's a matter of which activities should receive priority:
> >>
> >> 1) bugreports with patch (if someone took the time to investigate what=
> 's
> >> wrong and provides a solution, they should receive the highest priorit=
> y)
> >>
> >> 2) bugreports without patch (we should first fix existing bugs, before
> >> introducing new ones) :-)
> >>
> >> 3) feature requests (with or without patch)
> >
> > IMHO, since it seems like most of the reports coming in are
> > essentially feature requests (in the form of supporting new models and
> > protocols), I think the third category needs to be split somehow.
> 
> That suits me fine. I just wanted to list the priorities here. We should
> strive to keep the time that bugs are 'open' (with or without patches)
> short. On the other hand, feature requests can take a little longer.
> 
> >> In my opinion a feature request is not a patch and also should not be
> >> treated with the same priority as a 'real' patch. I find it very
> >> confusing to see these two separate categories listed under the same t=
> ab.
> > Do you have a suggestion for naming the trackers, assuming that for
> > orthogonality of categories, we should have a tracker for each
> > combination of (bug fix, feature request) and (patch included, no
> > patch provided)?
> 
> What about (in order of precedence)
> 
> 1) "Bug Fixes"
> 2) "Bug Reports"
> 3) "New Features"
> 4) "Feature Requests"
> 
> Best regards, Arjen
> 
> 
> _______________________________________________
> Nut-upsdev mailing list
> Nut-upsdev at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
>