[Zope-Coders] Re: [Zope-dev] Re: Collector Status Meanings

[Tres Seaver]

Chris McDonough wrote:
> On Fri, 2004-07-30 at 14:44, Chris Withers wrote:
> 
>>>But needing to wade through a bunch of wontfixes that are just responses
>>>to bad bugreporting
>>
>>These should be rejected, not wontfix'ed. And most of the time they now 
>>are. If I find any wontfix'es like this, I'd reject them, And given I 
>>went through ALL the wontfix'es today, I don't think there are any like 
>>this...
> 
> 
> Ya, you're right about this, I agree.
> 
> But still I would just never think to go through the "wontfix" entries
> on a bug day or any other time... I would think it would be a waste of
> time because I think of wontfix as a terminal state never to be looked
> at again except as a historical curiosity.  I think this may have to do
> with your definition of "wontfix", which differs from mine:
> 
>   Wontfix
> 
>   This means that the bug or feature request the issue refers to has
>   been accepted as valid but will not be dealt with for the
>   forseeable future.
> 
>   Reasons for this may include:
> 
>   Bugs in deprecated components of Zope.
> 
> OK, I agree with that.
> 
>   Bugs that are believable but that cannot be reproduced either by
>   the submitter or the wontfix'er.
> 
> I would mark this "rejected" or "pending rejection".  I'm not sure what
> "believable" means here; it's a little too fuzzy.
> 
>   Bugs where there is no solution but a common workaround which means
>   the bug should never be excercised. 
> 
> OK, agreed.
> 
>   Features that don't have a champion and so are unlikely to be 
>   implemented.
> 
> I would call this "deferred".
> 
>   Changes that don't fix a bug or add a new feature, and don't have a
>   champion, or haven't see activity in a long time.
> 
> I would also call this "deferred".

The major missing reason for "wontfix" is that the requested change 
breaks something more important than whatever pain / inconvenience / 
itch prompted the request


>>>The difference is that some pending items haven't even been looked at in
>>>earnest.  I usually put things in deferred only after I've spent a
>>>half-hour or hour or so trying to fix the thing and I've realized that
>>>it might take, say, a week to actually fix it.  OTOH, if I spent two
>>>minutes trying to fix something and fail but I still have no idea how
>>>long it would actually take to fix, I leave it in pending state.
>>
>>Okay, but other people don't do this, or see the difference.
>>For me, it's easy enough to page through http://collector.zope.org/Zope
>>and see the pending entries and see which ones of those have followups 
>>and which ones don't...
> 
> 
> Really?  There's like more than 200 of them, right?  That could take a
> while.. although granted you get to know them after a while. ;-)
> 
> 
>>>I'm not sure I care enough to further argue, but I'll note that you're
>>>suggesting that we change the meaning of deferred to something other
>>>than long-term-pending and communicating this decision to all longtime
>>>collector participants is gonna be hard and the result will probably be
>>>confusing.
>>
>>Well, at least there's a wiki page describing what the states mean now. 
>>I was contemplating linking that from the followup form just below/above 
>>the radio buttons for slecting the type of followup. Should I?
> 
> 
> I think that would be a good idea, my disagreements notwithstanding. 
> Thanks for doing this, BTW.
> 
> 
>>FWIW: had it been trivial to add a new state, I would have done, it 
>>wasn't so I didn't :-S
> 
> 
> Would you be willing add a "pending rejection" state, Ken?  Or if you
> tell me how to do it, I could do it.
> 
> If Ken added a pending rejection state, would it be reasonable to use
> that instead of deferred to mean "pending rejection"?

Tres.
-- 
===============================================================
Tres Seaver                                tseaver at zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com