Re: [Mono-list] Mono Bug Day
Paul F. Johnson wrote: On Thu, 2005-08-25 at 16:04 +0200, Paolo Molaro wrote: On 08/23/05 Julien Gilli wrote: There hasn't been any feedback from several core developers on this point. So I ask the same question again :-). Do you think that it's something that could be help mono development ? Yes, it would be useful. Who is going to step up and organize everything? What needs to be done? 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 ? * When does it take place ? - 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 ? * As for bug squashing : * How to find bug confirmed bug reports that are most important to fix ? * How to fix a bug ? along with an IRC channel and a mailing-list to announce special events (like special bug days before a release, etc.) could be a good step forward :-). What do you think about this ? I can give some time to help organize these bug squashing/triaging thing. I can write the wiki pages too . However, I think we should discuss about conventions used by mono developers for the bugzilla system (like what version or milestone a bug report should be assigned to, etc.) before doing it. Looking forward to hear your comments. All the best, -- Julien Gilli IDEALX http://www.idealx.com/ ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono Bug Day
Hi, What needs to be done? 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. 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. * 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. - 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. * 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. along with an IRC channel and a mailing-list to announce special events (like special bug days before a release, etc.) could be a good step forward :-). Definitely! What do you think about this ? I can give some time to help organize these bug squashing/triaging thing. I can write the wiki pages too . However, I think we should discuss about conventions used by mono developers for the bugzilla system (like what version or milestone a bug report should be assigned to, etc.) before doing it. Sounds a very good set of ideas. Would this bug day be best set on a saturday or sunday though? Whatever happens, I'm happy to give over as much time as I can. I am using mono more and more now (especially as it forms the basis of some of my research project) - I can give back this way :-) TTFN Paul (watching MS.NET deinstall while thrashing the HD) -- Logic, my dear Zoe, is merely the ability to be wrong with authority - Dr Who ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono Bug Day
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/ ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] Mono Bug Day
IIRC, the GNOME project has bug days from 15 PM to 21 PM UTC, which is nice during the week. UTC == GMT Universal Coordinated Time. Keeps the French happy (well, happier)! ;) -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono Bug Day
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 [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. 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/ ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono Bug Day
There are two email lists that will help: - mono-bugs - mono-patches If you subscribe to these mail lists, you will be able to get email about a new bug or a change in a bug or its status. Also, mono-patches will allow you to peer review others code. Maybe a Pre-Release Days instead of Bug Day would be more appropriate for Mono. We could help with docs, update status info on the mono wiki, test building the pre-release tarballs, test a pre-release of the installers, etc... And of course, make sure any serious bugs are squashedso we can have an outstandingstable release. However, any pre-release tarballs,RPMs,or installers would not be downloadable from the Downloads page. Maybe only available as ftp and the word prerelease is in the tarball or installer's filename. Just some ideas... I'll be waiting to see your wiki page. "Paul F. Johnson" [EMAIL PROTECTED] wrote: Hi, What needs to be done?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. For example, user"a" may write and compile some code which clearly shows (say) MWF is brokenfor spot colours. This is submitted and a peer proofs the code to see thatit's not user "a" who has made a boo-boo before submitting as a real bug. * When does it take place ?Logistically, the third is the biggest one given the diversity of placespeople are (I'm in the UK for instance while Peter (say) is out by 6 hoursfrom GMT). I'd suggest that the bug "day" would need to be split into two halfdays for when t he developers are around. - 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 onevery small bug in an application called TechWriterPro (it's a RISC OS app)which when investigated, proved to be massive and set back the releaseschedule by a month. * 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 iswere the peer review comes into it's own - bugs which aren't bugs never getpast the reviewer. along with an IRC channel and a mailing-list to announce specia l events (like special bug days before a release, etc.) could be a good step forward :-).Definitely! What do you think about this ? I can give some time to help organize these bug squashing/triaging thing. I can write the wiki pages too . However, I think we should discuss about conventions used by mono developers for the bugzilla system (like what version or milestone a bug report should be assigned to, etc.) before doing it.Sounds a very good set of ideas. Would this bug day be best set on a saturdayor sunday though? Whatever happens, I'm happy to give over as much time as Ican. I am using mono more and more now (especially as it forms the basis ofsome of my research project) - I can give back this way :-)TTFNPaul(watching MS.NET deinstall while thrashing the HD)-- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - DrWho___Mono-list maillist - Mono-list@lists.ximian.comhttp://lists.ximian.com/mailman/listinfo/mono-list__Do You Yahoo!?Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono Bug Day
Daniel Morgan wrote: Maybe a Pre-Release Days instead of Bug Day would be more appropriate for Mono. What do developers think about this ? I think that doing the hard work little by little is easier than having a big sprint once in a while, but I agree that prerelease days would be a great thing too :-). We could help with docs, update status info on the mono wiki, test building the pre-release tarballs, test a pre-release of the installers, etc... And of course, make sure any serious bugs are squashed so we can have an outstanding stable release. However, any pre-release tarballs, RPMs, or installers would not be downloadable from the Downloads page. Maybe only available as ftp and the word prerelease is in the tarball or installer's filename. Just some ideas... They sound great to me, however I don't think that prerelease days serve the same purpose as a bug day. I think that there is room for the two of them :-). -- Julien Gilli IDEALX http://www.idealx.com/ ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono Bug Day
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
Re: [Mono-list] Mono Bug Day
On 08/23/05 Julien Gilli wrote: There hasn't been any feedback from several core developers on this point. So I ask the same question again :-). Do you think that it's something that could be help mono development ? Yes, it would be useful. Who is going to step up and organize everything? lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono Bug Day
On Thu, 2005-08-25 at 16:04 +0200, Paolo Molaro wrote: On 08/23/05 Julien Gilli wrote: There hasn't been any feedback from several core developers on this point. So I ask the same question again :-). Do you think that it's something that could be help mono development ? Yes, it would be useful. Who is going to step up and organize everything? What needs to be done? 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
Re: [Mono-list] Mono Bug Day
Daniel Morgan wrote: Since GNOME is having a bug day, would it be possible that Mono have a Bug Day too? http://live.gnome.org/Bugsquad/BugDays There hasn't been any feedback from several core developers on this point. So I ask the same question again :-). Do you think that it's something that could be help mono development ? The bug squad days are good for GNOME development, one reason is because there are so many developers working from time to time on the code and so many bugs to squash, that everything get a bit messy quickly. Maybe this is not the case for Mono, and thus the idea of a Mono Bug Day is irrelevant. What do you think about this ? Best regards, -- Julien Gilli IDEALX http://www.idealx.com/ ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono Bug Day
Hi, The bug squad days are good for GNOME development, one reason is because there are so many developers working from time to time on the code and so many bugs to squash, that everything get a bit messy quickly. Maybe this is not the case for Mono, and thus the idea of a Mono Bug Day is irrelevant. What do you think about this ? It is probably a good idea, but how many are actually developing Mono? I know there are hundreds contributing to Gnome which makes bug days do-able. That said, an alternate idea would be once Mono is in official beta, that for a week all the website, documentation and other non-programming bits are sorted out properly. Given the mono stuff I have online and how much I'm actually using it, I'm happy to do website - the current one is really badly out of date and somewhat haphazard (IMHO). While the wiki style is an improvement, having material which is correct is more important. I'd personally love to see an open source version of MSDN just to hack MS off! 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
Re: [Mono-list] Mono Bug Day
Daniel Morgan wrote: Since GNOME is having a bug day, would it be possible that Mono have a Bug Day too? FWIW, it sounds like a good idea to me. I would be glad to get involved if such a thing is set up. Best regards, -- Julien Gilli IDEALX http://www.idealx.com/ ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono Bug Day
Hi, Since GNOME is having a bug day, would it be possible that Mono have a Bug Day too? FWIW, it sounds like a good idea to me. I would be glad to get involved if such a thing is set up. It does sound good - I think I've found some really fun ones which I'm just checking before making them lizard food. TTFN Paul -- Logic, my dear Zoe, is merely the ability to be wrong with authority - Dr Who ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
