[Mono-list] Mono Bug Day

[Paul F. Johnson]

Hi,

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

True. Problem here is that mono is not GNOME and while we certainly can
borrow the methodology, the most important thing has to be that the
compiler does as it's told and things like threading don't screw things
up. How often is the screw up in MWF or gtk-sharp because of faulty code
generation or a problem of the compiler?

> It must be highly reproductible, and affect many platforms.

Yep. We have to consider Win32, MacOSX as well as many different Linux
distros.

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

It certainly would be an interesting statistical exercise to see how
many people are affected by the same bug (or more likely, same root
problem bug).

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

I'd actually argue that that would not constitute it being a show
stopper unless it was a component (such as monodoc or gtksharp) which
was at fault in which case the show stopper is not with MonoDevelop, but
with the broken component, in which case we'd need to do some poking
around to form a test case.

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

Could do.

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

Couldn't agree more. Miguel, Peter, Jordi - comments?

TTFN

Paul
-- 
"A lot of football success is in the mind. You must believe you are the
best and then make sure that you are. In my time at Liverpool we always
said we had the best two teams on Merseyside, Liverpool and Liverpool
Reserves." - Bill Shankly