From paulspencer at mindspring.com Thu Dec 1 17:43:46 2005 From: paulspencer at mindspring.com (Paul Spencer) Date: Thu, 01 Dec 2005 12:43:46 -0500 Subject: FYI: The RoadMap is almost 1 year old. Message-ID: <438F3652.3050703@mindspring.com> The Milestone section if this pave is almost 1 year out of date. http://www.bugzilla.org/status/roadmap.html Paul Spencer From justdave at bugzilla.org Thu Dec 1 17:47:30 2005 From: justdave at bugzilla.org (David Miller) Date: Thu, 01 Dec 2005 12:47:30 -0500 Subject: FYI: The RoadMap is almost 1 year old. In-Reply-To: <438F3652.3050703@mindspring.com> References: <438F3652.3050703@mindspring.com> Message-ID: <438F3732.1060908@bugzilla.org> Paul Spencer wrote on 12/1/05 12:43 PM: > The Milestone section if this pave is almost 1 year out of date. > http://www.bugzilla.org/status/roadmap.html Yeah, I was noticing that the other day myself. I'll try to get it updated as soon as the sysadmin rush from the Firefox 1.5 release blows over. (probably this weekend or early next week) -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From LpSolit at gmail.com Thu Dec 1 22:51:06 2005 From: LpSolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Thu, 01 Dec 2005 23:51:06 +0100 Subject: QA tests: Selenium on landfill is up and running Message-ID: <438F7E5A.40102@gmail.com> Since my email to qa at bugzilla.org last week, we have made a lot of progress with our Selenium installation on landfill. Now, the installation is complete and is running properly. As not everybody has joined #qa-bugzilla yet, here is a brief summary of the last news from the QA world: - What is Selenium? It's a great tool to automatically test Bugzilla. While tests found in bugzilla/t mainly test the syntax of files only, Selenium allows you to test Bugzilla as if you were playing with it from your web browser yourself.... except that you are sleeping while tests are being done *automatically*. ;) - http://landfill.bugzilla.org/selenium/bugzilla/index.html is our start page to all Bugzilla installations being tested. You can freely test them from your web browser by following one of the links. Note that I am talking about QA tests, which have nothing to do with tests already run by tinderboxes, see my previous comment. - I finally reached to make Selenium work from runtests.pl, thanks to the author of Test::WWW::Selenium who gave me valuable advice. runtests.pl is now running from a VNC session and its output is available at: http://landfill.bugzilla.org/selenium/bugzilla/test/qa-output.log This link is also available from the page mentioned above. Don't be surprised if you see only a very small set of tests available so far. I first had to complete the Selenium installation before being able to write QA scripts. - I have written a page about the QA team and its work on MozillaWiki: http://wiki.mozilla.org/Bugzilla:QA This page contains many useful information for those who want to help writing some scripts. The more QA tests we have, the less we will have to do manually. - And finally, I want to mention bug 317695 on bugzilla.mozilla.org where you can find some useful scripts to help you writing scripts. That's also the place to submit yours. No need to request approval, I will manage them myself (I don't expect to see a lot of contribution outside the QA team anyway; am I wrong?). - And if you have questions, remarks or suggestions, you can find me on IRC in #qa-bugzilla. Regards, Frederic Buclin (LpSolit) From micklweiss at gmx.net Fri Dec 2 20:55:20 2005 From: micklweiss at gmx.net (Mick Weiss) Date: Fri, 02 Dec 2005 15:55:20 -0500 Subject: Another way to map users to LDAP In-Reply-To: <436E7395.1070803@inria.fr> References: <436E7395.1070803@inria.fr> Message-ID: <4390B4B8.6060003@gmx.net> Why not submit a patch :-) - Mick Guillaume Rousse wrote: > Current LDAP implementation use mail LDAP attribute from user login to > compute its bugzilla ID. This is quite fine on single-datastore > bugzilla system, but on multiple-datastore bugzilla, some users may > have to use different ids on different bugzilla. For instance, user X > involved in projects foo and bar would like to be X at foo.org in foo > project's bugzilla, and X at bar.org on bar project's bugzilla. > > I have a personal patch that completly replaced original bugzilla LDAP > mapping with this system. However, if there is any interest, I could > rewrite it so as to offer either a choice between the two different > mapping methods. > From mkanat at bugzilla.org Sat Dec 3 23:12:42 2005 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sat, 03 Dec 2005 15:12:42 -0800 Subject: Target For Next Release: December 14 Message-ID: <1133651563.3400.10.camel@localhost.localdomain> Hey there. So, I'd like to do the next release on December 14. That probably means we need all the patches reviewed and checked-in by December 10th at the latest, so that QA can do any testing they need to. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From LpSolit at gmail.com Sat Dec 3 23:24:13 2005 From: LpSolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Sun, 04 Dec 2005 00:24:13 +0100 Subject: Target For Next Release: December 14 In-Reply-To: <1133651563.3400.10.camel@localhost.localdomain> References: <1133651563.3400.10.camel@localhost.localdomain> Message-ID: <4392291D.7010909@gmail.com> Max Kanat-Alexander a ?crit : > Hey there. So, I'd like to do the next release on December 14. > > That probably means we need all the patches reviewed and checked-in by > December 10th at the latest, so that QA can do any testing they need to. Most blockers haven't a patch yet or their patches have been rejected. And those who have a patch are waiting for days/weeks... So: 1) we won't be ready in one week; 2) I disagree to release 2.20.1 with blockers still open (by definition of a blocker); 3) QA testing requires more than 4 days (especially because we are all pretty busy these days)! LpSolit From justdave at bugzilla.org Sun Dec 4 01:02:13 2005 From: justdave at bugzilla.org (David Miller) Date: Sat, 03 Dec 2005 20:02:13 -0500 Subject: Target For Next Release: December 14 In-Reply-To: <1133651563.3400.10.camel@localhost.localdomain> References: <1133651563.3400.10.camel@localhost.localdomain> Message-ID: <43924015.3050700@bugzilla.org> Max Kanat-Alexander wrote on 12/3/05 6:12 PM: > Hey there. So, I'd like to do the next release on December 14. > > That probably means we need all the patches reviewed and checked-in by > December 10th at the latest, so that QA can do any testing they need to. There's a few of those bugs that are mine, and there's no way I'm going to have them ready that soon. Although it'd be nice to try. Given the proximity of weekends I think between the 10th and the 14th sounds like a good goal for trying to get the blockers in. Then shoot for actually releasing on the 21st or so. Gives us a week for QA to test and everyone else to work on the release announcements, web site updates, etc. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From bugzilla at colinogilvie.co.uk Sun Dec 4 01:20:05 2005 From: bugzilla at colinogilvie.co.uk (Colin Ogilvie) Date: Sun, 04 Dec 2005 01:20:05 +0000 Subject: Target For Next Release: December 14 In-Reply-To: <1133651563.3400.10.camel@localhost.localdomain> References: <1133651563.3400.10.camel@localhost.localdomain> Message-ID: <43924445.8020109@colinogilvie.co.uk> Max Kanat-Alexander wrote: > Hey there. So, I'd like to do the next release on December 14 Which version(s) would you be intending releasing then? Colin From LpSolit at gmail.com Sun Dec 4 01:25:04 2005 From: LpSolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Sun, 04 Dec 2005 02:25:04 +0100 Subject: Target For Next Release: December 14 In-Reply-To: <43924445.8020109@colinogilvie.co.uk> References: <1133651563.3400.10.camel@localhost.localdomain> <43924445.8020109@colinogilvie.co.uk> Message-ID: <43924570.3090606@gmail.com> > Which version(s) would you be intending releasing then? AFAIK, 2.21.2, 2.20.1, 2.18.5 and 2.16.11 (due to security bugs). From mkanat at bugzilla.org Sun Dec 4 05:30:57 2005 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sat, 03 Dec 2005 21:30:57 -0800 Subject: Target For Next Release: December 14 In-Reply-To: <43924015.3050700@bugzilla.org> References: <1133651563.3400.10.camel@localhost.localdomain> <43924015.3050700@bugzilla.org> Message-ID: <1133674258.3229.0.camel@es-lappy> On Sat, 2005-12-03 at 20:02 -0500, David Miller wrote: > Given the proximity of weekends I think between the 10th and the 14th > sounds like a good goal for trying to get the blockers in. Then shoot > for actually releasing on the 21st or so. Gives us a week for QA to > test and everyone else to work on the release announcements, web site > updates, etc. OK, I agree. :-) The 21st sounds perfect. :-) -Max -- http://www.everythingsolved.com/ Everything Solved: Competent, Friendly Bugzilla and Linux Services From mkanat at bugzilla.org Sun Dec 4 14:16:06 2005 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sun, 04 Dec 2005 06:16:06 -0800 Subject: The Developers' Guide: New and Improved! Message-ID: <1133705766.3669.7.camel@es-lappy> Hey hey. So, I spent several days a few weeks ago updating the Developers' Guide so that it is up-to-date with our current coding standards. I also added some big new sections on SQL, to help out people doing cross-DB development work, and to help people understand JOIN statements. You can see it here: http://www.bugzilla.org/docs/developer.html Let me know if you have any good ideas for things that could be added! :-) -Max -- http://www.everythingsolved.com/ Everything Solved: Competent, Friendly Bugzilla and Linux Services From mkgnu at gmx.net Mon Dec 5 18:24:08 2005 From: mkgnu at gmx.net (Kristis Makris) Date: Mon, 05 Dec 2005 11:24:08 -0700 Subject: [Fwd: Scmbug problem] Message-ID: <1133807048.2743.7.camel@syd.mkgnu.net> Aleksey, have you seen anything like this before ? Bugzilla/DB.pm line 82 is the dbh->prepare statement from Bugzilla 2.20. sub SendSQL { my ($str) = @_; $_current_sth = Bugzilla->dbh->prepare($str); $_current_sth->execute; # This is really really ugly, but its what we get for not doing # error checking for 5 years. See bug 189446 and bug 192531 $_current_sth->{RaiseError} = 0; undef $_fetchahead; } I'm suspecting the 2.20 backend in Scmbug should stop using SendSQL. Bugzilla devs: what should be used instead of SendSql ? Thanks, Kristis -------------- next part -------------- An embedded message was scrubbed... From: "Christoph Mueller" Subject: Scmbug problem Date: Mon, 5 Dec 2005 15:01:50 +0100 Size: 4169 URL: From mkanat at bugzilla.org Mon Dec 5 20:06:25 2005 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 05 Dec 2005 12:06:25 -0800 Subject: [Fwd: Scmbug problem] In-Reply-To: <1133807048.2743.7.camel@syd.mkgnu.net> References: <1133807048.2743.7.camel@syd.mkgnu.net> Message-ID: <1133813185.3175.7.camel@es-lappy> On Mon, 2005-12-05 at 11:24 -0700, Kristis Makris wrote: > Bugzilla devs: what should be used instead of SendSql ? Hey Kristis. Probably the best thing to read would be: http://www.bugzilla.org/docs/developer.html#sql-sendreceive The whole Developer's Guide was updated recently, so it reflects a lot of good, modern recommendations for Bugzilla code. The whole "SQL" section is pretty much new, including the part I linked to. -Max -- http://www.everythingsolved.com/ Everything Solved: Competent, Friendly Bugzilla and Linux Services From gerv at mozilla.org Tue Dec 6 10:26:04 2005 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 06 Dec 2005 10:26:04 +0000 Subject: Target For Next Release: December 14 In-Reply-To: <43924570.3090606@gmail.com> References: <1133651563.3400.10.camel@localhost.localdomain> <43924445.8020109@colinogilvie.co.uk> <43924570.3090606@gmail.com> Message-ID: <4395673C.2070800@mozilla.org> Fr?d?ric Buclin wrote: >> Which version(s) would you be intending releasing then? > > AFAIK, 2.21.2, 2.20.1, 2.18.5 and 2.16.11 (due to security bugs). When are we dropping support for 2.16? Gerv From LpSolit at gmail.com Tue Dec 6 16:17:49 2005 From: LpSolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Tue, 06 Dec 2005 17:17:49 +0100 Subject: Target For Next Release: December 14 In-Reply-To: <4395673C.2070800@mozilla.org> References: <1133651563.3400.10.camel@localhost.localdomain> <43924445.8020109@colinogilvie.co.uk> <43924570.3090606@gmail.com> <4395673C.2070800@mozilla.org> Message-ID: <4395B9AD.90908@gmail.com> > When are we dropping support for 2.16? As soon as 2.22 is released. From mkgnu at gmx.net Wed Dec 7 04:49:56 2005 From: mkgnu at gmx.net (Kristis Makris) Date: Tue, 06 Dec 2005 21:49:56 -0700 Subject: [Fwd: Scmbug problem] In-Reply-To: <1133813185.3175.7.camel@es-lappy> References: <1133807048.2743.7.camel@syd.mkgnu.net> <1133813185.3175.7.camel@es-lappy> Message-ID: <1133930996.2794.21.camel@syd.mkgnu.net> Hi Max, On Mon, 2005-12-05 at 12:06 -0800, Max Kanat-Alexander wrote: > http://www.bugzilla.org/docs/developer.html#sql-sendreceive > > The whole Developer's Guide was updated recently, so it reflects a lot > of good, modern recommendations for Bugzilla code. The whole "SQL" > section is pretty much new, including the part I linked to. Thanks a lot! I was not even aware of it. A possible correction; I think in the link you've posted this: my $sth->execute("foobar"); should be changed into: $sth->execute("foobar"); Another confirmation question. The guide says this went into effect in 2.17.1. I haven't received any such complaints about the Windows version of Scmbug giving errors while supporting 2.18, so I'm wondering if anything else changed after 2.17.1 (e.g. more in the 2.19.x line) that could possible lead to errors. Just being careful... I changed Scmbug to use the standard DBI functions for the 2.20 backend, but I'm wondering if I should have it use them for 2.18.x too. From ralf.beckers at chipvision.com Wed Dec 7 08:52:16 2005 From: ralf.beckers at chipvision.com (Ralf Beckers) Date: Wed, 07 Dec 2005 09:52:16 +0100 Subject: Style of Resolved later/remind Message-ID: <4396A2C0.3030609@chipvision.com> Ahoi, we create lists of bug dependency trees to show them to our customers. Resolved/later bugs appear in a strike through style and are considered to be finished by them. Since this is not true, I'd like to modify the style. Where should I have a look at? The span class is bz_closed, I think, this must changed to s.th. like bz_later and then added to a stylesheet. Thanks for any hints, Ralf -- Ralf Beckers Lead Development Engineer ChipVision Design Systems AG Fritz-Bock-Strasse 5 - 26121 Oldenburg - Germany phone +49-441-35042-360 fax +49-441-35042-350 email ralf.beckers at chipvision.com www.chipvision.com From gerv at mozilla.org Thu Dec 8 11:51:01 2005 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 08 Dec 2005 11:51:01 +0000 Subject: Style of Resolved later/remind In-Reply-To: <4396A2C0.3030609@chipvision.com> References: <4396A2C0.3030609@chipvision.com> Message-ID: <43981E25.1020102@mozilla.org> Ralf Beckers wrote: Ralf, This sort of question is best addresses through the channels listed on http://www.bugzilla.org/support/. > we create lists of bug dependency trees to show them to our customers. > Resolved/later bugs appear in a strike through style and are considered > to be finished by them. > > Since this is not true, I'd like to modify the style. This is one of the reasons why "RESOLVED/LATER" is deprecated and, I believe, not enabled in new installations of Bugzilla. It's a bad resolution; if the bug is going to be fixed later, it should remain open. > Where should I > have a look at? I'm not sure it's possible to style different sorts of RESOLVED bug in different ways. Another reason not to use LATER :-) Gerv From luis.villa at gmail.com Thu Dec 8 13:54:03 2005 From: luis.villa at gmail.com (Luis Villa) Date: Thu, 8 Dec 2005 08:54:03 -0500 Subject: Style of Resolved later/remind In-Reply-To: <43981E25.1020102@mozilla.org> References: <4396A2C0.3030609@chipvision.com> <43981E25.1020102@mozilla.org> Message-ID: <2cb10c440512080554x2c56695evee8929a6fbddd2f6@mail.gmail.com> On 12/8/05, Gervase Markham wrote: > Ralf Beckers wrote: > > Ralf, > > This sort of question is best addresses through the channels listed on > http://www.bugzilla.org/support/. > > > we create lists of bug dependency trees to show them to our customers. > > Resolved/later bugs appear in a strike through style and are considered > > to be finished by them. > > > > Since this is not true, I'd like to modify the style. > > This is one of the reasons why "RESOLVED/LATER" is deprecated and, I > believe, not enabled in new installations of Bugzilla. Nope. This is still there: https://bugzilla.mozilla.org/show_bug.cgi?id=13534 We've been knowingly shipping bugzilla with this embarassingly broken default configuration since 1999. Luis From ralf.beckers at chipvision.com Thu Dec 8 14:25:40 2005 From: ralf.beckers at chipvision.com (Ralf Beckers) Date: Thu, 08 Dec 2005 15:25:40 +0100 Subject: Style of Resolved later/remind In-Reply-To: <2cb10c440512080554x2c56695evee8929a6fbddd2f6@mail.gmail.com> References: <4396A2C0.3030609@chipvision.com> <43981E25.1020102@mozilla.org> <2cb10c440512080554x2c56695evee8929a6fbddd2f6@mail.gmail.com> Message-ID: <43984264.4050405@chipvision.com> Hi, Luis Villa wrote: > Nope. This is still there: > https://bugzilla.mozilla.org/show_bug.cgi?id=13534 > We've been knowingly shipping bugzilla with this embarassingly broken > default configuration since 1999. So we can upgrade our 2.19.1 to 2.20.1 if it's released without loosing resolved/fixed? This would be great :) We have to think about another way of marking bugs as not being actively processed though. Do you have a bug report, where you already had the discussion, how to handle such cases? Ralf -- Ralf Beckers Lead Development Engineer ChipVision Design Systems AG Fritz-Bock-Strasse 5 - 26121 Oldenburg - Germany phone +49-441-35042-360 fax +49-441-35042-350 email ralf.beckers at chipvision.com www.chipvision.com From luis.villa at gmail.com Thu Dec 8 14:43:03 2005 From: luis.villa at gmail.com (Luis Villa) Date: Thu, 8 Dec 2005 09:43:03 -0500 Subject: Style of Resolved later/remind In-Reply-To: <43984264.4050405@chipvision.com> References: <4396A2C0.3030609@chipvision.com> <43981E25.1020102@mozilla.org> <2cb10c440512080554x2c56695evee8929a6fbddd2f6@mail.gmail.com> <43984264.4050405@chipvision.com> Message-ID: <2cb10c440512080643o2ce8d19ald76596727de01f0c@mail.gmail.com> On 12/8/05, Ralf Beckers wrote: > Hi, > > Luis Villa wrote: > > Nope. This is still there: > > https://bugzilla.mozilla.org/show_bug.cgi?id=13534 > > We've been knowingly shipping bugzilla with this embarassingly broken > > default configuration since 1999. > > So we can upgrade our 2.19.1 to 2.20.1 if it's released without loosing > resolved/fixed? This would be great :) We have to think about another > way of marking bugs as not being actively processed though. > > Do you have a bug report, where you already had the discussion, how to > handle such cases? 'target milestone: future' I believe that bug discusses it in some detail. Luis From justdave at bugzilla.org Thu Dec 8 16:56:24 2005 From: justdave at bugzilla.org (David Miller) Date: Thu, 08 Dec 2005 08:56:24 -0800 Subject: Style of Resolved later/remind In-Reply-To: <2cb10c440512080554x2c56695evee8929a6fbddd2f6@mail.gmail.com> References: <4396A2C0.3030609@chipvision.com> <43981E25.1020102@mozilla.org> <2cb10c440512080554x2c56695evee8929a6fbddd2f6@mail.gmail.com> Message-ID: <439865B8.3030305@bugzilla.org> Luis Villa wrote on 12/8/05 5:54 AM: > On 12/8/05, Gervase Markham wrote: >> Ralf Beckers wrote: >> >> Ralf, >> >> This sort of question is best addresses through the channels listed on >> http://www.bugzilla.org/support/. >> >>> we create lists of bug dependency trees to show them to our customers. >>> Resolved/later bugs appear in a strike through style and are considered >>> to be finished by them. >>> >>> Since this is not true, I'd like to modify the style. >> This is one of the reasons why "RESOLVED/LATER" is deprecated and, I >> believe, not enabled in new installations of Bugzilla. > > Nope. This is still there: > > https://bugzilla.mozilla.org/show_bug.cgi?id=13534 > > We've been knowingly shipping bugzilla with this embarassingly broken > default configuration since 1999. Fixing that was waiting on custom resolutions, I believe, which we either now have or are about to (it's just recently been worked on) -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From luis.villa at gmail.com Thu Dec 8 17:19:33 2005 From: luis.villa at gmail.com (Luis Villa) Date: Thu, 8 Dec 2005 12:19:33 -0500 Subject: Style of Resolved later/remind In-Reply-To: <439865B8.3030305@bugzilla.org> References: <4396A2C0.3030609@chipvision.com> <43981E25.1020102@mozilla.org> <2cb10c440512080554x2c56695evee8929a6fbddd2f6@mail.gmail.com> <439865B8.3030305@bugzilla.org> Message-ID: <2cb10c440512080919s70df5998x84d082c7ceba65f3@mail.gmail.com> On 12/8/05, David Miller wrote: > Luis Villa wrote on 12/8/05 5:54 AM: > > On 12/8/05, Gervase Markham wrote: > >> Ralf Beckers wrote: > >> > >> Ralf, > >> > >> This sort of question is best addresses through the channels listed on > >> http://www.bugzilla.org/support/. > >> > >>> we create lists of bug dependency trees to show them to our customers. > >>> Resolved/later bugs appear in a strike through style and are considered > >>> to be finished by them. > >>> > >>> Since this is not true, I'd like to modify the style. > >> This is one of the reasons why "RESOLVED/LATER" is deprecated and, I > >> believe, not enabled in new installations of Bugzilla. > > > > Nope. This is still there: > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=13534 > > > > We've been knowingly shipping bugzilla with this embarassingly broken > > default configuration since 1999. > > Fixing that was waiting on custom resolutions, I believe, > which we > either now have or are about to (it's just recently been worked on) Great if it actually comes through this time. I'd strongly suggest that the gross but effective patches I attached to the bug earlier this year be applied to 2.22 if the custom resolutions do not land by that time. This bug is just embarassing. Luis From mkanat at bugzilla.org Fri Dec 9 20:32:54 2005 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 09 Dec 2005 12:32:54 -0800 Subject: The Reviewers List Message-ID: <1134160375.12428.18.camel@localhost.localdomain> Hey. So, I just wanted to make sure the Reviewers List is up-to-date. Anybody want to put their name anywhere on it, or remove their name from it anywhere? Wicked just allowed me to add him in a few places, so you can see that that's been updated. I think some of the newer libraries are missing, too. Who wants to take those? http://www.bugzilla.org/docs/reviewer-list.html -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From LpSolit at gmail.com Fri Dec 9 22:40:05 2005 From: LpSolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Fri, 09 Dec 2005 23:40:05 +0100 Subject: The Reviewers List In-Reply-To: <1134160375.12428.18.camel@localhost.localdomain> References: <1134160375.12428.18.camel@localhost.localdomain> Message-ID: <439A07C5.20600@gmail.com> > Hey. So, I just wanted to make sure the Reviewers List is up-to-date. > Anybody want to put their name anywhere on it, or remove their name from > it anywhere? Wicked just allowed me to add him in a few places, so you > can see that that's been updated. All librairies are there, I added them already. And I think you should ask reviewers@, not developers at . From justdave at bugzilla.org Sat Dec 10 02:58:28 2005 From: justdave at bugzilla.org (David Miller) Date: Fri, 09 Dec 2005 18:58:28 -0800 Subject: The Reviewers List In-Reply-To: <1134160375.12428.18.camel@localhost.localdomain> References: <1134160375.12428.18.camel@localhost.localdomain> Message-ID: <439A4454.1030907@bugzilla.org> Max Kanat-Alexander wrote on 12/9/05 12:32 PM: > Hey. So, I just wanted to make sure the Reviewers List is up-to-date. > Anybody want to put their name anywhere on it, or remove their name from > it anywhere? Wicked just allowed me to add him in a few places, so you > can see that that's been updated. Besides adding your name to files, I seem to recall adding privs to a few folks in recent months and don't remember if I added you to the list at the top. So if you think you're a reviewer and you're not listed in the list of reviewers at the top, let me know. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From kevin.benton at amd.com Mon Dec 12 15:53:15 2005 From: kevin.benton at amd.com (Benton, Kevin) Date: Mon, 12 Dec 2005 07:53:15 -0800 Subject: The Reviewers List Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A42036E97A7@ssvlexmb2.amd.com> Tru: <- raises hand. :) --- Kevin Benton Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator Personal Computing Systems Group Advanced Micro Devices The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. > -----Original Message----- > From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] > On Behalf Of David Miller > Sent: Friday, December 09, 2005 7:58 PM > To: developers at bugzilla.org > Subject: Re: The Reviewers List > > Max Kanat-Alexander wrote on 12/9/05 12:32 PM: > > Hey. So, I just wanted to make sure the Reviewers List is up-to- > date. > > Anybody want to put their name anywhere on it, or remove their name from > > it anywhere? Wicked just allowed me to add him in a few places, so you > > can see that that's been updated. > > Besides adding your name to files, I seem to recall adding privs to a > few folks in recent months and don't remember if I added you to the list > at the top. So if you think you're a reviewer and you're not listed in > the list of reviewers at the top, let me know. > > -- > Dave Miller http://www.justdave.net/ > System Administrator, Mozilla Corporation http://www.mozilla.com/ > Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ > - > To view or change your list settings, click here: > From justdave at bugzilla.org Tue Dec 13 08:52:27 2005 From: justdave at bugzilla.org (David Miller) Date: Tue, 13 Dec 2005 03:52:27 -0500 Subject: The sudo feature Message-ID: <439E8BCB.7000409@bugzilla.org> I discussed this on IRC a bit tonight, but mentioning it here as well for a little wider audience. The sudo feature is making me damn nervous. Just the kinds of bugs I'm seeing going by, and the particular places in the code that are getting touched by the patches fixing them. The authentication code is getting hacked to hell and back, and I'm just scared we're going to wind up introducing more security bugs that we haven't even thought of. At this point, I'm kind of regretting ever approving that feature. But it's a bit late for that now I guess. Just everyone keep a vigilant eye out on that code... pound the heck out of it, and let's make sure it really is safe. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From myk at mozilla.org Tue Dec 13 09:07:39 2005 From: myk at mozilla.org (Myk Melez) Date: Tue, 13 Dec 2005 01:07:39 -0800 Subject: The sudo feature In-Reply-To: <439E8BCB.7000409@bugzilla.org> References: <439E8BCB.7000409@bugzilla.org> Message-ID: <439E8F5B.7030006@mozilla.org> David Miller wrote: > At this point, I'm kind of regretting ever approving that feature. > But it's a bit late for that now I guess. I wouldn't say it's too late to back it out. After all, we haven't shipped it in a release yet. If it hasn't been baked enough, it may be wise to remove it for 2.22 and check it back in for 2.24. Or, since code hooks are ready to land as soon as the tree opens for 2.24 checkins, we could reconstitute it as an extension and bake it there until popularity and experience make it ready for inclusion into the mainline code. -myk From bugreport at peshkin.net Tue Dec 13 10:43:46 2005 From: bugreport at peshkin.net (Joel Peshkin) Date: Tue, 13 Dec 2005 02:43:46 -0800 Subject: The sudo feature In-Reply-To: <439E8F5B.7030006@mozilla.org> References: <439E8BCB.7000409@bugzilla.org> <439E8F5B.7030006@mozilla.org> Message-ID: <439EA5E2.3020609@peshkin.net> Myk Melez wrote: > David Miller wrote: > >> At this point, I'm kind of regretting ever approving that feature. >> But it's a bit late for that now I guess. > > I wouldn't say it's too late to back it out. After all, we haven't > shipped it in a release yet. If it hasn't been baked enough, it may > be wise to remove it for 2.22 and check it back in for 2.24. Or, > since code hooks are ready to land as soon as the tree opens for 2.24 > checkins, we could reconstitute it as an extension and bake it there > until popularity and experience make it ready for inclusion into the > mainline code. > Except that ... if you really look at the code, it only touches the code in a very few places and only if enabled. It is vital for both testing sites and for testing bugzilla itself. Justdave is over-reacting a tad. From gerv at mozilla.org Tue Dec 13 11:02:44 2005 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 13 Dec 2005 11:02:44 +0000 Subject: The sudo feature In-Reply-To: <439EA5E2.3020609@peshkin.net> References: <439E8BCB.7000409@bugzilla.org> <439E8F5B.7030006@mozilla.org> <439EA5E2.3020609@peshkin.net> Message-ID: <439EAA54.4050708@mozilla.org> Joel Peshkin wrote: > Except that ... if you really look at the code, it only touches the code > in a very few places and only if enabled. It is vital for both testing > sites and for testing bugzilla itself. Justdave is over-reacting a tad. We seem to have managed without it for several years... what makes it so vital now? And is there a write-up or design document for this feature anywhere, so I can get up to speed? This is the first time it's been mentioned on this list... Gerv From djm at mindrot.org Tue Dec 13 11:14:16 2005 From: djm at mindrot.org (Damien Miller) Date: Tue, 13 Dec 2005 22:14:16 +1100 Subject: The sudo feature In-Reply-To: <439EAA54.4050708@mozilla.org> References: <439E8BCB.7000409@bugzilla.org> <439E8F5B.7030006@mozilla.org> <439EA5E2.3020609@peshkin.net> <439EAA54.4050708@mozilla.org> Message-ID: <439EAD08.7080906@mindrot.org> Gervase Markham wrote: > And is there a write-up or design document for this feature anywhere, so > I can get up to speed? or even a bug number? From bugreport at peshkin.net Tue Dec 13 11:28:10 2005 From: bugreport at peshkin.net (Joel Peshkin) Date: Tue, 13 Dec 2005 03:28:10 -0800 Subject: The sudo feature In-Reply-To: <439EAD08.7080906@mindrot.org> References: <439E8BCB.7000409@bugzilla.org> <439E8F5B.7030006@mozilla.org> <439EA5E2.3020609@peshkin.net> <439EAA54.4050708@mozilla.org> <439EAD08.7080906@mindrot.org> Message-ID: <439EB04A.8060603@peshkin.net> Damien Miller wrote: >Gervase Markham wrote: > > > >>And is there a write-up or design document for this feature anywhere, so >>I can get up to speed? >> >> > >or even a bug number? >- > > 204498 From LpSolit at gmail.com Tue Dec 13 19:47:22 2005 From: LpSolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Tue, 13 Dec 2005 20:47:22 +0100 Subject: The sudo feature In-Reply-To: <439E8F5B.7030006@mozilla.org> References: <439E8BCB.7000409@bugzilla.org> <439E8F5B.7030006@mozilla.org> Message-ID: <439F254A.3010900@gmail.com> > I wouldn't say it's too late to back it out. I see no reason to back it out. Now that developers are warned, we can honestly hope that any major security hole will be caught before 2.22rc1 (2.20.1 will not have this feature). We will also pay some special attention to this feature during our next QA cycle. LpSolit From djm at mindrot.org Wed Dec 14 04:57:10 2005 From: djm at mindrot.org (Damien Miller) Date: Wed, 14 Dec 2005 15:57:10 +1100 (EST) Subject: contrib/bzdbcopy.pl Message-ID: Hi, The contrib/bzdbcopy.pl script doesn't seem to be in the Bugzilla_Stable CVS branch: > # cvs up -r Bugzilla_Stable contrib/bzdbcopy.pl > # ls -l contrib/bzdbcopy.pl > ls: contrib/bzdbcopy.pl: No such file or directory Is this deliberate? If not, can it be corrected? -d From justdave at bugzilla.org Wed Dec 14 05:05:38 2005 From: justdave at bugzilla.org (David Miller) Date: Wed, 14 Dec 2005 00:05:38 -0500 Subject: contrib/bzdbcopy.pl In-Reply-To: References: Message-ID: <439FA822.2000001@bugzilla.org> Damien Miller wrote on 12/13/05 11:57 PM: > Hi, > > The contrib/bzdbcopy.pl script doesn't seem to be in the Bugzilla_Stable > CVS branch: > >> # cvs up -r Bugzilla_Stable contrib/bzdbcopy.pl >> # ls -l contrib/bzdbcopy.pl >> ls: contrib/bzdbcopy.pl: No such file or directory > > Is this deliberate? If not, can it be corrected? It's deliberate. There hasn't been any stable release containing it yet. It was checked in after the last release. It did get checked into the 2.20 branch though, so if you pull BUGZILLA-2_20-BRANCH you'll get it. Bugzilla_Stable won't include it until 2.20.1 is released (or 2.22, whichever comes first) -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From karl at kornel.name Wed Dec 14 06:52:59 2005 From: karl at kornel.name (A. Karl Kornel) Date: Wed, 14 Dec 2005 01:52:59 -0500 Subject: The sudo feature In-Reply-To: <439E8BCB.7000409@bugzilla.org> References: <439E8BCB.7000409@bugzilla.org> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Dec 13, 2005, at 3:52 AM, David Miller wrote: > I discussed this on IRC a bit tonight, but mentioning it here as > well for a little wider audience. > > The sudo feature is making me damn nervous. Just the kinds of bugs > I'm seeing going by, and the particular places in the code that are > getting touched by the patches fixing them. The authentication > code is getting hacked to hell and back, and I'm just scared we're > going to wind up introducing more security bugs that we haven't > even thought of. I have remained pretty quiet throughout this discussion, and most of what I would say has been said already. However, I do want to say a few things now. Although this may turn out to be false, I think that much of the suspense over this feature is a bit overdone. If you look at all of the patches related to user impersonation, Bugzilla is not touched in as many areas as you would think. In fact, up to now only one area of Bugzilla has needed to be modified to work with this feature (user prefs, see bug 313679). Most of the bugs only touch code introduced by bug 204498 (the initial implementation of user impersonation), and many of the bugs address issues that (depending on your views) are not critical issues. Now that I mention it, I am not sure if anyone has actually come up with a list of bugs that were filed as a result of the landing of bug 204498. Since it might be a good idea to do that, I am now going to provide a list of bugs that were filed as a result of the introduction of user impersonation, along with a description of what (in my view) the bug actually affected. To come up with the list, I searched for Bugzilla bugs that were RESOLVED after 2005-10-13 (when bug 204498 landed), where I was the assignee, the reporter, or on the CC list. That gave me a number of bugs, including the following (the URLs appear after my signature at the end of the email): Bug 204498: Add su (setuser/sudo/impersonate) function This, of course, is the big one. However, it does not seem as big as expected for the impact it produces, especially when you consider that more than a third of the patch is template code (with appropriate filters) and documentation. In fact I do not actually touch any of the authentication code at all (that is, I did not modify any files in the Bugzilla::Auth space). The code that does the work is in relogin.cgi and Bugzilla.pm (the login subroutine). Checksetup was touched to define two new system groups (with predefined membership), and Bugzilla::Template was touched to define a new template directive function. The code in Bugzilla.pm is relatively straightforward. I have a new function to return the identity of the impersonator, and I have a new function to convert the current session into an sudo session (used when sessions are being started/ended). The login sub experienced the biggest change, as I now begin an impersonation ONLY if a number of important tests are passed (which should be pretty clear from the code and the comments in the bug). I do not even attempt to begin/ resume a sudo session if the user is not authenticated. I also knew that many people would be interested in this, so I tried to comment liberally, and to keep the POD up-to-date. Bug 312386: Checksetup fails to check for existing group_group_map for new admins Bug 312406: Checksetup fails to check for existing group_group_map for Bugzilla <2.17 These two bugs came about as a result of the landing of bug 204498, so I thought I'd mention them here. It appeared that bug 204498 was the first time that someone had created a new system group and immediately set up initial group memberships. This caused checksetup to crash in certain situations. These two bugs fixed that problem (and led me to adopt the practice of running the full checksetup tinderbox test suite on all patches I am about to check in). Bug 312437: Do not display the "Impersonate this user" link when the user is in the bz_sudo_protect group This is a bit of a convenience thing, really. If you try to impersonate a user who is protected from impersonation, an error will be thrown (this has always been true). By removing the "Impersonate this user" link from the pages of protected users, the end result is the same (you are not able to begin a session), but it is brought on a few steps earlier. Bug 312439: The user being impersonated has "moral" rights to keep informed This was a simple enough bug to address, but raises moral issues that are not so simple. Maybe it is the moral issues that make this bug so problematic? There is support for not providing notification: When you use the `su` command in *nix to log in as someone else, should they be notified (yes, I know that this is not *nix)? When you remove a Bugzilla user from one or more groups, should they be notified? I decided to err on the side of notification, since it is much easier to deactivate the feature (by commenting out some code) than it is to properly implement the feature from scratch. Hopefully the fact that this can be easily disabled is enough to mollify the people who would prefer to see this bug marked WONTFIX or WORKSFORME. But how complex was this patch? As with bug 204498, a good-sized portion (in this case, at least half) of the patch was to documentation and templates. The CGI code in the patch was limited to taking the user-provided reason, trimming it down to a reasonable length for a URL, running it through a template, and sending it to the user. The templates included a new plain text template for the email, a modification of the sudo start page to ask for a reason, and the introduction of a new page.cgi "page" explaining what this feature is. You can actually see the "page" in action at . Bug 312441: relogin.cgi allows you to impersonate user accounts you are not allowed to see when 'usevisibilitygroups' is on This bug did two things: It streamlined the initial access checking when sessions are first started, and it includes a visibility check to make sure that the impersonator can see the user being impersonated. The streamlining looks pretty messy in patch form, but looks nice when applied. The visibility check is, in my mind, not really needed, as it should not even need to use visibility restrictions if you are trusted enough to be given access to this feature. However, as has been noted in the bug, this is needed when you have many disparate groups of users on the same installation. Again, I decided to go with the bug, knowing that the visibility check could be turned off in code. Bug 313677: Sudoers without editusers/bless access see no link to sudo page This was a templates-only change. Normally sudo sessions would be started by a link ("Impersonate this user") that appears when you view the information for a particular user in editusers.cgi. However, you need appropriate access to get to that page, and it's possible to not have appropriate access but still have sudo access, so I needed to provide a link somewhere else. Is this UI creep? Maybe. I agree with Myk and Dave (in comments 3 and 4 of the bug) in that it would be nicer to modify editusers to provide a "low-power" version for people who can use the sudo feature but who do not have editusers membership. However, given the current mood surrounding this feature, I am too scared to even file a bug on this, let alone submit a patch. Bug 313679: Changing email address in sudo mode logs user in as impersonated user This is another simple change to counteract a seemingly-big problem. In fact, my original solution was big, before Marc found a very elegant solution to the problem. It may seem that making Bugzilla ignore the login/password provided by CGI is not a good idea, but the parameters are restored after login, and editusers code makes sure that the password entered in the HTML form is checked against the encrypted password in the database. > At this point, I'm kind of regretting ever approving that feature. > But it's a bit late for that now I guess. Just everyone keep a > vigilant eye out on that code... pound the heck out of it, and > let's make sure it really is safe. As has been said already, it's not too late to back it out now, and it could be done (though it would take more than executing a few CVS commands). However, I do not think it should be backed out. Hopefully my comments above gave you a better idea of the scope of the sudo-related bugs that have appeared since bug 204498 landed. This new feature will be going through the normal QA testing process for 2.22, and will also be made available to everyone who decides to try out a 2.22 Release Candidate, not to mention all of the people who may be using it now. Will there be bugs with this feature? Yes. Will there be security bugs because of this? I certainly hope not, as I have been keeping security in my mind while working on this, but I stand ready to address questions as they come up (and as I have been doing on IRC), and I stand ready to work on all bugs found with user impersonation (be they security bugs or not). Later! =================== | A. Karl Kornel | | karl at kornel.name =================== Bug 204498: https://bugzilla.mozilla.org/show_bug.cgi?id=204498 Bug 312386: https://bugzilla.mozilla.org/show_bug.cgi?id=312386 Bug 312406: https://bugzilla.mozilla.org/show_bug.cgi?id=312406 Bug 312437: https://bugzilla.mozilla.org/show_bug.cgi?id=312437 Bug 312439: https://bugzilla.mozilla.org/show_bug.cgi?id=312439 Bug 312441: https://bugzilla.mozilla.org/show_bug.cgi?id=312441 Bug 313677: https://bugzilla.mozilla.org/show_bug.cgi?id=313677 Bug 313679: https://bugzilla.mozilla.org/show_bug.cgi?id=313679 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iQEVAwUBQ5/BTjjU38yKmHhCAQL4mQf/VAlsgDHWOT+/zWhlnhGRC2uKLoiMCn1t Y89+bBOIpcpnfECKnH9YzxwdZTeFnOTfLGzEWViYKKzrD/NxVUgcZyJ1+F8w0XCc vaIg/6oztLDBzya9wvTnUCRwmj+9S+7J1rEv0ct3otRlYrbf8zFpamW+fA/sQi17 wE1mB6KOYsdAjkOqmwqrYbc/u2teZVh8TaIWK79hUl2YfrYTTNLV8o/iJmIgxcJw vQWNonNYYcHyUkBUEEC+SzorqxCcZyalZBAuk6jGORrrguM7dOTmxGs6h6miGYoY 5qBMMLFNwxS7OLKGIND5+Cfdimudl3ZwwGl5U4+kibyKxCNfDjgSXQ== =7JXI -----END PGP SIGNATURE----- From ralf.beckers at chipvision.com Wed Dec 14 08:48:49 2005 From: ralf.beckers at chipvision.com (Ralf Beckers) Date: Wed, 14 Dec 2005 09:48:49 +0100 Subject: bugzilla.org on several blacklists Message-ID: <439FDC71.2030002@chipvision.com> Hi, do you guys know, that you server is listed on some blacklists and messages get marked as spam? e.g. my spamassassin reports: Content analysis details: (6.3 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.8 URIBL_PH_SURBL Contains an URL listed in the PH SURBL blocklist [URIs: bugzilla.org] 1.5 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist [URIs: bugzilla.org] 3.9 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist [URIs: bugzilla.org] Since this spamfilter is very common, it may be of interest for you ... Thanks for bugzilla, Ralf -- Ralf Beckers Lead Development Engineer ChipVision Design Systems AG Fritz-Bock-Strasse 5 - 26121 Oldenburg - Germany phone +49-441-35042-360 fax +49-441-35042-350 email ralf.beckers at chipvision.com www.chipvision.com From justdave at bugzilla.org Wed Dec 14 09:09:45 2005 From: justdave at bugzilla.org (David Miller) Date: Wed, 14 Dec 2005 04:09:45 -0500 Subject: bugzilla.org on several blacklists In-Reply-To: <439FDC71.2030002@chipvision.com> References: <439FDC71.2030002@chipvision.com> Message-ID: <439FE159.1060604@bugzilla.org> Ralf Beckers wrote on 12/14/05 3:48 AM: > do you guys know, that you server is listed on some blacklists and > messages get marked as spam? > > e.g. my spamassassin reports: > > Content analysis details: (6.3 points, 5.0 required) > > pts rule name description > ---- ---------------------- > -------------------------------------------------- > 0.8 URIBL_PH_SURBL Contains an URL listed in the PH SURBL blocklist > [URIs: bugzilla.org] > 1.5 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist > [URIs: bugzilla.org] > 3.9 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist > [URIs: bugzilla.org] > > Since this spamfilter is very common, it may be of interest for you ... Are you sure? I just looked it up on surbl.org and it says we're clean (on every variation of our URLs I could throw at it). -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From ralf.beckers at chipvision.com Wed Dec 14 13:17:46 2005 From: ralf.beckers at chipvision.com (Ralf Beckers) Date: Wed, 14 Dec 2005 14:17:46 +0100 Subject: bugzilla.org on several blacklists In-Reply-To: <439FE159.1060604@bugzilla.org> References: <439FDC71.2030002@chipvision.com> <439FE159.1060604@bugzilla.org> Message-ID: <43A01B7A.1080903@chipvision.com> Hi David, David Miller wrote: >> Since this spamfilter is very common, it may be of interest for you ... > Are you sure? I just looked it up on surbl.org and it says we're clean > (on every variation of our URLs I could throw at it). We use the std. configuration of spamassassin. I didn't check the listing manually, and just looked at the report in my mails. The reports where the only one, so no content was filtered to raise the spam rating (according to spamassassin). Ralf -- Ralf Beckers Lead Development Engineer ChipVision Design Systems AG Fritz-Bock-Strasse 5 - 26121 Oldenburg - Germany phone +49-441-35042-360 fax +49-441-35042-350 email ralf.beckers at chipvision.com www.chipvision.com From gerv at mozilla.org Thu Dec 15 09:31:30 2005 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 15 Dec 2005 09:31:30 +0000 Subject: The sudo feature In-Reply-To: References: <439E8BCB.7000409@bugzilla.org> Message-ID: <43A137F2.9080500@mozilla.org> A. Karl Kornel wrote: > I have remained pretty quiet throughout this discussion, and most of > what I would say has been said already. However, I do want to say a few > things now. One question that occurred to me: if only admins can impersonate other users, what's the point of bz_sudo_protect? After all, if they are admins, they can just go and change the Param value to remove the person they want to impersonate. Gerv From bugreport at peshkin.net Thu Dec 15 09:51:48 2005 From: bugreport at peshkin.net (Joel Peshkin) Date: Thu, 15 Dec 2005 01:51:48 -0800 Subject: The sudo feature In-Reply-To: <43A137F2.9080500@mozilla.org> References: <439E8BCB.7000409@bugzilla.org> <43A137F2.9080500@mozilla.org> Message-ID: <43A13CB4.5080807@peshkin.net> Gervase Markham wrote: > One question that occurred to me: if only admins can impersonate other > users, what's the point of bz_sudo_protect? After all, if they are > admins, they can just go and change the Param value to remove the > person they want to impersonate. Only admins by default. One could take a support or training person and add them to bz_sudo without permitting them to have full admin permissions. From karl at kornel.name Thu Dec 15 10:19:48 2005 From: karl at kornel.name (A. Karl Kornel) Date: Thu, 15 Dec 2005 05:19:48 -0500 Subject: The sudo feature In-Reply-To: <43A137F2.9080500@mozilla.org> References: <439E8BCB.7000409@bugzilla.org> <43A137F2.9080500@mozilla.org> Message-ID: <8AD3457D-2457-40FD-A708-88700756DF47@kornel.name> On Dec 15, 2005, at 4:31 AM, Gervase Markham wrote: > A. Karl Kornel wrote: >> I have remained pretty quiet throughout this discussion, and >> most of what I would say has been said already. However, I do >> want to say a few things now. > > One question that occurred to me: if only admins can impersonate > other users, what's the point of bz_sudo_protect? As Joel basically said, this is all determined by groups, so you could add people to bz_sudo, or just bz_sudo_protect if you want to afford them some protection. > After all, if they are admins, they can just go and change the > Param value to remove the person they want to impersonate. True, they could go and change the groups membership (for anyone with editusers, actually). =================== | A. Karl Kornel | | karl at kornel.name =================== From mkanat at bugzilla.org Thu Dec 15 01:18:29 2005 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 14 Dec 2005 17:18:29 -0800 Subject: Help Out With The Release! Message-ID: <1134609509.4735.7.camel@localhost.localdomain> Hey hey. So, we're quickly approaching a new release of *four* Bugzilla versions, and we could *really* use some help with the release! There's a bunch of stuff that needs to be done in order for us to release Bugzilla, and I've filed bugs for all of it. You can see the list here: https://bugzilla.mozilla.org/showdependencytree.cgi?id=320306 You'll notice that most of them don't have assignees, yet! Anybody can take any of those bugs, and help out with the release. Anybody! If you have any questions, you can just ask me, or see the Release Guide: http://www.bugzilla.org/docs/release.html -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From mkanat at bugzilla.org Tue Dec 20 01:39:55 2005 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 19 Dec 2005 17:39:55 -0800 Subject: Making It Easier To Start Working On Bugzilla Message-ID: <1135042796.3564.29.camel@localhost.localdomain> So, I'm always really happy to have new people working on Bugzilla, but I think that sometimes the barrier-to-entry is a bit too high. Let's work out some ways that we could lower it. Here's some thoughts I had: 1) We don't have any brief, clear documentation on the way that the Bugzilla Project uses Bugzilla, or what our actual development process is. I didn't realize this until I had to actually explain it in IRC the other day, and didn't have any document to refer to. :-) 2) We don't have any way to point new contributors to the bugs that they should work on. It's true that we have the blockers, and that's a good place to start, but there are a lot of other easy bugs that would be a valid place to start off contributing. 3) We don't really have any sort of defined "channel" (in the theoretical sense, not in the IRC sense) for new contributors to travel in. That is, we don't exactly have a written process for "This is how we handle people who want to contribute to Bugzilla." We have the Contributor's Guide, but that's more a list of "dos and don'ts." Any other ideas? Any other barriers that new developers out there have run into? I'd really like to have a *lot* of developers, which would in turn lead to a lot of reviewers. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From douglasfcalvert at gmail.com Tue Dec 20 02:20:49 2005 From: douglasfcalvert at gmail.com (Douglas F. Calvert) Date: Mon, 19 Dec 2005 21:20:49 -0500 Subject: Making It Easier To Start Working On Bugzilla In-Reply-To: <1135042796.3564.29.camel@localhost.localdomain> References: <1135042796.3564.29.camel@localhost.localdomain> Message-ID: <20ee876b0512191820v36334043v3cc62c23ecfc6e9e@mail.gmail.com> > 1) We don't have any brief, clear documentation on the way that the > Bugzilla Project uses Bugzilla, or what our actual development process > is. I didn't realize this until I had to actually explain it in IRC the > other day, and didn't have any document to refer to. :-) > This would also be a nice document for people interested in using bugzilla for there own purposes; a case-study of sorts. > 2) We don't have any way to point new contributors to the bugs that > they should work on. It's true that we have the blockers, and that's a > good place to start, but there are a lot of other easy bugs that would > be a valid place to start off contributing. > I actually think that blockers are not the best place to start. Blockers are important things that probably need a good deal of attention. New developers need a little bit of hand holding as it is and I think having a new person working on a blocker may be a bit much. I think a good place to start would be with trivial/enhancements. It would be nice if there was an invasiveness keyword, so that new people could pick stuff off the periphery that did not touch a million things. One other thing that I have always had trouble with is that there are not a lot of generic examples about how to do something. The source is there, don't get me wrong I have not missed it. However adding minor things to templates where the functionality is not already present is a little trying sometimes. It would be nice if there was a heavily documented template that had some examples of how to go about and do things. Does this make any sense? For instance the other day I wanted to change the bookmarkable template link to be the summary instead of the generic link title. Someone fixed it way before I could figure out how. In hind sight it was a pretty easy fix but I was unsure of how to start it... From bugreport at peshkin.net Tue Dec 20 04:42:07 2005 From: bugreport at peshkin.net (Joel Peshkin) Date: Mon, 19 Dec 2005 20:42:07 -0800 Subject: Making It Easier To Start Working On Bugzilla In-Reply-To: <1135042796.3564.29.camel@localhost.localdomain> References: <1135042796.3564.29.camel@localhost.localdomain> Message-ID: <43A78B9F.6070900@peshkin.net> Max Kanat-Alexander wrote: > Any other ideas? Any other barriers that new developers out there have >run into? I'd really like to have a *lot* of developers, which would in >turn lead to a lot of reviewers. > > I think we should make arrangments for contributors to be able to get some pointers about how to go about a particular fix before they start. It is a shame when someone pus a lot of effort into a patch just to find out that it conflicts with a general direction that all the reviewers know about but a new contributor has no way of knowing about. Similarly, guiding new contributos on how to break up a big patch into a series of smaller ones (rather than just telling them to do so) would be good. From micklweiss at gmx.net Tue Dec 20 05:47:41 2005 From: micklweiss at gmx.net (Mick Weiss) Date: Tue, 20 Dec 2005 00:47:41 -0500 Subject: Making It Easier To Start Working On Bugzilla In-Reply-To: <1135042796.3564.29.camel@localhost.localdomain> References: <1135042796.3564.29.camel@localhost.localdomain> Message-ID: <43A79AFD.9020002@gmx.net> For starters, I think that it would be a great idea to try to make it easier for people to help out. :-D I agree with a lot of the points, but I don't think that people should be working on blockers as their first task. I hear this a lot in projects, "Oh your new? Try to take on a blocker". Small enhancements are probably the best place to start for new people as blockers are often difficult and are better solved by people who know the code a lot better. Here are my 2 cents: - An introductory document with a general layout of class structure and how things work would be helpful for new people, but AFAIK doesn't exist. - I agree with having a contributors document, going over what happens with a patch (example: who should get the "review flag", what is it and why is it there and what to do if a reviewer doesn't have time to review your patch... that sort of stuff). - Maybe a document on an example patch would be interesting. "The step-by-step guide to creating a patch for Bugzilla", with an example patch (something not too incredibly hard). It would outline the problem and places the author looked to for info on solving a particular problem (like the Bugzilla POD, developer docs, other places in the source...). It could even say "checkout this version from cvs and follow along". I for one think that it would be a good idea, but that is just me ;-) - Right now, when patches are submitted - sometimes it takes a while for a patch to be merged into a release (one example off the top of my head is https://bugzilla.mozilla.org/show_bug.cgi?id=250916 which has been sitting there since 2004). To quote Dave, "Note that this has already missed the boat for both 2.18 and 2.20". I am aware of the issues behind this patch, but what I'm saying is - if you write a patch in 2004, and it is 2 weeks from 2006 and no real advancements have been made... would you want to contribute again? I know not everyone has LDAP/TLS setup to test this... but it is just meant as an example to backup a point. - Another issue is that patches need to be maintained from version to version, and some people submit a patch and then noone ever hears from them again. I don't really have a solution for this, but I have seen this with other projects. (I'm not sure if this is really an issue for Bugzilla). - Mick Max Kanat-Alexander wrote: > So, I'm always really happy to have new people working on Bugzilla, but >I think that sometimes the barrier-to-entry is a bit too high. Let's >work out some ways that we could lower it. > > Here's some thoughts I had: > > 1) We don't have any brief, clear documentation on the way that the >Bugzilla Project uses Bugzilla, or what our actual development process >is. I didn't realize this until I had to actually explain it in IRC the >other day, and didn't have any document to refer to. :-) > > 2) We don't have any way to point new contributors to the bugs that >they should work on. It's true that we have the blockers, and that's a >good place to start, but there are a lot of other easy bugs that would >be a valid place to start off contributing. > > 3) We don't really have any sort of defined "channel" (in the >theoretical sense, not in the IRC sense) for new contributors to travel >in. That is, we don't exactly have a written process for "This is how we >handle people who want to contribute to Bugzilla." We have the >Contributor's Guide, but that's more a list of "dos and don'ts." > > Any other ideas? Any other barriers that new developers out there have >run into? I'd really like to have a *lot* of developers, which would in >turn lead to a lot of reviewers. > > -Max > > From jochen.wiedmann at gmail.com Tue Dec 20 07:36:14 2005 From: jochen.wiedmann at gmail.com (Jochen Wiedmann) Date: Tue, 20 Dec 2005 08:36:14 +0100 Subject: Making It Easier To Start Working On Bugzilla In-Reply-To: <1135042796.3564.29.camel@localhost.localdomain> References: <1135042796.3564.29.camel@localhost.localdomain> Message-ID: <43A7B46E.80604@gmail.com> Max Kanat-Alexander wrote: > Any other ideas? Any other barriers that new developers out there have > run into? I'd really like to have a *lot* of developers, which would in > turn lead to a lot of reviewers. IMO, the Bugzilla developers have a clearly different attitude when handling contributed patches than other Open Source projects. There may be reasons for certain policies (quality, in particular), but to me, the policies are sometimes overemphasized. When I, as the committer of another Open Source project, receive a patch, then it is in my interest to encourage the contributor. Of course, if the patch is clearly wrong, overcomplicated, or whatever, then I have to reject the patch. But that is rarely the case. Typically, there are some oddities. Does the developer obeye style guides? Is the indentation right? Is the wording right (in particular, is the contributor using proper english)? At that point, I have two choices: First, I can tell the contributor what I dislike. Second, I can fix the problems for myself and pull the patch in. (Or, if a review is required, I can attach a modified version of the patch.) From my experience, Bugzilla developers will *always* choose the first alternative. I do not know, what the reasons are. It may be lack of time, but my personal impression is, that accepting the patch will sometimes be less work than reviewing a modified patch again. Do you think, it is encouraging to provide a patch the next time, if my suggestion is rejected simply because the reviewer does not like my wording? Do you think it is likely that I take the work the next time? But even when rejecting a patch, I do believe, that developers can be more encouraging to the contributor. For example, I once contributed a patch to a file, which was removed some weeks later. The review occurred even more weeks later and the developer took that for a reason to reject my patch. Okay, that's understandable. But I would expect to receive at least a hint, where I've got to look now. Being not as deep in the current happenings, it took me almost half an hour to find the new place. Jochen From justdave at bugzilla.org Tue Dec 20 08:20:59 2005 From: justdave at bugzilla.org (David Miller) Date: Tue, 20 Dec 2005 03:20:59 -0500 Subject: Making It Easier To Start Working On Bugzilla In-Reply-To: <43A7B46E.80604@gmail.com> References: <1135042796.3564.29.camel@localhost.localdomain> <43A7B46E.80604@gmail.com> Message-ID: <43A7BEEB.8020507@bugzilla.org> Jochen Wiedmann wrote on 12/20/05 2:36 AM: > IMO, the Bugzilla developers have a clearly different attitude when > handling contributed patches than other Open Source projects. There may > be reasons for certain policies (quality, in particular), but to me, the > policies are sometimes overemphasized. Yeah, it's mostly quality here... there's a number of sites that run in production pretty close to the cvs tip (mozilla.org used to be one of them until we got short on manpower to keep on on it), so we usually try to do everything possible to avoid breaking cvs. > At that point, I have two choices: First, I can tell the contributor > what I dislike. Second, I can fix the problems for myself and pull the > patch in. (Or, if a review is required, I can attach a modified version > of the patch.) > > From my experience, Bugzilla developers will *always* choose the first > alternative. I do not know, what the reasons are. It may be lack of > time, but my personal impression is, that accepting the patch will > sometimes be less work than reviewing a modified patch again. There's a couple different ways to look at this. I know we often expect the contributor to fix up their own patch, mostly with the goal of letting them get sole credit for the patch when it goes in. Some of us feel like we'd be stealing the glory from the contributor if we just took over the patch and fixed it up after they contribute it. On the other hand, the contributor might not have the patience or the time to fix it up, and might be happy to have us take it over and finish the job for them. Then the question becomes, how do we tell which type of contributor it is? Will he/she get offended if I fix the patch, or will they be happy I did it? This is a really good topic to get into our contributor docs probably. "Tell us if you don't mind someone else taking over your patch and fixing it up" or something. Or maybe people don't think that way and I'm just paranoid. :) -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From jochen.wiedmann at gmail.com Tue Dec 20 09:16:55 2005 From: jochen.wiedmann at gmail.com (Jochen Wiedmann) Date: Tue, 20 Dec 2005 10:16:55 +0100 Subject: Making It Easier To Start Working On Bugzilla In-Reply-To: <43A7BEEB.8020507@bugzilla.org> References: <1135042796.3564.29.camel@localhost.localdomain> <43A7B46E.80604@gmail.com> <43A7BEEB.8020507@bugzilla.org> Message-ID: On 12/20/05, David Miller wrote: > There's a couple different ways to look at this. I know we often expect > the contributor to fix up their own patch, mostly with the goal of > letting them get sole credit for the patch when it goes in. Some of us > feel like we'd be stealing the glory from the contributor if we just > took over the patch and fixed it up after they contribute it. That's, IMO, not the point. The question is, whether I have to push a patch ("against" the reviewer) or whether the reviewer pulls the patch. Besides, if a person has such a large ego, that he or she is unable to accept that a projects standards require some changes, then he or she should possibly better work on a standalone project and not in a team. To me, Max approach (contributors guide), and yours ("Tell us if you don't mind ...") are basically the same thing over and over again. You create bureaucratic structures. But bureaucreatic structures are also limits for new developers. In other words: Your attempts will fail. (At least, that's my opinion.) I wholeheartly support your concerns for quality. But isn't that exactly the reviewers job? If he does pull a patch in, applying necessary changes, isn't that enough for quality? If it is not, then he possibly should stop review. Jochen -- Often it does seem a pity that Noah and his party did not miss the boat. (Mark Twain) From bugzilla at colinogilvie.co.uk Tue Dec 20 10:07:33 2005 From: bugzilla at colinogilvie.co.uk (Colin Ogilvie) Date: Tue, 20 Dec 2005 10:07:33 +0000 Subject: Making It Easier To Start Working On Bugzilla Message-ID: <200512201005.jBKA5hSA003308@sinclair.syndicomm.com> On Tue Dec 20 9:16 , Jochen Wiedmann sent: >That's, IMO, not the point. The question is, whether I have to push a >patch ("against" the reviewer) or whether the reviewer pulls the >patch. Besides, if a person has such a large ego, that he or she is >unable to accept that a projects standards require some changes, then >he or she should possibly better work on a standalone project and not >in a team. > >To me, Max approach (contributors guide), and yours ("Tell us if you >don't mind ...") are basically the same thing over and over again. You >create bureaucratic structures. But bureaucreatic structures are also >limits for new developers. In other words: Your attempts will fail. >(At least, that's my opinion.) > >I wholeheartly support your concerns for quality. But isn't that >exactly the reviewers job? If he does pull a patch in, applying >necessary changes, isn't that enough for quality? If it is not, then >he possibly should stop review. Personally, I'd rather that if there was a problem with the patch (other than say a minor typo that could be fixed on Checkin) that I (as the author) got the opportunity to fix it, rather than the person reviewing it had to. What I think would be more useful is that you didn't have to wait weeks / months for reviews, sometimes but that could be partly what Max is trying to work towards... Colin From LpSolit at gmail.com Tue Dec 20 10:08:51 2005 From: LpSolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Tue, 20 Dec 2005 11:08:51 +0100 Subject: Making It Easier To Start Working On Bugzilla In-Reply-To: References: <1135042796.3564.29.camel@localhost.localdomain> <43A7B46E.80604@gmail.com> <43A7BEEB.8020507@bugzilla.org> Message-ID: <43A7D833.3020700@gmail.com> > I wholeheartly support your concerns for quality. But isn't that > exactly the reviewers job? If he does pull a patch in, applying > necessary changes, isn't that enough for quality? If it is not, then > he possibly should stop review. When there are minor remaining changes to apply, we often add comments such as "Fix that and that on checkin" and the one doing the checkin (in 99% of cases, a reviewer) will apply them when commiting the patch. Or we ask to open another bug to fix some remaining issues. If there is more than that to fix, then we deny review. So we are not as "strict" as what you seem to say here. But applying a patch on a new installation (to not conflict with our current work), doing necessary changes, and doing a "cvs diff" again, then commiting the patch and waiting for another reviewer to review it takes too much time, and we already have a long queue of pending reviews. So I prefer to say "Please fix that and I will r+ your patch" than doing it myself. This gives me more time for other reviews (I also try to have some free time for non-Bugzilla stuff... sometimes). LpSolit From jochen.wiedmann at gmail.com Tue Dec 20 10:17:18 2005 From: jochen.wiedmann at gmail.com (Jochen Wiedmann) Date: Tue, 20 Dec 2005 11:17:18 +0100 Subject: Making It Easier To Start Working On Bugzilla In-Reply-To: <200512201005.jBKA5hSA003308@sinclair.syndicomm.com> References: <200512201005.jBKA5hSA003308@sinclair.syndicomm.com> Message-ID: On 12/20/05, Colin Ogilvie wrote: > Personally, I'd rather that if there was a problem with the patch (other than say a minor typo > that could be fixed on Checkin) that I (as the author) got the opportunity to fix it, rather than > the person reviewing it had to. > > What I think would be more useful is that you didn't have to wait weeks / months for reviews, > sometimes but that could be partly what Max is trying to work towards... Don't you think, that the above paragraphs contain an obvious contradiction? -- Often it does seem a pity that Noah and his party did not miss the boat. (Mark Twain) From mkanat at bugzilla.org Tue Dec 20 10:39:03 2005 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 20 Dec 2005 02:39:03 -0800 Subject: Making It Easier To Start Working On Bugzilla In-Reply-To: <200512201005.jBKA5hSA003308@sinclair.syndicomm.com> References: <200512201005.jBKA5hSA003308@sinclair.syndicomm.com> Message-ID: <1135075144.7503.1.camel@localhost.localdomain> On Tue, 2005-12-20 at 10:07 +0000, Colin Ogilvie wrote: > What I think would be more useful is that you didn't have to wait > weeks / months for reviews, sometimes but that could be partly what > Max is trying to work towards... Yeah, definitely. :-) More solid contributors means eventually more reviewers, and that means faster reviews. :-) As we've seen before when we had lots of active reviewers, things move a lot faster. :-) -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From bugzilla at colinogilvie.co.uk Tue Dec 20 11:21:19 2005 From: bugzilla at colinogilvie.co.uk (Colin Ogilvie) Date: Tue, 20 Dec 2005 11:21:19 +0000 Subject: Making It Easier To Start Working On Bugzilla Message-ID: <200512201121.jBKBLdPJ015893@sinclair.syndicomm.com> On Tue Dec 20 10:17 , Jochen Wiedmann sent: >On 12/20/05, Colin Ogilvie bugzilla at colinogilvie.co.uk> wrote: > >> Personally, I'd rather that if there was a problem with the patch (other than say a minor typo >> that could be fixed on Checkin) that I (as the author) got the opportunity to fix it, rather than >> the person reviewing it had to. >> >> What I think would be more useful is that you didn't have to wait weeks / months for reviews, >> sometimes but that could be partly what Max is trying to work towards... > >Don't you think, that the above paragraphs contain an obvious contradiction? Nope, I don't see a contradiction... Colin From vseerror at lehigh.edu Tue Dec 20 15:36:57 2005 From: vseerror at lehigh.edu (Wayne Mery) Date: Tue, 20 Dec 2005 10:36:57 -0500 Subject: Making It Easier To Start Working On Bugzilla In-Reply-To: <43A79AFD.9020002@gmx.net> References: <1135042796.3564.29.camel@localhost.localdomain> <43A79AFD.9020002@gmx.net> Message-ID: <43A82519.7010001@lehigh.edu> On 12/20/2005 12:47 AM, Mick Weiss wrote: >... > - Another issue is that patches need to be maintained from version to > version, and some people submit a patch and then noone ever hears from > them again. I don't really have a solution for this, but I have seen > this with other projects. (I'm not sure if this is really an issue for > Bugzilla). On a related note, ability to get a quicker snapshot of patch state/status patches might be a worthy goal. For example in https://bugzilla.mozilla.org/show_bug.cgi?id=319082 (a bug marked fixed so perhaps not an ideal example) "patch, v2" has been reviewed. was it checked in? checked in for what versions? backed out? etc. The status is not completely and immediately apparent by looking at the attachment information block unless someone has modified the attachment's name to indicate it's status (eg "patch, v2 checked in v2.20"] Status information is often, as it should be, written in the comments. And bugzilla devs do an excellent good job of documenting what they have done (again, more consistently than some other products). But finding that information requires more reading. From eseyman at linagora.com Tue Dec 20 17:22:27 2005 From: eseyman at linagora.com (Emmanuel Seyman) Date: Tue, 20 Dec 2005 18:22:27 +0100 (CET) Subject: Making It Easier To Start Working On Bugzilla In-Reply-To: References: <1135042796.3564.29.camel@localhost.localdomain> <43A7B46E.80604@gmail.com> <43A7BEEB.8020507@bugzilla.org> Message-ID: <51752.192.168.1.254.1135099347.squirrel@tomate.linagora.lan> mkanat started this discussion saying (amongst other things) : > 2) We don't have any way to point new contributors to the bugs that > they should work on. It's true that we have the blockers, and that's a > good place to start, but there are a lot of other easy bugs that would > be a valid place to start off contributing. I really don't think giving newcomers blockers to fix is Every once in a while, I find myself wishing for two new fields in a Bugzilla bug report : Difficulty : How hard is it to resolve this bug (no idea who would set this, though). Field of resolution : Does the person who will try to resolve this need to know TT ? HTML ? Docbook XML ? Perl ? Any combination of the former ? This would enable us to point a newcomer who only knows HTML to the appropriate bugs and let them go at it without fearing they're out of their depths. From kevin.benton at amd.com Tue Dec 20 18:05:44 2005 From: kevin.benton at amd.com (Benton, Kevin) Date: Tue, 20 Dec 2005 10:05:44 -0800 Subject: Making It Easier To Start Working On Bugzilla Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203856CBB@ssvlexmb2.amd.com> Executive summary: More documentation is required to help new developers and reviewers see the entire development, review, approval and release processes. Reviewer and developer mentoring needs to be a greater emphasis. Reviewers and developers both need encouragement. Details: I would reply in-line, but I think this makes more sense for this case. At any rate... I agree - I think documentation showing users how to get to patches so they can see just what kinds of things have been approved in the past is a great way to help others gain confidence in the process. Small patches are the best to start with because they 1) demonstrate what kind of patches we'll accept, 2) demonstrate what the patch should look like, and 3) give them an opportunity to review the patch like a reviewer would. I think it would also be helpful for us to point people to some samples of patches that were rejected and discuss why those patches were rejected. That's jumping a bit ahead of ourselves, however. I think the documentation should... *) Document the entire patch submission process from conception / initial bug report through approval, check-in and release. *) Document how outsiders can look at the code via LXR and Bonsai to find out who to contact regarding specific updates. *) Document Tinderbox use so developers understand how they can see if their patch submission worked properly, or if not, what they need to do to begin the repair process. *) Document branching and how we use it - do the people doing a check-in create a branch to test the submission on then merge that back into the trunk if it works properly? If not, why? If so, why? Who has check-in authorization? How does one get it? Many others have made good points in the discussion as well. While it's true that at times, it would be quicker to let the reviewer make small mods, I think the point is well taken that the whole point of review is letting reviewers review and not ask them to make code changes. At the same time, reviewers have a responsibility to let developers know what issues they see as soon as possible. A challenge I've had in the review process in the past was I was asked to change one thing on one review, then on another subsequent review, I was asked to change more stuff, unrelated to what the original review discussed. It seems that it would be in our best interest to make sure reviews were adequately complete so that developers get a good sense of what needs to be fixed up front. This is especially true for new developers because the more times they go through r-, the less likely they are to continue submitting. At some point, a developer says to him/herself that submission was good enough. Take it or leave it. If the reviewer does another r-, development stops and we loose interest from an otherwise qualified developer. If the r- was over nits (I've seen a lot of that), we're shooting ourselves in the foot. I would hope that the review process would be more of a mentoring process than just a gate-keeping process. I've seen a lot more mentoring of late and that's good. As we developers get more and more r-'s, I think it becomes more critical for the reviewer (when possible) to make sure that the developer doesn't loose sight of what will change that r- to an r+. That means that each review needs to be complete and at times, reviewers must decide when something is "good enough." That is not to say we should drop our quality standards, but there are times when nits really do get in the way of good submissions. As a new reviewer, I really appreciate it a bunch when I'm lead to easy reviews as well so I can learn more about the review process. At times, I think it's really helpful for an experienced reviewer to mentor a new reviewer through the process, helping them see how they would do the review for a particular patch, discussing what are the plusses and the minuses of the patch. If we as reviewers can do that, we'll be doing ourselves a much better service - we'll be recruiting and training qualified reviewers. LpSolit (IRC) asked me if I would do a quick/easy review for him yesterday. I gladly accepted. I asked him some questions about his code, checked it against the CVS tip, found that it did what it promised to do, didn't interfere with Bugzilla operationally and gave him the r+. If I had not understood the implications of his changes, I would have discussed with him how he would have approached the review and asked him more about how he would research the patch. If at that point, I had felt it was okay to r+, I would have given it the r+ but asked for another review. I didn't need to do that for his patch. In the meantime, I got another review under my belt and he got his patch one step closer to inclusion in the Bugzilla trunk. This is a special case, of course... LpSolit is both a developer and reviewer so it was a great opportunity for mentoring. --- Kevin Benton Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator Personal Computing Systems Group Advanced Micro Devices The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. > -----Original Message----- > From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] > On Behalf Of Jochen Wiedmann > Sent: Tuesday, December 20, 2005 12:36 AM > To: developers at bugzilla.org > Subject: Re: Making It Easier To Start Working On Bugzilla > > Max Kanat-Alexander wrote: > > > Any other ideas? Any other barriers that new developers out there > have > > run into? I'd really like to have a *lot* of developers, which would in > > turn lead to a lot of reviewers. > > IMO, the Bugzilla developers have a clearly different attitude when > handling contributed patches than other Open Source projects. There may > be reasons for certain policies (quality, in particular), but to me, the > policies are sometimes overemphasized. > > When I, as the committer of another Open Source project, receive a > patch, then it is in my interest to encourage the contributor. Of > course, if the patch is clearly wrong, overcomplicated, or whatever, > then I have to reject the patch. But that is rarely the case. Typically, > there are some oddities. Does the developer obeye style guides? Is the > indentation right? Is the wording right (in particular, is the > contributor using proper english)? > > At that point, I have two choices: First, I can tell the contributor > what I dislike. Second, I can fix the problems for myself and pull the > patch in. (Or, if a review is required, I can attach a modified version > of the patch.) > > From my experience, Bugzilla developers will *always* choose the first > alternative. I do not know, what the reasons are. It may be lack of > time, but my personal impression is, that accepting the patch will > sometimes be less work than reviewing a modified patch again. > > Do you think, it is encouraging to provide a patch the next time, if my > suggestion is rejected simply because the reviewer does not like my > wording? Do you think it is likely that I take the work the next time? > > But even when rejecting a patch, I do believe, that developers can be > more encouraging to the contributor. For example, I once contributed a > patch to a file, which was removed some weeks later. The review occurred > even more weeks later and the developer took that for a reason to reject > my patch. Okay, that's understandable. But I would expect to receive at > least a hint, where I've got to look now. Being not as deep in the > current happenings, it took me almost half an hour to find the new place. > > > Jochen > - > To view or change your list settings, click here: > From eseyman at linagora.com Tue Dec 20 18:05:56 2005 From: eseyman at linagora.com (Emmanuel Seyman) Date: Tue, 20 Dec 2005 19:05:56 +0100 (CET) Subject: Making It Easier To Start Working On Bugzilla In-Reply-To: <51752.192.168.1.254.1135099347.squirrel@tomate.linagora.lan> References: <1135042796.3564.29.camel@localhost.localdomain> <43A7B46E.80604@gmail.com> <43A7BEEB.8020507@bugzilla.org> <51752.192.168.1.254.1135099347.squirrel@tomate.linagora.lan> Message-ID: <52460.192.168.1.254.1135101956.squirrel@tomate.linagora.lan> [ Apologies. My webmail sent the previous mail without asking for permission first ] mkanat started this discussion saying (amongst other things) : > > 2) We don't have any way to point new contributors to the bugs that > they should work on. It's true that we have the blockers, and that's a > good place to start, but there are a lot of other easy bugs that would > be a valid place to start off contributing. I really don't think giving newcomers blockers to fix is a good idea. Once developpement is in freeze (as it is now), blockers really need to be fixed ASAP. Giving these to newcomers probably won't help. > Any other ideas? Any other barriers that new developers out there have > run into? I'd really like to have a *lot* of developers, which would in > turn lead to a lot of reviewers. Every once in a while, I find myself wishing for two new fields in a Bugzilla bug report : Difficulty : How hard is it to resolve this bug (no idea who would set this, though). Field of resolution : Does the person who will try to resolve this need to know TT ? HTML ? Docbook XML ? Perl ? Any combination of the former ? This would enable us to point a newcomer who only knows HTML to the appropriate bugs and let them go at it without fearing they're out of their depths. Mick Weiss added : > > Here are my 2 cents: > - An introductory document with a general layout of class structure and > how things work would be helpful for new people, but AFAIK doesn't exist. Very true. Jochen Wiedmann then said : > > Do you think, it is encouraging to provide a patch the next time, if my > suggestion is rejected simply because the reviewer does not like my > wording? Do you think it is likely that I take the work the next time? While it's frustating to have your fourth patch for a bug get a negative review because of one mistake, it's a much more effective way of making sure that the contributor won't make that mistake again. > I wholeheartly support your concerns for quality. But isn't that > exactly the reviewers job? If he does pull a patch in, applying > necessary changes, isn't that enough for quality? If it is not, then > he possibly should stop review. The problem is that we have far fewer reviewers than contributors. It makes sense to shift the burden of developpement on the former more than the latter. Emmanuel From eseyman at linagora.com Tue Dec 20 18:10:29 2005 From: eseyman at linagora.com (Emmanuel Seyman) Date: Tue, 20 Dec 2005 19:10:29 +0100 (CET) Subject: Making It Easier To Start Working On Bugzilla In-Reply-To: <43A84650.9070002@lehigh.edu> References: <1135042796.3564.29.camel@localhost.localdomain> <43A7B46E.80604@gmail.com> <43A7BEEB.8020507@bugzilla.org> <51752.192.168.1.254.1135099347.squirrel@tomate.linagora.lan> <43A84650.9070002@lehigh.edu> Message-ID: <52568.192.168.1.254.1135102229.squirrel@tomate.linagora.lan> [ Wayne, I suppose you meant to send this to the list ] Wayne Mery wrote: > >> Difficulty : How hard is it to resolve this bug (no idea who would set >> this, though). >> Field of resolution : Does the person who will try to resolve this need >> to know TT ? HTML ? Docbook XML ? Perl ? Any combination of the former? >> >> This would enable us to point a newcomer who only knows HTML to the >> appropriate bugs and let them go at it without fearing they're out of >> their depths. > > excellent suggestion. > > whiteboard? keyword? I suppose it's a symptom of the problem we're discussing but I have absolutly no idea how these two fields are used for Bugzilla developpement. Field of resolution could be done with keywords, I guess. Not sure how I'ld go about implementing Difficulty. Emmanuel From justdave at bugzilla.org Tue Dec 20 19:40:35 2005 From: justdave at bugzilla.org (David Miller) Date: Tue, 20 Dec 2005 14:40:35 -0500 Subject: Making It Easier To Start Working On Bugzilla In-Reply-To: <51752.192.168.1.254.1135099347.squirrel@tomate.linagora.lan> References: <1135042796.3564.29.camel@localhost.localdomain> <43A7B46E.80604@gmail.com> <43A7BEEB.8020507@bugzilla.org> <51752.192.168.1.254.1135099347.squirrel@tomate.linagora.lan> Message-ID: <43A85E33.9030200@bugzilla.org> Emmanuel Seyman wrote on 12/20/05 12:22 PM: > Every once in a while, I find myself wishing for two new fields in a Bugzilla > bug report : > > Difficulty : How hard is it to resolve this bug (no idea who would set > this, though). > Field of resolution : Does the person who will try to resolve this need to > know TT ? HTML ? Docbook XML ? Perl ? Any combination of the former ? This might be a good thing to try out. The only real way to test this short term is just to add stuff to the status whiteboard indicating that I guess. The problem with using either the status whiteboard or keywords for this is that both are difficult to discover what the "legal" or desired values are to put there. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From mkanat at bugzilla.org Wed Dec 21 01:18:32 2005 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 20 Dec 2005 17:18:32 -0800 Subject: Making It Easier To Start Working On Bugzilla In-Reply-To: <43A85E33.9030200@bugzilla.org> References: <1135042796.3564.29.camel@localhost.localdomain> <43A7B46E.80604@gmail.com> <43A7BEEB.8020507@bugzilla.org> <51752.192.168.1.254.1135099347.squirrel@tomate.linagora.lan> <43A85E33.9030200@bugzilla.org> Message-ID: <1135127912.3429.2.camel@localhost.localdomain> On Tue, 2005-12-20 at 14:40 -0500, David Miller wrote: > This might be a good thing to try out. The only real way to test this > short term is just to add stuff to the status whiteboard indicating that > I guess. The problem with using either the status whiteboard or > keywords for this is that both are difficult to discover what the > "legal" or desired values are to put there. I liked the previous suggestion for "invasiveness," also. I'd just put "High" "Normal" or "Low." -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From tree at basistech.com Wed Dec 21 03:40:07 2005 From: tree at basistech.com (Tom Emerson) Date: Tue, 20 Dec 2005 22:40:07 -0500 Subject: Making It Easier To Start Working On Bugzilla In-Reply-To: <1135127912.3429.2.camel@localhost.localdomain> References: <1135042796.3564.29.camel@localhost.localdomain> <43A7B46E.80604@gmail.com> <43A7BEEB.8020507@bugzilla.org> <51752.192.168.1.254.1135099347.squirrel@tomate.linagora.lan> <43A85E33.9030200@bugzilla.org> <1135127912.3429.2.camel@localhost.localdomain> Message-ID: <17320.52887.747462.780493@tiphares.basistech.net> Max Kanat-Alexander writes: > I liked the previous suggestion for "invasiveness," also. I'd just put > "High" "Normal" or "Low." Gee, that sounds like a great idea for a custom field. Oh wait, custom fields are evil. I forgot. :-P -tree -- Tom Emerson Basis Technology Corp. Software Architect http://www.basistech.com "You can't fake quality any more than you can fake a good meal." (W.S.B.) From justdave at bugzilla.org Wed Dec 21 04:06:51 2005 From: justdave at bugzilla.org (David Miller) Date: Tue, 20 Dec 2005 23:06:51 -0500 Subject: Future of this list Message-ID: <43A8D4DB.7060100@bugzilla.org> This coming month, the long-standing dream of moving the netscape.public.mozilla.* newsgroup hierarchy to mozilla.* and getting it onto a server Mozilla has control over is finally coming true. This mailing list was born because the only newsgroup that covered Bugzilla was netscape.public.mozilla.webtools, and it was drowning in end-user support traffic. We created it here because there was no way to add new newsgroups on the old server (we didn't have any control over it). With the coming newsgroups reorganization this next month, the existing netscape.public.mozilla.webtools newsgroup is getting split into FOUR (4) different newsgroups in the mozilla.* hierarchy. One of which is intended to be a direct analog of this mailing list (developer discussion). The new newsgroups will be: mozilla.dev.apps.bugzilla <- Bugzilla developer discussion mozilla.dev.apps.webtools <- Other webtools developer discussion mozilla.support.bugzilla <- Bugzilla end-user support mozilla.support.webtools <- Other webtools end-user support These will all be gatewayed to mailing lists with periods changed to hyphens and @lists.mozilla.org tacked on the end. So we now have a decision to make. I *could* make an attempt to gateway *this* mailing list to the new newsgroup if we wanted. I don't know offhand how to do it. Majordomo2 doesn't include this functionality by default, but there are people that have done it, so I know it can be done. Or we could move wholesale to the new list. Or we could keep them separate, continue to have both and have disjointed discussions. :) Or any of a few other possibilities (we could veto the creation of the new dev group, too, though I'm not sure we would want to do that). What's everyone's thoughts on this? -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From micklweiss at gmx.net Wed Dec 21 04:28:00 2005 From: micklweiss at gmx.net (Mick Weiss) Date: Tue, 20 Dec 2005 23:28:00 -0500 Subject: Future of this list In-Reply-To: <43A8D4DB.7060100@bugzilla.org> References: <43A8D4DB.7060100@bugzilla.org> Message-ID: <43A8D9D0.9040804@gmx.net> Hi Dave, thats good news. I think, move to new newsgroup and find a Majordomo2 developer to help out with integrating into the mailinglist. (It is always best when a dev does this -- its assures that it will be done the right way - the first time). Though the saying "if it isn't broken, don't fix it" comes to mind ;-) - Mick > > > Or any of a few other possibilities (we could veto the creation of the > new dev group, too, though I'm not sure we would want to do that). > > What's everyone's thoughts on this? > From olav at bkor.dhs.org Wed Dec 21 08:25:11 2005 From: olav at bkor.dhs.org (Olav Vitters) Date: Wed, 21 Dec 2005 09:25:11 +0100 Subject: Future of this list In-Reply-To: <43A8D4DB.7060100@bugzilla.org> References: <43A8D4DB.7060100@bugzilla.org> Message-ID: <20051221082511.GA4451@bkor.dhs.org> On Tue, Dec 20, 2005 at 11:06:51PM -0500, David Miller wrote: > The new newsgroups will be: > > mozilla.dev.apps.bugzilla <- Bugzilla developer discussion [..] > Or we could move wholesale to the new list. What is different except that it has a new name? I'm for mass-subscribing everyone and remove the developers at bugzilla.org mailinglist (perhaps make an alias that redirects to mozilla-dev-apps etc as developers at bugzilla.org is easier to type ;). -- Regards, Olav From bugzilla at colinogilvie.co.uk Wed Dec 21 08:37:02 2005 From: bugzilla at colinogilvie.co.uk (Colin Ogilvie) Date: Wed, 21 Dec 2005 08:37:02 +0000 Subject: Future of this list Message-ID: <200512210834.jBL8YrRd025440@sinclair.syndicomm.com> On Wed Dec 21 4:06 , David Miller sent: >Or any of a few other possibilities (we could veto the creation of the >new dev group, too, though I'm not sure we would want to do that). > >What's everyone's thoughts on this? Personally, I'd rather see it remain as developers at bugzilla.org, but couldn't that just simply redirect to the new (VERY LONG) name @lists.mozilla.org? I know I wouldn't like to see it going usenet-only, as some people don't like it. Colin From justdave at bugzilla.org Wed Dec 21 12:31:26 2005 From: justdave at bugzilla.org (David Miller) Date: Wed, 21 Dec 2005 07:31:26 -0500 Subject: Future of this list In-Reply-To: <200512210834.jBL8YrRd025440@sinclair.syndicomm.com> References: <200512210834.jBL8YrRd025440@sinclair.syndicomm.com> Message-ID: <43A94B1E.4040507@bugzilla.org> Colin Ogilvie wrote on 12/21/05 3:37 AM: > On Wed Dec 21 4:06 , David Miller sent: >> Or any of a few other possibilities (we could veto the creation of the >> new dev group, too, though I'm not sure we would want to do that). >> >> What's everyone's thoughts on this? > > > Personally, I'd rather see it remain as developers at bugzilla.org, but couldn't that just simply > redirect to the new (VERY LONG) name @lists.mozilla.org? Yeah, we could do that, too. > I know I wouldn't like to see it going usenet-only, as some people don't like it. Another point I forgot to mention is that these new newsgroups will only be accessible via news.mozilla.org and Google Groups. We've got arrangements with both GigaNews and Google to not propagate them any further. This will hopefully help a lot with the spam content. The @lists.mozilla.org mailing lists will be using Mailman 2.1 (the existing @bugzilla.org lists use Majorodomo 2). -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From LpSolit at gmail.com Wed Dec 21 13:09:25 2005 From: LpSolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Wed, 21 Dec 2005 14:09:25 +0100 Subject: control characters and Util::clean_text() Message-ID: <43A95405.2000206@gmail.com> Hello! bug 238780 added a new method Util::clean_text($str) whose goal is to remove control characters from the string $str (ASCII 0 through 31 and ASCII 127). The idea was to prevent newlines and such characters in fields such as the product version (bug 238780), the target milestone (bug 177773) and the bug summary (bug 101380), among others. As far as I know, only comments should allow such characters (well, apart from newlines (ASCII 10 and 13) and maybe horizontal tabs (ASCII 9), I don't see why we should allow other control characters in comments). This brings us to the following problem: if we want to filter *all* fields using clean_text(), we would have to change a large part of the code, replacing most trim() by clean_text() (clean_text(), in his updated version, returns the trimmed string already). This is clearly not something I'm going to do nor to approve (6 patches are in my review queue about such changes, including one for the 2.16 branch!). So why not updating trim() to automatically remove such characters everywhere? This solution would be much less invasive. If nobody has objection about my suggestion, that's what I would like to see implemented. I could even imagine trick_taint() to do this kind of cleanup itself. Comments? LpSolit From bugzilla at colinogilvie.co.uk Wed Dec 21 15:30:36 2005 From: bugzilla at colinogilvie.co.uk (Colin Ogilvie) Date: Wed, 21 Dec 2005 15:30:36 +0000 Subject: Future of this list Message-ID: <200512211531.jBLFUwx3002896@sinclair.syndicomm.com> On Wed Dec 21 12:31 , David Miller sent: >Another point I forgot to mention is that these new newsgroups will only >be accessible via news.mozilla.org and Google Groups. We've got >arrangements with both GigaNews and Google to not propagate them any >further. This will hopefully help a lot with the spam content. That's a bit unfortunate, really - since many other providers (eg my ISP) carry the netscape.public.* heirarchy, and I can imagine many people finding this a problem... Colin From dennis.melentyev at infopulse.com.ua Wed Dec 21 15:42:40 2005 From: dennis.melentyev at infopulse.com.ua (Dennis Melentyev) Date: Wed, 21 Dec 2005 17:42:40 +0200 Subject: control characters and Util::clean_text() In-Reply-To: <43A95405.2000206@gmail.com> References: <43A95405.2000206@gmail.com> Message-ID: <1135179760.66183.5.camel@D-MELENTYEV.HOME> ASCII 127 is a *correct* Russian symbol in cp1251 (thanks to M$). Also, what to do with UTF-8 input? ? ??, 21/12/2005 ? 14:09 +0100, Fr?d?ric Buclin ?????: > Hello! > > bug 238780 added a new method Util::clean_text($str) whose goal is to > remove control characters from the string $str (ASCII 0 through 31 and > ASCII 127). The idea was to prevent newlines and such characters in > fields such as the product version (bug 238780), the target milestone > (bug 177773) and the bug summary (bug 101380), among others. > > As far as I know, only comments should allow such characters (well, > apart from newlines (ASCII 10 and 13) and maybe horizontal tabs (ASCII > 9), I don't see why we should allow other control characters in > comments). This brings us to the following problem: if we want to filter > *all* fields using clean_text(), we would have to change a large part of > the code, replacing most trim() by clean_text() (clean_text(), in his > updated version, returns the trimmed string already). This is clearly > not something I'm going to do nor to approve (6 patches are in my review > queue about such changes, including one for the 2.16 branch!). So why > not updating trim() to automatically remove such characters everywhere? > This solution would be much less invasive. > > If nobody has objection about my suggestion, that's what I would like to > see implemented. I could even imagine trick_taint() to do this kind of > cleanup itself. > > Comments? > > LpSolit > - > To view or change your list settings, click here: > From tree at basistech.com Wed Dec 21 16:08:48 2005 From: tree at basistech.com (Tom Emerson) Date: Wed, 21 Dec 2005 11:08:48 -0500 Subject: control characters and Util::clean_text() In-Reply-To: <1135179760.66183.5.camel@D-MELENTYEV.HOME> References: <43A95405.2000206@gmail.com> <1135179760.66183.5.camel@D-MELENTYEV.HOME> Message-ID: <17321.32272.724896.856642@tiphares.basistech.net> Dennis Melentyev writes: > ASCII 127 is a *correct* Russian symbol in cp1251 (thanks to M$). > Also, what to do with UTF-8 input? What about UTF-8? It won't matter. 0x7F is a control character in Unicode and is a valid UTF-8 single-byte value. Stripping it won't hurt anything. -tree -- Tom Emerson Basis Technology Corp. Software Architect http://www.basistech.com "You can't fake quality any more than you can fake a good meal." (W.S.B.) From eseyman at linagora.com Wed Dec 21 16:35:32 2005 From: eseyman at linagora.com (Emmanuel Seyman) Date: Wed, 21 Dec 2005 17:35:32 +0100 (CET) Subject: control characters and Util::clean_text() In-Reply-To: <1135179760.66183.5.camel@D-MELENTYEV.HOME> References: <43A95405.2000206@gmail.com> <1135179760.66183.5.camel@D-MELENTYEV.HOME> Message-ID: <38972.192.168.1.254.1135182932.squirrel@tomate.linagora.lan> Dennis Melentyev wrote: > > ASCII 127 is a *correct* Russian symbol in cp1251 (thanks to M$). > Also, what to do with UTF-8 input? 127 should be DELETE, no matter what charset you are using (since it's part of the ASCII charset). This is a non-printable character so it should be trimmed. What does it output in cp1251? Emmanuel From mkanat at bugzilla.org Wed Dec 21 16:59:05 2005 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 21 Dec 2005 08:59:05 -0800 Subject: control characters and Util::clean_text() In-Reply-To: <43A95405.2000206@gmail.com> References: <43A95405.2000206@gmail.com> Message-ID: <1135184345.3394.3.camel@localhost.localdomain> On Wed, 2005-12-21 at 14:09 +0100, Fr?d?ric Buclin wrote: > So why > not updating trim() to automatically remove such characters everywhere? > This solution would be much less invasive. I wouldn't object for the branches, but I'd definitely object for the tip. A developer expects a function called trim() to only remove whitespace. Functions should not have side effects. Replacing most calls to trim() with a call to clean_text() shouldn't be that hard, if that's what needs to be done. I don't particularly see a pressing reason to remove control characters in most cases, anyhow -- if somebody was silly enough to put a control character into a field, perhaps they intended for it to appear there. (Unless, of course, displaying the control character has some security implication.) -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From ghendricks at novell.com Wed Dec 21 17:01:30 2005 From: ghendricks at novell.com (Gregary Hendricks) Date: Wed, 21 Dec 2005 10:01:30 -0700 Subject: Making It Easier To Start Working On Bugzilla In-Reply-To: <51752.192.168.1.254.1135099347.squirrel@tomate.linagora.lan> References: <1135042796.3564.29.camel@localhost.localdomain> <43A7B46E.80604@gmail.com> <43A7BEEB.8020507@bugzilla.org> <51752.192.168.1.254.1135099347.squirrel@tomate.linagora.lan> Message-ID: <43A927FA.3532.00D2.0@novell.com> When starting out, I agree that taking on blockers is a bad idea. For one, putting critical code development into the hands of newcomers is not the best idea generally, both for the sake of the code and for the sake of the developer. Since it is a tall order to fill it has the potential to create major problems if something goes wrong. This would be a massive blow to the self esteem of a new developer. Here are a few notes on my experiences so far. I have been working on a number of patches simultaneously for the past year now, most of which are pretty minor with the exception of one very large one. In the case of some of my patches I have had a reviewer/mentor such as myk to hold my hand through the process. In these cases the reviewers have not only been supportive, but have actually pushed some of the proposed changes through some barriers and opposition. One of the challenges that has been particularly accute is that, though we use Bugzilla day to day, we use it in very different ways from those of Mozilla. Having to learn the bugzilla way of using bugzilla is something of an issue. It is easy to sound as though you are chastising in a review for not doing things the "right" way when in actuality it is just a different way of approaching things. One of the things I love most about Perl is its mantra "There's more than one way to do it". I have had multiple reviews get r- because it does not meet the coding style of the particular reviewer when in reality there is no good argument for changing it. If it is more efficient or reduces clock cycles, that is one thing, but otherwise if it works, why make a developer change something over and over again to satisfy nits? Just yesterday I spent litterally half my day helping rework a patch that worked but wasn't "cool enough" to get accepted because it didn't use a particular implimentation of an algorithm. Another thing that I have seen is reviewers that either do not read the comments of other reviews or forget their own comments. On at least two occasions I have had one reviewer tell me to do something one way and then get an r- on the next review (once a different reviewer and once the same reviewer) because I did it that way. This seems backwards. I appreciate the reviewers that have taken the time to actually provide proposals to solutions. It is true that sometimes the obvious solution is not so obvious and on multiple occasions I have been corrected in such a way as to help me learn more about the language and the thinking behind an implementation. I also appreciate reviewers like LpSolit who is willing to dive into an area that he may not be familiar with in order to give a thorough review, taking the time to learn what is going on in the process. Part of the beauty of open source in my mind is that we all have the opportunity to share our understanding and we can all help each other learn new things. -- Greg Hendricks Novell IS&T Engineer GHendricks at novell.com www.novell.com From paulo.casanova at link.pt Wed Dec 21 17:25:24 2005 From: paulo.casanova at link.pt (Paulo Casanova) Date: Wed, 21 Dec 2005 17:25:24 -0000 Subject: control characters and Util::clean_text() In-Reply-To: <1135179760.66183.5.camel@D-MELENTYEV.HOME> Message-ID: <013901c60653$871e4d00$0813a8c0@aitec.pt> Hi, 0x00 up to 0x7F are single byte characters on both ASCII and UTF-8 (they have equal meaning in both standards). As such, I see no problem with the stripping sub. If i'm not mistaken :) when you enter a character in a browser form, it will be encoded into UTF-8 and then sent to the web server which will decode it; you will receive a UTF-8 string in perl so the sub would work correctly too. Even if you have your pages in cp1251 and use russian characters in your bugzilla products. Or maybe i'm just wrong :) Paulo -----Original Message----- From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] On Behalf Of Dennis Melentyev Sent: quarta-feira, 21 de Dezembro de 2005 15:43 To: developers at bugzilla.org Subject: Re: control characters and Util::clean_text() ASCII 127 is a *correct* Russian symbol in cp1251 (thanks to M$). Also, what to do with UTF-8 input? ? ??, 21/12/2005 ? 14:09 +0100, Fr?d?ric Buclin ?????: > Hello! > > bug 238780 added a new method Util::clean_text($str) whose goal is to > remove control characters from the string $str (ASCII 0 through 31 and > ASCII 127). The idea was to prevent newlines and such characters in > fields such as the product version (bug 238780), the target milestone > (bug 177773) and the bug summary (bug 101380), among others. > > As far as I know, only comments should allow such characters (well, > apart from newlines (ASCII 10 and 13) and maybe horizontal tabs (ASCII > 9), I don't see why we should allow other control characters in > comments). This brings us to the following problem: if we want to > filter > *all* fields using clean_text(), we would have to change a large part > of the code, replacing most trim() by clean_text() (clean_text(), in > his updated version, returns the trimmed string already). This is > clearly not something I'm going to do nor to approve (6 patches are in > my review queue about such changes, including one for the 2.16 > branch!). So why not updating trim() to automatically remove such characters everywhere? > This solution would be much less invasive. > > If nobody has objection about my suggestion, that's what I would like > to see implemented. I could even imagine trick_taint() to do this kind > of cleanup itself. > > Comments? > > LpSolit > - > To view or change your list settings, click here: > .com.ua> - To view or change your list settings, click here: From karl at kornel.name Wed Dec 21 17:28:56 2005 From: karl at kornel.name (A. Karl Kornel) Date: Wed, 21 Dec 2005 12:28:56 -0500 Subject: Future of this list In-Reply-To: <200512211531.jBLFUwx3002896@sinclair.syndicomm.com> References: <200512211531.jBLFUwx3002896@sinclair.syndicomm.com> Message-ID: <7DCC3A82-1790-4FAB-894D-F5C481809954@kornel.name> On Dec 21, 2005, at 10:30 AM, Colin Ogilvie wrote: > On Wed Dec 21 12:31 , David Miller sent: >> Another point I forgot to mention is that these new newsgroups will > only >> be accessible via news.mozilla.org and Google Groups. We've got >> arrangements with both GigaNews and Google to not propagate them any >> further. This will hopefully help a lot with the spam content. > > That's a bit unfortunate, really - since many other providers (eg my > ISP) carry the netscape.public.* heirarchy, and I can imagine many > people finding this a problem... That will almost certainly be a problem. Unfortunately, I don't know how many servers honor requests to delete newsgroups (as opposed to requests to create them). It may be best if someone arranged a script to regularly send out a post to the old newsgroups, notifying people of the fact the the old groups are no longer in use and providing information on how to connect to the new groups. The last part is especially important if only a few servers are going to be carrying the groups. =================== | A. Karl Kornel | | karl at kornel.name =================== From kevin.benton at amd.com Wed Dec 21 17:34:30 2005 From: kevin.benton at amd.com (Benton, Kevin) Date: Wed, 21 Dec 2005 09:34:30 -0800 Subject: control characters and Util::clean_text() Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203856FC3@ssvlexmb2.amd.com> > -----Original Message----- > From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] > On Behalf Of Tom Emerson > Sent: Wednesday, December 21, 2005 9:09 AM > To: developers at bugzilla.org > Subject: Re: control characters and Util::clean_text() > > Dennis Melentyev writes: > > ASCII 127 is a *correct* Russian symbol in cp1251 (thanks to M$). > > Also, what to do with UTF-8 input? > > What about UTF-8? It won't matter. 0x7F is a control character in > Unicode and is a valid UTF-8 single-byte value. Stripping it won't > hurt anything. Actually, it does. If I put a character in and you strip it without telling me, you've hurt my ability to get my "stuff" done. We ran into this with Perforce and non-utf8 Unicode files that were getting corrupted on check-in. Perforce messed up the file format but didn't tell the user that it couldn't handle Unicode in any format except UTF-8. Users didn't know any better so they went on with their work only to find out later that their check-ins had been corrupted when they tried to use them from a different system at a later date (not easy to troubleshoot). As a result, I think we ought to do one of two things; 1) either treat characters that are to be stripped as errors in the user's input, or 2) we need to warn users that their input was modified by removing unsupported characters. Acting as if nothing happened is (in my mind) unacceptable. --- Kevin Benton Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator Personal Computing Systems Group Advanced Micro Devices The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. From justdave at bugzilla.org Wed Dec 21 17:40:25 2005 From: justdave at bugzilla.org (David Miller) Date: Wed, 21 Dec 2005 12:40:25 -0500 Subject: control characters and Util::clean_text() In-Reply-To: <1135184345.3394.3.camel@localhost.localdomain> References: <43A95405.2000206@gmail.com> <1135184345.3394.3.camel@localhost.localdomain> Message-ID: <43A99389.6040304@bugzilla.org> Max Kanat-Alexander wrote on 12/21/05 11:59 AM: > On Wed, 2005-12-21 at 14:09 +0100, Fr?d?ric Buclin wrote: >> So why >> not updating trim() to automatically remove such characters everywhere? >> This solution would be much less invasive. > > I wouldn't object for the branches, but I'd definitely object for the > tip. A developer expects a function called trim() to only remove > whitespace. Functions should not have side effects. I would think the other way around, because you're more likely to break people's customizations on the branches. With a major version update, they expect to need to change things. > I don't particularly see a pressing reason to remove control characters > in most cases, anyhow -- if somebody was silly enough to put a control > character into a field, perhaps they intended for it to appear there. > (Unless, of course, displaying the control character has some security > implication.) There are security implications for any field which is included in email headers. Allowing a linefeed lets you insert arbitrary email headers. Of course, the least invasive (and probably most secure) way to fix this is to strip the control characters before putting things in the headers. :) Technically, you're not allowed anything that's not US-ASCII in email headers, but that's another bug. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From justdave at bugzilla.org Wed Dec 21 17:45:52 2005 From: justdave at bugzilla.org (David Miller) Date: Wed, 21 Dec 2005 12:45:52 -0500 Subject: control characters and Util::clean_text() In-Reply-To: <013901c60653$871e4d00$0813a8c0@aitec.pt> References: <013901c60653$871e4d00$0813a8c0@aitec.pt> Message-ID: <43A994D0.10000@bugzilla.org> Paulo Casanova wrote on 12/21/05 12:25 PM: > If i'm not mistaken :) when you enter a character in a browser form, it will > be encoded into UTF-8 and then sent to the web server which will decode it; > you will receive a UTF-8 string in perl so the sub would work correctly too. > Even if you have your pages in cp1251 and use russian characters in your > bugzilla products. > > Or maybe i'm just wrong :) You are. The Browser will return it in whatever charset was specified by the web server feeding it the form, or with the charset specified in the attributes of the
element, defaulting to ISO-8859-1 if no charset was specified. If you include a character that's not representable in the charset selected, it will entity-encode the character with &#; -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From LpSolit at gmail.com Wed Dec 21 18:08:21 2005 From: LpSolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Wed, 21 Dec 2005 19:08:21 +0100 Subject: control characters and Util::clean_text() In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203856FC3@ssvlexmb2.amd.com> References: <6F7DA19D05F3CF40B890C7CA2DB13A4203856FC3@ssvlexmb2.amd.com> Message-ID: <43A99A15.1060409@gmail.com> > As a result, I think we ought to do one of two things; 1) either treat > characters that are to be stripped as errors in the user's input, or 2) > we need to warn users that their input was modified by removing > unsupported characters. Acting as if nothing happened is (in my mind) > unacceptable. Newlines and other control characters have nothing to do in a bug summary, a product version or a target milestone, etc... Silently removing these characters sounds fine to me. We are not going to remove these characters in comments, nor in product/component/group descriptions for instance, and of course not in attachments. How could you corrupt checkins this way??? From LpSolit at gmail.com Wed Dec 21 18:20:47 2005 From: LpSolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Wed, 21 Dec 2005 19:20:47 +0100 Subject: control characters and Util::clean_text() In-Reply-To: <1135184345.3394.3.camel@localhost.localdomain> References: <43A95405.2000206@gmail.com> <1135184345.3394.3.camel@localhost.localdomain> Message-ID: <43A99CFF.6030401@gmail.com> > Replacing most calls to trim() with a call to clean_text() shouldn't be > that hard, if that's what needs to be done. Someone said on IRC that there are 150 occurences of trim() within the Bugzilla code. But I agree that it's not "hard" to change them (and is mostly harmless, unless you inadvertently remove newlines from comments). The only problem is that I'm not a fan of such changes on branches. In this case, bug 101380 should limit itself to bug summaries and nothing else. > I don't particularly see a pressing reason to remove control characters > in most cases, anyhow -- if somebody was silly enough to put a control > character into a field, perhaps they intended for it to appear there. I see no case where a user could be tempted to "honestly" use such characters. LpSolit From tree at basistech.com Wed Dec 21 18:45:15 2005 From: tree at basistech.com (Tom Emerson) Date: Wed, 21 Dec 2005 13:45:15 -0500 Subject: control characters and Util::clean_text() In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203856FC3@ssvlexmb2.amd.com> References: <6F7DA19D05F3CF40B890C7CA2DB13A4203856FC3@ssvlexmb2.amd.com> Message-ID: <17321.41659.95534.962575@tiphares.basistech.net> Benton, Kevin writes: > Actually, it does. If I put a character in and you strip it without > telling me, you've hurt my ability to get my "stuff" done. We ran into > this with Perforce and non-utf8 Unicode files that were getting > corrupted on check-in. Perforce messed up the file format but didn't > tell the user that it couldn't handle Unicode in any format except > UTF-8. Users didn't know any better so they went on with their work > only to find out later that their check-ins had been corrupted when they > tried to use them from a different system at a later date (not easy to > troubleshoot). This isn't the issue. The issue, as I read the question, was this: if you have Unicode text encoded in UTF-8 and you strip control characters (including 0x7F) from it, will that corrupt the text. The answer is no, it will not. If you have UTF-16 or UCS-2 or UTF-32 text and you start stripping random bytes, then you will have a problem. The fact that Perforce choked and did the wrong thing is a bug on their side. Stripping control codes from UTF-8 is no different from stripping control codes from Latin-1. -- Tom Emerson Basis Technology Corp. Software Architect http://www.basistech.com "You can't fake quality any more than you can fake a good meal." (W.S.B.) From mkanat at bugzilla.org Wed Dec 21 18:51:09 2005 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 21 Dec 2005 10:51:09 -0800 Subject: For New Contributors: Good Bugs To Start With Message-ID: <1135191069.3394.8.camel@localhost.localdomain> Hey hey. Okay, so as a first response to all the feedback I got on the "Making It Easier To Start..." thread, I've gone through our currently-open bugs and tagged certain bugs as being good bugs for new Bugzilla contributors to start with: http://tinyurl.com/do9uh They have the following qualities: * We really do want them fixed. * They are not extremely hard. (Some are slightly easier or harder than others.) * Nobody *at all* is currently working on them. As always, if you have any questions about them, we're always available in IRC. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From kevin.benton at amd.com Wed Dec 21 20:24:06 2005 From: kevin.benton at amd.com (Benton, Kevin) Date: Wed, 21 Dec 2005 12:24:06 -0800 Subject: control characters and Util::clean_text() Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203A44C53@ssvlexmb2.amd.com> > -----Original Message----- > From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] > On Behalf Of Fr?d?ric Buclin > Sent: Wednesday, December 21, 2005 11:08 AM > To: developers at bugzilla.org > Subject: Re: control characters and Util::clean_text() > > > As a result, I think we ought to do one of two things; 1) either treat > > characters that are to be stripped as errors in the user's input, or 2) > > we need to warn users that their input was modified by removing > > unsupported characters. Acting as if nothing happened is (in my mind) > > unacceptable. > > > Newlines and other control characters have nothing to do in a bug > summary, a product version or a target milestone, etc... Silently > removing these characters sounds fine to me. We are not going to remove > these characters in comments, nor in product/component/group > descriptions for instance, and of course not in attachments. > > How could you corrupt checkins this way??? Modifying data given to a program without letting the user know it was modified in my mind is unacceptable. There may be a reason why someone wants a carriage return in the summary, milestone, or version. I don't know of any reasons off the top of my head at the moment, but as I mentioned, I don't think it's wise of us to modify user input without letting them know. If we don't let them know, someone will file a bug telling us we aren't supporting their input. If we let them know, at least then we tell them we chose not to support their data, then they can make the decision to modify the code or not. I'm not against it because I have a concrete reason right now, however, from what I've seen in my experience with Perforce, I'm afraid that stripping characters without notifying users will set us up for a problem later. Specifically, if we have UTF-16/32 LE/BE pairs that have some non-printable and some printable characters in the pair, we'll corrupt their data on import - something I work hard to avoid. --- Kevin Benton Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator Personal Computing Systems Group Advanced Micro Devices The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. From justdave at bugzilla.org Wed Dec 21 20:24:56 2005 From: justdave at bugzilla.org (David Miller) Date: Wed, 21 Dec 2005 15:24:56 -0500 Subject: Future of this list In-Reply-To: <7DCC3A82-1790-4FAB-894D-F5C481809954@kornel.name> References: <200512211531.jBLFUwx3002896@sinclair.syndicomm.com> <7DCC3A82-1790-4FAB-894D-F5C481809954@kornel.name> Message-ID: <43A9BA18.4060409@bugzilla.org> A. Karl Kornel wrote on 12/21/05 12:28 PM: > That will almost certainly be a problem. Unfortunately, I don't > know how many servers honor requests to delete newsgroups (as opposed to > requests to create them). It may be best if someone arranged a script > to regularly send out a post to the old newsgroups, notifying people of > the fact the the old groups are no longer in use and providing > information on how to connect to the new groups. The last part is > especially important if only a few servers are going to be carrying the > groups. Yeah, that's the plan. Mozilla Staff has been discussing this for a while. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From mkanat at bugzilla.org Wed Dec 21 20:59:29 2005 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 21 Dec 2005 12:59:29 -0800 Subject: Making It Easier To Start Working On Bugzilla In-Reply-To: <43A927FA.3532.00D2.0@novell.com> References: <1135042796.3564.29.camel@localhost.localdomain> <43A7B46E.80604@gmail.com> <43A7BEEB.8020507@bugzilla.org> <51752.192.168.1.254.1135099347.squirrel@tomate.linagora.lan> <43A927FA.3532.00D2.0@novell.com> Message-ID: <1135198769.3394.15.camel@localhost.localdomain> On Wed, 2005-12-21 at 10:01 -0700, Gregary Hendricks wrote: > I have had multiple reviews get r- because it does not meet the coding > style of the particular reviewer when in reality there is no good > argument for changing it. If it is more efficient or reduces clock > cycles, that is one thing, but otherwise if it works, why make > a developer change something over and over again to satisfy nits? For a long time, we didn't have an up-to-date or accurate Developer's Guide. Now that we do, these things should no longer happen. Unless we're dealing with some area not covered in the Developer's Guide (such as Object-Oriented architecture), review comments based on style should be coming mostly from the Guide. Nits alone are never enough to justify r-. > Just yesterday I spent litterally half my day helping rework a patch > that worked but wasn't "cool enough" to get accepted because it > didn't use a particular implimentation of an algorithm. Which patch? > Another thing that I have seen is reviewers that either do not read the > comments of other reviews or forget their own comments. On at least two > occasions I have had one reviewer tell me to do something one way and > then get an r- on the next review (once a different reviewer and once the > same reviewer) because I did it that way. This seems backwards. Hahahaha, yes, sometimes this happens. :-) You can always point it out, when it happens. Sometimes the reviewer doesn't realize he's contradicting the previous reviewer. > Part of the beauty of open source in my mind is that we all have the > opportunity to share our understanding and we can all help each other > learn new things. Yeah, definitely. :-) -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From bugreport at peshkin.net Wed Dec 21 21:33:17 2005 From: bugreport at peshkin.net (Joel Peshkin) Date: Wed, 21 Dec 2005 13:33:17 -0800 Subject: Making It Easier To Start Working On Bugzilla In-Reply-To: <1135198769.3394.15.camel@localhost.localdomain> References: <1135042796.3564.29.camel@localhost.localdomain> <43A7B46E.80604@gmail.com> <43A7BEEB.8020507@bugzilla.org> <51752.192.168.1.254.1135099347.squirrel@tomate.linagora.lan> <43A927FA.3532.00D2.0@novell.com> <1135198769.3394.15.camel@localhost.localdomain> Message-ID: <43A9CA1D.8070309@peshkin.net> This is quite a thread for making reviewers feel unappreciated. From ghendricks at novell.com Wed Dec 21 23:11:33 2005 From: ghendricks at novell.com (Gregary Hendricks) Date: Wed, 21 Dec 2005 16:11:33 -0700 Subject: Making It Easier To Start Working On Bugzilla In-Reply-To: <1135198769.3394.15.camel@localhost.localdomain> References: <1135042796.3564.29.camel@localhost.localdomain> <43A7B46E.80604@gmail.com> <43A7BEEB.8020507@bugzilla.org> <51752.192.168.1.254.1135099347.squirrel@tomate.linagora.lan> <43A927FA.3532.00D2.0@novell.com> <1135198769.3394.15.camel@localhost.localdomain> Message-ID: <43A97EB5.3532.00D2.0@novell.com> > Unless we're dealing with some area not covered in the Developer's >Guide (such as Object- Oriented architecture), review comments based on >style should be coming mostly from the Guide. This usually deals with the way perl does things and I don't think we would really want to include all of the perlisms in the developers guide. >> Just yesterday I spent litterally half my day helping rework a patch >> that worked but wasn't "cool enough" to get accepted because it >> didn't use a particular implimentation of an algorithm. > Which patch? https://bugzilla.mozilla.org/show_bug.cgi?id=313571 Specificallly in dealing with the Slice. It took Justin and I several hours of searching to figure out what this was and how it worked. His previous patch worked just fine without it. Sure it wasn't the cleanest perl code in existence, but this is Justin's first patch and neither of us are perl gurus. Justin worked really hard to get a working solution and it was a working solution. Now I am not complaining, in this case we both learned something that will be useful next time we come accross a similar problem. But this just hi-lights the point I was trying to make earlier: For someone that is just starting out to have something like this prevent an r+ is discouraging. LpSolit's review was very well done and each of his points here is valid for making good code, but the master woodsmith does not expect perfection from his apprentice on the first day or week of work. I would expect an r- if this was submitted by someone with a deep understanding of DBI and perl. But for a first time contributor...? This is a dilemma and I am not sure there is an easy solution. I just think it needs further discussion. >>> bugreport at peshkin.net 12/21/05 2:33 pm >>> >This is quite a thread for making reviewers feel unappreciated. This was not my intention. We really appreciate all the hard work and effort that you all put into bugzilla. Thank you. Greg Hendricks From LpSolit at gmail.com Wed Dec 21 23:32:48 2005 From: LpSolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Thu, 22 Dec 2005 00:32:48 +0100 Subject: Making It Easier To Start Working On Bugzilla In-Reply-To: <43A97EB5.3532.00D2.0@novell.com> References: <1135042796.3564.29.camel@localhost.localdomain> <43A7B46E.80604@gmail.com> <43A7BEEB.8020507@bugzilla.org> <51752.192.168.1.254.1135099347.squirrel@tomate.linagora.lan> <43A927FA.3532.00D2.0@novell.com> <1135198769.3394.15.camel@localhost.localdomain> <43A97EB5.3532.00D2.0@novell.com> Message-ID: <43A9E620.7010404@gmail.com> > I would expect an r- if this was submitted by someone with a deep > understanding of DBI and perl. But for a first time contributor...? I don't think that making a distinction between a newbie and an experienced developer is a good idea when deciding to give a r+ or a r-. Either it worths a r+ or it doesn't. What I do when I review a newbie's patch is to give much more information on how to fix the patch correctly, to avoid him to resubmit again and again. For experienced developers, I only say the patch doesn't work and only briefly explain why, without indicating on how to fix it. I think that's the best way to learn Perl and our Bugzilla-specific conventions. LpSolit From altlst at sonic.net Thu Dec 22 00:00:24 2005 From: altlst at sonic.net (Albert Ting) Date: Wed, 21 Dec 2005 16:00:24 -0800 Subject: Making It Easier To Start Working On Bugzilla Message-ID: <17321.60568.248783.824945@gargle.gargle.HOWL> Joel Peshkin writes: > From: Joel Peshkin > To: developers at bugzilla.org > Subject: Re: Making It Easier To Start Working On Bugzilla > Date: Wed, 21 Dec 2005 13:33:17 -0800 > > This is quite a thread for making reviewers feel unappreciated. Thought I pipe in and give my viewpoint. For starters, I do appreciate the reviewers effort. Joel, I would not have been able to get the Classification patch approved without all your help and campaigning. And it was hugely beneficial to me to see this patch be part of the code stream. Not only did it reduce my burden, I saw a number folks enhance it, improve it, and restructure it. Yes, it can be a pain getting repeated r- for various issues. But it does make the bugzilla code maintainable in the long term. So I'm glad there is a review process which allows multiple folks to cleanly contribute to Bugzilla. But yea, some things can be improved. For me, I found the main challenge to be the various "coding" changes that has happened the past year. Some examples: - the new sql mechanism, deprecating SendSQL, etc. - new structure guidelines in checksetup.pl - new admin parameter structure - Schema.pm - new structure changes in the latest tip. These are all good. But as a contributer, I'm never quite sure what the "new" coding styles are and often find out after I get a "r-". It would be nice to know up front what the bugzilla team expects and to be kept abreast of the infrastructure changes. This way, one doesn't have to unnecessarily rewrite the patch. The other is synchronizing existing patches with the code stream schedule. >From where I stand, the window of opportunity to add new features to an existing branch is a bit too short for me. Both the reviewer and the contributor have to be free during that time to go through a couple iterations. Many of the current patches are so "old" that it now no longer meets current coding standards. It is now too old and needs to be revamped. Not sure what is a better solution as I know the Bugzilla team doesn't want to stretch out the development schedule. Albert From micklweiss at gmx.net Thu Dec 22 02:58:01 2005 From: micklweiss at gmx.net (Mick Weiss) Date: Wed, 21 Dec 2005 21:58:01 -0500 Subject: cvs web? Message-ID: <43AA1639.6000007@gmx.net> I was just on the download site again, and I noticed that there is no way to browse cvs from the web: http://www.bugzilla.org/download/#cvs Is it not possible, or not listed on the site? I always find this to be very useful :-) - Mick From bugreport at peshkin.net Thu Dec 22 03:10:42 2005 From: bugreport at peshkin.net (Joel Peshkin) Date: Wed, 21 Dec 2005 19:10:42 -0800 Subject: Making It Easier To Start Working On Bugzilla In-Reply-To: <17321.60568.248783.824945@gargle.gargle.HOWL> References: <17321.60568.248783.824945@gargle.gargle.HOWL> Message-ID: <43AA1932.4000301@peshkin.net> Albert Ting wrote: >The other is synchronizing existing patches with the code stream schedule. >>From where I stand, the window of opportunity to add new features to an >existing branch is a bit too short for me. Both the reviewer and the >contributor have to be free during that time to go through a couple >iterations. Many of the current patches are so "old" that it now no longer >meets current coding standards. It is now too old and needs to be >revamped. Not sure what is a better solution as I know the Bugzilla team >doesn't want to stretch out the development schedule. > > > I think a common thread is the need to encourage new contributors to discuss their plans with a reviewer before investing a lot of time in a patch. That way, they will have design issues and general roadmap issues addressed in advance as well as confirming that someone is actually interested enough in the feature to do the review. From karl at kornel.name Thu Dec 22 03:21:36 2005 From: karl at kornel.name (A. Karl Kornel) Date: Wed, 21 Dec 2005 22:21:36 -0500 Subject: cvs web? In-Reply-To: <43AA1639.6000007@gmx.net> References: <43AA1639.6000007@gmx.net> Message-ID: On Dec 21, 2005, at 9:58 PM, Mick Weiss wrote: > I was just on the download site again, and I noticed that there is > no way to browse cvs from the web: http://www.bugzilla.org/download/ > #cvs > > Is it not possible, or not listed on the site? I always find this > to be very useful :-) > > - Mick > > > - > To view or change your list settings, click here: > You actually do have two resources available to view Bugzilla files (or any file in the mozilla CVS, for that matter) on the web. * http://lxr.mozilla.org/bugzilla/ This is a cross-referenced listing of all files that make up Bugzilla. Go to to see links to archives for released versions of Bugzilla (2.20, etc.). * http://bonsai.mozilla.org/cvsqueryform.cgi?module=Bugzilla Search for any revision of any file in Bugzilla. This is centered around looking up changes to files in Bugzilla. Also see . That should hopefully give you the info you need. Later! =================== | A. Karl Kornel | | karl at kornel.name =================== From micklweiss at gmx.net Thu Dec 22 03:30:30 2005 From: micklweiss at gmx.net (Mick Weiss) Date: Wed, 21 Dec 2005 22:30:30 -0500 Subject: control characters and Util::clean_text() In-Reply-To: <43A99389.6040304@bugzilla.org> References: <43A95405.2000206@gmail.com> <1135184345.3394.3.camel@localhost.localdomain> <43A99389.6040304@bugzilla.org> Message-ID: <43AA1DD6.8050703@gmx.net> David Miller wrote: > ... > There are security implications for any field which is included in > email headers. Allowing a linefeed lets you insert arbitrary email > headers. > > Of course, the least invasive (and probably most secure) way to fix > this is to strip the control characters before putting things in the > headers. :) > > Technically, you're not allowed anything that's not US-ASCII in email > headers, but that's another bug. Didn't this recently change? I believe umlauts and such characters are (since very very recently) allowed. - Mick From bugreport at peshkin.net Thu Dec 22 03:13:33 2005 From: bugreport at peshkin.net (Joel Peshkin) Date: Wed, 21 Dec 2005 19:13:33 -0800 Subject: cvs web? In-Reply-To: <43AA1639.6000007@gmx.net> References: <43AA1639.6000007@gmx.net> Message-ID: <43AA19DD.5070605@peshkin.net> Mick Weiss wrote: > I was just on the download site again, and I noticed that there is no > way to browse cvs from the web: http://www.bugzilla.org/download/#cvs > > Is it not possible, or not listed on the site? I always find this to > be very useful :-) > Not exactly, but.... http://lxr.mozilla.org/mozilla/source/webtools/bugzilla/ http://bonsai.mozilla.org/rview.cgi?dir=mozilla/webtools/bugzilla&cvsroot=/cvsroot From justdave at bugzilla.org Thu Dec 22 04:39:01 2005 From: justdave at bugzilla.org (David Miller) Date: Wed, 21 Dec 2005 23:39:01 -0500 Subject: control characters and Util::clean_text() In-Reply-To: <43AA1DD6.8050703@gmx.net> References: <43A95405.2000206@gmail.com> <1135184345.3394.3.camel@localhost.localdomain> <43A99389.6040304@bugzilla.org> <43AA1DD6.8050703@gmx.net> Message-ID: <43AA2DE5.9000607@bugzilla.org> Mick Weiss wrote on 12/21/05 10:30 PM: > David Miller wrote: >> Technically, you're not allowed anything that's not US-ASCII in email >> headers, but that's another bug. > > Didn't this recently change? I believe umlauts and such characters are > (since very very recently) allowed. RFC2822 (April 2001) section 2.1 states: A message that is conformant with this standard is comprised of characters with values in the range 1 through 127 and interpreted as US-ASCII characters [ASCII]. For brevity, this document sometimes refers to this range of characters as simply "US-ASCII characters". That RFC is not listed as being obsoleted or updated by any other RFCs yet. The only legal way to get around that is by base64 or quoted-printable encoding the header values, which is described in RFC2045 and RFC2231. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From micklweiss at gmx.net Tue Dec 20 05:12:48 2005 From: micklweiss at gmx.net (Mick Weiss) Date: Tue, 20 Dec 2005 00:12:48 -0500 Subject: http://bugzilla.org Message-ID: <43A792D0.9070008@gmx.net> Hi guys, I have a small request, could someone change the DNS for bugzilla.org to allow not just http://www.bugzilla.org but also http://bugzilla.org ? http://bugzilla.org is used in the docs, but it currently doesn't work ;-) Thanks, - Mick From bugzilla at glob.com.au Thu Dec 22 05:20:52 2005 From: bugzilla at glob.com.au (byron) Date: Thu, 22 Dec 2005 13:20:52 +0800 Subject: control characters and Util::clean_text() In-Reply-To: <43AA2DE5.9000607@bugzilla.org> References: <43A95405.2000206@gmail.com> <1135184345.3394.3.camel@localhost.localdomain> <43A99389.6040304@bugzilla.org> <43AA1DD6.8050703@gmx.net> <43AA2DE5.9000607@bugzilla.org> Message-ID: <20051222052052.GB2482@sweep.bur.st> > >>Technically, you're not allowed anything that's not US-ASCII in email > >>headers, but that's another bug. > > > >Didn't this recently change? I believe umlauts and such characters are > >(since very very recently) allowed. > > RFC2822 (April 2001) section 2.1 states: > > A message that is conformant with this standard is comprised of > characters with values in the range 1 through 127 and interpreted as > US-ASCII characters [ASCII]. For brevity, this document sometimes > refers to this range of characters as simply "US-ASCII characters". > > That RFC is not listed as being obsoleted or updated by any other RFCs yet. > > The only legal way to get around that is by base64 or quoted-printable > encoding the header values, which is described in RFC2045 and RFC2231. RFC1652 (July 1994) introduced 8bit MIME. RFC3030 (December 2000) introduced BDAT (binary version of DATA) [obsoletes RFC1830 - August 1995]. -b begin-base64 644 signature.gif R0lGODlhbQAHAIAAAABPo////ywAAAAAbQAHAAACfAxuGAnch+Bibkn7FL1p XgVl4Ig1jjlZRoqybgun2Cur5uOunq7u/Ipq7WIyIc7XG9JquEgumPzdlhTf h0O83kDJaXEm8mRHwXKJy5sac7qYOpT+gtv0n+0ujQOfdqh16caWt0foBViH N1PRMXimiLUGt3ElVimlgbllWAAAOw== ==== From zach at zachlipton.com Thu Dec 22 05:36:50 2005 From: zach at zachlipton.com (Zach Lipton) Date: Wed, 21 Dec 2005 21:36:50 -0800 Subject: http://bugzilla.org In-Reply-To: <43A792D0.9070008@gmx.net> References: <43A792D0.9070008@gmx.net> Message-ID: <15093ACA-6BDC-4ED5-B608-B82CDEE9F5D4@zachlipton.com> On Dec 19, 2005, at 9:12 PM, Mick Weiss wrote: > I have a small request, could someone change the DNS for > bugzilla.org to allow not just http://www.bugzilla.org but also > http://bugzilla.org ? > http://bugzilla.org is used in the docs, but it currently doesn't > work ;-) > That's odd. http://bugzilla.org works for me. It just gets redirected to www.bugzilla.org. Took a moment to resolve the first time around, but it certainly works. --zach From micklweiss at gmx.net Thu Dec 22 06:24:37 2005 From: micklweiss at gmx.net (Mick Weiss) Date: Thu, 22 Dec 2005 01:24:37 -0500 Subject: cvs web? In-Reply-To: <43AA19DD.5070605@peshkin.net> References: <43AA1639.6000007@gmx.net> <43AA19DD.5070605@peshkin.net> Message-ID: <43AA46A5.3070109@gmx.net> Joel Peshkin wrote: > Mick Weiss wrote: > >> I was just on the download site again, and I noticed that there is no >> way to browse cvs from the web: http://www.bugzilla.org/download/#cvs >> >> Is it not possible, or not listed on the site? I always find this to >> be very useful :-) >> > Not exactly, but.... > http://lxr.mozilla.org/mozilla/source/webtools/bugzilla/ > http://bonsai.mozilla.org/rview.cgi?dir=mozilla/webtools/bugzilla&cvsroot=/cvsroot > Wouldn't that be worth adding to http://www.bugzilla.org/download/#cvs ? - Mick > - > To view or change your list settings, click here: > > > From micklweiss at gmx.net Thu Dec 22 06:25:57 2005 From: micklweiss at gmx.net (Mick Weiss) Date: Thu, 22 Dec 2005 01:25:57 -0500 Subject: http://bugzilla.org In-Reply-To: <15093ACA-6BDC-4ED5-B608-B82CDEE9F5D4@zachlipton.com> References: <43A792D0.9070008@gmx.net> <15093ACA-6BDC-4ED5-B608-B82CDEE9F5D4@zachlipton.com> Message-ID: <43AA46F5.1060906@gmx.net> WFM now too. - Mick Zach Lipton wrote: > On Dec 19, 2005, at 9:12 PM, Mick Weiss wrote: > >> I have a small request, could someone change the DNS for >> bugzilla.org to allow not just http://www.bugzilla.org but also >> http://bugzilla.org ? >> http://bugzilla.org is used in the docs, but it currently doesn't >> work ;-) >> > That's odd. http://bugzilla.org works for me. It just gets redirected > to www.bugzilla.org. Took a moment to resolve the first time around, > but it certainly works. > > --zach > - > To view or change your list settings, click here: > > > From justdave at bugzilla.org Thu Dec 22 07:08:48 2005 From: justdave at bugzilla.org (David Miller) Date: Thu, 22 Dec 2005 02:08:48 -0500 Subject: http://bugzilla.org In-Reply-To: <15093ACA-6BDC-4ED5-B608-B82CDEE9F5D4@zachlipton.com> References: <43A792D0.9070008@gmx.net> <15093ACA-6BDC-4ED5-B608-B82CDEE9F5D4@zachlipton.com> Message-ID: <43AA5100.1020009@bugzilla.org> Zach Lipton wrote on 12/22/05 12:36 AM: > On Dec 19, 2005, at 9:12 PM, Mick Weiss wrote: >> I have a small request, could someone change the DNS for bugzilla.org >> to allow not just http://www.bugzilla.org but also http://bugzilla.org ? >> http://bugzilla.org is used in the docs, but it currently doesn't work >> ;-) >> > That's odd. http://bugzilla.org works for me. It just gets redirected to > www.bugzilla.org. Took a moment to resolve the first time around, but it > certainly works. bugzilla.org and www.bugzilla.org are two different servers. It works this way because of the web interface for the mailing lists. The list server is on bugzilla.org, and the rest of the website on www.bugzilla.org. The URLs for each will redirect to the appropriate server if you hit the wrong one. Noticing the timestamp of when Mick sent that, the upstream provider of the mail server had a several-hour-long outage that day (they had a fiber cut somewhere in Kentucky). We shouldn't be using bugzilla.org without the www on it in the docs anywhere unless we're referring to the mailing list URLs. Otherwise you're causing useless redirects. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From mkanat at bugzilla.org Thu Dec 22 08:59:31 2005 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 22 Dec 2005 00:59:31 -0800 Subject: cvs web? In-Reply-To: <43AA46A5.3070109@gmx.net> References: <43AA1639.6000007@gmx.net> <43AA19DD.5070605@peshkin.net> <43AA46A5.3070109@gmx.net> Message-ID: <1135241971.3421.8.camel@localhost.localdomain> On Thu, 2005-12-22 at 01:24 -0500, Mick Weiss wrote: > Wouldn't that be worth adding to http://www.bugzilla.org/download/#cvs ? Yep. File a bug against Bugzilla -> bugzilla.org. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From chicks at chicks.net Thu Dec 22 09:05:53 2005 From: chicks at chicks.net (Christopher Hicks) Date: Thu, 22 Dec 2005 04:05:53 -0500 (EST) Subject: Future of this list In-Reply-To: <43A8D4DB.7060100@bugzilla.org> References: <43A8D4DB.7060100@bugzilla.org> Message-ID: On Tue, 20 Dec 2005, David Miller wrote: > I *could* make an attempt to gateway *this* mailing list to the new > newsgroup if we wanted. I don't know offhand how to do it. This would seem to be good. Many folks never touch a news reader or google groups. It sounds like the news stuff is being done well enough that spam concerns and such could be addressed without miminal agony. I also like the idea of keeping the existing address as usable for posting purposes. Was any consideration given to an intermidiate sort of list/group? We have a lot of folks who aren't developers of bugzilla itself and don't intend to be who have questions that are more code-oriented. Given that code confuses many sadly (so it should be minimized in the support area) and the developers list should be focused on general issues and isn't the ideal place to deal with support stuff, having another group in between might be good. -- The significant problems we face cannot be solved by the same level of thinking that created them. -- Albert Einstein From LpSolit at gmail.com Thu Dec 22 10:06:08 2005 From: LpSolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Thu, 22 Dec 2005 11:06:08 +0100 Subject: control characters and Util::clean_text() In-Reply-To: <43AA1DD6.8050703@gmx.net> References: <43A95405.2000206@gmail.com> <1135184345.3394.3.camel@localhost.localdomain> <43A99389.6040304@bugzilla.org> <43AA1DD6.8050703@gmx.net> Message-ID: <43AA7A90.60007@gmail.com> > Didn't this recently change? I believe umlauts and such characters are > (since very very recently) allowed. URLs now accept such characters. Maybe that's what you were thinking about? LpSolit From eseyman at linagora.com Thu Dec 22 10:27:26 2005 From: eseyman at linagora.com (Emmanuel Seyman) Date: Thu, 22 Dec 2005 11:27:26 +0100 (CET) Subject: control characters and Util::clean_text() In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203A44C53@ssvlexmb2.amd.com> References: <6F7DA19D05F3CF40B890C7CA2DB13A4203A44C53@ssvlexmb2.amd.com> Message-ID: <53036.192.168.1.254.1135247246.squirrel@tomate.linagora.lan> Benton, Kevin wrote: > > Modifying data given to a program without letting the user know it was > modified in my mind is unacceptable. This is what trim() does and we run it on certains fields. Has any user ever complained? Has it ever caused any corruption? Emmanuel From dennis.melentyev at infopulse.com.ua Thu Dec 22 11:14:16 2005 From: dennis.melentyev at infopulse.com.ua (Dennis Melentyev) Date: Thu, 22 Dec 2005 13:14:16 +0200 Subject: control characters and Util::clean_text() In-Reply-To: <38972.192.168.1.254.1135182932.squirrel@tomate.linagora.lan> References: <43A95405.2000206@gmail.com> <1135179760.66183.5.camel@D-MELENTYEV.HOME> <38972.192.168.1.254.1135182932.squirrel@tomate.linagora.lan> Message-ID: <1135250056.66183.14.camel@D-MELENTYEV.HOME> Wed, 21/12/2005 ? 17:35 +0100, Emmanuel Seyman wrote: > Dennis Melentyev wrote: > > > > ASCII 127 is a *correct* Russian symbol in cp1251 (thanks to M$). > > Also, what to do with UTF-8 input? > > 127 should be DELETE, no matter what charset you are using (since it's > part of the ASCII charset). This is a non-printable character so it should > be trimmed. Please pardon me. I wrongly got it as 0xFF, not 0x7F. Later one means nothing meaningful in cp1251. I just triggered on really frequent problem with 0xFF treated as a whitespace character, which is a small cyrillic "JA". From dennis.melentyev at infopulse.com.ua Thu Dec 22 11:17:56 2005 From: dennis.melentyev at infopulse.com.ua (Dennis Melentyev) Date: Thu, 22 Dec 2005 13:17:56 +0200 Subject: control characters and Util::clean_text() In-Reply-To: <43A99389.6040304@bugzilla.org> References: <43A95405.2000206@gmail.com> <1135184345.3394.3.camel@localhost.localdomain> <43A99389.6040304@bugzilla.org> Message-ID: <1135250276.66183.19.camel@D-MELENTYEV.HOME> Wed, 21/12/2005 ? 12:40 -0500, David Miller wrote: > Max Kanat-Alexander wrote on 12/21/05 11:59 AM: ... > > I don't particularly see a pressing reason to remove control characters > > in most cases, anyhow -- if somebody was silly enough to put a control > > character into a field, perhaps they intended for it to appear there. > > (Unless, of course, displaying the control character has some security > > implication.) > > There are security implications for any field which is included in email > headers. Allowing a linefeed lets you insert arbitrary email headers. > > Of course, the least invasive (and probably most secure) way to fix this > is to strip the control characters before putting things in the headers. :) > > Technically, you're not allowed anything that's not US-ASCII in email > headers, but that's another bug. ... unless you wrap it in base64 or other 7-bit clear encoding. Which is the right way to support localizations and customizations. From dennis.melentyev at infopulse.com.ua Thu Dec 22 11:29:42 2005 From: dennis.melentyev at infopulse.com.ua (Dennis Melentyev) Date: Thu, 22 Dec 2005 13:29:42 +0200 Subject: control characters and Util::clean_text() In-Reply-To: <43AA1DD6.8050703@gmx.net> References: <43A95405.2000206@gmail.com> <1135184345.3394.3.camel@localhost.localdomain> <43A99389.6040304@bugzilla.org> <43AA1DD6.8050703@gmx.net> Message-ID: <1135250982.66183.30.camel@D-MELENTYEV.HOME> Wed, 21/12/2005 ? 22:30 -0500, Mick Weiss wrote: > David Miller wrote: > > > ... > > Technically, you're not allowed anything that's not US-ASCII in email > > headers, but that's another bug. > Didn't this recently change? I believe umlauts and such characters are > (since very very recently) allowed. I'm not aware of any new RFC's on this, but I can state, that most mailers (MTA/MSA/IMAP/POP3) allow 8-bit headers. The only known IMAP server explicitly replacing 8-bit chars to 'X' is courier-imap. So, technically, there is no problem to transmit 8-bit headers but this will violate RFC's. As Dave and I told earlier - the simplest way is to base64/qp encode ALL e-Mail headers. From dennis.melentyev at infopulse.com.ua Thu Dec 22 11:51:05 2005 From: dennis.melentyev at infopulse.com.ua (Dennis Melentyev) Date: Thu, 22 Dec 2005 13:51:05 +0200 Subject: control characters and Util::clean_text() In-Reply-To: <20051222052052.GB2482@sweep.bur.st> References: <43A95405.2000206@gmail.com> <1135184345.3394.3.camel@localhost.localdomain> <43A99389.6040304@bugzilla.org> <43AA1DD6.8050703@gmx.net> <43AA2DE5.9000607@bugzilla.org> <20051222052052.GB2482@sweep.bur.st> Message-ID: <1135252265.66183.45.camel@D-MELENTYEV.HOME> Thr, 22/12/2005 ? 13:20 +0800, byron wrote: > RFC1652 (July 1994) introduced 8bit MIME. This RFC specify that server must accept any bits client will send it. Do not separating header and body of the message, but there still RFC822, which denies NON-ASCII characters in headers. And RFC1521 refers to it in that part. And RFC1522 is more precise, putting all responsibility onto the mail composers/readers while still talking on RFC822 (AKA STD11) conformance: A mail composer that implements this specification will provide a means of inputting non-ASCII text in header fields, but will translate these fields (or appropriate portions of these fields) into encoded-words before inserting them into the message header. A mail reader that implements this specification will recognize encoded-words when they appear in certain portions of the message header. Instead of displaying the encoded-word "as is", it will reverse the encoding and display the original text in the designated character set. (See http://www.faqs.org/rfcs/rfc1522.html for details) > RFC3030 (December 2000) introduced BDAT (binary version of DATA) > [obsoletes RFC1830 - August 1995]. I'm not sure how widely is it supported. Just don't know that. From micklweiss at gmx.net Thu Dec 22 12:42:38 2005 From: micklweiss at gmx.net (Mick Weiss) Date: Thu, 22 Dec 2005 07:42:38 -0500 Subject: control characters and Util::clean_text() In-Reply-To: <43AA7A90.60007@gmail.com> References: <43A95405.2000206@gmail.com> <1135184345.3394.3.camel@localhost.localdomain> <43A99389.6040304@bugzilla.org> <43AA1DD6.8050703@gmx.net> <43AA7A90.60007@gmail.com> Message-ID: <43AA9F3E.4030807@gmx.net> Fr?d?ric Buclin wrote: >> Didn't this recently change? I believe umlauts and such characters >> are (since very very recently) allowed. > > > URLs now accept such characters. Maybe that's what you were thinking > about? Yes, so wouldn't that apply to email addresses (which would be in an email header)? - Mick > > > LpSolit > - > To view or change your list settings, click here: > > > From sothat at bsdx.org Thu Dec 22 10:26:32 2005 From: sothat at bsdx.org (Martin Y. Chiu) Date: Thu, 22 Dec 2005 18:26:32 +0800 Subject: A PAM-login module for bugzilla login Message-ID: <20051222102632.GA31458@bsd.ee.ntu.edu.tw> Dear All, I'd like to use bugzilla with exist user database but didn't find one. So I modified one from CGI.pm & Env.pm, which use Authen::PAM module to authenticate user. You could modify pam_login() for other auth method. With this login module, you should modified your params user_info_class to 'Pam,CGI' with fallback to e-mail auth or use 'Pam' only, and 'emailsuffix' to '@your-email.host'. Attachment is the modified code. -- Sincerely, sothat -------------- next part -------------- A non-text attachment was scrubbed... Name: Pam.pm Type: application/x-perl Size: 13118 bytes Desc: not available URL: From mkanat at bugzilla.org Thu Dec 22 13:38:43 2005 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 22 Dec 2005 05:38:43 -0800 Subject: control characters and Util::clean_text() In-Reply-To: <1135250982.66183.30.camel@D-MELENTYEV.HOME> References: <43A95405.2000206@gmail.com> <1135184345.3394.3.camel@localhost.localdomain> <43A99389.6040304@bugzilla.org> <43AA1DD6.8050703@gmx.net> <1135250982.66183.30.camel@D-MELENTYEV.HOME> Message-ID: <1135258723.6723.1.camel@localhost.localdomain> On Thu, 2005-12-22 at 13:29 +0200, Dennis Melentyev wrote: > So, technically, there is no problem to transmit 8-bit headers but this > will violate RFC's. It causes problems with some mail clients. I've had experience customizing a Bugzilla installation to do that, and some of the developers complained that it caused problems. > As Dave and I told earlier - the simplest way is to base64/qp encode ALL > e-Mail headers. I believe that also causes problems with some mail clients. I know personally that some mail clients do not properly decode qp-encoded subject lines. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From kevin.benton at amd.com Thu Dec 22 15:57:02 2005 From: kevin.benton at amd.com (Benton, Kevin) Date: Thu, 22 Dec 2005 07:57:02 -0800 Subject: control characters and Util::clean_text() Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203A44DF5@ssvlexmb2.amd.com> > > Modifying data given to a program without letting the user know it was > > modified in my mind is unacceptable. > > This is what trim() does and we run it on certains fields. > Has any user ever complained? > Has it ever caused any corruption? If nobody else sees this as a problem, then I will shut up about it. Like I said, I don't have any concrete examples for now, but I do think it could come back to bite us. --- Kevin Benton Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator Personal Computing Systems Group Advanced Micro Devices The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. From kevin.benton at amd.com Thu Dec 22 16:11:52 2005 From: kevin.benton at amd.com (Benton, Kevin) Date: Thu, 22 Dec 2005 08:11:52 -0800 Subject: A PAM-login module for bugzilla login Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203A44DFD@ssvlexmb2.amd.com> Hi Sothat. Thank you for sending us your PAM module update for Bugzilla. The best way to submit information like this is by filing a bug for it on http://bugzilla.mozilla.org/. That way, we can track the history of updates to the module, etc. along with the rest of the updates to Bugzilla. It also helps you get someone to review your update if you add a flag called review and set it to ?. By setting that review flag, it'll tell the review team that you would like someone to look at your code to consider for inclusion in the next release of Bugzilla. I haven't looked at your code yet, but you'll want to make sure you use the testing script included with Bugzilla (runtests.sh). If you get NOK back from any of the tests, you'll need to track down why before submitting your update. I usually do a cvs co first, then use runtests.sh to make sure I don't have to fix anyone else's issues (unlikely, but does happen rarely), then I start making my changes. If runtests.sh reports problems after, then I know I am troubleshooting my updates. When submitting updates to existing files, the best way to do that is by sending us a diff -uN (unified diff, new files treated as empty in old directory). Also, make sure your diff submissions are against the latest revision of what you're trying to see fixed. If you're trying for a new feature in Bugzilla going forward, you'll want to work against the HEAD (sometimes referred to as tip) revision. Again, thanks for your hard work putting together that new module. --- Kevin Benton Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator Personal Computing Systems Group Advanced Micro Devices The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. > -----Original Message----- > From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] > On Behalf Of Martin Y. Chiu > Sent: Thursday, December 22, 2005 3:27 AM > To: developers at bugzilla.org > Subject: A PAM-login module for bugzilla login > > Dear All, > > I'd like to use bugzilla with exist user database but > didn't find one. So I modified one from CGI.pm & Env.pm, which use > Authen::PAM module to authenticate user. You could modify > pam_login() for other auth method. > > With this login module, you should modified your params > user_info_class to 'Pam,CGI' with fallback to e-mail auth > or use 'Pam' only, and 'emailsuffix' to '@your-email.host'. > > Attachment is the modified code. > -- > Sincerely, > sothat From gerv at mozilla.org Fri Dec 23 10:49:16 2005 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 23 Dec 2005 10:49:16 +0000 Subject: Future of this list In-Reply-To: References: <43A8D4DB.7060100@bugzilla.org> Message-ID: <43ABD62C.9060401@mozilla.org> Christopher Hicks wrote: > Was any consideration given to an intermidiate sort of list/group? We > have a lot of folks who aren't developers of bugzilla itself and don't > intend to be who have questions that are more code-oriented. Given that > code confuses many sadly (so it should be minimized in the support area) > and the developers list should be focused on general issues and isn't > the ideal place to deal with support stuff, having another group in > between might be good. I think we'd just end up having more "discussions" about which questions belonged in which group :-) If someone is managing Bugzilla and so confused by code that they refuse to take part in a forum where it's quoted, they have bigger problems than not being able to get support :-) Gerv From gerv at mozilla.org Fri Dec 23 10:52:21 2005 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 23 Dec 2005 10:52:21 +0000 Subject: Future of this list In-Reply-To: <200512210834.jBL8YrRd025440@sinclair.syndicomm.com> References: <200512210834.jBL8YrRd025440@sinclair.syndicomm.com> Message-ID: <43ABD6E5.7000206@mozilla.org> Colin Ogilvie wrote: > Personally, I'd rather see it remain as developers at bugzilla.org, but > couldn't that just simply redirect to the new (VERY LONG) name > @lists.mozilla.org? This seems like the right plan to me, if it's possible. If not, let's just move wholesale over to the new lists, migrating the subscriber email addresses. Gerv From gerv at mozilla.org Fri Dec 23 10:52:20 2005 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 23 Dec 2005 10:52:20 +0000 Subject: Future of this list In-Reply-To: <43A8D4DB.7060100@bugzilla.org> References: <43A8D4DB.7060100@bugzilla.org> Message-ID: <43ABD6E4.5030208@mozilla.org> David Miller wrote: > The new newsgroups will be: > > mozilla.dev.apps.bugzilla <- Bugzilla developer discussion > mozilla.dev.apps.webtools <- Other webtools developer discussion > mozilla.support.bugzilla <- Bugzilla end-user support > mozilla.support.webtools <- Other webtools end-user support > > These will all be gatewayed to mailing lists with periods changed to > hyphens and @lists.mozilla.org tacked on the end. Presumably without the initial, redundant "mozilla"? So e.g. dev-apps-bugzilla at lists.mozilla.org? That's what I'd always imagined and planned, anyway. Gerv From LpSolit at gmail.com Fri Dec 23 11:04:57 2005 From: LpSolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Fri, 23 Dec 2005 12:04:57 +0100 Subject: control characters and Util::clean_text() In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203A44DF5@ssvlexmb2.amd.com> References: <6F7DA19D05F3CF40B890C7CA2DB13A4203A44DF5@ssvlexmb2.amd.com> Message-ID: <43ABD9D9.3010308@gmail.com> I have backed out bug 238780 (Edit versions should reject newline characters) because I found a testcase which makes it to fail and also because we have to take a clear decision on how to handle these control characters. Here are the four choices we have (I see no others for the moment): 1) force checksetup.pl to scan the whole DB to remove such characters (except for fields which are in some given whitelist) and prevent such characters for all future values for fields which are not in this whitelist; 2) only prevent *new* values to have such characters (either new values or renamed values), but let old (existing) values untouched; 3) do nothing (except for bug summaries?) and live with it; 4) force Util::perform_substs() to remove these control characters when preparing the templates to be passed to your MTA, except for fields being in some given whitelist, but don't alter the DB itself. 1. is a problem because scanning the whole DB (even only once) would probably take a huge time. Moreover, we could fall on the testcase I describe in bug 238780 comment 23 (duplicated entries in the DB). The reason to do these changes from checksetup.pl itself is that as long as they are not made by someone with enough privs, e.g. the bug summary by a user with editbugs privs, or a version value by a user with editcomponents privs, the existing "corrupted" values would still be used, and would still be sent as is per email. I reviewed a patch yesterday which automatically removes control characters from bug summaries when editing a bug, but if the user editing this bug is a user with no privs, process_bug.cgi is complaining that this powerless user tries to alter the bug summary (because control characters are removed) and so the user cannot edit bugs having such characters anymore. And so he would have to wait till a nice guy with editbugs privs edits the bug. Argh!! A workaround would be to call CheckCanChangeField() *before* removing such characters so that it doesn't complain if that's really the only change occuring with the bug summary. And this way the bug summary used in the email header would be "clean" (because the new bug summary is used, the old one appearing in the body of the email, which is safe). But there are other fields involved when editing a bug, such as the product name itself, the component name, the product version, the target milestone, etc.. and such values can only be edited by someone with editcomponents privs. But as long as no such users go to edit*.cgi to change these values, the "corrupted" ones would still be used, again and again, and would still appear in emails (but by default, they do not appear in the email header, so that's not a security issue). That's why I suggested to let checksetup.pl do this cleanup itself, to be sure to have a clean and usable DB. 2) here, we keep existing values as is, but prevent to rename them to values having control characters, and also prevent the user from creating new values with such characters. But we would have mixed values, some without and some with control characters in them. We could as well do nothing... this is precisely my point 3). Moreover, even this kind of approach can fail, see again my testcase in bug 238780 comment 23. 4) this last suggestion is to only filter values passed to emails, but without altering values being in the DB. After all, Bugzilla lives pretty well with such characters AFAIK. We would have to edit some email templates too, because not all scripts call perform_substs() (the ones calling BugMail::MessageToMTA() directly) and those have to be checked too, and "FILTER html" used in templates doesn't prevent control characters, so we would need a new "FILTER paranoid" or something like that. As you can see, I have no good solution so far. Some are more invasive than others, some are prone to regressions, etc... Have you other suggestions? Or any preference among the ones I presented here? What I would like, really, is a "Live" discussion on IRC at some given date and time where we could discuss such problems. A kind of weekly (?) "Bugzilla meeting", as someone suggested on IRC a few days ago. LpSolit From gerv at mozilla.org Fri Dec 23 11:50:21 2005 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 23 Dec 2005 11:50:21 +0000 Subject: Making It Easier To Start Working On Bugzilla In-Reply-To: <43A7B46E.80604@gmail.com> References: <1135042796.3564.29.camel@localhost.localdomain> <43A7B46E.80604@gmail.com> Message-ID: <43ABE47D.60603@mozilla.org> Jochen Wiedmann wrote: > At that point, I have two choices: First, I can tell the contributor > what I dislike. Second, I can fix the problems for myself and pull the > patch in. (Or, if a review is required, I can attach a modified version > of the patch.) > > From my experience, Bugzilla developers will *always* choose the first > alternative. I do not know, what the reasons are. It may be lack of > time, but my personal impression is, that accepting the patch will > sometimes be less work than reviewing a modified patch again. One factor for me is that if I take a patch on and fix it up, because of the Bugzilla review process, it then means that I am now responsible for finding someone to review it. My role turns from reviewer to patch submitter. And, knowing how difficult getting reviews is, I don't want to take that on! So the problem amplifies itself - reviews being difficult to get leads to that burden being placed on newbies. Perhaps we could relax the rules so a person could still review a patch to which they had personally made "minor" review markups. Gerv From mkanat at bugzilla.org Fri Dec 23 12:40:47 2005 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 23 Dec 2005 04:40:47 -0800 Subject: control characters and Util::clean_text() In-Reply-To: <43ABD9D9.3010308@gmail.com> References: <6F7DA19D05F3CF40B890C7CA2DB13A4203A44DF5@ssvlexmb2.amd.com> <43ABD9D9.3010308@gmail.com> Message-ID: <1135341648.7550.1.camel@localhost.localdomain> On Fri, 2005-12-23 at 12:04 +0100, Fr?d?ric Buclin wrote: > I have backed out bug 238780 (Edit versions should reject newline > characters) because I found a testcase which makes it to fail and also > because we have to take a clear decision on how to handle these control > characters. If the only place that they cause a *bug* is in emails, then it should only be fixed in emails. There's no reason to fix a problem that nobody is experiencing or going to experience. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From dennis.melentyev at infopulse.com.ua Fri Dec 23 13:02:07 2005 From: dennis.melentyev at infopulse.com.ua (Dennis Melentyev) Date: Fri, 23 Dec 2005 15:02:07 +0200 Subject: control characters and Util::clean_text() In-Reply-To: <1135258723.6723.1.camel@localhost.localdomain> References: <43A95405.2000206@gmail.com> <1135184345.3394.3.camel@localhost.localdomain> <43A99389.6040304@bugzilla.org> <43AA1DD6.8050703@gmx.net> <1135250982.66183.30.camel@D-MELENTYEV.HOME> <1135258723.6723.1.camel@localhost.localdomain> Message-ID: <1135342927.66183.61.camel@D-MELENTYEV.HOME> Thr, 22/12/2005 ? 05:38 -0800, Max Kanat-Alexander wrote: > On Thu, 2005-12-22 at 13:29 +0200, Dennis Melentyev wrote: > > So, technically, there is no problem to transmit 8-bit headers but this > > will violate RFC's. > > It causes problems with some mail clients. I've had experience > customizing a Bugzilla installation to do that, and some of the > developers complained that it caused problems. There is no such mail clients in xUSSR :) Alot of mail just use plain 8-bit Subjects. (Yes, violating the RFC) > > As Dave and I told earlier - the simplest way is to base64/qp encode ALL > > e-Mail headers. > > I believe that also causes problems with some mail clients. I know > personally that some mail clients do not properly decode qp-encoded > subject lines. Could you name them? Afraid, that's limited with old MS Internet Mail, very first MS Outlook and, probably, early Eudora. Nowadays [almost?] all are Ok with that. Please, correct me if I'm wrong. Also, AFAIU, this kind of problem could appear only if you do have 8-bit in headers. So, every administrator could choose whether provide them or not in their templates. I'm pretty sure, there are no users in xUSSR that will have any problem with QP/base64 encoding in headers. Umlaut's users - your turn! From kevin.benton at amd.com Fri Dec 23 16:54:49 2005 From: kevin.benton at amd.com (Benton, Kevin) Date: Fri, 23 Dec 2005 08:54:49 -0800 Subject: control characters and Util::clean_text() Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203A450DB@ssvlexmb2.amd.com> FYI all - I have a user that's seeing a similar if not the same issue. If they drag & drop text from our Debussy tool into Bugzilla 2.17.4 Custom using Mozilla 1.4, 1.5, or 1.7.5, the field (description in this case) gets chopped off at the non-printable character. What's the bug number this issue is being tracked under so I can file my observations against the proper bug? --- Kevin Benton Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator Personal Computing Systems Group Advanced Micro Devices The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. From justdave at bugzilla.org Sat Dec 24 14:27:48 2005 From: justdave at bugzilla.org (David Miller) Date: Sat, 24 Dec 2005 09:27:48 -0500 Subject: Future of this list In-Reply-To: <43ABD6E4.5030208@mozilla.org> References: <43A8D4DB.7060100@bugzilla.org> <43ABD6E4.5030208@mozilla.org> Message-ID: <43AD5AE4.5000806@bugzilla.org> Gervase Markham wrote on 12/23/05 5:52 AM: > David Miller wrote: >> The new newsgroups will be: >> >> mozilla.dev.apps.bugzilla <- Bugzilla developer discussion >> mozilla.dev.apps.webtools <- Other webtools developer discussion >> mozilla.support.bugzilla <- Bugzilla end-user support >> mozilla.support.webtools <- Other webtools end-user support >> >> These will all be gatewayed to mailing lists with periods changed to >> hyphens and @lists.mozilla.org tacked on the end. > > Presumably without the initial, redundant "mozilla"? > > So e.g. dev-apps-bugzilla at lists.mozilla.org? > > That's what I'd always imagined and planned, anyway. Actually, that's not what you planned (see http://www.mozilla.org/community/newsgroups.txt for your original plan), but I like that idea better myself anyway. :) -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From gerv at mozilla.org Sat Dec 24 18:40:53 2005 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 24 Dec 2005 18:40:53 +0000 Subject: Future of this list In-Reply-To: <43AD5AE4.5000806@bugzilla.org> References: <43A8D4DB.7060100@bugzilla.org> <43ABD6E4.5030208@mozilla.org> <43AD5AE4.5000806@bugzilla.org> Message-ID: <43AD9635.7050805@mozilla.org> David Miller wrote: > Actually, that's not what you planned (see > http://www.mozilla.org/community/newsgroups.txt for your original plan), > but I like that idea better myself anyway. :) How right you are. At one time, a long time ago, I must have thought differently. :-) Still, let's go with plan B. Gerv From wicked at etlicon.fi Wed Dec 28 21:24:50 2005 From: wicked at etlicon.fi (wicked at etlicon.fi) Date: Wed, 28 Dec 2005 23:24:50 +0200 Subject: Making It Easier To Start Working On Bugzilla In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203856CBB@ssvlexmb2.amd.com> References: <6F7DA19D05F3CF40B890C7CA2DB13A4203856CBB@ssvlexmb2.amd.com> Message-ID: <43B302A2.6070806@etlicon.com> Benton, Kevin wrote: > More documentation is required to help new developers and reviewers see > the entire development, review, approval and release processes. Note that there's "Review process" chapter in the Reviewer's Guide at http://www.bugzilla.org/docs/reviewer.html. I did find that illuminative when I was trying to find out the process. Granted, it would need some enhancements like mentioning the Reviewer's List. Hmm, I'm sure we mention that list somewhere already.. Maybe docs people should rewrite that section as a separate Guide? -- Teemu Mannermaa System Specialist "Anything is possible. It's all about probabilities." From justdave at bugzilla.org Fri Dec 30 10:32:24 2005 From: justdave at bugzilla.org (David Miller) Date: Fri, 30 Dec 2005 05:32:24 -0500 Subject: [Fwd: Re: Software error] Message-ID: <43B50CB8.1050804@bugzilla.org> -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ -------------- next part -------------- An embedded message was scrubbed... From: Septhar M Subject: Re: Software error Date: Fri, 30 Dec 2005 02:26:39 -0800 (PST) Size: 2501 URL: From gerv at mozilla.org Fri Dec 30 11:57:59 2005 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 30 Dec 2005 11:57:59 +0000 Subject: [Fwd: Re: Software error] In-Reply-To: <43B50CB8.1050804@bugzilla.org> References: <43B50CB8.1050804@bugzilla.org> Message-ID: <43B520C7.3030802@mozilla.org> > I started from > http://landfill.bugzilla.org/bugzilla-2.20-branch/report.cgi > and clicked on "Old Reports", then clicked on > "Continue". > > I observed this error on this page > > http://landfill.bugzilla.org/bugzilla-2.20-branch/reports.cgi?product=-All-&datasets=NEW%3A&datasets=ASSIGNED%3A&datasets=REOPENED%3A&datasets=UNCONFIRMED%3A I see this, although not 100% of the time. It's probably because landfill isn't running collectstats, and doesn't have all the right modules, or both. Gerv From LpSolit at gmail.com Fri Dec 30 12:51:30 2005 From: LpSolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Fri, 30 Dec 2005 13:51:30 +0100 Subject: [Fwd: Re: Software error] In-Reply-To: <43B520C7.3030802@mozilla.org> References: <43B50CB8.1050804@bugzilla.org> <43B520C7.3030802@mozilla.org> Message-ID: <43B52D52.7010504@gmail.com> > I see this, although not 100% of the time. It's probably because > landfill isn't running collectstats, and doesn't have all the right > modules, or both. I also see this error message: Can't locate object method "png" via package "GD::Image" at /usr/lib/perl5/vendor_perl/5.8.5/Chart/Base.pm line 265. The error only appears the first time you access the page. Then, I think Apache remembers that it displayed the error already and doesn't bother you with it again (well, I suppose it's Apache. The same behavior appears when you insert a die() somewhere... it only appears the first time). I can reproduce the error on landfill on our QA installations, where collectstats.pl is running daily, so it's not related to running it or not. I cannot reproduce on my local installations though, so it's specific to landfill. LpSolit