quetz-mod_python-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Gallacher <...@jgassociates.ca>
Subject Re: My plans for mod_python changes (260206).
Date Sun, 05 Mar 2006 15:53:38 GMT
Graham Dumpleton wrote:
> 
> On 04/03/2006, at 4:59 AM, Jim Gallacher wrote:
> 
>> More in the way of a general observation rather than on these  
>> specific issues, but I wouldn't necessarily mark things as resolved  
>> just on the basis of the fix being committed. For the big changes  at 
>> least, I think we should see some testing on a couple of  different 
>> platforms. Maybe we could announce development milestones  and ask the 
>> community for a round of testing? Issues would be  marked as resolved 
>> after each milestone test cycle. That way we are  more likely to catch 
>> problems early and hopefully reduce the time  it takes for the next 
>> beta cycle. We should do whatever we can to  avoid the 7 months it 
>> took to get 3.2 out. (Actually, it was even  longer than that, as 
>> Grisha first mentioned a 3.2 release last  spring). Ideally trunk 
>> would always be in a stable enough condition  that we could do a 
>> release within a month of making a decision.
> 
> 
> Jim, have read through the JIRA documentation page you once referred  me to
> about status values and what they mean and for "Resolved" it states:
> 
>   http://www.atlassian.com/software/jira/docs/v3.3.2/images/docs/ 
> config/statuses-addstatus.png
> 
>   A resolution has been taken, and it is awaiting verification by     
> reporter. From here
>   issues are either reopened and or closed.
> 
> The issue for us is whether one expects a reporter to verify a fix  for 
> an issue before it
> has even been committed to the repository. For them it would probably  
> be a pain to
> have to first checkout latest version from repository and then also  
> apply a patch. If
> they do say it is okay, then by rights should verify it again after  it 
> has then been committed
> as who is to say the final commit isn't stuffed up somehow.

I think in most cases it is too much to expect the reporter to verify a 
fix. To do so assumes that they are closely following mod_python and 
their particular issue. That may not be the case, especially if we defer 
the fix to a future version. The reporter may not be subscribed to 
python-dev and so not be aware that their bug is receiving any 
attention. I'm sure we've all reported bugs in other projects but never 
followed up. Perhaps the reporter has stopped using mod_python so the 
issue no longer matters to them, but it is still a bug that *we* want fixed.

> They way I read all the status values is that it would be quite  
> reasonable once a fix
> has been committed to mark it as resolved. If the reporter then  
> disagrees it can be
> reopened. If they agree it is okay, then it should be closed there  and 
> then and not
> wait until some milestone. If a problem is later found, then a new  
> issue can be created
> and linked to the original.

As I argue above I don't think we should depend too heavily on feedback 
from the original reporter, as I think that is the exception rather than 
the rule. We should use our own judgement on setting the status if we 
can reproduce the bug. If the bug is specific to a particular platform 
to which we don't have access, then a higher level of involvement from 
the reporter will be required.

I'm not saying we should ignore feedback from the reporter, just that it 
shouldn't be a requirement.

> Without moving issues through resolved/closed in a timely fashion,  too 
> me it just
> makes it harder to work out where one is up to amongst the large list  
> of issues.

Agreed.

I still think we should declare milestones for general testing purposes, 
but that is really a separate issue from this JIRA housekeeping discussion.

Jim



Mime
View raw message