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

[Arnaud Quette]

2007/1/5, Arjen de Korte <nut+devel at de-korte.org>:
>
> >> 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 priority)
> >>
> >> 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 tab.
> > 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"

I now better see where you wanted to go ;-)
that would allow a better priority management, and that suits me fine.
But I'm not sure we can modify/create such trackers on alioth (not
looked at all though).

Arnaud
-- 
Linux / Unix Expert - MGE UPS SYSTEMS - R&D Dpt
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://people.debian.org/~aquette/
OpenSource Developer - http://arnaud.quette.free.fr/