From fedrushkov at users.sourceforge.net Sat Feb 2 05:26:20 2008 From: fedrushkov at users.sourceforge.net (Vitaly Fedrushkov) Date: Sat, 02 Feb 2008 10:26:20 +0500 Subject: Known localization problems... In-Reply-To: References: Message-ID: <47A3FEFC.70803@users.sourceforge.net> > For "Grammatical gender" issue, isn't that already dealt with using > $terms.ABug? $terms.ABug="El Bug" or $terms.ABug="La Peticion"? I must admit that example was too short and fuzzy. $terms.ABug is able to address only 'nearest' dependency, and fail on long distance. For example, as in '$terms.Bug was resolved': El Bug fue resuelto but La petici?n fue resuelta At template/es-es/default/global/variables.none.html: | bug_status => { | "UNCONFIRMED" => "SIN CONFIRMAR", | "NEW" => "NUEVO", | "ASSIGNED" => "ASIGNADO", | "REOPENED" => "REABIERTO", | "RESOLVED" => "RESUELTO", | "VERIFIED" => "VERIFICADO", | "CLOSED" => "CERRADO" | }, Again this one is easily customizable. But at template/es-es/default/global/user-error.none.html: | [% ELSIF error == "bugs_not_changed" %] | [% title = BLOCK %]Los [% terms.bugs %] no han cambiado[% END %] | Parece que no se ha realizado ning?n cambio en los [% terms.bugs %] | seleccionados. it should have read 'las [% terms.bugs %] seleccionadas'. Regards, Vitaly. _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From sam at predisposition.com Sat Feb 2 11:49:42 2008 From: sam at predisposition.com (Sam Folk-Williams) Date: Sat, 2 Feb 2008 06:49:42 -0500 Subject: [DOCS] Shadowdb and Table locking issues Message-ID: I am updating the docs on the configuration parameters (http://www.bugzilla.org/docs/tip/html/parameters.html), and I have a question on the shadowdb bits. It looks like the described behavior of MySQL and table locking is still accurate as of MySQL 5. But, I'm wondering if this same issue exists in Postgres and Oracle? I'd like to add a reference to the other DBs for completeness. Also, I'm wondering if this bit should still be included or if anyone can provide an update on this: "Note that more recent versions of mysql support row level locking using different table types. These types are slower than the standard type, and Bugzilla does not yet take advantage of features such as transactions which would justify this speed decrease. The Bugzilla team are, however, happy to hear about any experiences with row level locking and Bugzilla." Is it still the case that we don't take advantage of these features? Are there new recommendations for dealing with this? For example, MySQL docs say to use InnoDB or BDB to get around the locking problem... Thanks, Sam From apenguinlinux at gmail.com Sat Feb 2 12:21:33 2008 From: apenguinlinux at gmail.com (Deepak Tripathi) Date: Sat, 2 Feb 2008 17:51:33 +0530 Subject: Self-Introduction: Deepak Tripathi Message-ID: <21331eda0802020421x709c500y96cf352f42cda97c@mail.gmail.com> Hi All, I am Deepak Tripathi ,Working as Team Lead in Well known software organization. I basically do work with Perl,Python ,C and Ruby . I also do maintain packages and Debian GNU/Linux and closely associated with debian-perl and debian-ruby group. You can see my current status in Debian on Following link. http://qa.debian.org/developer.php?login=apenguinlinux%40gmail.com&comaint=yes I am interested in joining Bugzilla Team ,I mean i want to contribute as a Developer. I belongs to India . My nick name at irc.mozilla.org is "deepak" and at irc.debian.org is "deepak" Kind to see existing mentors response as soon as possible and tell me the way to contribute . -- Jai Hind Deepak Tripathi E3 71V3 8Y C063 (We Live By Code) http://deepkatripathi.blogspot.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkanat at bugzilla.org Sat Feb 2 16:42:58 2008 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sat, 2 Feb 2008 08:42:58 -0800 Subject: [DOCS] Shadowdb and Table locking issues In-Reply-To: References: Message-ID: <20080202084258.6776ab64@es-compy> On Sat, 2 Feb 2008 06:49:42 -0500 "Sam Folk-Williams" wrote: > I am updating the docs on the configuration parameters > (http://www.bugzilla.org/docs/tip/html/parameters.html), and I have a > question on the shadowdb bits. [snip] We now use transactions instead of locks, in HEAD. Bugzilla does not use whole-table locks anywhere anymore. As far as how valid this section still is, we don't know, because we haven't had any large installations use our new transaction-based code instead of our old locking code. So I have no idea how it performs, or anything. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mkanat at bugzilla.org Sat Feb 2 16:45:27 2008 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sat, 2 Feb 2008 08:45:27 -0800 Subject: Self-Introduction: Deepak Tripathi In-Reply-To: <21331eda0802020421x709c500y96cf352f42cda97c@mail.gmail.com> References: <21331eda0802020421x709c500y96cf352f42cda97c@mail.gmail.com> Message-ID: <20080202084527.6b7ae5b8@es-compy> On Sat, 2 Feb 2008 17:51:33 +0530 "Deepak Tripathi" wrote: > I am interested in joining Bugzilla Team ,I mean i want to contribute > as a Developer. [snip] Hi Deepak! That's great, new contributors are always welcome. Here's a list of bugs that we've marked as being "good intro bugs", meaning that they should be easy (or at least possible) for a newcomer to fix: http://tinyurl.com/2mmepu You could start off by fixing one of those bugs, or by searching for other bugs that you are interested in seeing fixed! -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From sam at predisposition.com Sat Feb 2 22:04:26 2008 From: sam at predisposition.com (Sam Folk-Williams) Date: Sat, 2 Feb 2008 17:04:26 -0500 Subject: [DOCS] Shadowdb and Table locking issues In-Reply-To: <20080202084258.6776ab64@es-compy> References: <20080202084258.6776ab64@es-compy> Message-ID: On 2/2/08, Max Kanat-Alexander wrote: > On Sat, 2 Feb 2008 06:49:42 -0500 "Sam Folk-Williams" > wrote: > > I am updating the docs on the configuration parameters > > (http://www.bugzilla.org/docs/tip/html/parameters.html), and I have a > > question on the shadowdb bits. [snip] > > We now use transactions instead of locks, in HEAD. Bugzilla does > not use whole-table locks anywhere anymore. Hi Max - OK so it looks like the switch was made to InnoDB to avoid this in 3.2, correct? But 3.0 and below still uses MyISAM (and hence locking). So should this whole shadow DB thing be removed for 3.2? Or is there still some benefit to using it? > As far as how valid this > section still is, we don't know, because we haven't had any large > installations use our new transaction-based code instead of our old > locking code. So I have no idea how it performs, or anything. > OK but for 3.2 this is no longer correct: "These types are slower than the standard type, and Bugzilla does not yet take advantage of features such as transactions which would justify this speed decrease". It sounds like now Bugzilla /does/ use these features and InnoDB, yeah? Thanks for the clarification! -Sam > -Max > -- > http://www.everythingsolved.com/ > Competent, Friendly Bugzilla and Perl Services. Everything Else, too. > - > To view or change your list settings, click here: > > From mkanat at bugzilla.org Sun Feb 3 02:54:06 2008 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sat, 2 Feb 2008 18:54:06 -0800 Subject: [DOCS] Shadowdb and Table locking issues In-Reply-To: References: <20080202084258.6776ab64@es-compy> Message-ID: <20080202185406.23d33c30@es-compy> On Sat, 2 Feb 2008 17:04:26 -0500 "Sam Folk-Williams" wrote: > Hi Max - OK so it looks like the switch was made to InnoDB to avoid > this in 3.2, correct? But 3.0 and below still uses MyISAM (and hence > locking). That's right. > So should this whole shadow DB thing be removed for 3.2? Or > is there still some benefit to using it? I really have no idea at this point, actually. > OK but for 3.2 this is no longer correct: "These types are slower than > the standard > type, and Bugzilla does not yet take advantage of features such as > transactions which would justify this speed decrease". It sounds like > now Bugzilla /does/ use these features and InnoDB, yeah? Yes, kind of. Since we aren't MySQL-specific, we don't use the MySQL-specific row-locking SQL, or at the very least we haven't yet identified any race conditions that would make that necessary. There's a certain sort of row-level locking that happens automatically inside our transactions. Anyhow, that was me being all technical, but the simple answer is "Yes, that section is no longer needed." -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From apenguinlinux at gmail.com Sat Feb 2 12:40:23 2008 From: apenguinlinux at gmail.com (Deepak Tripathi) Date: Sat, 2 Feb 2008 18:10:23 +0530 Subject: Self-Introduction: Deepak Tripathi Message-ID: <21331eda0802020440n3cfac7d3j4715c9b299f83cfd@mail.gmail.com> Hi All, I am Deepak Tripathi ,Working as Team Lead in Well known software organization. I basically do work with Perl,Python ,C and Ruby . I also do maintain packages and Debian GNU/Linux and closely associated with debian-perl and debian-ruby group. You can see my current status in Debian on Following link. http://qa.debian.org/developer.php?login=apenguinlinux%40gmail.com&comaint=yes I am interested in joining Bugzilla Team ,I mean i want to contribute as a Developer. I belongs to India . My nick name at irc.mozilla.org is "deepak" and at irc.debian.org is "deepak" Kind to see existing mentors response as soon as possible and tell me the way to contribute . -- Jai Hind Deepak Tripathi E3 71V3 8Y C063 (We Live By Code) http://deepkatripathi.blogspot.com -- Deepak Tripathi E3 71V3 8Y C063 (We Live By Code) http://deepkatripathi.blogspot.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkanat at bugzilla.org Tue Feb 5 02:20:30 2008 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 4 Feb 2008 18:20:30 -0800 Subject: Waiting To Create The Branch Message-ID: <20080204182030.2481b1cb@es-compy> So, I told you that today I'd be creating a BUGZILLA-3_2-BRANCH. I'm going to wait until there's something we'd want to check into trunk that would be appropriate for 4.0 but not for 3.2. That is, there's no reason to branch unless the branch and the trunk are actually going to start being different. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From lpsolit at gmail.com Wed Feb 6 15:06:22 2008 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Wed, 06 Feb 2008 16:06:22 +0100 Subject: Bugzilla meeting next Tuesday at 11:00 PST (19:00 GMT, 20:00 CET) Message-ID: <47A9CCEE.8080102@gmail.com> We will have another Bugzilla meeting next Tuesday, February 12 at 11:00 PST (19:00 GMT, 20:00 CET) in the #bugzilla-meeting channel on irc.mozilla.org. Everyone is free to attend. The agenda is at http://wiki.mozilla.org/Bugzilla:Meetings. See you next week, LpSolit From jeff.hedlund at matrixsi.com Wed Feb 6 19:38:39 2008 From: jeff.hedlund at matrixsi.com (Jeff Hedlund) Date: Wed, 6 Feb 2008 14:38:39 -0500 (EST) Subject: Search by comparing a field to another field? (eg: deadline) Message-ID: <1567.70.43.3.2.1202326719.squirrel@thehedlunds.com> I am looking to accomplish a search "resolved after the deadline". I've done some searching and could not find an appropriate bug to help me out, though LpSolit did recommend I look at bug 380878 (https://bugzilla.mozilla.org/show_bug.cgi?id=380878). It's possible that would meet my needs, but I thought I'd post here as well to see if anyone has any thoughts. One thought I had was to use a special field in the boolean charts ("%deadline%") that would do some special magic behind the scenes to compare the given field with the deadline field. So I could do a boolean chart with "resolved" "changed after" "%deadline%" to see anything that was resolved after the deadline date. Has anyone else implemented this sort of search in a customized bugzilla? Any other ideas? Should I enter a request on b.m.o or would this sort of thing not be desired in the stock Bugzilla distro? Thanks, Jeff From fedrushkov at users.sourceforge.net Wed Feb 6 23:55:51 2008 From: fedrushkov at users.sourceforge.net (Vitaly Fedrushkov) Date: Thu, 07 Feb 2008 04:55:51 +0500 Subject: Search by comparing a field to another field? (eg: deadline) In-Reply-To: References: Message-ID: <47AA4907.3090609@users.sourceforge.net> Jeff Hedlund wrote: > So I could do a boolean chart with "resolved" "changed after" "%deadline%" > to see anything that was resolved after the deadline date. Perhaps we need some macro syntax to refer to any field value instead of constants in comparison. HP OV ServiceDesk suffers the same problem, and adding surrogate status fields changed by triggers here and there increases complexity for almost no gain. Regards, Vitaly. _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From Jesse.J.Clark at nasa.gov Thu Feb 7 01:37:19 2008 From: Jesse.J.Clark at nasa.gov (Jesse J. Clark) Date: Wed, 6 Feb 2008 17:37:19 -0800 Subject: Search by comparing a field to another field? (eg: deadline) In-Reply-To: <47AA4907.3090609@users.sourceforge.net> References: <47AA4907.3090609@users.sourceforge.net> Message-ID: At NASA we have a lot of requests for custom search columns such as "last date that Resolution was changed". A column like this can easily be compared to the deadline column in Excel if you export the search to CSV. What does everybody think about formalizing synthetic search columns for upstream Bugzilla? Jesse J. Clark, Computer Scientist NASA Ames Research Center Office: (650) 604-3242 Mobile: (408) 888-8883 On Feb 6, 2008, at 3:55 PM, Vitaly Fedrushkov wrote: > Jeff Hedlund wrote: >> So I could do a boolean chart with "resolved" "changed after" >> "%deadline%" >> to see anything that was resolved after the deadline date. > > Perhaps we need some macro syntax to refer to any field value > instead of > constants in comparison. > > HP OV ServiceDesk suffers the same problem, and adding surrogate > status > fields changed by triggers here and there increases complexity for > almost no gain. > > Regards, > Vitaly. From bill.winett at tektronix.com Mon Feb 4 19:21:14 2008 From: bill.winett at tektronix.com (bill.winett at tektronix.com) Date: Mon, 4 Feb 2008 11:21:14 -0800 Subject: XSS attack prevention taken out of Template.pm? Message-ID: <8709A371FC010847904C149AEF35163802E179FB@us-bv-m23.global.tektronix.net> Sorry if this has already been discussed or is already documented (I couldn't find either), but I noticed that the following code was removed in version 3.0.3: # Prevent XSS attacks in WYSIWYG fields. xss => sub{ my ($var) = @_; $var =~ s/(<|<)script/_script/ig; $var =~ s/(<|<)\/script(>|>)/script_/gi; return $var; }, Is this code no longer needed? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkanat at bugzilla.org Thu Feb 7 06:16:06 2008 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 6 Feb 2008 22:16:06 -0800 Subject: XSS attack prevention taken out of Template.pm? In-Reply-To: <8709A371FC010847904C149AEF35163802E179FB@us-bv-m23.global.tektronix.net> References: <8709A371FC010847904C149AEF35163802E179FB@us-bv-m23.global.tektronix.net> Message-ID: <20080206221606.295c5cd9@es-compy> On Mon, 4 Feb 2008 11:21:14 -0800 bill.winett at tektronix.com wrote: > xss => sub{ That isn't even in Bugzilla *2.18* code. We don't use any such filter--we have specific filters for HTML, JS, etc. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mkanat at bugzilla.org Thu Feb 7 06:17:04 2008 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 6 Feb 2008 22:17:04 -0800 Subject: Search by comparing a field to another field? (eg: deadline) In-Reply-To: References: <47AA4907.3090609@users.sourceforge.net> Message-ID: <20080206221704.2ae208be@es-compy> On Wed, 6 Feb 2008 17:37:19 -0800 "Jesse J. Clark" wrote: > What does everybody think about formalizing synthetic search columns > for upstream Bugzilla? It depends on the implementation and the complexity it introduces compared to the benefits we get. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From ghendricks at novell.com Thu Feb 7 17:19:51 2008 From: ghendricks at novell.com (Gregary Hendricks) Date: Thu, 07 Feb 2008 10:19:51 -0700 Subject: XSS attack prevention taken out of Template.pm? In-Reply-To: <47AADB47020000D20001A3AE@lucius.provo.novell.com> References: <47AA3FDD020000AD0001F7A3@lucius.provo.novell.com> <47AADB47020000D20001A3AE@lucius.provo.novell.com> Message-ID: <47AADB47020000D20001A3AE@lucius.provo.novell.com> On Wed, 2008-02-06 at 22:16 -0800, Max Kanat-Alexander wrote: > On Mon, 4 Feb 2008 11:21:14 -0800 bill.winett at tektronix.com wrote: > > xss => sub{ > > That isn't even in Bugzilla *2.18* code. We don't use any such > filter--we have specific filters for HTML, JS, etc. > > -Max That is part of the patch for Testopia. If you have installed Testopia it should still be there. If you upgraded your Bugzilla installation from tarball it could be removed. Otherwise I don't know how it went missing on you. Greg From bill.winett at tektronix.com Thu Feb 7 21:47:28 2008 From: bill.winett at tektronix.com (bill.winett at tektronix.com) Date: Thu, 7 Feb 2008 13:47:28 -0800 Subject: XSS attack prevention taken out of Template.pm? In-Reply-To: <47AADB47020000D20001A3AE@lucius.provo.novell.com> References: <47AA3FDD020000AD0001F7A3@lucius.provo.novell.com> <47AADB47020000D20001A3AE@lucius.provo.novell.com> <47AADB47020000D20001A3AE@lucius.provo.novell.com> Message-ID: <8709A371FC010847904C149AEF35163802E18062@us-bv-m23.global.tektronix.net> Thanks for the info. I had installed Testopia and was reinstalling Bugzilla to remote Testopia. Regards, Bill -----Original Message----- From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] On Behalf Of Gregary Hendricks Sent: Thursday, February 07, 2008 9:20 AM To: developers at bugzilla.org; Gregary Hendricks Subject: Re: XSS attack prevention taken out of Template.pm? On Wed, 2008-02-06 at 22:16 -0800, Max Kanat-Alexander wrote: > On Mon, 4 Feb 2008 11:21:14 -0800 bill.winett at tektronix.com wrote: > > xss => sub{ > > That isn't even in Bugzilla *2.18* code. We don't use any such > filter--we have specific filters for HTML, JS, etc. > > -Max That is part of the patch for Testopia. If you have installed Testopia it should still be there. If you upgraded your Bugzilla installation from tarball it could be removed. Otherwise I don't know how it went missing on you. Greg - To view or change your list settings, click here: From lpsolit at gmail.com Tue Feb 12 12:26:14 2008 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Tue, 12 Feb 2008 13:26:14 +0100 Subject: Reminder: Bugzilla meeting today! Message-ID: <47B19066.9080001@gmail.com> Just a reminder: we have another Bugzilla meeting today at 11:00 PST (19:00 GMT, 20:00 CET) on irc.mozilla.org in the #bugzilla-meeting channel. LpSolit From vseerror at lehigh.edu Wed Feb 13 18:15:04 2008 From: vseerror at lehigh.edu (Wayne Mery) Date: Wed, 13 Feb 2008 13:15:04 -0500 Subject: boolean chart OR in b.m.o advanced search Message-ID: <8q-dndqbU4c1ri7anZ2dnUVZ_h2pnZ2d@mozilla.org> Is there a method to join two sets of search results into one query result? Via two boolean charts that are OR instead of AND, or some other method? _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From kristis.makris at asu.edu Thu Feb 14 18:34:28 2008 From: kristis.makris at asu.edu (Kristis Makris) Date: Thu, 14 Feb 2008 11:34:28 -0700 Subject: [scmbug-users] Scmbug error 79: Package 'Bugzilla' not foundin installation In-Reply-To: References: Message-ID: <1203014068.4070.21.camel@localhost> Hello Bugzilla Developers, We are experiencing a problem with Scmbug when Scmbug attempts to reuse the Bugzilla 3.0.3 API. It seems that checking for presence of the "Bugzilla.pm" package fails. The full thread of this discussion is at: http://lists.mkgnu.net/pipermail/scmbug-users/2008-February/001777.html John confirmed that this isn't due to a permissions error. His environment is: scmbug 0-23-4 bugzilla 3.0 and bugzilla 3.0.3 OS: Solaris 8 Perl 5.8.8 MySQL 5.0 My question to the Bugzilla developers is has a similar issue (I'm inclined to attribute this to Solaris) been reported before by people trying to use the Bugzilla API ? Incidentally, the code Scmbug uses to check for the presence of a package was copy-pasted from checksetup.pl:have_vers() from Bugzilla 2.20, which now seems to have been moved in Bugzilla 3.0 in Bugzilla/Install/Requirements.pm. Do you know if there are any issues related to have_vers on Solaris ? > >On Thu, 2008-02-14 at 10:58 -0500, John Coffie wrote: > > > It appears that I can get the scmbug_daemon to start if I do the > >following > > > in /proj/apps/scmbug/share/scmbug/lib/Scmbug/Common.pm: > > > > > > sub package_exists { > > > : > > > : > > > }elsif ($package_name eq "Bugzilla) { > > > $cmd = "require Bugzilla::Bug"; > > > } else { > > > : > > > : > > > } > > > > > > I hardcoded the package name 'Bugzilla' to 'Bugzilla::Bug'. > > > > > > This enabled me to get past this higher level package. All subsequent > > > "Buzilla::XXX" packages processed fine. > > > > > > The "Bugzilla.pm" file that is in the bugzilla installation directory is > >not > > > found by the Common.pm package. It dies at the '( ! eval ($cmd)) section > >of > > > 'Common.pm'. > > > > > > Packages that work: > > > > > > /proj/apps/bugzilla/Bugzilla/XXX.pm > > > > > > package that doesn't work: > > > > > > /proj/apps/bugzilla/Bugzilla.pm (this DOES exist and is the @INC when > > > printed to STDOUT). > > > > > > What gives? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mkanat at bugzilla.org Thu Feb 14 20:05:46 2008 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 14 Feb 2008 12:05:46 -0800 Subject: [scmbug-users] Scmbug error 79: Package 'Bugzilla' not foundin installation In-Reply-To: <1203014068.4070.21.camel@localhost> References: <1203014068.4070.21.camel@localhost> Message-ID: <20080214120546.6b1ef35a@es-compy> On Thu, 14 Feb 2008 11:34:28 -0700 Kristis Makris wrote: > We are experiencing a problem with Scmbug when Scmbug attempts to > reuse the Bugzilla 3.0.3 API. First off, I know I'm being nitpicky, but the "Bugzilla API" is in Bugzilla::WebService. Everything else is just "a bunch of objects and functions we use inside of Bugzilla." > Do you know if there are any issues related to have_vers on Solaris? No, it should work fine, it's all Perl. What you want to do is have him try, inside whatever code is failing to load the Bugzilla module: eval { require Bugzilla; 1; } || die $@; Which will tell you what the problem is. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From kristis.makris at asu.edu Fri Feb 15 17:39:15 2008 From: kristis.makris at asu.edu (Kristis Makris) Date: Fri, 15 Feb 2008 10:39:15 -0700 Subject: [Fwd: Re: [scmbug-users] Scmbug error 79: Package 'Bugzilla' notfoundin inst In-Reply-To: References: Message-ID: <1203097155.4094.25.camel@localhost> John, Many thanks for this investigation and the correction supplied. I applied your fix. Max, thanks for pointing us to the right direction. I don't understand why eval ( ) worked on Linux for so long. But it is what it is. On Fri, 2008-02-15 at 11:14 -0500, John Coffie wrote: > Kristis/Max, > > We placed this code: > eval { require Bugzilla; 1; } || die $@; > in the Common.pm where the packages are being included. It died, but with no > error. We tried a bunch of different things with it, but still no errors > were printed. > > We then tried adding the eval line before the if statement in Common.pm: > 1 eval { require Bugzilla; }; > 2 if ( !eval ( $cmd ) ) { > 3 return 0, ""; > 4 } else { > ... > > Everything worked, although I was confused for awhile as to why that would > work. I then realized that the line 1 eval uses {} and line 2 uses (). I > took out line 1, changed () to {} in line 2 and NO ERROR! > > Fix: change > if ( !eval ( $cmd ) ) { > to > if ( !eval { $cmd } ) { > > It was brought to our attention by another perl colleague that the 'eval {}' > handles the argument differently in that when using 'eval ()' the argument > is treated as text. So our 'require Bugzilla' argument bombed since it > treated it as text. Now, when we use '{}' it tells eval to execute the > "require" function and return its result. > > We were able to get this working. > > Question: How can we tell if SCMBUG is working? Are there test cases we can > run after installing the glue etc? > > Thanks for ALL of your help. > > John/Teri > > > >From: Kristis Makris > >To: John Coffie > >CC: scmbug-users at lists.mkgnu.net > >Subject: [Fwd: Re: [scmbug-users] Scmbug error 79: Package 'Bugzilla' > >notfoundin installation] > >Date: Thu, 14 Feb 2008 14:44:51 -0700 > > > >Teri, perhaps you can try Max's suggestion ? > > > > > >-------- Forwarded Message -------- > >From: Max Kanat-Alexander > >Reply-To: developers at bugzilla.org > >To: developers at bugzilla.org > >Subject: Re: [scmbug-users] Scmbug error 79: Package 'Bugzilla' not > >foundin installation > >Date: Thu, 14 Feb 2008 12:05:46 -0800 > > > >On Thu, 14 Feb 2008 11:34:28 -0700 Kristis Makris > > wrote: > > > We are experiencing a problem with Scmbug when Scmbug attempts to > > > reuse the Bugzilla 3.0.3 API. > > > > First off, I know I'm being nitpicky, but the "Bugzilla API" is > >in Bugzilla::WebService. Everything else is just "a bunch of objects > >and functions we use inside of Bugzilla." > > > > > Do you know if there are any issues related to have_vers on Solaris? > > > > No, it should work fine, it's all Perl. > > > > What you want to do is have him try, inside whatever code is > >failing to load the Bugzilla module: > > > > eval { require Bugzilla; 1; } || die $@; > > > > Which will tell you what the problem is. > > > > -Max > > > ><< signature.asc >> > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mkanat at bugzilla.org Fri Feb 15 23:08:13 2008 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 15 Feb 2008 15:08:13 -0800 Subject: [Fwd: Re: [scmbug-users] Scmbug error 79: Package 'Bugzilla' notfoundin inst In-Reply-To: <1203097155.4094.25.camel@localhost> References: <1203097155.4094.25.camel@localhost> Message-ID: <20080215150813.4912c896@es-compy> On Fri, 15 Feb 2008 10:39:15 -0700 Kristis Makris wrote: > > Fix: change > > if ( !eval ( $cmd ) ) { > > to > > if ( !eval { $cmd } ) { Hrm. Um, actually, that works because $cmd is a string and a string is always true. It's not actually executing the command. An "eval {}" block is just a way of catching exceptions, where a "die" doesn't really cause the system to die. "eval()" on the other hand, actually executes the code contained in the string. He could also try changing his "die $@" in my original code, if it was dying with just "Died" to "die($@ || $!)". -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From lpsolit at gmail.com Mon Feb 18 17:52:09 2008 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Mon, 18 Feb 2008 18:52:09 +0100 Subject: Bug 417290 - The "The bug is resolved or reopened" email pref should also include newly created bugs Message-ID: <47B9C5C9.60601@gmail.com> In bug 417290, I change the "The bug is resolved or reopened" email pref to also include newly created bugs, and rename the pref as "The bug is created, resolved or reopened". Would the majority of you using this email pref agree with this change? The reason to change it is that we currently have no way to get bugmail when a bug is created and resolved only (reopened can be seen as a 2nd life to the bug), and I think both steps are related (status change, start and end of the bug life). Related enough to be enclosed in the same email pref IMO. I know mkanat disagrees with this change (his reason given on IRC didn't convince me; maybe he wants to re-explain it here once more), but I would like more opinions on it. LpSolit From kevin.benton at amd.com Mon Feb 18 18:10:48 2008 From: kevin.benton at amd.com (Benton, Kevin) Date: Mon, 18 Feb 2008 10:10:48 -0800 Subject: Bug 417290 - The "The bug is resolved or reopened" email pref should also include newly created bugs In-Reply-To: <47B9C5C9.60601@gmail.com> References: <47B9C5C9.60601@gmail.com> Message-ID: > In bug 417290, I change the "The bug is resolved or reopened" > email pref > to also include newly created bugs, and rename the pref as > "The bug is > created, resolved or reopened". > > Would the majority of you using this email pref agree with > this change? Frankly, I think we ought to be able to specify email notifications on change by status so that the entire list of possible status changes appears. For example, verification engineers might care about all email until VERIFIED, but most developers won't care about status beyond RESOLVED. With custom workflow, this will become increasingly important because users may want to know when state changes to DEFERRED for example, but not care much as long as things continue to progress. It all depends on the role of the "watcher". Notify me when a bug I have a role in: As Reporter | As Assignee | As CC | As QA Contact | Becomes | Stays | Becomes | Stays | Becomes | Stays | Becomes | Stays | Status O | O | O | O | O | O | O | O | Newly Created O | O | O | O | O | O | O | O | UNCONFIRMED O | O | O | O | O | O | O | O | NEW O | O | O | O | O | O | O | O | REOPENED O | O | O | O | O | O | O | O | DEFERRED O | O | O | O | O | O | O | O | ASSIGNED O | O | O | O | O | O | O | O | RESOLVED O | O | O | O | O | O | O | O | VDEFERRED O | O | O | O | O | O | O | O | VERIFIED O | O | O | O | O | O | O | O | CLOSED Kevin Kevin Benton MySQL DBA #5739 Senior Software Developer CAD Global Infrastructure Flow Services Advanced Micro Devices 2950 E Harmony Rd Fort Collins, CO 80528 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 wurblzap at gmail.com Mon Feb 18 18:22:21 2008 From: wurblzap at gmail.com (Marc Schumann) Date: Mon, 18 Feb 2008 19:22:21 +0100 Subject: Bug 417290 - The "The bug is resolved or reopened" email pref should also include newly created bugs In-Reply-To: References: <47B9C5C9.60601@gmail.com> Message-ID: 2008/2/18, Benton, Kevin : > Frankly, I think we ought to be able to specify email notifications on > change by status so that the entire list of possible status changes > appears. For example, verification engineers might care about all email I'm with Kevin. Plus, it should be product-wise. Let's have the status transition matrix as e-mail prefs: I want to receive an e-mail when the status changes to UNCO NEW ASSI from UNCO NEW ASSI ... with each cell letting me specify bug roles. Marc From lpsolit at gmail.com Mon Feb 18 18:46:04 2008 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Mon, 18 Feb 2008 19:46:04 +0100 Subject: Bug 417290 - The "The bug is resolved or reopened" email pref should also include newly created bugs In-Reply-To: References: <47B9C5C9.60601@gmail.com> Message-ID: <47B9D26C.6020904@gmail.com> > I'm with Kevin. Plus, it should be product-wise. Let's have the status > transition matrix as e-mail prefs: Do you realize how many checkboxes this would involve? Times the number of product if you want it per-product. Why is status transition so important compared to other bug fields? What if I'm only interested in bugs marked blocker or critical, or with priority P1 and P2 only, etc...? This looks insane to me. Maybe should you let your email client tag and filter incoming bugmails rather than making the email prefs UI overcomplicated. In my proposed patch, I'm only talking about open vs closed bugs, not each step between. LpSolit From kevin.benton at amd.com Mon Feb 18 19:03:08 2008 From: kevin.benton at amd.com (Benton, Kevin) Date: Mon, 18 Feb 2008 11:03:08 -0800 Subject: Bug 417290 - The "The bug is resolved or reopened" email pref should also include newly created bugs In-Reply-To: <47B9D26C.6020904@gmail.com> References: <47B9C5C9.60601@gmail.com> <47B9D26C.6020904@gmail.com> Message-ID: > > I'm with Kevin. Plus, it should be product-wise. Let's have > the status > > transition matrix as e-mail prefs: > > Do you realize how many checkboxes this would involve? Times > the number > of product if you want it per-product. Yes, that's why I didn't suggest notifications by product, priority, severity, or other. It is also why I didn't suggest doing notifications by query filter either. > Why is status transition so important compared to other bug > fields? What > if I'm only interested in bugs marked blocker or critical, or with > priority P1 and P2 only, etc...? This looks insane to me. > > Maybe should you let your email client tag and filter > incoming bugmails > rather than making the email prefs UI overcomplicated. > > In my proposed patch, I'm only talking about open vs closed bugs, not > each step between. I think your patch is cool, though I think a nice incremental "next step" will allow users to specify a finer granularity than open versus closed especially for those sites that use QA contacts actively and have implemented other status transitions. You'll note that I did not utilize the full matrix of status transitions as Marc suggested :-) I agree that overly complex notification schemes will only slow things down for everyone and decrease usability. OTOH, what I do see is real value in being able to help users reduce incoming mail before they get it rather than forcing them to create rules to process what they would see as "junk". >From a practical perspective, triagers don't care much about bugs after triage. Developers don't care about bugs except when a bug has been triaged and is assigned to them (or they're on the CC list). QA contacts care about bugs from post-triage until verification has been completed. Program managers care about bugs throughout the entire lifecycle. I think you can see why I responded the way I did. As I said above, I think that this type of matrix can be a very nice incremental next step. :-) Of course it will mean more coding to be done from the UI and the back-end to implement. I'll go ahead and file an enhancement request for this capability. Kevin Benton MySQL DBA #5739 Senior Software Developer CAD Global Infrastructure Flow Services Advanced Micro Devices 2950 E Harmony Rd Fort Collins, CO 80528 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 wurblzap at gmail.com Mon Feb 18 19:59:06 2008 From: wurblzap at gmail.com (Marc Schumann) Date: Mon, 18 Feb 2008 20:59:06 +0100 Subject: Bug 417290 - The "The bug is resolved or reopened" email pref should also include newly created bugs In-Reply-To: <47B9D26C.6020904@gmail.com> References: <47B9C5C9.60601@gmail.com> <47B9D26C.6020904@gmail.com> Message-ID: 2008/2/18, Fr?d?ric Buclin : > Do you realize how many checkboxes this would involve? Times the number > of product if you want it per-product. it's a lot of boxes. Drop-downs, even, if we put roles there. But as it is, I'm a QS person in one product, so I'm interested in new bugs, in status changes to RESOLVED, to FEEDBACK_CUSTOMER, to VERIFIED and to CLOSED. In another product, I'm a QS person as well, but the workflow is different, and I'm interested in status changes to RESOLVED only. In most products, I'm interested in almost anything about bugs I report, but for one product, where I file bugs for others. I'm really, really willing to go through UI hell to get this. Marc From kevin.benton at amd.com Mon Feb 18 22:16:06 2008 From: kevin.benton at amd.com (Benton, Kevin) Date: Mon, 18 Feb 2008 14:16:06 -0800 Subject: Bug 417290 - The "The bug is resolved or reopened" email pref should also include newly created bugs In-Reply-To: References: <47B9C5C9.60601@gmail.com> Message-ID: > Frankly, I think we ought to be able to specify email notifications on > change by status so that the entire list of possible status changes > appears. For example, verification engineers might care > about all email > until VERIFIED, but most developers won't care about status beyond > RESOLVED. With custom workflow, this will become > increasingly important > because users may want to know when state changes to DEFERRED for > example, but not care much as long as things continue to progress. It > all depends on the role of the "watcher". ... Filed https://bugzilla.mozilla.org/show_bug.cgi?id=418301 as promised :-) Kevin Benton MySQL DBA #5739 Senior Software Developer CAD Global Infrastructure Flow Services Advanced Micro Devices 2950 E Harmony Rd Fort Collins, CO 80528 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 mkanat at bugzilla.org Mon Feb 18 22:21:36 2008 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 18 Feb 2008 14:21:36 -0800 Subject: Bug 417290 - The "The bug is resolved or reopened" email pref should also include newly created bugs In-Reply-To: <47B9C5C9.60601@gmail.com> References: <47B9C5C9.60601@gmail.com> Message-ID: <20080218142136.2fd165be@es-compy> On Mon, 18 Feb 2008 18:52:09 +0100 Fr?d?ric Buclin wrote: > The reason to change it is that we currently have no way to > get bugmail when a bug is created Then add a preference "the bug is created". This is like saying, "I have no way to drive to the store, so I'm going to turn my cat into a car." > I know mkanat disagrees with this change (his reason given on IRC > didn't convince me; maybe he wants to re-explain it here once more), > but I would like more opinions on it. "The bug is resolved or reopened" means "the bug is closed, or stops being closed." "The bug is created" means "the bug is created". They aren't related actions. For example, imagine a company where managers want to know where a bug is resolved, but they don't want to know when a bug is filed, because there could be hundreds of bugs filed per day and they don't care about them unless they're confirmed. (For example, I write release notes, so I have exactly this sort of preference.) -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mkanat at bugzilla.org Mon Feb 18 22:23:46 2008 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 18 Feb 2008 14:23:46 -0800 Subject: Bug 417290 - The "The bug is resolved or reopened" email pref should also include newly created bugs In-Reply-To: References: <47B9C5C9.60601@gmail.com> Message-ID: <20080218142346.2a4fa630@es-compy> On Mon, 18 Feb 2008 10:10:48 -0800 "Benton, Kevin" wrote: > Frankly, I think we ought to be able to specify email notifications on > change by status [snip] Although we as advanced Bugzilla users may want that, the UI complexity would be totally overwhelming to the average user. It would also be a lot of implementation for not enough value. Instead we should look into specific real-world use cases and see how best to accommodate them. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From lpsolit at gmail.com Mon Feb 18 22:26:29 2008 From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Mon, 18 Feb 2008 23:26:29 +0100 Subject: Bug 417290 - The "The bug is resolved or reopened" email pref should also include newly created bugs In-Reply-To: <20080218142136.2fd165be@es-compy> References: <47B9C5C9.60601@gmail.com> <20080218142136.2fd165be@es-compy> Message-ID: <47BA0615.5080509@gmail.com> > This is like saying, "I have no way to drive to the store, so > I'm going to turn my cat into a car." Example completely unrelated. > For example, imagine a company where managers want to know > where a bug is resolved, but they don't want to know when a bug is > filed, because there could be hundreds of bugs filed per day and they > don't care about them unless they're confirmed. But as a core developer/triager, I want to know when bugs are both created (to triage them) and resolved (to know what has been fixed (core developer) or incorrectly closed or reopened (triager)). I can implement it as a separate email pref if you *really* want to. LpSolit From mkanat at bugzilla.org Mon Feb 18 22:27:18 2008 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 18 Feb 2008 14:27:18 -0800 Subject: Bug 417290 - The "The bug is resolved or reopened" email pref should also include newly created bugs In-Reply-To: References: <47B9C5C9.60601@gmail.com> <47B9D26C.6020904@gmail.com> Message-ID: <20080218142718.214d3dc9@es-compy> On Mon, 18 Feb 2008 20:59:06 +0100 "Marc Schumann" wrote: > But as it is, I'm a QS person in one product, so I'm interested in new > bugs, in status changes to RESOLVED, to FEEDBACK_CUSTOMER, to VERIFIED > and to CLOSED. In another product, I'm a QS person as well, but the > workflow is different, and I'm interested in status changes to > RESOLVED only. In most products, I'm interested in almost anything > about bugs I report, but for one product, where I file bugs for > others. The correct solution to this problem is: 1) https://bugzilla.mozilla.org/show_bug.cgi?id=278455 2) The ability to "AND" together such criteria. Then, for example, you could say: "QA Contact" is "%user%" AND "Product" is "blah" AND "Status" is "RESOLVED". That would be ultimately flexible for very little UI complexity. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mkanat at bugzilla.org Mon Feb 18 22:47:16 2008 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 18 Feb 2008 14:47:16 -0800 Subject: Bug 417290 - The "The bug is resolved or reopened" email pref should also include newly created bugs In-Reply-To: <47BA0615.5080509@gmail.com> References: <47B9C5C9.60601@gmail.com> <20080218142136.2fd165be@es-compy> <47BA0615.5080509@gmail.com> Message-ID: <20080218144716.66f73de4@es-compy> On Mon, 18 Feb 2008 23:26:29 +0100 Fr?d?ric Buclin wrote: > But as a core developer/triager, I want to know when bugs are both > created (to triage them) and resolved (to know what has been fixed > (core developer) or incorrectly closed or reopened (triager)). > > I can implement it as a separate email pref if you *really* want to. Yes, a separate pref would still allow you to do what you want, and would be more flexible. Also the way the code works now for new bugs, I think it would probably be easier to make it a separate pref anyhow. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From kevin.benton at amd.com Mon Feb 18 22:51:30 2008 From: kevin.benton at amd.com (Benton, Kevin) Date: Mon, 18 Feb 2008 14:51:30 -0800 Subject: Bug 417290 - The "The bug is resolved or reopened" email pref should also include newly created bugs In-Reply-To: <20080218144716.66f73de4@es-compy> References: <47B9C5C9.60601@gmail.com> <20080218142136.2fd165be@es-compy> <47BA0615.5080509@gmail.com> <20080218144716.66f73de4@es-compy> Message-ID: developers-owner at bugzilla.org wrote: > On Mon, 18 Feb 2008 23:26:29 +0100 Fr?d?ric Buclin > wrote: >> But as a core developer/triager, I want to know when bugs are both >> created (to triage them) and resolved (to know what has been fixed >> (core developer) or incorrectly closed or reopened (triager)). >> >> I can implement it as a separate email pref if you *really* want to. > > Yes, a separate pref would still allow you to do what you > want, and would be more flexible. Also the way the code works now for > new bugs, I think it would probably be easier to make it a > separate pref > anyhow. For the list - I responded in bug 278455 in favor of bug 418301 (still there as a point of reference): Max, Re: bug 418301 - I agree that this solution *could* work if it included the ability to do both all base logic types (AND, OR, XOR, and NOT). The problem I see with this is when a notification list is very long, it can take a significant amount of time to send emails. That means a user must "hang in there" longer for the "bug updated" message. A challenge I see in light of this bug (278455) is usability - how does one display the logic tree and how does one tell the system to send email when a value changes to or from another value versus when a value remains in a given state... I must assume that allowing users to do this would have to be a configuration parameter as large installations would probably want to turn this off or keep the number of allowable limitations per-user to a reasonable minimum. I also (wondering out loud) am considering - "How do I tell users how to utilize this method versus the method I proposed in bug 418301?" because it seems that this method will require users to be more Bugzilla-savvy. That's not a bad thing, it just seems that the learning curve will be steeper. Kevin Kevin Benton MySQL DBA #5739 Senior Software Developer CAD Global Infrastructure Flow Services Advanced Micro Devices 2950 E Harmony Rd Fort Collins, CO 80528 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 mkanat at bugzilla.org Mon Feb 18 23:04:43 2008 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 18 Feb 2008 15:04:43 -0800 Subject: Bug 417290 - The "The bug is resolved or reopened" email pref should also include newly created bugs In-Reply-To: References: <47B9C5C9.60601@gmail.com> <20080218142136.2fd165be@es-compy> <47BA0615.5080509@gmail.com> <20080218144716.66f73de4@es-compy> Message-ID: <20080218150443.22d9b59e@es-compy> On Mon, 18 Feb 2008 14:51:30 -0800 "Benton, Kevin" wrote: > For the list - I responded in bug 278455 in favor of bug 418301 > (still there as a point of reference): My answer is in the bug: https://bugzilla.mozilla.org/show_bug.cgi?id=278455#c11 -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From michael.j.tosh at lmco.com Tue Feb 19 14:03:58 2008 From: michael.j.tosh at lmco.com (Tosh, Michael J) Date: Tue, 19 Feb 2008 09:03:58 -0500 Subject: Bug 417551 - Need Dev Input Message-ID: Need opinions on this bug 417551 - CSV headers should be the field description, not the field name https://bugzilla.mozilla.org/show_bug.cgi?id=417551 As a Spreadsheet output format, the default template for list/list.csv.tmpl uses the database column names, which even for the default Bugzilla install, and most likely all Bugzilla's out there, doesn't match the adapted field descriptions. Max & Fr?d?ric suggested I ask developers@ for a preference. We have 4 options: 1) Leave it. (if people reading the csv output don't know what short_desc or short_short_desc is, oh well.) 2) Append a param to the string, &machine=1, to revert to the column names, otherwise display the descriptions 3) Append a param to the string, &spreadsheet=1, to provide pretty column descriptions, otherwise display the column names. This requires a change to list/list.html.tmpl as well as list/list.csv.tmpl. 4) Change it to descriptions only. If an install needs the column headers, they can change their own list.csv.tmpl. Thoughts? Thanks, Tosh Michael J Tosh Lockheed Martin, TSS WJHTC Bldg 316 2nd Fl S074, x5-5831 Quis custodiet ipsos custodes? -------------- next part -------------- An HTML attachment was scrubbed... URL: From wurblzap at gmail.com Tue Feb 19 18:36:28 2008 From: wurblzap at gmail.com (Marc Schumann) Date: Tue, 19 Feb 2008 19:36:28 +0100 Subject: Bug 417551 - Need Dev Input In-Reply-To: References: Message-ID: Michael, 2008/2/19, Tosh, Michael J : > 2) Append a param to the string, &machine=1, to revert to the column names, > otherwise display the descriptions this would be great. This way, people clicking CSV would get human-readable output (and it'd be localizable, too), ready for usage in some spreadsheet application, while we'd still be able to provide machine-readable data. Marc From after.fallout at gmail.com Tue Feb 19 18:42:27 2008 From: after.fallout at gmail.com (Bill Barry) Date: Tue, 19 Feb 2008 11:42:27 -0700 Subject: Bug 417551 - Need Dev Input In-Reply-To: References: Message-ID: <47BB2313.9060509@gmail.com> 2 sounds best to me; occasionally this list is useful when I am writing scripts (and when that happens the column names are helpful), but I don't think they are a good thing most of the time. Tosh, Michael J wrote: > > Need opinions on this bug 417551 - CSV headers should be the field > description, not the field name > _https://bugzilla.mozilla.org/show_bug.cgi?id=417551_ > > > As a Spreadsheet output format, the default template for > list/list.csv.tmpl uses the database column names, which even for the > default Bugzilla install, and most likely all Bugzilla's out there, > doesn't match the adapted field descriptions. Max & Fr?d?ric > suggested I ask developers@ for a preference. > > > We have 4 options: > 1) Leave it. (if people reading the csv output don't know what > short_desc or short_short_desc is, oh well.) > > 2) Append a param to the string, &machine=1, to revert to the column > names, otherwise display the descriptions > > 3) Append a param to the string, &spreadsheet=1, to provide pretty > column descriptions, otherwise display the column names. This > requires a change to list/list.html.tmpl as well as list/list.csv.tmpl. > > 4) Change it to descriptions only. If an install needs the column > headers, they can change their own list.csv.tmpl. > > > Thoughts? > Thanks, > Tosh > > > > Michael J Tosh > Lockheed Martin, TSS > WJHTC Bldg 316 2nd Fl S074, x5-5831 > /Quis custodiet ipsos custodes?/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wessel.lubberhuizen at gmail.com Tue Feb 19 21:49:31 2008 From: wessel.lubberhuizen at gmail.com (WH Lubberhuizen (INSPIRO)) Date: Tue, 19 Feb 2008 13:49:31 -0800 (PST) Subject: Scmbug error 79: Package 'Bugzilla' not foundin installation References: <1203014068.4070.21.camel@localhost> Message-ID: <7023a634-5053-4f52-8e3e-feaf0fd038ff@s37g2000prg.googlegroups.com> This problem may be caused by an old Bugzilla installation residing somewhere in your perl include path. Because scmbug appends the Bugzilla installation directory to the include path, it may try to load the old package. In my case, I wanted to run different Bugzilla versions next to eachother. So applied the following patch: change the line 114 of Daemon/Bugzilla.pm from: push @INC, $self->installation_directory(); to: unshift @INC, $self->installation_directory(); Hope it works! Wessel _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From gerv at mozilla.org Wed Feb 20 10:24:54 2008 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 20 Feb 2008 10:24:54 +0000 Subject: Bug 417551 - Need Dev Input In-Reply-To: References: Message-ID: <47BBFFF6.1020206@mozilla.org> Tosh, Michael J wrote: > We have 4 options: > 1) Leave it. (if people reading the csv output don't know what > short_desc or short_short_desc is, oh well.) > > 2) Append a param to the string, &machine=1, to revert to the column > names, otherwise display the descriptions I'd go for 2, or the reverse - there needs to be a non-localised form. The question is whether it's the default. For backwards-compatibility reasons, it might be better to have a human=1 parameter (or better name) and add that to the links within the product. This has the advantage of making it fairly obvious to a dev reading the url: http://bugzilla/buglist.cgi?human=1 what to do to make it machine-readable. Gerv From mkanat at bugzilla.org Wed Feb 20 22:16:57 2008 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 20 Feb 2008 14:16:57 -0800 Subject: Bug 417551 - Need Dev Input In-Reply-To: <47BBFFF6.1020206@mozilla.org> References: <47BBFFF6.1020206@mozilla.org> Message-ID: <20080220141657.784d613e@es-compy> On Wed, 20 Feb 2008 10:24:54 +0000 Gervase Markham wrote: > This has the advantage of making it fairly obvious to a dev reading > the url: http://bugzilla/buglist.cgi?human=1 > what to do to make it machine-readable. Well, buglist URLs are so long that it won't be that obvious. :-) But yes, I'd go with that. But make that the default when clicking on the CSV link. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mkanat at bugzilla.org Thu Feb 21 00:19:41 2008 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 20 Feb 2008 16:19:41 -0800 Subject: "Root Bug" or "Master Bug"? Message-ID: <20080220161941.0428eb4c@es-compy> So, there's a system for "branches" that I've proposed here: https://bugzilla.mozilla.org/show_bug.cgi?id=55970 I was wondering whether you prefer the term "master bug" or "root bug" for the bug that represents the "main" bug in the relationship, for those who've read the spec on that bug. (The spec calls it "root cause", but for the good reason mentioned in comment 25, that's out of the running.) -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From lpsolit at gmail.com Thu Feb 21 00:25:48 2008 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Thu, 21 Feb 2008 01:25:48 +0100 Subject: "Root Bug" or "Master Bug"? In-Reply-To: <20080220161941.0428eb4c@es-compy> References: <20080220161941.0428eb4c@es-compy> Message-ID: <47BCC50C.40407@gmail.com> > I was wondering whether you prefer the term "master bug" or > "root bug" master From dwierenga at valueclick.com Thu Feb 21 00:31:06 2008 From: dwierenga at valueclick.com (Dan Wierenga) Date: Wed, 20 Feb 2008 16:31:06 -0800 Subject: "Root Bug" or "Master Bug"? In-Reply-To: <20080220161941.0428eb4c@es-compy> References: <20080220161941.0428eb4c@es-compy> Message-ID: <24CF2B9B9D2BCC4B8F6EA9528B63C83609A56815@LA-EXCLUST01.corp.valueclick.com> I like the term "master bug" much better. My reasoning: a) "root bug" immediately makes me think of some issue regarding a Unix superuser. Not so good for my blood pressure. Trivial, however, compared to: b) There's a lot of "tree" terminology already, and this doesn't mesh. You've got a trunk, and you've got some branches. And now you're going to define a "root bug" which will almost certainly sit on a branch and not at the gravity-facing end of the trunk where you'd expect to find "roots". Just my $0.02 though. > -----Original Message----- > From: developers-owner at bugzilla.org [mailto:developers- > owner at bugzilla.org] On Behalf Of Max Kanat-Alexander > Sent: Wednesday, February 20, 2008 4:20 PM > To: developers at bugzilla.org > Subject: "Root Bug" or "Master Bug"? > > > So, there's a system for "branches" that I've proposed here: > > https://bugzilla.mozilla.org/show_bug.cgi?id=55970 > > I was wondering whether you prefer the term "master bug" or > "root bug" for the bug that represents the "main" bug in the > relationship, for those who've read the spec on that bug. (The spec > calls it "root cause", but for the good reason mentioned in comment 25, > that's out of the running.) > > -Max > -- > http://www.everythingsolved.com/ > Competent, Friendly Bugzilla and Perl Services. Everything Else, too. > - > To view or change your list settings, click here: > From guy.pyrzak at gmail.com Thu Feb 21 01:31:08 2008 From: guy.pyrzak at gmail.com (Guy Pyrzak) Date: Wed, 20 Feb 2008 17:31:08 -0800 Subject: "Root Bug" or "Master Bug"? In-Reply-To: <24CF2B9B9D2BCC4B8F6EA9528B63C83609A56815@LA-EXCLUST01.corp.valueclick.com> References: <20080220161941.0428eb4c@es-compy> <24CF2B9B9D2BCC4B8F6EA9528B63C83609A56815@LA-EXCLUST01.corp.valueclick.com> Message-ID: I prefer [% terms.master_bug %] in the template code I think it should be called fhqwhgads, or whatever makes the other developers happy, as long as it isn't jocking me (or any of the other end users). -g On Wed, Feb 20, 2008 at 4:31 PM, Dan Wierenga wrote: > I like the term "master bug" much better. My reasoning: > > a) "root bug" immediately makes me think of some issue regarding a Unix > superuser. Not so good for my blood pressure. Trivial, however, > compared to: > b) There's a lot of "tree" terminology already, and this doesn't mesh. > You've got a trunk, and you've got some branches. And now you're going > to define a "root bug" which will almost certainly sit on a branch and > not at the gravity-facing end of the trunk where you'd expect to find > "roots". > > Just my $0.02 though. > > > > -----Original Message----- > > From: developers-owner at bugzilla.org [mailto:developers- > > owner at bugzilla.org] On Behalf Of Max Kanat-Alexander > > Sent: Wednesday, February 20, 2008 4:20 PM > > To: developers at bugzilla.org > > Subject: "Root Bug" or "Master Bug"? > > > > > > So, there's a system for "branches" that I've proposed here: > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=55970 > > > > I was wondering whether you prefer the term "master bug" or > > "root bug" for the bug that represents the "main" bug in the > > relationship, for those who've read the spec on that bug. (The spec > > calls it "root cause", but for the good reason mentioned in comment > 25, > > that's out of the running.) > > > > -Max > > -- > > http://www.everythingsolved.com/ > > Competent, Friendly Bugzilla and Perl Services. Everything Else, too. > > - > > To view or change your list settings, click here: > > > - > To view or change your list settings, click here: > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla at displague.com Thu Feb 21 22:42:44 2008 From: bugzilla at displague.com (Marques Johansson) Date: Thu, 21 Feb 2008 17:42:44 -0500 Subject: Self-Introduction: Marques Johansson Message-ID: <527759310802211442p5cc5631dv57c2594d67965310@mail.gmail.com> Hello. I'm Marques Johansson. I'm rarely found on IRC, but when I am, I'm displague (displague.com). I live in Egg Harbor City, NJ, USA somewhere between Atlantic City and Philadelphia. I currently work in Philadelphia as a PHP developer (vod.com,voddollars.com,others) but my background is all over the board as development and administration goes. I'm a very proficient UNIX admin, current in the ways of Linux, especially Debian and Ubuntu. I've spent a few years employed as a Solaris admin as well (pppl.gov). I introduced my company to Bugzilla a little over a year ago. With 1300 filed bugs, I'd say adoption has gone pretty well - but most issues continue to be dealt with outside of the system. The process could be streamlined for some departments that don't want to fill out the details of a bug (or be presented with complex fields like "description"). As for other skills, I'm a good listener ( nevermind what my wife says ;-) ) and I'll likely chime in when I feel I can contribute. I'm enrolling by invitation from Max Kanat-Alexander to close a bug I submitted (Bug 418672). I have other local changes, but I'll need to review their worth before submitting them as patches. -- Marques Johansson bugzilla at displague.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkanat at bugzilla.org Fri Feb 22 06:04:27 2008 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 21 Feb 2008 22:04:27 -0800 Subject: Self-Introduction: Marques Johansson In-Reply-To: <527759310802211442p5cc5631dv57c2594d67965310@mail.gmail.com> References: <527759310802211442p5cc5631dv57c2594d67965310@mail.gmail.com> Message-ID: <20080221220427.5faec4f8@es-compy> On Thu, 21 Feb 2008 17:42:44 -0500 "Marques Johansson" wrote: > I introduced my company to Bugzilla a little over a year ago. With > 1300 filed bugs, I'd say adoption has gone pretty well - but most > issues continue to be dealt with outside of the system. The process > could be streamlined for some departments that don't want to fill out > the details of a bug (or be presented with complex fields like > "description"). Yeah, we have a bug filed for streamlining the entry page. Actually, all of the infrastructure for that is done for 3.2, we just have to add a preference for it. > As for other skills, I'm a good listener ( nevermind what my wife > says ;-) ) and I'll likely chime in when I feel I can contribute. Great! > I'm enrolling by invitation from Max Kanat-Alexander to close a bug I > submitted (Bug 418672). I have other local changes, but I'll need to > review their worth before submitting them as patches. Sure. You can search and see if we already have bugs filed for similar things and check their priority (or as me or someone else to set their priority), and that could give you an idea how wanted they are. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From guy.pyrzak at gmail.com Fri Feb 22 10:10:14 2008 From: guy.pyrzak at gmail.com (Guy Pyrzak) Date: Fri, 22 Feb 2008 02:10:14 -0800 Subject: Another bug? Message-ID: So I know this probably a can of worms that I kinda don't want to get into but.... I found this cool site with public domain images, i did a search for insects and bugs and found the following: http://openclipart.org/media/files/valessiobrito/2564 http://openclipart.org/media/files/aurium/1450 http://www.pdphoto.org/PictureDetail.php?pg=5348&mat=pdef a public domain image site: http://www.pdphoto.org/index.php or http://www.openstockphotography.org/stock-photography-search/insect the list of the insect tags (incase you all are interested) http://openclipart.org/media/tags/insect I'm sure everyone is very happy with the current bug on the homepage, but something to think about. -Guy -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerv at mozilla.org Fri Feb 22 14:17:46 2008 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 22 Feb 2008 14:17:46 +0000 Subject: "Root Bug" or "Master Bug"? In-Reply-To: References: <20080220161941.0428eb4c@es-compy> <24CF2B9B9D2BCC4B8F6EA9528B63C83609A56815@LA-EXCLUST01.corp.valueclick.com> Message-ID: <47BED98A.7040202@mozilla.org> Guy Pyrzak wrote: > I prefer [% terms.master_bug %] in the template code I think it should > be called fhqwhgads, or whatever makes the other developers happy, as > long as it isn't jocking me (or any of the other end users). I think we should strongly resist the temptation to parameterise too many terms. A case made for this one would have to be strong. I prefer "master bug". Gerv From guy.pyrzak at gmail.com Fri Feb 22 17:47:40 2008 From: guy.pyrzak at gmail.com (Guy Pyrzak) Date: Fri, 22 Feb 2008 09:47:40 -0800 Subject: "Root Bug" or "Master Bug"? In-Reply-To: <47BED98A.7040202@mozilla.org> References: <20080220161941.0428eb4c@es-compy> <24CF2B9B9D2BCC4B8F6EA9528B63C83609A56815@LA-EXCLUST01.corp.valueclick.com> <47BED98A.7040202@mozilla.org> Message-ID: I was kinda hoping for a resounding "of course!" but since that wasn't the response let me make my strong case for this. The terms that have been discussed are "master/slave" and "root/branch", however, other possibilities include "parent/child", "base/associated", or "hen/chicks" (actually used by NASA engineers due to over use of root and master). I understand why people dislike root. Some systems don't use the word bug they use the word "cause", others use the word issue, others ticket. Bugzilla implemented [% terms.bugs %] for that exact reason, so that bugzilla could be used in different domains. It just so happens that in the developer domain the term "root" is overused due to the CVS and linux terminology. However, in other domains the term "master" means many different things and could just as easily be just as equally over used and frustrating to users. In a hardware company the term master might be overused the same way as root is in a software company. (I can list many more examples here if that would make my case stronger) Then there is the fact that in some areas of the US and the world as a whole, having the terms master/slave appear anywhere is generally disliked unless undeniably appropriate. I know this might sound silly, but in the same way the term root has connotations to linux developers master/slave has connotations to others due to not too distant history. For example, a southern school that has this as their student bug reporting and tracking system might just rather not have the word master/slave all over their website. I'm not saying this to sound silly, but I could imagine this happening at a school which is trying to be as sensitive as possible. The other question is what is the paradigm we are following, does the master bug control the other bugs (as the term master/slave suggests?) Or is the master bug actually the base from which all the others are associated? Master would suggest that closing/changing the master would cause the slaves to follow suit (the same way changing the master database changes its slaves), is that the case? b/c i understood that to be an option but not always true. Can the slave have slaves? If so that seems weird, although I do recall hearing in some cultures slaves could have slaves, so eh. But the term master/slave definitely implies ownership and control and I'm not sure if that's the association we want to make, maybe it is. Based on these 3 points above I feel like the parameterization of this term makes sense. However, if you all still think that parameterization is too much I would strongly suggest using a less over used term than master or root b/c both can be over used in various domains. -Guy On Fri, Feb 22, 2008 at 6:17 AM, Gervase Markham wrote: > Guy Pyrzak wrote: > > I prefer [% terms.master_bug %] in the template code I think it should > > be called fhqwhgads, or whatever makes the other developers happy, as > > long as it isn't jocking me (or any of the other end users). > > I think we should strongly resist the temptation to parameterise too > many terms. A case made for this one would have to be strong. > > I prefer "master bug". > > Gerv > - > To view or change your list settings, click here: > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkanat at bugzilla.org Sat Feb 23 00:06:11 2008 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 22 Feb 2008 16:06:11 -0800 Subject: "Root Bug" or "Master Bug"? In-Reply-To: References: <20080220161941.0428eb4c@es-compy> <24CF2B9B9D2BCC4B8F6EA9528B63C83609A56815@LA-EXCLUST01.corp.valueclick.com> <47BED98A.7040202@mozilla.org> Message-ID: <20080222160611.2a02d567@es-compy> On Fri, 22 Feb 2008 09:47:40 -0800 "Guy Pyrzak" wrote: > Based on these 3 points above I feel like the parameterization of > this term makes sense. However, if you all still think that > parameterization is too much I would strongly suggest using a less > over used term than master or root b/c both can be over used in > various domains. This is all fair enough, but I don't think that the term "master bug" will be used in so many places that it would currently deserve parameterization. Let's wait and see if there's a problem before imagining one and solving the imaginary problem. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From fedrushkov at users.sourceforge.net Sat Feb 23 00:26:57 2008 From: fedrushkov at users.sourceforge.net (Vitaly Fedrushkov) Date: Sat, 23 Feb 2008 05:26:57 +0500 Subject: "Root Bug" or "Master Bug"? In-Reply-To: References: Message-ID: <47BF6851.8050208@users.sourceforge.net> This resembles early ITIL terminology disputes. Now, with difference between Incident Management and Problem Management widely understood, it is called a 'Problem': Problem The root cause of one or more incidents. See Problem Management, Problem Record. Problem Control (Problem Management) Part of the Problem Management Process. Problem Control is the Activity responsible for identifying the Root Cause and developing a Workaround or Structural Solution for a Problem. Error Control (Problem Management) The Activity responsible for managing Known Errors until they are Resolved by the successful implementation of Changes. See Problem Control. http://www.itil.org/en/shortcuts/glossarinhalt/glossarp.php Bugzilla by itself is not an ITIL tool, so standard term is 'Bug', not 'Incident'. But it IS widely used for incident management tasks. Regards, Vitaly. _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From lpsolit at gmail.com Sat Feb 23 15:51:33 2008 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Sat, 23 Feb 2008 16:51:33 +0100 Subject: Bugzilla meeting next Tuesday, Feb 26 Message-ID: <47C04105.7050707@gmail.com> Hi all, Our next meeting will take place on Tuesday, February 26 at 11:00 PST (19:00 GMT, 20:00 CET) on irc.mozilla.org in the #bugzilla-meeting channel. Everyone is free to attend. If you would like us to discuss about some specific topic, please add your suggestions to our agenda at http://wiki.mozilla.org/Bugzilla:Meetings See you on Tuesday, LpSolit From repeat at gmail.com Tue Feb 26 15:46:09 2008 From: repeat at gmail.com (Repeat) Date: Tue, 26 Feb 2008 07:46:09 -0800 (PST) Subject: Bugzilla traditional Chinese localization Message-ID: <39fb1d72-6090-4432-b832-47bd930764db@s37g2000prg.googlegroups.com> Hi all, I have recently created a traditional Chinese localization (zh-TW) of Bugzilla 3.1.2. The localization pack is now at http://code.google.com/p/bugzilla-tw/ and is public for download. I would like to know whether I need to provide any other information or not. Thank you. Best regards, Repeat _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From naujas at kaunoturgus.lt Thu Feb 28 07:40:10 2008 From: naujas at kaunoturgus.lt (news.mozilla.org) Date: Thu, 28 Feb 2008 09:40:10 +0200 Subject: www.kaunoturgus.lt Message-ID: -- View the new internet autos page Buy and sell for free www.kaunoturgus.lt _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From hexsmith at gmail.com Sun Feb 24 09:46:30 2008 From: hexsmith at gmail.com (Scott Glazer) Date: Sun, 24 Feb 2008 01:46:30 -0800 Subject: LP.net Feature Suggestion Message-ID: <1203846390.29276.12.camel@puff> Hello, I was pondering a method for enticing users to fix bugs, and I shared the idea I had with a friend of mine who suggested that I forward to you: Similar to the way prizes have been offered as a bounty for developing software, I assume a similar idea could be applied to Launchpad. When a user submits a bug report, confirms that they experience the same problem, or simply posts a feature request, they should have the ability to donate to a bounty pool. When the bug is fixed or the feature implemented, and this is confirmed by the users experiencing the problems (or requesting the feature), then the pool is released to the contributing developers. Of course, as with other types of donations, a percentage could be lifted for administrative needs -- servers, bandwidth, personnel, etc. I'm simply sharing this idea in the hopes that it can be used to coordinate developers where they are needed most. Many users donating a little can add up to a significant amount for a given bug. A few users donating a lot of money can get a bug fixed that is of great importance to them even if it benefits the community little. As I said, I discussed this idea with a friend, and one of the concerns he brought up was distribution support within the FOSS community. I urge you to forward this idea to anyone else in the community who may be able to use it in a productive way. Additionally, I'm concerned that bugs that receive large support may be targeted by developers, and other projects would be sidelined; in an effort to minimize this, a percentage of the bounty may be spread equally among a random sampling of bugs. Given enough donations, random bugs would also accrue bounties -- though without bounties being placed directly on them, they would accrue much slower. Thanks for reading, and I hope this idea is useful, -Scott _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla