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 > >[EMAIL PROTECTED]) 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 _______________________________________________ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list