[Mono-list] Mono Bug Day

[Julien Gilli]

Hello,

Paul F. Johnson wrote:

>>I think that putting  the following couple of pages together on the Wiki  :
>>
>>- General informations on bug days :
>>
>> * What is a bug day ?
>> * Who can attempt ?
>>    
>>
>
>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 ?

>For example, user
>"a" may write and compile some code which clearly shows (say) MWF is broken
>for spot colours. This is submitted and a peer proofs the code to see that
>it's not user "a" who has made a boo-boo before submitting as a real bug.
>
>  
>
I totally agree with that, it is a typical use case of a bug day :-).

>> * When does it take place ?
>>    
>>
>
>Logistically, the third is the biggest one given the diversity of places
>people are (I'm in the UK for instance while Peter (say) is out by 6 hours
>from GMT). I'd suggest that the bug "day" would need to be split into two half
>days for when the developers are around.
>  
>
IIRC, the GNOME project has bug days from 15 PM to 21 PM UTC, which is 
nice during the week.
I agree that bug days during the week-end would be fine too. Maybe we 
could split bug days with one in the middle of the week and one during 
the week-end ?

> 
>  
>
>>-  Detailed informations on what to do during a bug day :
>>
>>This can be split in two parts : bug squashing and bug triaging :
>>
>> * As for bug triaging :
>>  * How to find bug reports that are most important to triage ?
>>  * How to triage a bug report ?
>>    
>>
>
>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).

>>* As for bug squashing :
>> * How to find bug confirmed bug reports that are most important to fix ?
>> * How to fix a bug ?
>>    
>>
>
>Ideally, the developers, though others should never be discouraged. This is
>were the peer review comes into it's own - bugs which aren't bugs never get
>past the reviewer.
>  
>
I agree too : triaging bug is the primary goal, nevertheless fixing them 
is great :-).

>>Would this bug day be best set on a saturday
>>or sunday though?
>>
What do you think about the middle of the week/week-end schedule i 
mentionned above ?

Maybe we should set a goal for the first milestone, like having a bug 
day next saturday, or on 09/10 ? By trying to get things done, we will 
probably come across some problems that we'll resolve, and then we can 
go from there for the future bug days.

Again, looking forward to hearing from you :-).

All the best,

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