[Mono-list] Mono Bug Day

[Paul F. Johnson]

Hi,

> >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.

> >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.

Argh! I'm in the UK, have lead a sheltered life and know of EST, WST,
GMT and CET. The rest are a mystery!

> 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 ?

Sounds good - I usually have far more time of a weekend, but can still
give up other activities during the week.

> >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.

> >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 :-).

Who knows, those triaging the bugs may even hack the fixes!

> >>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 ?

Extremely good idea - though I would imagine the final say would have to
come from the key developers.

> 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?

> 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.

Experience is a great thing :-)

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

Thanks. The community spirit of open source is a fantastic thing to
behold and even more to be a part of.

TTFN

Paul
-- 
"Logic, my dear Zoe, is merely the ability to be wrong with authority" -
Dr Who