[Mono-list] Mono Bug Day

[Julien Gilli]

Paul F. Johnson wrote:

>>>This would need to be split and preferably, peer mentored. 
>>>
>>>      
>>>
>>I don't understand what you think should be peer mentored. Do you mean 
>>that attempting a bug day should be peer mentored ? Or were you 
>>mentionning writing up these pages should be peer mentored ?
>>    
>>
>
>The reports coming in. For example, if I was to submit a massive lump of
>code which demonstrated two bugs, neither of which depending on each
>other, then the reviewer would reject the code and ask for the smallest
>case of each to demonstrate the point.
>
>  
>
Ok, got it :-).

>>>All bugs are important, just some more than others. I remember finding one
>>>very small bug in an application called TechWriterPro (it's a RISC OS app)
>>>which when investigated, proved to be massive and set back the release
>>>schedule by a month.
>>> 
>>>      
>>>
>>I agree too, but there are some special cases for which you could want 
>>to focus your attention on a certain kind of bugs (just before a 
>>release, a feature freeze, whatever).
>>    
>>
>
>True. I'm assuming this will be a freeze before an official beta release
>(going by the time line). In that case, some order of importance needs
>to be given over - something like (most important) compiler and mono
>runtime -> corelibs -> MWF [inc. cairo/libgdiplus] -> monodevelop ->
>gtklibs -> monodoc (least). I've distinguished between MWF and the
>corelibs as despite it being mega important, having the likes of
>Encoding, threading and IO streams working spot on is of greater
>importance as a whole.
>
>  
>
Again, I will refer to GNOME for this : they use the term "showstopper" 
for bugs that truly "shows". That is, everybody get to see the 
consequence of the bug. As for GNOME, it can be for example the mouse 
pointer that get locked inside the panel, or evolution that can't send 
and e-mail.
It must be highly reproductible, and affect many platforms.
Briefly, the order of importance here is given by how many users can see 
the bug and how much it prevents them from doing what they want.

For example, if there's a bug that prevent monodevelop from starting, it 
would be marked as a showstopper, whereas not being able to compile a 
given type of not so often used code with the compiler (which is more a 
core component than monodevelop) would not.

>>Maybe we should set a goal for the first milestone, like having a bug 
>>day next saturday, or on 09/10 ? 
>>    
>>
>
>Next sat sounds fine, though will there be enough time to set things up
>and would it be an idea for there to be a default email address (say
>mono-triage at ximian.com) whereby test cases arrive to all the reviewers
>and if they pass, bugzilla them?
>  
>
We can go this way, or mark bug that have not been reviewed as 
"UNAPROVED" and then wait for either a developer or a bug day buddy to 
confirm it before working on a fix.

Whatever we choose, we must have some agreement from the key developers 
to even start thinking about seting up what we are discussing now.

All the best,

-- 

Julien Gilli
IDEALX http://www.idealx.com/