From jth at mikrobitti.fi Tue Apr 1 11:56:46 2003 From: jth at mikrobitti.fi (Jouni Heikniemi) Date: Tue, 01 Apr 2003 14:56:46 +0300 Subject: SQL call formatting style In-Reply-To: <3E862096.9000608@mozilla.org> References: Message-ID: <5.1.0.14.2.20030401143928.0305c590@mikrobitti.fi> At 22:39 29.3.2003 +0000, you wrote: >- If people's code is creating warnings, it won't get checked in By the way, this is not true. Apache (with the default configuration) is a bit deceptive, because runtime warnings are buried in the error log where nobody really reads them. Run Bugzilla on IIS (which redirects standard error stream into the standard output) for a while, and you'll notice how many warnings a completely functional Bugzilla installation can emit :-) I'm not saying that the current tip creates warnings, though; our cvs checkout from December does, but at least some of those were already fixed before I could file bugs on them. >- If people don't understand interpolation in Perl, I'd be wary about >letting them write code for Bugzilla This is true, but I agree with bbaetz that understanding quotation and basics like q{} is equally important. What makes me want to minimize the use of "" is the ease of _accidentally_ typing something like '$a = "abc at def.example"' and not noticing it. Other than that, I have no opinion on this. Jouni From justdave at syndicomm.com Tue Apr 1 17:50:53 2003 From: justdave at syndicomm.com (David Miller) Date: Tue, 1 Apr 2003 12:50:53 -0500 Subject: SQL call formatting style In-Reply-To: <3E862096.9000608@mozilla.org> References: <3E862096.9000608@mozilla.org> Message-ID: On 3/29/03 10:39 PM +0000, Gervase Markham wrote: > Anyway, we are now going round in circles, and it's time for a justdave > ruling :-) > > Dave? Pick a "standard", or say there's none and everyone can use > whatever quoting style they like. If I had to pick a preference, I'd go for the q{} stuff, personally. Once you get past that initial hurdle of realizing it's a way to quote, I find it much easier to read, and you don't have to worry about quoting quotes inside it, which can cause coding errors if you're not careful with normal quotes. :) And vim seems perfectly happy to syntax highlight it correctly :) My general practice has been to use q{} or qq{} in situations where there will be quotes inside the string, and in line nearby the ones done that was for consistency, and "" or '' otherwise, which actually, now that I look at it, is exactly what it says in 'man perlstyle' which is what we've already stated is our guide for coding style. :) -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From justdave at syndicomm.com Tue Apr 1 19:29:07 2003 From: justdave at syndicomm.com (David Miller) Date: Tue, 1 Apr 2003 14:29:07 -0500 Subject: SQL call formatting style In-Reply-To: References: <3E862096.9000608@mozilla.org> Message-ID: On 4/1/03 12:50 PM -0500, David Miller wrote: > and in line nearby the ones done that was for consistency s/line/lines/ s/was/way/ I wasn't awake enough to type straight yet :) -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From gerv at mozilla.org Tue Apr 1 22:44:55 2003 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 01 Apr 2003 23:44:55 +0100 Subject: SQL call formatting style In-Reply-To: References: <3E862096.9000608@mozilla.org> Message-ID: <3E8A1667.9050803@mozilla.org> David Miller wrote: > On 3/29/03 10:39 PM +0000, Gervase Markham wrote: > If I had to pick a preference, I'd go for the q{} stuff, personally. OK :-) Revised proposal: my ($comma, $separated, $list, $of, $vars, $on, $one, $line) = $dbh->some_longwinded_methodname(q{SELECT some SQL variables ON multiple lines IF necessary WITH placeholders ?, ?, ?}, undef, $placeholder, $variables, $here); How's that look? The SQL block could be outdented if you need the room, and the placeholders could run onto a second line if necessary. I think this combines compactness with readability; it's also pretty like most of the calls currently in the code. Gerv From gerv at mozilla.org Wed Apr 2 10:42:52 2003 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 02 Apr 2003 11:42:52 +0100 Subject: bz2gnats Message-ID: <3E8ABEAC.3000300@mozilla.org> http://bz2gnats.sourceforge.net/ I wonder how many people would actually move from Bugzilla to Gnats? What do they have that we don't? :-) Gerv From bbaetz at acm.org Wed Apr 2 11:36:54 2003 From: bbaetz at acm.org (Bradley Baetz) Date: Wed, 2 Apr 2003 21:36:54 +1000 Subject: bz2gnats In-Reply-To: <3E8ABEAC.3000300@mozilla.org> References: <3E8ABEAC.3000300@mozilla.org> Message-ID: <20030402113654.GA2143@mango.home> On Wed, Apr 02, 2003 at 11:42:52AM +0100, Gervase Markham wrote: > http://bz2gnats.sourceforge.net/ > > I wonder how many people would actually move from Bugzilla to Gnats? > What do they have that we don't? :-) http://gcc.gnu.org/ml/gcc/2003-03/msg01809.html http://gcc.gnu.org/ml/gcc/2003-03/msg01811.html :) Bradley From gerv at mozilla.org Wed Apr 2 14:22:40 2003 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 02 Apr 2003 15:22:40 +0100 Subject: bz2gnats In-Reply-To: <20030402113654.GA2143@mango.home> References: <3E8ABEAC.3000300@mozilla.org> <20030402113654.GA2143@mango.home> Message-ID: <3E8AF230.3040304@mozilla.org> Bradley Baetz wrote: > On Wed, Apr 02, 2003 at 11:42:52AM +0100, Gervase Markham wrote: > >>http://bz2gnats.sourceforge.net/ >> >>I wonder how many people would actually move from Bugzilla to Gnats? >>What do they have that we don't? :-) > > http://gcc.gnu.org/ml/gcc/2003-03/msg01809.html > http://gcc.gnu.org/ml/gcc/2003-03/msg01811.html Well yes :-) But I mean people who are _really_ moving from Bugzilla to Gnats. Gerv From jon at vmware.com Wed Apr 2 20:36:28 2003 From: jon at vmware.com (Jonathan Schatz) Date: 02 Apr 2003 12:36:28 -0800 Subject: bz2gnats In-Reply-To: <3E8ABEAC.3000300@mozilla.org> References: <3E8ABEAC.3000300@mozilla.org> Message-ID: <1049315788.23152.9.camel@jonschatz-lx.vmware.com> On Wed, 2003-04-02 at 02:42, Gervase Markham wrote: > I wonder how many people would actually move from Bugzilla to Gnats? > What do they have that we don't? :-) 1) a db index that corrupts itself without requiring user interaction 2) an innovative way to store bug information using RFC 822 3) a revolutionary new hardware benchmarking system built in to their free form text search (searching through ~25k records on our p4 2.4ghz gnats server brings it to its' knees) -jon -- Jonathan Schatz Engineering System Administrator VMware, Inc "Te occidere possunt sed te edere non possunt nefas est." From JWilmoth at starbucks.com Wed Apr 2 21:18:28 2003 From: JWilmoth at starbucks.com (Jon Wilmoth) Date: Wed, 2 Apr 2003 13:18:28 -0800 Subject: Legal Keywords in 2.17.3 Message-ID: I'd like to customize the keywords text field to be a select element. Previously (2.16.x) I was able to modify bug_form.pl to add this list. However, that is now gone in 2.17.3. Where is the best place to initialize a template variable that is an array of all the available keywords (Assuming one doesn't already exist)? Thanks, Jon Jon Wilmoth Technical Specialist Global SCCO IT ext. 84745 From myk at mozilla.org Wed Apr 2 21:43:39 2003 From: myk at mozilla.org (Myk Melez) Date: Wed, 02 Apr 2003 13:43:39 -0800 Subject: SQL call formatting style In-Reply-To: <3E8A1667.9050803@mozilla.org> References: <3E862096.9000608@mozilla.org> <3E8A1667.9050803@mozilla.org> Message-ID: <3E8B598B.3010408@mozilla.org> Gervase Markham wrote: > David Miller wrote: > >> On 3/29/03 10:39 PM +0000, Gervase Markham wrote: >> If I had to pick a preference, I'd go for the q{} stuff, personally. > > > OK :-) > > Revised proposal: > > my ($comma, $separated, $list, $of, $vars, $on, $one, $line) = > $dbh->some_longwinded_methodname(q{SELECT some SQL variables > ON multiple lines > IF necessary > WITH placeholders ?, ?, ?}, > undef, > $placeholder, $variables, $here); > > How's that look? The SQL block could be outdented if you need the > room, and the placeholders could run onto a second line if necessary. > I think this combines compactness with readability; it's also pretty > like most of the calls currently in the code. That's ok, except we should allow the following when the name is really long: $dbh->some_longwinded_methodname( q{SELECT some SQL variables ON multiple lines IF necessary WITH placeholders ?, ?, ?}, undef, $placeholder, $variables, $here ); And placeholders should be able to be aligned vertically (perhaps this should be the default in fact): $dbh->some_longwinded_methodname(q{SELECT some SQL variables ON multiple lines IF necessary WITH placeholders ?, ?, ?}, undef, $placeholder, $variables, $here); And indenting the SQL a few extra spaces would help readability: $dbh->some_longwinded_methodname( q{ SELECT some SQL variables ON multiple lines IF necessary WITH placeholders ?, ?, ?}, undef, $placeholder, $variables, $here ); $dbh->some_longwinded_methodname(q{ SELECT some SQL variables ON multiple lines IF necessary WITH placeholders ?, ?, ?}, undef, $placeholder, $variables, $here); And this should be a recommendation, not a rule. -myk From myk at mozilla.org Wed Apr 2 21:52:06 2003 From: myk at mozilla.org (Myk Melez) Date: Wed, 02 Apr 2003 13:52:06 -0800 Subject: Legal Keywords in 2.17.3 In-Reply-To: References: Message-ID: <3E8B5B86.7000505@mozilla.org> Jon Wilmoth wrote: >I'd like to customize the keywords text field to be a select element. >Previously (2.16.x) I was able to modify bug_form.pl to add this list. >However, that is now gone in 2.17.3. Where is the best place to >initialize a template variable that is an array of all the available >keywords (Assuming one doesn't already exist)? > > See the rotted code in bug 80169 (http://bugzilla.mozilla.org/show_bug.cgi?id=80169) for another pre-templatization implementation of this feature. I would add the code to show_bug.cgi after the GetVersionTable call and just set $vars->{keywords} to @::legal_keywords or %::keywordsbyname. -myk From justdave at syndicomm.com Wed Apr 2 21:55:44 2003 From: justdave at syndicomm.com (David Miller) Date: Wed, 2 Apr 2003 16:55:44 -0500 Subject: Legal Keywords in 2.17.3 In-Reply-To: <3E8B5B86.7000505@mozilla.org> References: <3E8B5B86.7000505@mozilla.org> Message-ID: On 4/2/03 1:52 PM -0800, Myk Melez wrote: > Jon Wilmoth wrote: > >>I'd like to customize the keywords text field to be a select element. >>Previously (2.16.x) I was able to modify bug_form.pl to add this list. >>However, that is now gone in 2.17.3. Where is the best place to >>initialize a template variable that is an array of all the available >>keywords (Assuming one doesn't already exist)? >> >> > See the rotted code in bug 80169 > (http://bugzilla.mozilla.org/show_bug.cgi?id=80169) for another > pre-templatization implementation of this feature. > > I would add the code to show_bug.cgi after the GetVersionTable call and > just set $vars->{keywords} to @::legal_keywords or %::keywordsbyname. Actually, show_bug.cgi isn't a good place to put it because it'll be missing when the bug form is displayed after changing a bug in process_bug. I'd probably put it in the choices sub in Bug.pm. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From JWilmoth at starbucks.com Wed Apr 2 23:44:22 2003 From: JWilmoth at starbucks.com (Jon Wilmoth) Date: Wed, 2 Apr 2003 15:44:22 -0800 Subject: Legal Keywords in 2.17.3 Message-ID: Thanks! That did the trick. BTW...Is anyone interested in changing the keywords from an open text box to a select list? If so, I'd be more than willing to contribute a patch to 2.17.3! -----Original Message----- From: David Miller [mailto:justdave at syndicomm.com] Sent: Wednesday, April 02, 2003 1:56 PM To: developers at bugzilla.org Subject: Re: Legal Keywords in 2.17.3 On 4/2/03 1:52 PM -0800, Myk Melez wrote: > Jon Wilmoth wrote: > >>I'd like to customize the keywords text field to be a select element. >>Previously (2.16.x) I was able to modify bug_form.pl to add this list. >>However, that is now gone in 2.17.3. Where is the best place to >>initialize a template variable that is an array of all the available >>keywords (Assuming one doesn't already exist)? >> >> > See the rotted code in bug 80169 > (http://bugzilla.mozilla.org/show_bug.cgi?id=80169) for another > pre-templatization implementation of this feature. > > I would add the code to show_bug.cgi after the GetVersionTable call and > just set $vars->{keywords} to @::legal_keywords or %::keywordsbyname. Actually, show_bug.cgi isn't a good place to put it because it'll be missing when the bug form is displayed after changing a bug in process_bug. I'd probably put it in the choices sub in Bug.pm. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ ---- To view or change your list settings, click here: From myk at mozilla.org Thu Apr 3 00:35:51 2003 From: myk at mozilla.org (Myk Melez) Date: Wed, 02 Apr 2003 16:35:51 -0800 Subject: Legal Keywords in 2.17.3 In-Reply-To: References: Message-ID: <3E8B81E7.3080606@mozilla.org> Jon Wilmoth wrote: >Thanks! That did the trick. > >BTW...Is anyone interested in changing the keywords from an open text >box to a select list? If so, I'd be more than willing to contribute a >patch to 2.17.3! > > A multi-select list? Those tend to be the bane of users' existences. Novice users don't understand them, and power users find them clumsy. At least one UI expert (Alan Cooper) recommends against them, although I think you can get away with them for small lists where every option is visible at all times. Or did you have something else in mind? -myk From justdave at syndicomm.com Thu Apr 3 00:40:43 2003 From: justdave at syndicomm.com (David Miller) Date: Wed, 2 Apr 2003 19:40:43 -0500 Subject: Legal Keywords in 2.17.3 In-Reply-To: <3E8B81E7.3080606@mozilla.org> References: <3E8B81E7.3080606@mozilla.org> Message-ID: On 4/2/03 4:35 PM -0800, Myk Melez wrote: > Jon Wilmoth wrote: > >>Thanks! That did the trick. >> >>BTW...Is anyone interested in changing the keywords from an open text >>box to a select list? If so, I'd be more than willing to contribute a >>patch to 2.17.3! >> >> > A multi-select list? Those tend to be the bane of users' existences. > Novice users don't understand them, and power users find them clumsy. > At least one UI expert (Alan Cooper) recommends against them, although I > think you can get away with them for small lists where every option is > visible at all times. Or did you have something else in mind? I think if it worked exactly like the CC list it might be usable. For example, a text box to put in a comma-separated list of keywords to add, and the list box only contains the ones that are already there. Then you have a checkbox to check to remove the ones you highlighted in the list box to get rid of them. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From JWilmoth at starbucks.com Thu Apr 3 00:49:44 2003 From: JWilmoth at starbucks.com (Jon Wilmoth) Date: Wed, 2 Apr 2003 16:49:44 -0800 Subject: Legal Keywords in 2.17.3 Message-ID: This is what we use here. I can definitely see how they could be the "bane of users' existence". However we have a pretty small list ~8 (6 are shown at a time) and it seems to work pretty well. Users here weren't putting in keywords because they either didn't know what to put in (yes...even though the describekeywords gives them the list of possibilities. I'm not sure the keywords list would ever be very large since they have to apply to all products. -----Original Message----- From: Myk Melez [mailto:myk at mozilla.org] Sent: Wednesday, April 02, 2003 4:36 PM To: developers at bugzilla.org Subject: Re: Legal Keywords in 2.17.3 Jon Wilmoth wrote: >Thanks! That did the trick. > >BTW...Is anyone interested in changing the keywords from an open text >box to a select list? If so, I'd be more than willing to contribute a >patch to 2.17.3! > > A multi-select list? Those tend to be the bane of users' existences. Novice users don't understand them, and power users find them clumsy. At least one UI expert (Alan Cooper) recommends against them, although I think you can get away with them for small lists where every option is visible at all times. Or did you have something else in mind? -myk ---- To view or change your list settings, click here: From myk at mozilla.org Thu Apr 3 01:00:01 2003 From: myk at mozilla.org (Myk Melez) Date: Wed, 02 Apr 2003 17:00:01 -0800 Subject: Legal Keywords in 2.17.3 In-Reply-To: References: Message-ID: <3E8B8791.5010504@mozilla.org> Jon Wilmoth wrote: >This is what we use here. I can definitely see how they could be the >"bane of users' existence". However we have a pretty small list ~8 (6 >are shown at a time) and it seems to work pretty well. Users here >weren't putting in keywords because they either didn't know what to put >in (yes...even though the describekeywords gives them the list of >possibilities. > > If you are comfortable with your users having JavaScript capabilities, I think the solution proposed in bug 80169 is a pretty good one. It provides two drop-down menus next to the keywords field, one for adding keywords and one for removing them. Keywords get added to/removed from the field as the user selects them from the lists. http://bugzilla.mozilla.org/show_bug.cgi?id=80169 This aids discoverability, since users can look at the lists to see what they can add, while improving usability, since users can select an item from a list to add it instead of having to type it into a text field filled with other keywords and can remove keywords using the same kind of mechanism they used to add them. >I'm not sure the keywords list would ever be very large since they have >to apply to all products. > > Yeah, that needs to be fixed, and there's even a bug on it, although it hasn't gotten any traction for a while. http://bugzilla.mozilla.org/show_bug.cgi?id=106592 -myk From jason at pyeron.com Thu Apr 3 01:15:47 2003 From: jason at pyeron.com (Jason Pyeron) Date: Wed, 2 Apr 2003 20:15:47 -0500 (EST) Subject: Legal Keywords in 2.17.3 In-Reply-To: <3E8B8791.5010504@mozilla.org> Message-ID: Here is what we did for some asp modeled inventory software. We had a situation where new entries were added at a rate of one per week. we had a multi select above and underneath and a icon [add new] wich set the style to disp=yes showing the box further lynx always showed the text box (not understanding display=none) next we had a js listener on the box whenever it lost focus or enter was pressed, it added it to the box above (registered it w/ the server 1st) in the selected state. if the browser did not understand js then the list was post processed, all the same. Jason Pyeron On Wed, 2 Apr 2003, Myk Melez wrote: Jon Wilmoth wrote: >This is what we use here. I can definitely see how they could be the >"bane of users' existence". However we have a pretty small list ~8 (6 >are shown at a time) and it seems to work pretty well. Users here >weren't putting in keywords because they either didn't know what to put >in (yes...even though the describekeywords gives them the list of >possibilities. > > If you are comfortable with your users having JavaScript capabilities, I think the solution proposed in bug 80169 is a pretty good one. It provides two drop-down menus next to the keywords field, one for adding keywords and one for removing them. Keywords get added to/removed from the field as the user selects them from the lists. http://bugzilla.mozilla.org/show_bug.cgi?id=80169 This aids discoverability, since users can look at the lists to see what they can add, while improving usability, since users can select an item from a list to add it instead of having to type it into a text field filled with other keywords and can remove keywords using the same kind of mechanism they used to add them. >I'm not sure the keywords list would ever be very large since they have >to apply to all products. > > Yeah, that needs to be fixed, and there's even a bug on it, although it hasn't gotten any traction for a while. http://bugzilla.mozilla.org/show_bug.cgi?id=106592 -myk ---- To view or change your list settings, click here: -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron http://www.pyerotechnics.com - - Owner & Lead Pyerotechnics Development, Inc. - - +1 410 808 6646 (c) 500 West University Parkway #1S - - +1 410 467 2266 (f) Baltimore, Maryland 21210-3253 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, purge the message from your system and notify the sender immediately. Any other use of the email by you is prohibited. From bbaetz at acm.org Thu Apr 3 07:49:49 2003 From: bbaetz at acm.org (Bradley Baetz) Date: Thu, 3 Apr 2003 17:49:49 +1000 Subject: Legal Keywords in 2.17.3 In-Reply-To: References: Message-ID: <20030403074949.GA1241@mango.home> On Wed, Apr 02, 2003 at 04:49:44PM -0800, Jon Wilmoth wrote: > This is what we use here. I can definitely see how they could be the > "bane of users' existence". However we have a pretty small list ~8 (6 > are shown at a time) and it seems to work pretty well. Users here > weren't putting in keywords because they either didn't know what to put > in (yes...even though the describekeywords gives them the list of > possibilities. If you only have a small number of keywords, why not make them into bug flags instead? Bradley From caseyg at chsamerica.com Fri Apr 4 16:42:53 2003 From: caseyg at chsamerica.com (Casey Gregoire) Date: Fri, 4 Apr 2003 11:42:53 -0500 Subject: Conversion of Outside Bug database to Bugzilla Message-ID: Is there some sort of import program for importing data from outside databases into the bug database? Maybe something I can export to that I can run an import on to get data from an outside database into Bugzilla? Thank you, Casey Gregoire Programmer CHS of America 100 1st Ave S. Suite 601 St. Petersburg, FL 33701 Phone - (727) 824-0800 ext 1236 Every great achievement was once impossible. -- Anonymous I'd like to get started on time, if we can, inasmuch as we're late already. -- Larry Gelbart Nothing is accomplished without passion. -- My Fortune Cookie From caseyg at chsamerica.com Fri Apr 4 17:02:45 2003 From: caseyg at chsamerica.com (Casey Gregoire) Date: Fri, 4 Apr 2003 12:02:45 -0500 Subject: Enter_bug.cgi Message-ID: When I go to the enter_bug.cgi on the Bugzilla.org I get a quite different looking bug entry then the one I see on the current system that I run 2.17.3. Is this is because it has changed since that version? Or is it in my system, and not showing? If it is not in the current system, could I get it easily? Thank you, Casey Gregoire Programmer CHS of America 100 1st Ave S. Suite 601 St. Petersburg, FL 33701 Phone - (727) 824-0800 ext 1236 Every great achievement was once impossible. -- Anonymous I'd like to get started on time, if we can, inasmuch as we're late already. -- Larry Gelbart Nothing is accomplished without passion. -- My Fortune Cookie From gerv at mozilla.org Fri Apr 4 19:57:05 2003 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 04 Apr 2003 20:57:05 +0100 Subject: Enter_bug.cgi In-Reply-To: References: Message-ID: <3E8DE391.3090705@mozilla.org> Casey Gregoire wrote: > When I go to the enter_bug.cgi on the Bugzilla.org I get a quite different > looking bug entry then the one I see on the current system that I run > 2.17.3. Is this is because it has changed since that version? Or is it in my > system, and not showing? If it is not in the current system, could I get it > easily? You mean http://bugzilla.mozilla.org ? The Guided bug entry format is in the 2.17.3 distribution - add &format=guided to the enter_bug.cgi URL. But it's mozilla.org-specific; you'll need to customise it. Gerv From gerv at mozilla.org Fri Apr 4 19:59:01 2003 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 04 Apr 2003 20:59:01 +0100 Subject: Conversion of Outside Bug database to Bugzilla In-Reply-To: References: Message-ID: <3E8DE405.7060709@mozilla.org> Casey Gregoire wrote: > Is there some sort of import program for importing data from outside > databases into the bug database? Maybe something I can export to that I can > run an import on to get data from an outside database into Bugzilla? No, because there are as many formats the data could be in as there are bug systems. You can either write your own input script to write directly to the database, or convert to XML and use importxml.pl. The latter might well be safer. Gerv From caseyg at chsamerica.com Fri Apr 4 20:22:30 2003 From: caseyg at chsamerica.com (Casey Gregoire) Date: Fri, 4 Apr 2003 15:22:30 -0500 Subject: Conversion of Outside Bug database to Bugzilla Message-ID: That is what I was looking for, the is there a format for the XML export? I actually have to import from two different systems so this would be ideal. Thanks, Casey Gregoire -----Original Message----- From: Gervase Markham [mailto:gerv at mozilla.org] Sent: Friday, April 04, 2003 2:59 PM To: developers at bugzilla.org Subject: Re: Conversion of Outside Bug database to Bugzilla Casey Gregoire wrote: > Is there some sort of import program for importing data from outside > databases into the bug database? Maybe something I can export to that I can > run an import on to get data from an outside database into Bugzilla? No, because there are as many formats the data could be in as there are bug systems. You can either write your own input script to write directly to the database, or convert to XML and use importxml.pl. The latter might well be safer. Gerv ---- To view or change your list settings, click here: From justdave at syndicomm.com Fri Apr 4 20:32:26 2003 From: justdave at syndicomm.com (David Miller) Date: Fri, 4 Apr 2003 15:32:26 -0500 Subject: Conversion of Outside Bug database to Bugzilla In-Reply-To: References: Message-ID: On 4/4/03 3:22 PM -0500, Casey Gregoire wrote: > That is what I was looking for, the is there a format for the XML export? I > actually have to import from two different systems so this would be ideal. bugzilla.dtd in your distribution folder, if you know how to read DTD files. Otherwise it should be easy enough to reverse-engineer the output from xml.cgi -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From gerv at mozilla.org Fri Apr 4 20:44:15 2003 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 04 Apr 2003 21:44:15 +0100 Subject: Conversion of Outside Bug database to Bugzilla In-Reply-To: References: Message-ID: <3E8DEE9F.5090604@mozilla.org> Casey Gregoire wrote: > That is what I was looking for, the is there a format for the XML export? I > actually have to import from two different systems so this would be ideal. I assume you mean XML import. Yes, there is. See bugzilla.dtd. Gerv From gerv at mozilla.org Fri Apr 4 21:50:48 2003 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 04 Apr 2003 22:50:48 +0100 Subject: Bugzilla Installation List Message-ID: <3E8DFE38.6000705@mozilla.org> Here it is - 213 of them in all, obtained by a long trawl through Google. The page is generated from a plain text list by a quick bit of Perl. It's rather heartwarming to know we have so many users. I'll turn this into a proper website page at some point. Gerv -------------- next part -------------- An HTML attachment was scrubbed... URL: From justdave at syndicomm.com Fri Apr 4 21:58:18 2003 From: justdave at syndicomm.com (David Miller) Date: Fri, 4 Apr 2003 16:58:18 -0500 Subject: Bugzilla Installation List In-Reply-To: <3E8DFE38.6000705@mozilla.org> References: <3E8DFE38.6000705@mozilla.org> Message-ID: On 4/4/03 10:50 PM +0100, Gervase Markham wrote: > Here it is - 213 of them in all, obtained by a long trawl through > Google. The page is generated from a plain text list by a quick bit of Perl. > > It's rather heartwarming to know we have so many users. A few I know of that are missing from your list: Activestate: http://bugs.activestate.com/ InTrec Software: http://bugzilla.intrec.com/ Syndicomm: http://bugzilla.syndicomm.com/ -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From daa at rm.incc.net Fri Apr 4 23:50:11 2003 From: daa at rm.incc.net (David Avery) Date: Fri, 4 Apr 2003 16:50:11 -0700 Subject: Bugzilla Installation List In-Reply-To: <3E8DFE38.6000705@mozilla.org>; from gerv@mozilla.org on Fri, Apr 04, 2003 at 10:50:48PM +0100 References: <3E8DFE38.6000705@mozilla.org> Message-ID: <20030404165011.A25317@daa.dyndns.org> also www.distrtibuted.net/bugs "Distributed.net" and intrnal use at UD.com "United devices" dave From etzwane at schwag.org Sat Apr 5 01:33:38 2003 From: etzwane at schwag.org (Sean McAfee) Date: Fri, 04 Apr 2003 20:33:38 -0500 Subject: New custom fields proposal Message-ID: <20030405013338.5BC22C2CC@diggity.schwag.org> Hi, folks-- Enclosed is my proposal for new custom field functionality to be added to Bugzilla. Please read, discuss, criticize, etc., especially the "Open questions". Note that this is a requirements document, and describes only WHAT I'd like to see implemented, not HOW it is to be implemented. The "how" will be left for a future document, when we've settled on the "what". Also note that I've omitted any reference to how custom fields will be administered. This is obviously important, but I found myself getting bogged down in the details, so I decided to just go ahead and send the part I'd completed. --Sean McAfee ---------------------------------------------------------------------- Definition ========== Currently, Bugzilla offers a fixed number of named fields to describe bugs. These fields are shared across every component in the system. The proposed additional functionalty is the ability to define additional fields on a per-component basis. These additional fields are called "custom fields". Custom fields will be available in five major varieties: integer, float, string, date, and selection. The first four of these types are collectively referred to as "scalar" types. All scalar fields can be set to a special "undefined" value in additional to the valid values described below. Integer ------- An integer custom field contains values which are integers. Such fields must be able to store at least the range of integers which are typically represented as a signed four-byte quantity. [Open question: Should integer fields be available in signed and unsigned varieties?] Bugzilla should signal an error condition if a user attempts to store an integer outside of the allowed range into an integer field. [Open question: Should Bugzilla transparently offer large-integer semantics?] Bugzilla may emit client-side scripting code onto any pages that request custom-field input that will abort form submission if an integer field's submitted value is out of range. Float ----- A float custom fields contains values which are floating-point numbers. Such fields must be able to store at least the range of floating-point numbers which are typically represented as an eight-byte double-precision quantity. When a user enters a text string which is intended to be stored in a float field, it must match the usual pattern: * an optional leading plus sign ('+') or minus sign ('-'); * an integer part consisting only of digits; * an fractional part matching the following pattern: + a period character ('.'); + an optional sequence of digits; + an optional exponent, expressed as an 'E' or 'e' character, followed by an optional plus sign ('+') or minus sign ('-'), followed by a sequence of digits Either the integer part or the fractional part may be omitted, but not both. Bugzilla should signal an error condition if a user attempts to store a floating-point number outside of the allowed range into a float field. String ------ This type of field contains human-readable text. [Open question: Should Bugzilla reject attempts to store arbitrary binary data in a string field?] Each string field is flagged as belonging to one of two varieties: short and long. A short string field can hold a maximum of 255 characters, and may contain no vertical whitespace characters (carriage return, newline, or vertical tab). It is represented on Bugzilla's Web interface using a single-line text form element. A long string field can hold large amounts of text, possibly consisting of several lines. It is represented on Bugzilla's Web interface as a multiline textarea form element. Date ---- A date field contains either a date (ie, a specific day of a specific month in a specific year), a time of day (ie, an hour from 0-23 inclusive, and a minute and second, both from 0-59 inclusive), or both. Each date field is flagged as containing one of these three subsets of data. [Open question: Is the "time of day" subtype really necessary?] Bugzilla should signal an error condition if a user attempts to store an illegal date value in a date field. Examples: * An invalid day of the month: March 50, February 30 * An invalid date: February 29, 2001 * An invalid time: 12:66:00 Date fields are represented on Bugzilla's web interface using a pair of drop-down listbox form elements (for the month and day) and a single-line text-entry element (for the year) for the date portion of the field's value (if appropriate), and a single-line text entry widget for the time portion (if appropriate). Bugzilla should signal an error if an invalid date or time is submitted. [Open question: Is this too busy? Should a simple text-entry widget suffice for all date types?] Selection --------- A selection field takes its value from a set of distinct string values. No string value in any selection field's set of valid values may contain vertical whitespace, contain leading or trailing whitespace, or exceed 255 characters in length. [Open question: Should there be a limit on the size of the set of valid strings? If so, should this limit be global or per-component?] Each selection field comes in one of two varieties: "single-selection" and "multiselection". A single-selection field's value is a subset of the field's possible values of size either zero or one. It is represented on Bugzilla's web interface as a drop-down listbox form element. A multiselection field's value is an arbitrary subset of the field's possible values. It is represented on Bugzilla's web interface as a multiline listbox in which multiple simultaneous selections are allowed. Each selection field's set of allowed values may be specified in one of two ways. A "local" selection field's values are defined by the Bugzilla administrator, and are managed by Bugzilla itself. A "remote" selection field's values are taken from a table in a database which need not be the same database used by Bugzilla. The administrator defines the remote database in the form of a DBI connect string, a username and password with which to log in to the other database, a table name, and a column name. Bugzilla generates the set of allowed values by logging in to the remote database using the supplied username and password, and issuing the following query: SELECT DISTINCT source_column FROM source_table WHERE source_column IS NOT NULL; Bugzilla should apply the following modifications to each element of the result set, in the order given: * Delete all characters after and including the first vertical whitespace character, if any * Trim leading and trailing whitespace * Truncate to a maximum length of 255 characters After this, duplicate elements should be eliminated, and the remaining elements should be sorted alphabetically before the set is presented to the user. [Open question: Should other sorting criteria be supported? If so, how?] Since such queries may be expensive, Bugzilla may cache the results for up to one hour. Since any given selection field's allowed values may change over time, due to administrator action or variation in a remote data source, Bugzilla should not signal an error if "invalid" field values are found in the database. Enforcement of a selection field's valid values is to be done only on the client side. If a bug containing a selection field whose value is no longer valid is edited by the user, the invalid field's value should be presented as being the null set. It should be possible to share the definitions of selection fields among multiple Bugzilla components, such that a change to one field's data source is reflected in all other fields which share that source. [Open question: Should the field subtypes described above really be their own top-level types?] Logging ======= Whenever a custom field's value is changed, this change should be logged. Log information should include the identity of the user who made the change, the time the change took place, the field's old value, and the field's new value. Presentation ============ Custom fields are to be presented on each Bugzilla page that presents the standard Bugzilla fields. These pages include at least the following: On "show_bug.cgi" and "post_bug.cgi", the custom fields should be shown just prior to the list of attachments. On "enter_bug.cgi" and "long_list.cgi", the custom fields should be shown just after the "Description" text box. When a bug is being created or edited, custom fields are represented as per the field type descriptions above. When a bug is being shown but not edited, scalar fields and single-selection fields are represented as simple text; multiselection fields are represented using disabled multiline listboxes. The query.cgi page requires more extensive modifications. Currently query.cgi knows only about Bugzilla's standard fields. Since all components share the same set of standard fields, these fields can be displayed before the user has chosen a Product and Component at the top of the page. To add the capability to search on custom fields, a straightforward approach would be to require the user to first specify the projects and components within which to search, then display the usual query page augmented with the custom fields which exist in those components. However, this is too invasive for components which don't use custom fields, and also for queries which don't care about custom fields. Here is an alternate approach. A button is to be added to the query page, to the right of the "Product", "Component", and "Version" listboxes, labelled "Show custom fields for these components". If the user clicks it, the query form is redisplayed, augmented with all custom fields in all of the selected components. If no components were selected, or if no selected component has any custom fields, the page is simply redisplayed as it was before. The user may freely change the target components and press the "Show custom fields" button again. The query page will be redisplayed with new form elements for the most recently chosen components. When custom fields are being shown, a second button is to be added below the "Show custom fields" button, labelled "Hide custom fields". When it is clicked, the query page is redisplayed as it was originally, without any custom field elements. It is an error for the user to select one or more target components, show the custom fields for those components, change the target components, and begin a search. In this case Bugzilla should redisplay the query page with an appropriate error message at the top. Different components may define different custom fields with the same name. Therefore, custom field form elements for custom fields belonging to the same component will need to be grouped together, clearly labelled as belonging to that component. Custom string fields may be queried in the same manner as the stock fields "Comment" and "URL". That is, they may be matched against a user-supplied string using any of the following predicates: * contains all of the words/strings * contains any of the words/strings * contains the string * contains the string (exact case) * contains all of the words * contains any of the words * matches the regexp * doesn't match the regexp Custom integer and float fields may be queried against a user-supplied string (which must look like an integer or a floating-point number, respectively) using the following predicates: * is equal to * is less than * is greater than * is less than or equal to * is greater than or equal to Custom date fields may be queried using a group of selection elements representing the year/month/year and/or the hour/minute/second (as appropriate) using the following predicates: * is exactly * is at or earlier than * is at or later than (The open versions of the latter two inequalities--ie, strictly earlier than or strictly later than--are probably not worth including.) Custom single-selection selection fields may be queried against a multiline listbox containing all valid values for the field. Multiple selections within this listbox are allowed. A bug matches this query term if this field's value is equal to ANY of the user-selected values. Custom multiselection selection fields may be queried against a multiline listbox containing all valid values for the fields. Multiple selections within this listbox are allowed. A pair of radiobuttons is placed next to the listbox which present two choices: "Any" and "All". Initially, "Any" is selected. If the "Any" button is selected at the time the query is initiated, then a bug matches this query term if any of the selected values are set in this field. If the "All" button is selected instead, then a bug matches this query term if all of the selected values are set in this field. ---------------------------------------------------------------------- From kiko at async.com.br Sat Apr 5 14:50:31 2003 From: kiko at async.com.br (Christian Reis) Date: Sat, 5 Apr 2003 11:50:31 -0300 Subject: Bugzilla Installation List In-Reply-To: <3E8DFE38.6000705@mozilla.org>; from gerv@mozilla.org on Fri, Apr 04, 2003 at 10:50:48PM +0100 References: <3E8DFE38.6000705@mozilla.org> Message-ID: <20030405115031.B13530@blackjesus.async.com.br> On Fri, Apr 04, 2003 at 10:50:48PM +0100, Gervase Markham wrote: > Here it is - 213 of them in all, obtained by a long trawl through > Google. The page is generated from a plain text list by a quick bit of Perl. Async Open Source: http://bugs.async.com.br/ Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL From timeless at myrealbox.com Sun Apr 6 22:31:51 2003 From: timeless at myrealbox.com (timeless) Date: Sun, 06 Apr 2003 18:31:51 -0400 Subject: Bugzilla Installation List In-Reply-To: <3E8DFE38.6000705@mozilla.org> References: <3E8DFE38.6000705@mozilla.org> Message-ID: <3E90AAD7.7090707@myrealbox.com> Gervase Markham wrote: > Here it is - 213 of them in all, obtained by a long trawl through > Google. The page is generated from a plain text list by a quick bit of > Perl. > > It's rather heartwarming to know we have so many users. > > I'll turn this into a proper website page at some point. Duplicate (drop Darwin): > Darwin > OpenDarwin My former employer used bugzilla internally... From preed at sigkill.com Sun Apr 6 23:40:44 2003 From: preed at sigkill.com (J. Paul Reed) Date: Sun, 6 Apr 2003 16:40:44 -0700 Subject: Bugzilla Installation List In-Reply-To: <3E8DFE38.6000705@mozilla.org>; from gerv@mozilla.org on Fri, Apr 04, 2003 at 10:50:48PM +0100 References: <3E8DFE38.6000705@mozilla.org> Message-ID: <20030406164044.B3922@sigkill.com> On 04 Apr 2003 at 22:50:48, Gervase Markham moved bits on my disk to say: > Here it is - 213 of them in all, obtained by a long trawl through > Google. The page is generated from a plain text list by a quick bit of Perl. > > It's rather heartwarming to know we have so many users. *Supposedly*, Google uses a hacked 2.14 internally. But I don't know if they'd want to be on a list; I guess I could ask if we wanted to put 'em on the list. Later, Paul ------------------------------------------------------------------------ J. Paul Reed -- 0xDF8708F8 || preed at sigkill.com || web.sigkill.com/preed To hold on to sanity too tight is insane. -- Nick Falzone, Pushing Tin I use PGP; you should use PGP too... if only to piss off John Ashcroft From myk at mozilla.org Mon Apr 7 00:43:16 2003 From: myk at mozilla.org (Myk Melez) Date: Sun, 06 Apr 2003 17:43:16 -0700 Subject: cnet: HP finds a thrilla in Mozilla In-Reply-To: <3E8C9FF0.1000008@netscape.com> References: <3E89F916.7090602@netscape.com> <3E8A0123.8030104@netscape.com> <3E8A0959.1000200@netscape.com> <3E8A1052.2040109@netscape.com> <3E8B3BF9.70501@netscape.com> <3E8B3F51.5030607@netscape.com> <3E8B4E48.7050504@netscape.com> <3E8B5B1E.10507@netscape.com> <3E8C9FF0.1000008@netscape.com> Message-ID: <3E90C9A4.10409@mozilla.org> Chris Hofmann wrote: > > Let's get the bugzilla entries going maybe one entry for each > "category" of bugzilla users large and small... Bugzilla developers are in the process of putting together just such a list, and they have a few hundred entries so far. Perhaps this work could be coordinated so we don't duplicate efforts. cc:ing developers at bugzilla.org. -myk -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerv at mozilla.org Mon Apr 7 07:44:40 2003 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 07 Apr 2003 08:44:40 +0100 Subject: cnet: HP finds a thrilla in Mozilla In-Reply-To: <3E90C9A4.10409@mozilla.org> References: <3E89F916.7090602@netscape.com> <3E8A0123.8030104@netscape.com> <3E8A0959.1000200@netscape.com> <3E8A1052.2040109@netscape.com> <3E8B3BF9.70501@netscape.com> <3E8B3F51.5030607@netscape.com> <3E8B4E48.7050504@netscape.com> <3E8B5B1E.10507@netscape.com> <3E8C9FF0.1000008@netscape.com> <3E90C9A4.10409@mozilla.org> Message-ID: <3E912C68.5000405@mozilla.org> Myk Melez wrote: > Chris Hofmann wrote: >> Let's get the bugzilla entries going maybe one entry for each >> "category" of bugzilla users large and small... > > Bugzilla developers are in the process of putting together just such a > list, and they have a few hundred entries so far. Perhaps this work > could be coordinated so we don't duplicate efforts. cc:ing > developers at bugzilla.org . Myk: what's the root of this conversation? Gerv From bugzilla3sd at matthewelvey.f-m.fm Mon Apr 7 18:26:19 2003 From: bugzilla3sd at matthewelvey.f-m.fm (Matthew Elvey) Date: Mon, 07 Apr 2003 11:26:19 -0700 Subject: [Bug 120030] Bugzilla bug lists are a spammer's paradise Message-ID: <3E91C2CB.7010702@matthewelvey.f-m.fm> Hi. Apropos the check-in policy update, I'm writing to ask the project leadership what solutions will likely be given approval, to fix Bug 120030. There are four options mentined in the comments (summarized on comment 70: http://bugzilla.mozilla.org/show_bug.cgi?id=120030#c70 ) In addition to the usual spam to bugzilla3sd at matthewelvey.f-m.fm, today I got a virus too: I-Worm.Lentin.n ! Please reply by posting a comment to the bug. (Email to bugzilla3sd at matthewelvey.f-m.fm may bounce; you could email bugzilla-try3 at matthewelvey.f-m.fm instead.) From myk at mozilla.org Mon Apr 7 21:03:27 2003 From: myk at mozilla.org (Myk Melez) Date: Mon, 07 Apr 2003 14:03:27 -0700 Subject: cnet: HP finds a thrilla in Mozilla In-Reply-To: <3E912C68.5000405@mozilla.org> References: <3E89F916.7090602@netscape.com> <3E8A0123.8030104@netscape.com> <3E8A0959.1000200@netscape.com> <3E8A1052.2040109@netscape.com> <3E8B3BF9.70501@netscape.com> <3E8B3F51.5030607@netscape.com> <3E8B4E48.7050504@netscape.com> <3E8B5B1E.10507@netscape.com> <3E8C9FF0.1000008@netscape.com> <3E90C9A4.10409@mozilla.org> <3E912C68.5000405@mozilla.org> Message-ID: <3E91E79F.7060207@mozilla.org> Gervase Markham wrote: > Myk Melez wrote: > >> Chris Hofmann wrote: >> >>> Let's get the bugzilla entries going maybe one entry for each >>> "category" of bugzilla users large and small... >> >> >> Bugzilla developers are in the process of putting together just such >> a list, and they have a few hundred entries so far. Perhaps this >> work could be coordinated so we don't duplicate efforts. cc:ing >> developers at bugzilla.org . > > > Myk: what's the root of this conversation? I'm not entirely sure, but I think there's an effort to add Bugzilla installations to the Mozilla hall of fame page: http://www.mozilla.org/university/HOF.html -myk From arthur.barrett at march-hare.com Tue Apr 8 07:17:26 2003 From: arthur.barrett at march-hare.com (Arthur Barrett) Date: Tue, 8 Apr 2003 17:17:26 +1000 Subject: Sybase help ? (or MSSQL help) Message-ID: I noticed some limited references to using Sybase with Bugzilla. Can someone please point me at the patches or whatever I need to try this ? I am specifically interested to know if DBI-MySQL is still needed as a Perl package, or if it needs to be modified in some way, or if each call from Bugzilla to the DBI package needs to be massaged ? Also are there table creation scripts for Sybase ? I actaully am trying to get Bugzilla working with Win2K and MSSQL2K - has anyone else attempted this? Regs, Arthur From arthur.barrett at march-hare.com Tue Apr 8 15:21:33 2003 From: arthur.barrett at march-hare.com (Arthur Barrett) Date: Wed, 9 Apr 2003 01:21:33 +1000 Subject: Migrate Bugzilla 2.12 to 2.17 (MySQL) Message-ID: Has anybody got some scripts for converting a MySQL repository (Bugzilla 2.12) to the latest 2.17 repository. Regs, Arthur From bugreport at peshkin.net Tue Apr 8 15:26:22 2003 From: bugreport at peshkin.net (Joel Peshkin) Date: Tue, 08 Apr 2003 08:26:22 -0700 Subject: MySQL 4.0 Message-ID: <3E92EA1E.8060102@peshkin.net> I see that MySQL 4.0 is now in "production" and supports a number of the features whose absence complicates our lives. (Foreign keys, Transactions -- sorry, no subselects) Has anyone properly investigated this? -Joel From gerv at mozilla.org Tue Apr 8 15:57:54 2003 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 08 Apr 2003 16:57:54 +0100 Subject: Migrate Bugzilla 2.12 to 2.17 (MySQL) In-Reply-To: References: Message-ID: <3E92F182.1080306@mozilla.org> Arthur Barrett wrote: > Has anybody got some scripts for converting a MySQL repository (Bugzilla > 2.12) to the latest 2.17 repository. Yes. It's called "checksetup.pl" and it comes with Bugzilla :-) Read the documentation for upgrade instructions. Gerv From jason at pyeron.com Tue Apr 8 15:58:27 2003 From: jason at pyeron.com (Jason Pyeron) Date: Tue, 8 Apr 2003 11:58:27 -0400 (EDT) Subject: MySQL 4.0 In-Reply-To: <3E92EA1E.8060102@peshkin.net> Message-ID: release 4.0.12 (15 Mar 2003: Production) I think it should be waited until September 15 before any changes are introduced into bugzilla which would force My-SQL v4 usage. I know they have had v4 in beta/alpha for a while, but many people have been wary about installing it on their servers, since it was not stamped production. Now that it has been stamped, and many will be using it, let them fix their bugs which will be found. We will be upgrading to it in May if it does not have any major issues on Slashdot, which are not fixed. remember there are a lot of "gotchas" in v4 http://www.mysql.com/doc/en/Upgrading-from-3.23.html Jason Pyeron On Tue, 8 Apr 2003, Joel Peshkin wrote: I see that MySQL 4.0 is now in "production" and supports a number of the features whose absence complicates our lives. (Foreign keys, Transactions -- sorry, no subselects) Has anyone properly investigated this? -Joel ---- To view or change your list settings, click here: -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron http://www.pyerotechnics.com - - Owner & Lead Pyerotechnics Development, Inc. - - +1 410 808 6646 (c) 500 West University Parkway #1S - - +1 410 467 2266 (f) Baltimore, Maryland 21210-3253 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, purge the message from your system and notify the sender immediately. Any other use of the email by you is prohibited. From mh12am4077 at hotmail.com Tue Apr 8 17:22:18 2003 From: mh12am4077 at hotmail.com (Me And You) Date: Tue, 08 Apr 2003 22:52:18 +0530 Subject: Adding more OS to select from dropdown list while entering new bugs. Message-ID: An HTML attachment was scrubbed... URL: From myk at mozilla.org Tue Apr 8 17:25:18 2003 From: myk at mozilla.org (Myk Melez) Date: Tue, 08 Apr 2003 10:25:18 -0700 Subject: MySQL 4.0 In-Reply-To: References: Message-ID: <3E9305FE.8060302@mozilla.org> Jason Pyeron wrote: >release 4.0.12 (15 Mar 2003: Production) > > >I think it should be waited until September 15 before any changes are >introduced into bugzilla which would force My-SQL v4 usage. > >I know they have had v4 in beta/alpha for a while, but many people have >been wary about installing it on their servers, since it was not stamped >production. Now that it has been stamped, and many will be using it, let >them fix their bugs which will be found. We will be upgrading to it in May >if it does not have any major issues on Slashdot, which are not fixed. > >remember there are a lot of "gotchas" in v4 >http://www.mysql.com/doc/en/Upgrading-from-3.23.html > > Are there? I just read through the list for the second time, and I still haven't found anything that looks like it affects Bugzilla. I do agree that more bugs will be found now that it's in production, however. I found one myself the other day after upgrading a b.m.o mirror from 3.32.54 to 4.0.12 while leaving b.m.o at 3.23.44: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=4577f265.0303281306.43bd7dff%40posting.google.com&rnum=3&prev=/groups%3Fq%3Dmelez%26hl%3Den%26lr%3D%26ie%3DUTF-8%26scoring%3Dd In fairness, the MySQL manual does say, "With regard to version 4.0, we recommend using same version on both sides," although it isn't clear if they are discouraging 3.23.x <-> 4.0.x replication or just 4.0.x <-> 4.0.y replication. http://www.mysql.com/doc/en/Replication_Implementation.html -myk From jason at pyeron.com Tue Apr 8 17:59:24 2003 From: jason at pyeron.com (Jason Pyeron) Date: Tue, 8 Apr 2003 13:59:24 -0400 (EDT) Subject: MySQL 4.0 In-Reply-To: <3E9305FE.8060302@mozilla.org> Message-ID: the gotchas mostly have to do with sign on numeric operations but also have an effect on sorting, etc. v4 has specific operations which are not consistent with v3. I am not saying that Bugzilla will have a breakage as a result, but with documented incompatibility, we must allow for a migration window for those systems where this is an issue, or at least time for the product to be mature (according to 80% of the population) On Tue, 8 Apr 2003, Myk Melez wrote: Jason Pyeron wrote: >release 4.0.12 (15 Mar 2003: Production) > > >I think it should be waited until September 15 before any changes are >introduced into bugzilla which would force My-SQL v4 usage. > >I know they have had v4 in beta/alpha for a while, but many people have >been wary about installing it on their servers, since it was not stamped >production. Now that it has been stamped, and many will be using it, let >them fix their bugs which will be found. We will be upgrading to it in May >if it does not have any major issues on Slashdot, which are not fixed. > >remember there are a lot of "gotchas" in v4 >http://www.mysql.com/doc/en/Upgrading-from-3.23.html > > Are there? I just read through the list for the second time, and I still haven't found anything that looks like it affects Bugzilla. I do agree that more bugs will be found now that it's in production, however. I found one myself the other day after upgrading a b.m.o mirror from 3.32.54 to 4.0.12 while leaving b.m.o at 3.23.44: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=4577f265.0303281306.43bd7dff%40posting.google.com&rnum=3&prev=/groups%3Fq%3Dmelez%26hl%3Den%26lr%3D%26ie%3DUTF-8%26scoring%3Dd In fairness, the MySQL manual does say, "With regard to version 4.0, we recommend using same version on both sides," although it isn't clear if they are discouraging 3.23.x <-> 4.0.x replication or just 4.0.x <-> 4.0.y replication. http://www.mysql.com/doc/en/Replication_Implementation.html -myk ---- To view or change your list settings, click here: -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron http://www.pyerotechnics.com - - Owner & Lead Pyerotechnics Development, Inc. - - +1 410 808 6646 (c) 500 West University Parkway #1S - - +1 410 467 2266 (f) Baltimore, Maryland 21210-3253 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, purge the message from your system and notify the sender immediately. Any other use of the email by you is prohibited. From myk at mozilla.org Tue Apr 8 18:27:10 2003 From: myk at mozilla.org (Myk Melez) Date: Tue, 08 Apr 2003 11:27:10 -0700 Subject: MySQL 4.0 In-Reply-To: References: Message-ID: <3E93147E.2040807@mozilla.org> Jason Pyeron wrote: >the gotchas mostly have to do with sign on numeric operations but also >have an effect on sorting, etc. v4 has specific operations which are not >consistent with v3. I am not saying that Bugzilla will have a breakage as a >result, but with documented incompatibility, we must allow for a migration >window for those systems where this is an issue, or at least time for the >product to be mature (according to 80% of the population) > > Right, i.e. we shouldn't require it for 2.18, but we could require it soon in the 2.19 cycle if our major testing installations get on the bandwagon. -myk From justdave at netscape.com Tue Apr 8 17:37:55 2003 From: justdave at netscape.com (David Miller) Date: Tue, 8 Apr 2003 13:37:55 -0400 Subject: Sybase help ? (or MSSQL help) In-Reply-To: References: Message-ID: On 4/8/03 5:17 PM +1000, Arthur Barrett wrote: > I noticed some limited references to using Sybase with Bugzilla. > > Can someone please point me at the patches or whatever I need to try this ? There's nothing posted yet. I'll try really hard to get something up in the next few weeks. We have it mostly working now, I just haven't had time to pull all of our local customizations out of it so I can post it. > I am specifically interested to know if DBI-MySQL is still needed as a Perl > package, or if it needs to be modified in some way, or if each call from > Bugzilla to the DBI package needs to be massaged ? You won't need DBD::mysql. Replace it with DBD::Sybase. :) And yes, many calls had to be "massaged" :) It wasn't anywhere near as bad as you'd think though. > Also are there table creation scripts for Sybase ? That'd be part of the above-mentioned patch when it becomes available. We have them, but they also create a bunch of tables that aren't part of the standard Bugzilla. :) > I actaully am trying to get Bugzilla working with Win2K and MSSQL2K - has > anyone else attempted this? Not that I know of. Sybase and MSSQL are similar enough that it might work with the Sybase patches. On the other hand, they diverged several versions back, and the newer each version is, the less chance it'll still work, since they seem to be going in different directions. -- Dave Miller Project Leader, Bugzilla Bug Tracking System Webtools Developer, Netscape Client QA http://www.bugzilla.org/ From dberlin at dberlin.org Tue Apr 8 18:36:28 2003 From: dberlin at dberlin.org (Daniel Berlin) Date: Tue, 8 Apr 2003 14:36:28 -0400 Subject: Weekly bug summary report Message-ID: <02FA74A6-69F1-11D7-8BB4-000393575BCC@dberlin.org> I ported gnome's weekly bug summary report to Bugzilla 2.17.3 for use in GCC's bugzilla. See http://gcc.gnu.org/bugzilla/weekly-bug-summary.cgi Anyone else interested in it? If so, i'll throw it in a bug at bugzilla.mozilla.org Be forewarned, however, that it generates it's own html (though the queries it uses to determine counts and whatnot are nicely encapsulated in weekly-summary-utils.pl), and i can't see an easy way to templatize it. I also rewrote the queries so they are about 10-100x faster than the ones the gnome version uses (see http://bugzilla.gnome.org/weekly-bug-summary.cgi for an example as to how slow the ones they use are). Had the same problem regenerate mode of collectstats.pl originally did (to_days on every record). --Dan From justdave at syndicomm.com Tue Apr 8 18:38:47 2003 From: justdave at syndicomm.com (David Miller) Date: Tue, 8 Apr 2003 14:38:47 -0400 Subject: Adding more OS to select from dropdown list while entering In-Reply-To: References: Message-ID: On 4/8/03 10:52 PM +0530, Me And You wrote: > Thanks so much friend, > > Finally I could find the solution :) > > I modified the field "op_sys" under the table "bugs". > > The the field "op_sys" is of type > > ENUM('All','Windows 3.1','Windows 95','Windows 98','Windows ME','Windows >2000','Windows NT','Mac System 7','Mac System 7.5','Mac System 7.6.1','Mac >System 8.0','Mac System 8.5','Mac System 8.6','Mac System >9.0','Linux','BSDI','FreeBSD','NetBSD','OpenBSD','AIX','BeOS','HP-UX','IRIX','Neutrino','OpenVMS','OS/2','OSF/1','Solaris','SunOS','other') > > You can run the command (to add 'Windows XP','Windows XP Home' and >'Windows XP Pro') > > mysql> ALTER TABLE bugs MODIFY op_sys enum('All','Windows 3.1','Windows >95','Windows 98','Windows ME','Windows 2000','Windows XP','Windows XP >Home','Windows XP Pro','Windows NT','Mac System 7','Mac System 7.5','Mac >System 7.6.1','Mac System 8.0','Mac System 8.5','Mac System 8.6','Mac >System >9.0','Linux','BSDI','FreeBSD','NetBSD','OpenBSD','AIX','BeOS','HP-UX','IRIX','Neutrino','OpenVMS','OS/2','OSF/1','Solaris','SunOS','other'); > > Hope this experience of mine will be helpful for all of us. > > Thanks to all for you for quick attempts to help me. Uhhh, why not just change the list in the localconfig file and run checksetup.pl again? It'll change the schema for you. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From AGalewsky at evokesoft.com Tue Apr 8 18:49:58 2003 From: AGalewsky at evokesoft.com (Andy Galewsky) Date: Tue, 8 Apr 2003 11:49:58 -0700 Subject: Weekly bug summary report Message-ID: I find this very interesting and would like to se it! -----Original Message----- From: Daniel Berlin [mailto:dberlin at dberlin.org] Sent: Tuesday, April 08, 2003 1:36 PM To: developers at bugzilla.org I ported gnome's weekly bug summary report to Bugzilla 2.17.3 for use in GCC's bugzilla. See http://gcc.gnu.org/bugzilla/weekly-bug-summary.cgi Anyone else interested in it? If so, i'll throw it in a bug at bugzilla.mozilla.org Be forewarned, however, that it generates it's own html (though the queries it uses to determine counts and whatnot are nicely encapsulated in weekly-summary-utils.pl), and i can't see an easy way to templatize it. I also rewrote the queries so they are about 10-100x faster than the ones the gnome version uses (see http://bugzilla.gnome.org/weekly-bug-summary.cgi for an example as to how slow the ones they use are). Had the same problem regenerate mode of collectstats.pl originally did (to_days on every record). --Dan ---- To view or change your list settings, click here: From etzwane at schwag.org Tue Apr 8 20:04:11 2003 From: etzwane at schwag.org (Sean McAfee) Date: Tue, 08 Apr 2003 16:04:11 -0400 Subject: New custom fields proposal In-Reply-To: <20030405013338.5BC22C2CC@diggity.schwag.org> Message-ID: <20030408200412.03426BC51@diggity.schwag.org> Hi, folks-- I haven't seen any feedback regarding my custom fields proposal. I'd love to get cracking on the design, but I'd rather do so with some sort of blessing from the developer community. If you have any comments, please let me know within the next couple of days. Thanks. --Sean From justdave at syndicomm.com Tue Apr 8 21:06:12 2003 From: justdave at syndicomm.com (David Miller) Date: Tue, 8 Apr 2003 17:06:12 -0400 Subject: New custom fields proposal In-Reply-To: <20030408200412.03426BC51@diggity.schwag.org> References: <20030408200412.03426BC51@diggity.schwag.org> Message-ID: On 4/8/03 4:04 PM -0400, Sean McAfee wrote: > I haven't seen any feedback regarding my custom fields proposal. I'd love > to get cracking on the design, but I'd rather do so with some sort of > blessing from the developer community. If you have any comments, please let > me know within the next couple of days. Thanks. I've been meaning to reply but there's a lot of stuff in that proposal and I haven't had time to sit down and think about it yet. I'll try again in the next couple days. (Life is busy at work at the moment :) -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From arthur.barrett at march-hare.com Tue Apr 8 21:57:06 2003 From: arthur.barrett at march-hare.com (Arthur Barrett) Date: Wed, 9 Apr 2003 07:57:06 +1000 Subject: Migrate Bugzilla 2.12 to 2.17 (MySQL) Message-ID: Gervase, Thanks for that - couldnt find any mention in the manual 2.17.4 (in the install section or the upgrade section)- but you're right it does work! There are a few references to "attachstatusdefs" that really ought to be qualified with "if TableExists" - but other than that it's all good. Thanks for your help! Regards, Arthur Barrett > ---------- > From: Gervase Markham > Reply To: developers at bugzilla.org > Sent: Wednesday, April 9, 2003 1:57 AM > To: developers at bugzilla.org > Subject: Re: Migrate Bugzilla 2.12 to 2.17 (MySQL) > > Arthur Barrett wrote: > > Has anybody got some scripts for converting a MySQL repository (Bugzilla > > 2.12) to the latest 2.17 repository. > > Yes. It's called "checksetup.pl" and it comes with Bugzilla :-) Read the > documentation for upgrade instructions. > > Gerv > > ---- > To view or change your list settings, click here: > > > From justdave at syndicomm.com Tue Apr 8 22:00:15 2003 From: justdave at syndicomm.com (David Miller) Date: Tue, 8 Apr 2003 18:00:15 -0400 Subject: Migrate Bugzilla 2.12 to 2.17 (MySQL) In-Reply-To: References: Message-ID: On 4/9/03 7:57 AM +1000, Arthur Barrett wrote: > Thanks for that - couldnt find any mention in the manual 2.17.4 (in the > install section or the upgrade section)- but you're right it does work! You're not looking very hard. There's an entire section devoted to it. http://www.bugzilla.org/docs/html/stepbystep.html see section 4.1.9 -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From gerv at mozilla.org Tue Apr 8 22:26:51 2003 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 08 Apr 2003 23:26:51 +0100 Subject: SQL call formatting style In-Reply-To: <3E8B598B.3010408@mozilla.org> References: <3E862096.9000608@mozilla.org> <3E8A1667.9050803@mozilla.org> <3E8B598B.3010408@mozilla.org> Message-ID: <3E934CAB.6000308@mozilla.org> Myk Melez wrote: > Gervase Markham wrote: >> Revised proposal: >> >> my ($comma, $separated, $list, $of, $vars, $on, $one, $line) = >> $dbh->some_longwinded_methodname(q{SELECT some SQL variables >> ON multiple lines >> IF necessary >> WITH placeholders ?, ?, ?}, >> undef, >> $placeholder, $variables, $here); > > That's ok, except we should allow the following when the name is really > long: > > $dbh->some_longwinded_methodname( > q{SELECT some SQL variables ON multiple lines IF necessary > WITH placeholders ?, ?, ?}, > undef, > $placeholder, $variables, $here > ); I personally don't like the split-braces style for function calls; it makes it look like a code block. > And placeholders should be able to be aligned vertically (perhaps this > should be the default in fact): > > $dbh->some_longwinded_methodname(q{SELECT some SQL variables > ON multiple lines > IF necessary > WITH placeholders ?, ?, ?}, > undef, > $placeholder, > $variables, > $here); We have to balance the readability of the DB call with the readability of the code in general, which isn't helped if each DB call takes up a third of a page. IMO, the vertical alignment of placeholders doesn't help enough for it to be worth it for all the lines it takes up. > And this should be a recommendation, not a rule. Well, inasmuch as any Bugzilla coding standards are recommendations rather than rules; but I believe consistent coding standards are really important to keep our code understandable. Gerv From arthur.barrett at march-hare.com Tue Apr 8 23:01:36 2003 From: arthur.barrett at march-hare.com (Arthur Barrett) Date: Wed, 9 Apr 2003 09:01:36 +1000 Subject: Migrate Bugzilla 2.12 to 2.17 (MySQL) Message-ID: Duh! Must have read that 10 times without seeing the little note on the last line. Regs, arthur -----Original Message----- From: David Miller [mailto:justdave at syndicomm.com] Sent: Wednesday, April 09, 2003 8:00 AM To: developers at bugzilla.org Subject: Re: Migrate Bugzilla 2.12 to 2.17 (MySQL) On 4/9/03 7:57 AM +1000, Arthur Barrett wrote: > Thanks for that - couldnt find any mention in the manual 2.17.4 (in the > install section or the upgrade section)- but you're right it does work! You're not looking very hard. There's an entire section devoted to it. http://www.bugzilla.org/docs/html/stepbystep.html see section 4.1.9 -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ ---- To view or change your list settings, click here: From arthur.barrett at march-hare.com Tue Apr 8 23:16:04 2003 From: arthur.barrett at march-hare.com (Arthur Barrett) Date: Wed, 9 Apr 2003 09:16:04 +1000 Subject: Sybase help ? (or MSSQL help) Message-ID: Dave, Thanks for that - let me know as soon as you have some patches. Alternatively if it looks like patches are not going to happen in the next couple of weeks - I'd be fine with just the whole lot and any notes you have and when I get stuck I can just look at what you had done. Regs, Arthur -----Original Message----- From: David Miller [mailto:justdave at netscape.com] Sent: Wednesday, April 09, 2003 3:38 AM To: developers at bugzilla.org Subject: Re: Sybase help ? (or MSSQL help) On 4/8/03 5:17 PM +1000, Arthur Barrett wrote: > I noticed some limited references to using Sybase with Bugzilla. > > Can someone please point me at the patches or whatever I need to try this ? There's nothing posted yet. I'll try really hard to get something up in the next few weeks. We have it mostly working now, I just haven't had time to pull all of our local customizations out of it so I can post it. > I am specifically interested to know if DBI-MySQL is still needed as a Perl > package, or if it needs to be modified in some way, or if each call from > Bugzilla to the DBI package needs to be massaged ? You won't need DBD::mysql. Replace it with DBD::Sybase. :) And yes, many calls had to be "massaged" :) It wasn't anywhere near as bad as you'd think though. > Also are there table creation scripts for Sybase ? That'd be part of the above-mentioned patch when it becomes available. We have them, but they also create a bunch of tables that aren't part of the standard Bugzilla. :) > I actaully am trying to get Bugzilla working with Win2K and MSSQL2K - has > anyone else attempted this? Not that I know of. Sybase and MSSQL are similar enough that it might work with the Sybase patches. On the other hand, they diverged several versions back, and the newer each version is, the less chance it'll still work, since they seem to be going in different directions. -- Dave Miller Project Leader, Bugzilla Bug Tracking System Webtools Developer, Netscape Client QA http://www.bugzilla.org/ ---- To view or change your list settings, click here: From gerv at mozilla.org Tue Apr 8 23:12:58 2003 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 09 Apr 2003 00:12:58 +0100 Subject: Bugzilla Installation List In-Reply-To: <20030405115031.B13530@blackjesus.async.com.br> References: <3E8DFE38.6000705@mozilla.org> <20030405115031.B13530@blackjesus.async.com.br> Message-ID: <3E93577A.1080709@mozilla.org> > Async Open Source: http://bugs.async.com.br/ You know you've picked the right format for your data file when everyone guesses it without knowing :-) Gerv From gerv at mozilla.org Tue Apr 8 23:16:14 2003 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 09 Apr 2003 00:16:14 +0100 Subject: Bugzilla Installation List In-Reply-To: <20030406164044.B3922@sigkill.com> References: <3E8DFE38.6000705@mozilla.org> <20030406164044.B3922@sigkill.com> Message-ID: <3E93583E.70709@mozilla.org> J. Paul Reed wrote: > *Supposedly*, Google uses a hacked 2.14 internally. > > But I don't know if they'd want to be on a list; I guess I could ask if we > wanted to put 'em on the list. If you mean what I think you mean, then go ahead and ask them :-) Gerv From JWilmoth at starbucks.com Tue Apr 8 23:39:50 2003 From: JWilmoth at starbucks.com (Jon Wilmoth) Date: Tue, 8 Apr 2003 16:39:50 -0700 Subject: New custom fields proposal Message-ID: Thoughts/question inline... -----Original Message----- From: Sean McAfee [mailto:etzwane at schwag.org] Sent: Friday, April 04, 2003 5:34 PM To: developers at bugzilla.org Subject: New custom fields proposal Hi, folks-- Enclosed is my proposal for new custom field functionality to be added to Bugzilla. Please read, discuss, criticize, etc., especially the "Open questions". Note that this is a requirements document, and describes only WHAT I'd like to see implemented, not HOW it is to be implemented. The "how" will be left for a future document, when we've settled on the "what". Also note that I've omitted any reference to how custom fields will be administered. This is obviously important, but I found myself getting bogged down in the details, so I decided to just go ahead and send the part I'd completed. --Sean McAfee ---------------------------------------------------------------------- Definition ========== Currently, Bugzilla offers a fixed number of named fields to describe bugs. These fields are shared across every component in the system. The proposed additional functionalty is the ability to define additional fields on a per-component basis. These additional fields are called "custom fields". I assume your talking about "component" being a broad system module (i.e. search, creation, reporting, etc.). I'd suggest you use a different term so as not to be confused with a Product component. Custom fields will be available in five major varieties: integer, float, string, date, and selection. The first four of these types are collectively referred to as "scalar" types. All scalar fields can be set to a special "undefined" value in additional to the valid values described below. Integer ------- An integer custom field contains values which are integers. Such fields must be able to store at least the range of integers which are typically represented as a signed four-byte quantity. [Open question: Should integer fields be available in signed and unsigned varieties?] Bugzilla should signal an error condition if a user attempts to store an integer outside of the allowed range into an integer field. [Open question: Should Bugzilla transparently offer large-integer semantics?] Bugzilla may emit client-side scripting code onto any pages that request custom-field input that will abort form submission if an integer field's submitted value is out of range. Float ----- A float custom fields contains values which are floating-point numbers. Such fields must be able to store at least the range of floating-point numbers which are typically represented as an eight-byte double-precision quantity. When a user enters a text string which is intended to be stored in a float field, it must match the usual pattern: * an optional leading plus sign ('+') or minus sign ('-'); * an integer part consisting only of digits; * an fractional part matching the following pattern: + a period character ('.'); + an optional sequence of digits; + an optional exponent, expressed as an 'E' or 'e' character, followed by an optional plus sign ('+') or minus sign ('-'), followed by a sequence of digits Either the integer part or the fractional part may be omitted, but not both. Bugzilla should signal an error condition if a user attempts to store a floating-point number outside of the allowed range into a float field. String ------ This type of field contains human-readable text. [Open question: Should Bugzilla reject attempts to store arbitrary binary data in a string field?] Each string field is flagged as belonging to one of two varieties: short and long. A short string field can hold a maximum of 255 characters, and may contain no vertical whitespace characters (carriage return, newline, or vertical tab). It is represented on Bugzilla's Web interface using a single-line text form element. A long string field can hold large amounts of text, possibly consisting of several lines. It is represented on Bugzilla's Web interface as a multiline textarea form element. Date ---- A date field contains either a date (ie, a specific day of a specific month in a specific year), a time of day (ie, an hour from 0-23 inclusive, and a minute and second, both from 0-59 inclusive), or both. Each date field is flagged as containing one of these three subsets of data. [Open question: Is the "time of day" subtype really necessary?] Bugzilla should signal an error condition if a user attempts to store an illegal date value in a date field. Examples: * An invalid day of the month: March 50, February 30 * An invalid date: February 29, 2001 * An invalid time: 12:66:00 Date fields are represented on Bugzilla's web interface using a pair of drop-down listbox form elements (for the month and day) and a single-line text-entry element (for the year) for the date portion of the field's value (if appropriate), and a single-line text entry widget for the time portion (if appropriate). Bugzilla should signal an error if an invalid date or time is submitted. [Open question: Is this too busy? Should a simple text-entry widget suffice for all date types?] IMHO, yes...it's too busy. If it's a date field it would be more useful to have a popup calendar (bottom of which could also include time elements). I would think a date field should have a input pattern that could vary on a field by field basis. This can be compared to java's simple date format (http://java.sun.com/j2se/1.4.1/docs/api/java/text/SimpleDateFormat.html ) class or oracle's to_date fuction that allow for a pattern (i.e. MM/dd/yyyy HH:mm:ss aa zz to define a date input valid for 04/08/2003 16:25:30 pm PDT) Selection --------- A selection field takes its value from a set of distinct string values. No string value in any selection field's set of valid values may contain vertical whitespace, contain leading or trailing whitespace, or exceed 255 characters in length. [Open question: Should there be a limit on the size of the set of valid strings? If so, should this limit be global or per-component?] The main issue here is screen real-estate which is a global issue. Having unlimited select lists can throw the html tables out of wack. I'd suggest a global limit set to the largest possible value for the UI where custom fields will be added. Each selection field comes in one of two varieties: "single-selection" and "multiselection". A single-selection field's value is a subset of the field's possible values of size either zero or one. It is represented on Bugzilla's web interface as a drop-down listbox form element. A multiselection field's value is an arbitrary subset of the field's possible values. It is represented on Bugzilla's web interface as a multiline listbox in which multiple simultaneous selections are allowed. Each selection field's set of allowed values may be specified in one of two ways. A "local" selection field's values are defined by the Bugzilla administrator, and are managed by Bugzilla itself. A "remote" selection field's values are taken from a table in a database which need not be the same database used by Bugzilla. The administrator defines the remote database in the form of a DBI connect string, a username and password with which to log in to the other database, a table name, and a column name. Bugzilla generates the set of allowed values by logging in to the remote database using the supplied username and password, and issuing the following query: While the "remote" concept is cool, I think it should receive a lower priority and perhaps even be treated as a separate release of "custom fields". There's a lot of work to do as is to manage "local" custom fields. SELECT DISTINCT source_column FROM source_table WHERE source_column IS NOT NULL; Bugzilla should apply the following modifications to each element of the result set, in the order given: * Delete all characters after and including the first vertical whitespace character, if any * Trim leading and trailing whitespace * Truncate to a maximum length of 255 characters After this, duplicate elements should be eliminated, and the remaining elements should be sorted alphabetically before the set is presented to the user. [Open question: Should other sorting criteria be supported? If so, how?] Since such queries may be expensive, Bugzilla may cache the results for up to one hour. Since any given selection field's allowed values may change over time, due to administrator action or variation in a remote data source, Bugzilla should not signal an error if "invalid" field values are found in the database. Enforcement of a selection field's valid values is to be done only on the client side. If a bug containing a selection field whose value is no longer valid is edited by the user, the invalid field's value should be presented as being the null set. It should be possible to share the definitions of selection fields among multiple Bugzilla components, such that a change to one field's data source is reflected in all other fields which share that source. [Open question: Should the field subtypes described above really be their own top-level types?] Logging ======= Whenever a custom field's value is changed, this change should be logged. Log information should include the identity of the user who made the change, the time the change took place, the field's old value, and the field's new value. Presentation ============ Custom fields are to be presented on each Bugzilla page that presents the standard Bugzilla fields. These pages include at least the following: On "show_bug.cgi" and "post_bug.cgi", the custom fields should be shown just prior to the list of attachments. On "enter_bug.cgi" and "long_list.cgi", the custom fields should be shown just after the "Description" text box. When a bug is being created or edited, custom fields are represented as per the field type descriptions above. When a bug is being shown but not edited, scalar fields and single-selection fields are represented as simple text; multiselection fields are represented using disabled multiline listboxes. The query.cgi page requires more extensive modifications. Currently query.cgi knows only about Bugzilla's standard fields. Since all components share the same set of standard fields, these fields can be displayed before the user has chosen a Product and Component at the top of the page. To add the capability to search on custom fields, a straightforward approach would be to require the user to first specify the projects and components within which to search, then display the usual query page augmented with the custom fields which exist in those components. However, this is too invasive for components which don't use custom fields, and also for queries which don't care about custom fields. Here is an alternate approach. A button is to be added to the query page, to the right of the "Product", "Component", and "Version" listboxes, labelled "Show custom fields for these components". If the user clicks it, the query form is redisplayed, augmented with all custom fields in all of the selected components. If no components were selected, or if no selected component has any custom fields, the page is simply redisplayed as it was before. The user may freely change the target components and press the "Show custom fields" button again. The query page will be redisplayed with new form elements for the most recently chosen components. When custom fields are being shown, a second button is to be added below the "Show custom fields" button, labelled "Hide custom fields". When it is clicked, the query page is redisplayed as it was originally, without any custom field elements. It is an error for the user to select one or more target components, show the custom fields for those components, change the target components, and begin a search. In this case Bugzilla should redisplay the query page with an appropriate error message at the top. Different components may define different custom fields with the same name. Therefore, custom field form elements for custom fields belonging to the same component will need to be grouped together, clearly labelled as belonging to that component. I'd like to see two levels of scoping global and by product for custom fields. Anything else is gravy. Custom string fields may be queried in the same manner as the stock fields "Comment" and "URL". That is, they may be matched against a user-supplied string using any of the following predicates: * contains all of the words/strings * contains any of the words/strings * contains the string * contains the string (exact case) * contains all of the words * contains any of the words * matches the regexp * doesn't match the regexp Custom integer and float fields may be queried against a user-supplied string (which must look like an integer or a floating-point number, respectively) using the following predicates: * is equal to * is less than * is greater than * is less than or equal to * is greater than or equal to Custom date fields may be queried using a group of selection elements representing the year/month/year and/or the hour/minute/second (as appropriate) using the following predicates: * is exactly * is at or earlier than * is at or later than (The open versions of the latter two inequalities--ie, strictly earlier than or strictly later than--are probably not worth including.) Custom single-selection selection fields may be queried against a multiline listbox containing all valid values for the field. Multiple selections within this listbox are allowed. A bug matches this query term if this field's value is equal to ANY of the user-selected values. Custom multiselection selection fields may be queried against a multiline listbox containing all valid values for the fields. Multiple selections within this listbox are allowed. A pair of radiobuttons is placed next to the listbox which present two choices: "Any" and "All". Initially, "Any" is selected. If the "Any" button is selected at the time the query is initiated, then a bug matches this query term if any of the selected values are set in this field. If the "All" button is selected instead, then a bug matches this query term if all of the selected values are set in this field. Security - Assign access to custom fields to groups. Assignment would hide fields from being displayed. Validation - Required vs. not required. In addition to the type checking described above, a required flag should be included in the definition of the field. Presentation - Error messages, Labels and references to the custom field names (i.e. contextual help pages) should allow for the displaying of a system admin controlled term. Consistency - It would be nice to have a uniform approach to field definitions (security, validation, and presentation) for both stock and custom fields alike. ---------------------------------------------------------------------- ---- To view or change your list settings, click here: From preed at sigkill.com Wed Apr 9 00:15:33 2003 From: preed at sigkill.com (J. Paul Reed) Date: Tue, 8 Apr 2003 17:15:33 -0700 Subject: Bugzilla Installation List In-Reply-To: <3E93583E.70709@mozilla.org>; from gerv@mozilla.org on Wed, Apr 09, 2003 at 12:16:14AM +0100 References: <3E8DFE38.6000705@mozilla.org> <20030406164044.B3922@sigkill.com> <3E93583E.70709@mozilla.org> Message-ID: <20030408171533.C26590@sigkill.com> On 09 Apr 2003 at 00:16:14, Gervase Markham moved bits on my disk to say: > J. Paul Reed wrote: > > *Supposedly*, Google uses a hacked 2.14 internally. > > > > But I don't know if they'd want to be on a list; I guess I could ask if we > > wanted to put 'em on the list. > > If you mean what I think you mean, then go ahead and ask them :-) Yeah, I meant something like what you think I meant... ;-) Later, Paul ------------------------------------------------------------------------ J. Paul Reed -- 0xDF8708F8 || preed at sigkill.com || web.sigkill.com/preed To hold on to sanity too tight is insane. -- Nick Falzone, Pushing Tin I use PGP; you should use PGP too... if only to piss off John Ashcroft From jake at bugzilla.org Wed Apr 9 02:09:25 2003 From: jake at bugzilla.org (Jake) Date: Tue, 08 Apr 2003 22:09:25 -0400 Subject: Bugzilla Installation List In-Reply-To: <3E8DFE38.6000705@mozilla.org> References: <3E8DFE38.6000705@mozilla.org> Message-ID: <3E9380D5.1090803@bugzilla.org> Gervase Markham wrote: > Here it is - 213 of them in all, obtained by a long trawl through > Google. The page is generated from a plain text list by a quick bit of > Perl. > > It's rather heartwarming to know we have so many users. > I don't know if we wanna include it or not, but American Megatrends, Inc. (AMI) runs and old version of Bugzilla internally (RH's 2.8, heavily forked). From bbaetz at acm.org Wed Apr 9 07:41:36 2003 From: bbaetz at acm.org (Bradley Baetz) Date: Wed, 9 Apr 2003 17:41:36 +1000 Subject: SQL call formatting style In-Reply-To: <3E934CAB.6000308@mozilla.org> References: <3E862096.9000608@mozilla.org> <3E8A1667.9050803@mozilla.org> <3E8B598B.3010408@mozilla.org> <3E934CAB.6000308@mozilla.org> Message-ID: <20030409074136.GA1130@mango.home> On Tue, Apr 08, 2003 at 11:26:51PM +0100, Gervase Markham wrote: > Myk Melez wrote: > >Gervase Markham wrote: > >And placeholders should be able to be aligned vertically (perhaps this > >should be the default in fact): > > > > $dbh->some_longwinded_methodname(q{SELECT some SQL variables > > ON multiple lines > > IF necessary > > WITH placeholders ?, ?, ?}, > > undef, > > $placeholder, > > $variables, > > $here); > > We have to balance the readability of the DB call with the readability > of the code in general, which isn't helped if each DB call takes up a > third of a page. IMO, the vertical alignment of placeholders doesn't > help enough for it to be worth it for all the lines it takes up. > I think you both meant s/placeholders/keywords/. I think it does help, for complex queries. Even for simple ones, it helps to split up the various parts. When you come back to 30-40 line SQL statements a few weeks later..... Don't forget that we're slowly moving to a case where none of htese queries appear in cgis, but instead in teh associated modules. Thats already the case for index.cgi and show_bug. > >And this should be a recommendation, not a rule. > > Well, inasmuch as any Bugzilla coding standards are recommendations > rather than rules; but I believe consistent coding standards are really > important to keep our code understandable. Whilst true, I think that we have a sufficent lack of resources that spending two weeks arguing about^W^Wdiscussing brace style was a waste of time :) > > Gerv Bradley From bbaetz at acm.org Wed Apr 9 07:46:36 2003 From: bbaetz at acm.org (Bradley Baetz) Date: Wed, 9 Apr 2003 17:46:36 +1000 Subject: Sybase help ? (or MSSQL help) In-Reply-To: References: Message-ID: <20030409074636.GB1130@mango.home> On Wed, Apr 09, 2003 at 09:16:04AM +1000, Arthur Barrett wrote: > Dave, > > Thanks for that - let me know as soon as you have some patches. > > Alternatively if it looks like patches are not going to happen in the next > couple of weeks - I'd be fine with just the whole lot and any notes you have > and when I get stuck I can just look at what you had done. I should point out that there are serious problems with sybase - its protocol format doesn't allow more than one active statement handle at once, which sort of sucks. Justdave is running without locks ATM, and when he turns those on, he'll get a deadlock when logging in. Not to mention that its totally non-transaction safe, since DBD::Sybase spawns a separate connection, which of course runs in a totaly differnt transaction. > > Regs, > > > Arthur Bradley From gerv at mozilla.org Wed Apr 9 08:25:43 2003 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 09 Apr 2003 09:25:43 +0100 Subject: SQL call formatting style In-Reply-To: <20030409074136.GA1130@mango.home> References: <3E862096.9000608@mozilla.org> <3E8A1667.9050803@mozilla.org> <3E8B598B.3010408@mozilla.org> <3E934CAB.6000308@mozilla.org> <20030409074136.GA1130@mango.home> Message-ID: <3E93D907.8090405@mozilla.org> >>>And placeholders should be able to be aligned vertically (perhaps this >>>should be the default in fact): >>> >>> $dbh->some_longwinded_methodname(q{SELECT some SQL variables >>> ON multiple lines >>> IF necessary >>> WITH placeholders ?, ?, ?}, >>> undef, >>> $placeholder, >>> $variables, >>> $here); >> >>We have to balance the readability of the DB call with the readability >>of the code in general, which isn't helped if each DB call takes up a >>third of a page. IMO, the vertical alignment of placeholders doesn't >>help enough for it to be worth it for all the lines it takes up. > > I think you both meant s/placeholders/keywords/. No, I meant placeholders - the thing Myk labels as $placeholder $variables $here. I'm all for lining up the keywords in SQL queries. >>>And this should be a recommendation, not a rule. >> >>Well, inasmuch as any Bugzilla coding standards are recommendations >>rather than rules; but I believe consistent coding standards are really >>important to keep our code understandable. > > Whilst true, I think that we have a sufficent lack of resources that > spending two weeks arguing about^W^Wdiscussing brace style was a waste > of time :) I have done other things in between. :-) Gerv From bbaetz at acm.org Wed Apr 9 09:59:18 2003 From: bbaetz at acm.org (Bradley Baetz) Date: Wed, 9 Apr 2003 19:59:18 +1000 Subject: SQL call formatting style In-Reply-To: <3E93D907.8090405@mozilla.org> References: <3E862096.9000608@mozilla.org> <3E8A1667.9050803@mozilla.org> <3E8B598B.3010408@mozilla.org> <3E934CAB.6000308@mozilla.org> <20030409074136.GA1130@mango.home> <3E93D907.8090405@mozilla.org> Message-ID: <20030409095918.GA11989@mango.home> On Wed, Apr 09, 2003 at 09:25:43AM +0100, Gervase Markham wrote: > > > >I think you both meant s/placeholders/keywords/. > > No, I meant placeholders - the thing Myk labels as $placeholder > $variables $here. Oh, I thought you were talking about the ?. That depends on how far along the line we are when we get there, how long the vars are, whether some of the vars are logincally grouped (eg attributes on an object) and so on. > >Whilst true, I think that we have a sufficent lack of resources that > >spending two weeks arguing about^W^Wdiscussing brace style was a waste > >of time :) > > I have done other things in between. :-) Yes, I know :) Bradley From bbaetz at acm.org Wed Apr 9 10:43:12 2003 From: bbaetz at acm.org (Bradley Baetz) Date: Wed, 9 Apr 2003 20:43:12 +1000 Subject: New custom fields proposal In-Reply-To: <20030405013338.5BC22C2CC@diggity.schwag.org> References: <20030405013338.5BC22C2CC@diggity.schwag.org> Message-ID: <20030409104312.GA12021@mango.home> On Fri, Apr 04, 2003 at 08:33:38PM -0500, Sean McAfee wrote: > Hi, folks-- > > Enclosed is my proposal for new custom field functionality to be added to > Bugzilla. Please read, discuss, criticize, etc., especially the "Open > questions". > > > Definition > ========== > > Currently, Bugzilla offers a fixed number of named fields to describe > bugs. These fields are shared across every component in the system. > The proposed additional functionalty is the ability to define > additional fields on a per-component basis. These additional fields > are called "custom fields". I thought we were only going to do per-product? Everything else is per product. Per component is a pain, because it means that we have to handle the 'what happens when you move a bug between components' case which we sort of fudge ATM. > > Custom fields will be available in five major varieties: integer, > float, string, date, and selection. The first four of these types are > collectively referred to as "scalar" types. All scalar fields can be > set to a special "undefined" value in additional to the valid values > described below. How are you planning on storing those in the db? > > Integer > ------- > > An integer custom field contains values which are integers. Such > fields must be able to store at least the range of integers which are > typically represented as a signed four-byte quantity. > > [Open question: Should integer fields be available in signed and > unsigned varieties?] Should be fine - its just a check on entry, really. > > Bugzilla should signal an error condition if a user attempts to store > an integer outside of the allowed range into an integer field. > > [Open question: Should Bugzilla transparently offer large-integer > semantics?] I don't think theres a need. I don't see much use for integer (or float) custfields in any event - what sort of use do you have anyway? > > Bugzilla may emit client-side scripting code onto any pages that > request custom-field input that will abort form submission if an > integer field's submitted value is out of range. > Thats a separate bug. Don't put too much into this, or it'll never get done. > Float > ----- > This is all fine, but what sort of stuff do you expect people to have custom floats for? > > String > ------ > > This type of field contains human-readable text. > > [Open question: Should Bugzilla reject attempts to store arbitrary > binary data in a string field?] UTF8 only. > Each string field is flagged as belonging to one of two varieties: > short and long. A short string field can hold a maximum of 255 > characters, and may contain no vertical whitespace characters > (carriage return, newline, or vertical tab). It is represented on > Bugzilla's Web interface using a single-line text form element. A > long string field can hold large amounts of text, possibly consisting > of several lines. It is represented on Bugzilla's Web interface as a > multiline textarea form element. > > Date > ---- > > A date field contains either a date (ie, a specific day of a specific > month in a specific year), a time of day (ie, an hour from 0-23 > inclusive, and a minute and second, both from 0-59 inclusive), or > both. Each date field is flagged as containing one of these three > subsets of data. > > [Open question: Is the "time of day" subtype really necessary?] > Again, start of simple. What would people want to have a time of day for? Just a date... > Date fields are represented on Bugzilla's web interface using a pair > of drop-down listbox form elements (for the month and day) and a > single-line text-entry element (for the year) for the date portion of > the field's value (if appropriate), and a single-line text entry > widget for the time portion (if appropriate). Bugzilla should signal > an error if an invalid date or time is submitted. > > [Open question: Is this too busy? Should a simple text-entry widget > suffice for all date types?] To start with, yes. Adding a calendar popup can be a separate bug. > > Selection > --------- > > A selection field takes its value from a set of distinct string > values. No string value in any selection field's set of valid values > may contain vertical whitespace, contain leading or trailing > whitespace, or exceed 255 characters in length. > > [Open question: Should there be a limit on the size of the set of > valid strings? If so, should this limit be global or per-component?] > No limit. People can set however many entries they want. If they hve several thousand, then its their problem. > Each selection field comes in one of two varieties: "single-selection" > and "multiselection". A single-selection field's value is a subset of > the field's possible values of size either zero or one. No, an entry should always have to be selected. If people want a none option, then they can add it to teh select list. It makes the code a lost timpler, not to mention the ui. > It is > represented on Bugzilla's web interface as a drop-down listbox form > element. A multiselection field's value is an arbitrary subset of the > field's possible values. It is represented on Bugzilla's web > interface as a multiline listbox in which multiple simultaneous > selections are allowed. > Technically, its represented as :) > Each selection field's set of allowed values may be specified in one > of two ways. A "local" selection field's values are defined by the > Bugzilla administrator, and are managed by Bugzilla itself. A > "remote" selection field's values are taken from a table in a database > which need not be the same database used by Bugzilla. Thats very complex.... Lose it for the first round, I think. > > Since such queries may be expensive, Bugzilla may cache the results > for up to one hour. What do you do when the remote db drops an entry which you ahve values for? > > Since any given selection field's allowed values may change over time, > due to administrator action or variation in a remote data source, > Bugzilla should not signal an error if "invalid" field values are > found in the database. Enforcement of a selection field's valid > values is to be done only on the client side. If a bug containing a > selection field whose value is no longer valid is edited by the user, > the invalid field's value should be presented as being the null set. No. Enforcement _must_ be done on the server, or rather it must be able to be done that way on a db which supports foreign keys. We have all sorts of bugs because we do stuff on the client. > > It should be possible to share the definitions of selection fields > among multiple Bugzilla components, such that a change to one field's > data source is reflected in all other fields which share that source. Again, s/components/products/ We can do like what we do for flags, but I';m worried about perf if we have to do it in perl, without subselects. > > Logging > ======= > > Whenever a custom field's value is changed, this change should be > logged. Log information should include the identity of the user who > made the change, the time the change took place, the field's old > value, and the field's new value. This is the activity log, right? > > > Presentation > ============ > > Custom fields are to be presented on each Bugzilla page that presents > the standard Bugzilla fields. These pages include at least the > following: My idea was that we show them all at the end by default, but have a way of the template 'knowing' which ones have been done already. That way an admoin can sutomise teh templte for afield, and then it won't appear with the rest of them below. > > The query.cgi page requires more extensive modifications. > > Here is an alternate approach. A button is to be added to the query > page, to the right of the "Product", "Component", and "Version" > listboxes, labelled "Show custom fields for these components". If the > user clicks it, the query form is redisplayed, augmented with all > custom fields in all of the selected components. If no components > were selected, or if no selected component has any custom fields, the > page is simply redisplayed as it was before. Again, this is why it should be per product. Why not just show them all? We show all teh target milestones, after all (and the UI should be able to combine entries in some way, where teh field is the same but the values are different) Show them all, or at least those which are avliable on products the user has privs to see. > Different components may define different custom fields with the same > name. Therefore, custom field form elements for custom fields > belonging to the same component will need to be grouped together, > clearly labelled as belonging to that component. Good. > > Custom string fields may be queried in the same manner as the stock > fields "Comment" and "URL". That is, they may be matched against a > user-supplied string using any of the following predicates: Currently, we 'allow' any of those, and rely on the db to not prseent any matches. Thats not portable, so whatever we so with that will depend on how we solve teh generic value/ > Custom multiselection selection fields may be queried against a > multiline listbox containing all valid values for the fields. > Multiple selections within this listbox are allowed. A pair of > radiobuttons is placed next to the listbox which present two choices: > "Any" and "All". Initially, "Any" is selected. If the "Any" button > is selected at the time the query is initiated, then a bug matches > this query term if any of the selected values are set in this field. > If the "All" button is selected instead, then a bug matches this query > term if all of the selected values are set in this field. I'm not sure about this. attachments/cc/etc are a bit strange surrently with the search stuff. You left out the 'how is this stored in teh db' answer, which is the important one. Bradley From bbaetz at acm.org Wed Apr 9 11:15:48 2003 From: bbaetz at acm.org (Bradley Baetz) Date: Wed, 9 Apr 2003 21:15:48 +1000 Subject: checksetup.pl schema change locations Message-ID: <20030409111548.GA32580@mango.home> There are a whole set of these below the creation of the admin account. Anyone know why? I have this recolection that this has something to do with the groups changes that joel put in. If so, we should document it so that we know where to put later updates. Bradley From myk at mozilla.org Wed Apr 9 15:29:02 2003 From: myk at mozilla.org (Myk Melez) Date: Wed, 09 Apr 2003 08:29:02 -0700 Subject: Sybase help ? (or MSSQL help) In-Reply-To: References: Message-ID: <3E943C3E.9030603@mozilla.org> Dave wrote: >> Arthur Barrett wrote: > > >>I actaully am trying to get Bugzilla working with Win2K and MSSQL2K - has >>anyone else attempted this? >> >> > >Not that I know of. Sybase and MSSQL are similar enough that it might work >with the Sybase patches. On the other hand, they diverged several versions >back, and the newer each version is, the less chance it'll still work, >since they seem to be going in different directions. > Here's a comparison done by the MySQL folks: http://www.mysql.com/information/crash-me.php?ms_sql=on&sybase=on And, for the record, here's MySQL, PostGreSQL, and Sybase (the extant Bugzilla ports): http://www.mysql.com/information/crash-me.php?mysql_4_1=on&mysql_4_0=on&postgres=on&sybase=on -myk -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerv at mozilla.org Wed Apr 9 23:13:41 2003 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 10 Apr 2003 00:13:41 +0100 Subject: Bugzilla Installation List Message-ID: <3E94A925.9050401@mozilla.org> Available in about an hour for your inspection: http://www.bugzilla.org/installation_list.html Gerv From timeless at myrealbox.com Thu Apr 10 00:54:42 2003 From: timeless at myrealbox.com (timeless) Date: Wed, 09 Apr 2003 20:54:42 -0400 Subject: Bugzilla Installation List In-Reply-To: <3E94A925.9050401@mozilla.org> References: <3E94A925.9050401@mozilla.org> Message-ID: <3E94C0D2.9020201@myrealbox.com> Gervase Markham wrote: > Available in about an hour for your inspection: > http://www.bugzilla.org/installation_list.html netbeans isn't on the list (it's an issuezilla install) but openoffice is on the list (it's an issuezilla install) From etzwane at schwag.org Thu Apr 10 01:13:05 2003 From: etzwane at schwag.org (Sean McAfee) Date: Wed, 09 Apr 2003 21:13:05 -0400 Subject: New custom fields proposal In-Reply-To: Message-ID: <20030410011305.D69C6BC51@diggity.schwag.org> "Jon Wilmoth" wrote: >Thoughts/question inline... >Definition >========== > >Currently, Bugzilla offers a fixed number of named fields to describe >bugs. These fields are shared across every component in the system. >The proposed additional functionalty is the ability to define >additional fields on a per-component basis. These additional fields >are called "custom fields". > >I assume your talking about "component" being a broad system module >(i.e. search, creation, reporting, etc.). I'd suggest you use a >different term so as not to be confused with a Product component. > Er, no, actually. I did mean "component" in the "Product component" sense. >Date fields are represented on Bugzilla's web interface using a pair >of drop-down listbox form elements (for the month and day) and a >single-line text-entry element (for the year) for the date portion of >the field's value (if appropriate), and a single-line text entry >widget for the time portion (if appropriate). Bugzilla should signal >an error if an invalid date or time is submitted. > >[Open question: Is this too busy? Should a simple text-entry widget >suffice for all date types?] > >IMHO, yes...it's too busy. If it's a date field it would be more useful >to have a popup calendar (bottom of which could also include time >elements). I would think a date field should have a input pattern that >could vary on a field by field basis. This can be compared to java's >simple date format >(http://java.sun.com/j2se/1.4.1/docs/api/java/text/SimpleDateFormat.html >) class or oracle's to_date fuction that allow for a pattern (i.e. >MM/dd/yyyy HH:mm:ss aa zz to define a date input valid for 04/08/2003 >16:25:30 pm PDT) > Sounds reasonable to me. I've never incorporated one of those calendar popups into any of the pages I've created, but I imagine it can't be too difficult. >Selection >--------- > >A selection field takes its value from a set of distinct string >values. No string value in any selection field's set of valid values >may contain vertical whitespace, contain leading or trailing >whitespace, or exceed 255 characters in length. > >[Open question: Should there be a limit on the size of the set of >valid strings? If so, should this limit be global or per-component?] > >The main issue here is screen real-estate which is a global issue. >Having unlimited select lists can throw the html tables out of wack. >I'd suggest a global limit set to the largest possible value for the UI >where custom fields will be added. > I was talking about the total number of selections allowed in a single selection field, whereas you seem to be referring to the maximum displayed length of a single selection field. I wouldn't mind chopping displayed selection values at some reasonable length limit, but in that case the admin interface should probably display a warning if an attempt is made to create selection values which exceed this limit. >Each selection field's set of allowed values may be specified in one >of two ways. A "local" selection field's values are defined by the >Bugzilla administrator, and are managed by Bugzilla itself. A >"remote" selection field's values are taken from a table in a database >which need not be the same database used by Bugzilla. The >administrator defines the remote database in the form of a DBI connect >string, a username and password with which to log in to the other >database, a table name, and a column name. Bugzilla generates the set >of allowed values by logging in to the remote database using the >supplied username and password, and issuing the following query: > >While the "remote" concept is cool, I think it should receive a lower >priority and perhaps even be treated as a separate release of "custom >fields". There's a lot of work to do as is to manage "local" custom >fields. > That's fine with me. I was perhaps copying features too liberally from our existing system (TeamTrack), which offers a feature like this (although only for tables in TeamTrack's local database). >Different components may define different custom fields with the same >name. Therefore, custom field form elements for custom fields >belonging to the same component will need to be grouped together, >clearly labelled as belonging to that component. > >I'd like to see two levels of scoping global and by product for custom >fields. Anything else is gravy. > Is it normal that a Bugzilla installation will want to define some common information that applies to *every* product? > >Security - Assign access to custom fields to groups. Assignment would >hide fields from being displayed. > >Validation - Required vs. not required. In addition to the type >checking described above, a required flag should be included in the >definition of the field. I thought of including this, as TeamTrack offers it, but there a field's "required" status is based on an incident's state within its enclosing project's workflow. Bugzilla doesn't offer a similar state-dependent view (as far as I know). Do you mean that a "required" field would be required only when a bug is first created? >Presentation - Error messages, Labels and references to the custom field >names (i.e. contextual help pages) should allow for the displaying of a >system admin controlled term. I'm not sure I understand. Can you provide some examples? >Consistency - It would be nice to have a uniform approach to field >definitions (security, validation, and presentation) for both stock and >custom fields alike. > I agree that it would be nice--very nice, even--but I'd prefer to keep custom fields orthogonal and avoid modifying Bugzilla's core. We'll get done much faster that way. A stock/custom unification could be a separate phase. --Sean From etzwane at schwag.org Thu Apr 10 01:55:36 2003 From: etzwane at schwag.org (Sean McAfee) Date: Wed, 09 Apr 2003 21:55:36 -0400 Subject: New custom fields proposal In-Reply-To: <20030409104312.GA12021@mango.home> Message-ID: <20030410015536.64CCABC51@diggity.schwag.org> Bradley Baetz wrote: >On Fri, Apr 04, 2003 at 08:33:38PM -0500, Sean McAfee wrote: >> Definition >> ========== >> >> Currently, Bugzilla offers a fixed number of named fields to describe >> bugs. These fields are shared across every component in the system. >> The proposed additional functionalty is the ability to define >> additional fields on a per-component basis. These additional fields >> are called "custom fields". >I thought we were only going to do per-product? Everything else is >per product. > >Per component is a pain, because it means that we have to handle the >'what happens when you move a bug between components' case which we sort >of fudge ATM. I'm not so familiar with real-world use of Bugzilla yet. It was my perception that "Product" and "Component" formed a two-level hierarchy within which bug categories could be arbitrarily placed. You seem to be saying that Components within a Product are necessarily related in some way. Correct? >> Custom fields will be available in five major varieties: integer, >> float, string, date, and selection. The first four of these types are >> collectively referred to as "scalar" types. All scalar fields can be >> set to a special "undefined" value in additional to the valid values >> described below. >How are you planning on storing those in the db? I hadn't determined that yet. Still working out the "What" before attacking the "How". >> Bugzilla should signal an error condition if a user attempts to store >> an integer outside of the allowed range into an integer field. >> >> [Open question: Should Bugzilla transparently offer large-integer >> semantics?] >I don't think theres a need. I agree. >I don't see much use for integer >(or float) custfields in any event - what sort of use do you have >anyway? I included the two numeric types mainly because our existing system (TeamTrack) offers them. I suppose it wouldn't break my heart if Bugzilla didn't have them. The vast majority of our TeamTrack custom fields are of the String and Selection variety, the rest being mostly Dates. Anyone else have an opinion? >> Bugzilla may emit client-side scripting code onto any pages that >> request custom-field input that will abort form submission if an >> integer field's submitted value is out of range. >Thats a separate bug. Don't put too much into this, or it'll never get >done. Check. >> String >> ------ >> >> This type of field contains human-readable text. >> >> [Open question: Should Bugzilla reject attempts to store arbitrary >> binary data in a string field?] >UTF8 only. Sounds reasonable. >> Date >> ---- >> >> A date field contains either a date (ie, a specific day of a specific >> month in a specific year), a time of day (ie, an hour from 0-23 >> inclusive, and a minute and second, both from 0-59 inclusive), or >> both. Each date field is flagged as containing one of these three >> subsets of data. >> >> [Open question: Is the "time of day" subtype really necessary?] >Again, start of simple. What would people want to have a time of day >for? Just a date... Time-of-day was another (probably unnecessary) carryover from TeamTrack. I don't mind getting rid of it. But I think a distinction between date-only and date-plus-time-of-day could still be useful. The former might describe when a shipment of parts arrived, and the latter might describe when during a particular day that a test was performed on one of those parts. >> Date fields are represented on Bugzilla's web interface using a pair >> of drop-down listbox form elements (for the month and day) and a >> single-line text-entry element (for the year) for the date portion of >> the field's value (if appropriate), and a single-line text entry >> widget for the time portion (if appropriate). Bugzilla should signal >> an error if an invalid date or time is submitted. >> >> [Open question: Is this too busy? Should a simple text-entry widget >> suffice for all date types?] >To start with, yes. Adding a calendar popup can be a separate bug. Okay, that's fine. >> Selection >> --------- >> >> A selection field takes its value from a set of distinct string >> values. No string value in any selection field's set of valid values >> may contain vertical whitespace, contain leading or trailing >> whitespace, or exceed 255 characters in length. >> >> [Open question: Should there be a limit on the size of the set of >> valid strings? If so, should this limit be global or per-component?] >No limit. People can set however many entries they want. If they hve >several thousand, then its their problem. Sounds reasonable. >> Each selection field comes in one of two varieties: "single-selection" >> and "multiselection". A single-selection field's value is a subset of >> the field's possible values of size either zero or one. >No, an entry should always have to be selected. If people want a none >option, then they can add it to teh select list. It makes the code a >lost timpler, not to mention the ui. As long as a "None" option is provided by default when a custom selection field is created, I suppose I have no objection. >> Each selection field's set of allowed values may be specified in one >> of two ways. A "local" selection field's values are defined by the >> Bugzilla administrator, and are managed by Bugzilla itself. A >> "remote" selection field's values are taken from a table in a database >> which need not be the same database used by Bugzilla. >Thats very complex.... Lose it for the first round, I think. Okay. >> Since any given selection field's allowed values may change over time, >> due to administrator action or variation in a remote data source, >> Bugzilla should not signal an error if "invalid" field values are >> found in the database. Enforcement of a selection field's valid >> values is to be done only on the client side. If a bug containing a >> selection field whose value is no longer valid is edited by the user, >> the invalid field's value should be presented as being the null set. >No. Enforcement _must_ be done on the server, or rather it must be able >to be done that way on a db which supports foreign keys. We have all >sorts of bugs because we do stuff on the client. Well, okay... I was attempting to avoid creating some of the awkwardness I've had to deal with when programming for TeamTrack. There, very few objects are ever actually removed from the database; instead, they get tagged as being "deleted". Client code must often include clauses like "WHERE AND DELETED = 0". Nasty. And then the interface is inconsistent about how it represents these tagged values. Sometimes it just appends the string " (Deleted)" to them; other times it ignores them. I'm hoping a reasonable alternative can be worked out here. >> Logging >> ======= >> >> Whenever a custom field's value is changed, this change should be >> logged. Log information should include the identity of the user who >> made the change, the time the change took place, the field's old >> value, and the field's new value. >This is the activity log, right? Precisely. >> Presentation >> ============ >> >> Custom fields are to be presented on each Bugzilla page that presents >> the standard Bugzilla fields. These pages include at least the >> following: >My idea was that we show them all at the end by default, but have a way >of the template 'knowing' which ones have been done already. That way an >admoin can sutomise teh templte for afield, and then it won't appear >with the rest of them below. I don't follow. How would a field have been "done" already? >> The query.cgi page requires more extensive modifications. >> >> Here is an alternate approach. A button is to be added to the query >> page, to the right of the "Product", "Component", and "Version" >> listboxes, labelled "Show custom fields for these components". If the >> user clicks it, the query form is redisplayed, augmented with all >> custom fields in all of the selected components. If no components >> were selected, or if no selected component has any custom fields, the >> page is simply redisplayed as it was before. >Again, this is why it should be per product. Why not just show them all? >We show all teh target milestones, after all (and the UI should be able >to combine entries in some way, where teh field is the same but the >values are different) > >Show them all, or at least those which are avliable on products the user >has privs to see. Well, first of all, some of the projects I have here which I plan to convert from TeamTrack to Bugzilla contain dozens of custom fields. The query page would quickly become very long if they were all always shown. Secondly, it's misleading to present query elements which may have no bearing on the final query. What should Bugzilla do if the user enters a query term for project Foo, but then searches project Bar? Raise an error? Silently ignore? >> Custom string fields may be queried in the same manner as the stock >> fields "Comment" and "URL". That is, they may be matched against a >> user-supplied string using any of the following predicates: >Currently, we 'allow' any of those, and rely on the db to not prseent >any matches. Thats not portable, so whatever we so with that will depend >on how we solve teh generic value/ I don't understand. Can you elaborate? >You left out the 'how is this stored in teh db' answer, which is the >important one. That was intentional. Again, "What" before "How". --Sean From bugreport at peshkin.net Thu Apr 10 02:31:44 2003 From: bugreport at peshkin.net (Joel Peshkin) Date: Wed, 09 Apr 2003 19:31:44 -0700 Subject: Bugzilla Installation List In-Reply-To: <3E94A925.9050401@mozilla.org> References: <3E94A925.9050401@mozilla.org> Message-ID: <3E94D790.5000307@peshkin.net> Odd.... I could swear Netscape used Bugzilla :-) From jon at vmware.com Thu Apr 10 02:39:25 2003 From: jon at vmware.com (Jonathan Schatz) Date: 09 Apr 2003 19:39:25 -0700 Subject: Bugzilla Installation List In-Reply-To: <3E94A925.9050401@mozilla.org> References: <3E94A925.9050401@mozilla.org> Message-ID: <1049942365.19037.20.camel@jonschatz-lx.vmware.com> On Wed, 2003-04-09 at 16:13, Gervase Markham wrote: > Available in about an hour for your inspection: > http://www.bugzilla.org/installation_list.html don't forget VMware (even though our's isn't public). also, i get "access denied" when i try to access the nasa bugzilla.. -jon -- Jonathan Schatz Engineering System Administrator VMware, Inc "Te occidere possunt sed te edere non possunt nefas est." From dberlin at dberlin.org Thu Apr 10 03:46:36 2003 From: dberlin at dberlin.org (Daniel Berlin) Date: Wed, 9 Apr 2003 23:46:36 -0400 Subject: New custom fields proposal In-Reply-To: <20030410011305.D69C6BC51@diggity.schwag.org> Message-ID: <07B6E10E-6B07-11D7-9AF6-000393575BCC@dberlin.org> > >> >> I'd like to see two levels of scoping global and by product for custom >> fields. Anything else is gravy. >> > > Is it normal that a Bugzilla installation will want to define some > common > information that applies to *every* product? > Just to chime in, if/when binutils and gdb move from GNATS to bugzilla (they are waiting for us to see how it goes), they'll need to use the 3 custom fields i added (host, target, build). > >> Consistency - It would be nice to have a uniform approach to field >> definitions (security, validation, and presentation) for both stock >> and >> custom fields alike. >> > > I agree that it would be nice--very nice, even--but I'd prefer to keep > custom fields orthogonal and avoid modifying Bugzilla's core. We'll > get > done much faster that way. A stock/custom unification could be a > separate > phase. > > From dberlin at dberlin.org Thu Apr 10 03:50:54 2003 From: dberlin at dberlin.org (Daniel Berlin) Date: Wed, 9 Apr 2003 23:50:54 -0400 Subject: New custom fields proposal In-Reply-To: <20030410015536.64CCABC51@diggity.schwag.org> Message-ID: >> My idea was that we show them all at the end by default, but have a >> way >> of the template 'knowing' which ones have been done already. That way >> an >> admoin can sutomise teh templte for afield, and then it won't appear >> with the rest of them below. > > I don't follow. How would a field have been "done" already? I think he means if it appears somewhere else in the template for the page already. IE if i don't do anything special, the custom fields appear at the end. let's say i have 4 fields, 2 stock, 2 custom. And say the template for the page looked like: Then, the page would display: He wants that if i specifically put somewhere else on the page via the template, like so: then it will display and *not* because 3 is already "done". From bbaetz at acm.org Thu Apr 10 08:03:13 2003 From: bbaetz at acm.org (Bradley Baetz) Date: Thu, 10 Apr 2003 18:03:13 +1000 Subject: New custom fields proposal In-Reply-To: <20030410015536.64CCABC51@diggity.schwag.org> References: <20030409104312.GA12021@mango.home> <20030410015536.64CCABC51@diggity.schwag.org> Message-ID: <20030410080313.GA1288@mango.home> On Wed, Apr 09, 2003 at 09:55:36PM -0400, Sean McAfee wrote: > > I'm not so familiar with real-world use of Bugzilla yet. It was my > perception that "Product" and "Component" formed a two-level hierarchy > within which bug categories could be arbitrarily placed. You seem to be > saying that Components within a Product are necessarily related in some way. > Correct? Well, its a hierarchy. So the stuff lower down is related to the stuff higher up, sort of by definition. IT may be useful to do this on a per component basis, but lets start with per product. Flags are per component, but the moving cases are broken with that. > Time-of-day was another (probably unnecessary) carryover from TeamTrack. I > don't mind getting rid of it. But I think a distinction between date-only > and date-plus-time-of-day could still be useful. The former might describe > when a shipment of parts arrived, and the latter might describe when during > a particular day that a test was performed on one of those parts. Well, bugzilla is a bug tracking tool, remember... > >No, an entry should always have to be selected. If people want a none > >option, then they can add it to teh select list. It makes the code a > >lost timpler, not to mention the ui. > > As long as a "None" option is provided by default when a custom selection > field is created, I suppose I have no objection. We'll probbaly insert something just to make things easier, and refuse to allow the last element to be removed - it makes stuff easier. > >No. Enforcement _must_ be done on the server, or rather it must be able > >to be done that way on a db which supports foreign keys. We have all > >sorts of bugs because we do stuff on the client. > > Well, okay... I was attempting to avoid creating some of the awkwardness > I've had to deal with when programming for TeamTrack. There, very few > objects are ever actually removed from the database; instead, they get > tagged as being "deleted". Client code must often include clauses like > "WHERE AND DELETED = 0". Nasty. And then the interface is > inconsistent about how it represents these tagged values. Sometimes it just > appends the string " (Deleted)" to them; other times it ignores them. I'm > hoping a reasonable alternative can be worked out here. Well, we ahve products which are clsoed to entry. If we have views, then we could easily and simply abstract it, but... > >My idea was that we show them all at the end by default, but have a way > >of the template 'knowing' which ones have been done already. That way an > >admoin can sutomise teh templte for afield, and then it won't appear > >with the rest of them below. > > I don't follow. How would a field have been "done" already? Imagine that the status whiteboard and the os were custom fields, as well as a new field called 'expected finish date'. We want all those fields to be displayed. The whiteboard and the os are hard coded into a position here they make logical sense (eg os next to platform). At the end of this display, we want to dump out all the other fields (the finish date), but we don't want to display the os/whiteboard again. Baicsally, we'd iterate through teh fields, and skip out those which are already part of some hash > >Show them all, or at least those which are avliable on products the user > >has privs to see. > > Well, first of all, some of the projects I have here which I plan to > convert from TeamTrack to Bugzilla contain dozens of custom fields. The > query page would quickly become very long if they were all always shown. > > Secondly, it's misleading to present query elements which may have no > bearing on the final query. What should Bugzilla do if the user enters a > query term for project Foo, but then searches project Bar? Raise an error? > Silently ignore? Well, this doesn't solve that problem - what if you search on (product is a or product is b) and (custfield-a is ? or custfield-b is ?)? You still need an answer for that... > > >> Custom string fields may be queried in the same manner as the stock > >> fields "Comment" and "URL". That is, they may be matched against a > >> user-supplied string using any of the following predicates: > > >Currently, we 'allow' any of those, and rely on the db to not prseent > >any matches. Thats not portable, so whatever we so with that will depend > >on how we solve teh generic value/ > > I don't understand. Can you elaborate? We allow searchs for ' after ' for example, and that just returns false in mysql. > > >You left out the 'how is this stored in teh db' answer, which is the > >important one. > > That was intentional. Again, "What" before "How". > True, but you do have to remember the limitations of the db when coming up with a design. Bradley From justdave at syndicomm.com Thu Apr 10 14:42:41 2003 From: justdave at syndicomm.com (David Miller) Date: Thu, 10 Apr 2003 10:42:41 -0400 Subject: New custom fields proposal In-Reply-To: <20030410080313.GA1288@mango.home> References: <20030409104312.GA12021@mango.home> <20030410015536.64CCABC51@diggity.schwag.org> <20030410080313.GA1288@mango.home> Message-ID: On 4/10/03 6:03 PM +1000, Bradley Baetz wrote: >> >Currently, we 'allow' any of those, and rely on the db to not prseent >> >any matches. Thats not portable, so whatever we so with that will depend >> >on how we solve teh generic value/ >> >> I don't understand. Can you elaborate? > > We allow searchs for ' after ' for example, and > that just returns false in mysql. And returns an SQL type mismatch error in Sybase, hence the "not portable" comment a couple replies back. :) -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From JWilmoth at starbucks.com Thu Apr 10 19:05:17 2003 From: JWilmoth at starbucks.com (Jon Wilmoth) Date: Thu, 10 Apr 2003 12:05:17 -0700 Subject: New custom fields proposal Message-ID: -----Original Message----- From: Sean McAfee [mailto:etzwane at schwag.org] Sent: Wednesday, April 09, 2003 6:13 PM To: developers at bugzilla.org Subject: Re: New custom fields proposal "Jon Wilmoth" wrote: >Thoughts/question inline... >Definition >========== > >Currently, Bugzilla offers a fixed number of named fields to describe >bugs. These fields are shared across every component in the system. >The proposed additional functionalty is the ability to define >additional fields on a per-component basis. These additional fields >are called "custom fields". > >I assume your talking about "component" being a broad system module >(i.e. search, creation, reporting, etc.). I'd suggest you use a >different term so as not to be confused with a Product component. > Er, no, actually. I did mean "component" in the "Product component" sense. I think component specific custom fields might be valuable in the future however I agree with the statement there are serious cons with that approach. I'd stick with per product and global. >Selection >--------- > >A selection field takes its value from a set of distinct string >values. No string value in any selection field's set of valid values >may contain vertical whitespace, contain leading or trailing >whitespace, or exceed 255 characters in length. > >[Open question: Should there be a limit on the size of the set of >valid strings? If so, should this limit be global or per-component?] > >The main issue here is screen real-estate which is a global issue. >Having unlimited select lists can throw the html tables out of wack. >I'd suggest a global limit set to the largest possible value for the UI >where custom fields will be added. > I was talking about the total number of selections allowed in a single selection field, whereas you seem to be referring to the maximum displayed length of a single selection field. I wouldn't mind chopping displayed selection values at some reasonable length limit, but in that case the admin interface should probably display a warning if an attempt is made to create selection values which exceed this limit. Agreed, admins will need to know a max length. I would suggest restricting admins from violating the max length rather than warning and truncating. Also I don't think the system should impose a constraint on the number of values available. Certainly there are usability issues when a list gets too long, but let's make the Bugzilla administrators accountable for some common sense things. >Different components may define different custom fields with the same >name. Therefore, custom field form elements for custom fields >belonging to the same component will need to be grouped together, >clearly labelled as belonging to that component. > >I'd like to see two levels of scoping global and by product for custom >fields. Anything else is gravy. > Is it normal that a Bugzilla installation will want to define some common information that applies to *every* product? In my experience yes. We may have a "need by date" that all dev teams use, but certain products may have special "value add" fields like test lab location or bandwidth elements that don't apply to other products. > >Security - Assign access to custom fields to groups. Assignment would >hide fields from being displayed. > >Validation - Required vs. not required. In addition to the type >checking described above, a required flag should be included in the >definition of the field. I thought of including this, as TeamTrack offers it, but there a field's "required" status is based on an incident's state within its enclosing project's workflow. Bugzilla doesn't offer a similar state-dependent view (as far as I know). Do you mean that a "required" field would be required only when a bug is first created? I agree that often there is more value in state-aware constraints than not. For simplicity sake, my suggestion would be to do a first cut of either required or not...no state considerations. If this is toggleable, admins can select values appropriate to their "typical state". >Presentation - Error messages, Labels and references to the custom field >names (i.e. contextual help pages) should allow for the displaying of a >system admin controlled term. I'm not sure I understand. Can you provide some examples? Let's say I add a "NeedBy" field, the field may have a systematic name or identifier and it will should have a user-friendly name "i.e. "Need By Date". The label next to the field, any popup error msgs etc. should use the text "Need By Date" rather than "NeedBy" or "customField4". >Consistency - It would be nice to have a uniform approach to field >definitions (security, validation, and presentation) for both stock and >custom fields alike. > I agree that it would be nice--very nice, even--but I'd prefer to keep custom fields orthogonal and avoid modifying Bugzilla's core. We'll get done much faster that way. A stock/custom unification could be a separate phase. Yep the old compromise. --Sean ---- To view or change your list settings, click here: From mh12am4077 at hotmail.com Thu Apr 10 21:32:42 2003 From: mh12am4077 at hotmail.com (Me And You) Date: Fri, 11 Apr 2003 03:02:42 +0530 Subject: Adding more OS to select from dropdown list while entering Message-ID: An HTML attachment was scrubbed... URL: From justdave at syndicomm.com Thu Apr 10 22:18:42 2003 From: justdave at syndicomm.com (David Miller) Date: Thu, 10 Apr 2003 18:18:42 -0400 Subject: Adding more OS to select from dropdown list while entering In-Reply-To: References: Message-ID: On 4/11/03 3:02 AM +0530, Me And You wrote: > Hey David , > > I liked u'r suggestion. > > Why don't you let me know the file details to do it :) I did. Read the post again. :) The file is called localconfig, and it's in your bugzilla root directory. There's a list of op_sys values in there. Edit that list to suit, and when you run checksetup.pl, it'll fix the database to match what's in that file. >>From: David Miller >>Reply-To: developers at bugzilla.org >>To: developers at bugzilla.org >>Subject: Re: Adding more OS to select from dropdown list while entering >>Date: Tue, 8 Apr 2003 14:38:47 -0400 >> >>On 4/8/03 10:52 PM +0530, Me And You wrote: >> >> > Thanks so much friend, >> > >> > Finally I could find the solution :) >> > >> > I modified the field "op_sys" under the table "bugs". >> > >> > The the field "op_sys" is of type >> > >> > ENUM('All','Windows 3.1','Windows 95','Windows 98','Windows ME','Windows >> >2000','Windows NT','Mac System 7','Mac System 7.5','Mac System 7.6.1','Mac >> >System 8.0','Mac System 8.5','Mac System 8.6','Mac System >> >9.0','Linux','BSDI','FreeBSD','NetBSD','OpenBSD','AIX','BeOS','HP-UX','IRIX','Neutrino','OpenVMS','OS/2','OSF/1','Solaris','SunOS','other') >> > >> > You can run the command (to add 'Windows XP','Windows XP Home' and >> >'Windows XP Pro') >> > >> > mysql> ALTER TABLE bugs MODIFY op_sys enum('All','Windows 3.1','Windows >> >95','Windows 98','Windows ME','Windows 2000','Windows XP','Windows XP >> >Home','Windows XP Pro','Windows NT','Mac System 7','Mac System 7.5','Mac >> >System 7.6.1','Mac System 8.0','Mac System 8.5','Mac System 8.6','Mac >> >System >> >9.0','Linux','BSDI','FreeBSD','NetBSD','OpenBSD','AIX','BeOS','HP-UX','IRIX','Neutrino','OpenVMS','OS/2','OSF/1','Solaris','SunOS','other'); >> > >> > Hope this experience of mine will be helpful for all of us. >> > >> > Thanks to all for you for quick attempts to help me. >> >>Uhhh, why not just change the list in the localconfig file and run >>checksetup.pl again? It'll change the schema for you. >>-- >>Dave Miller Project Leader, Bugzilla Bug Tracking System >>http://www.justdave.net/ http://www.bugzilla.org/ >>---- >>To view or change your list settings, click here: >> > > > Mobile, masti, magic! Cool ringtones & logos. >Get noticed -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From gerv at mozilla.org Thu Apr 10 23:27:05 2003 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 11 Apr 2003 00:27:05 +0100 Subject: New custom fields proposal In-Reply-To: <20030405013338.5BC22C2CC@diggity.schwag.org> References: <20030405013338.5BC22C2CC@diggity.schwag.org> Message-ID: <3E95FDC9.3020207@mozilla.org> Sean McAfee wrote: > Enclosed is my proposal for new custom field functionality to be added to > Bugzilla. Sorry it's taken me so long to read this. > Definition > ========== > > Currently, Bugzilla offers a fixed number of named fields to describe > bugs. These fields are shared across every component in the system. > The proposed additional functionalty is the ability to define > additional fields on a per-component basis. These additional fields > are called "custom fields". As I think someone else has commented, I strongly suggest that they be per-product. That's the scope we tend to use for this sort of thing; the idea is that you should be able to move bugs between components without any values of any other fields (or their very existence) becoming invalid. > Custom fields will be available in five major varieties: integer, > float, string, date, and selection. The first four of these types are > collectively referred to as "scalar" types. All scalar fields can be > set to a special "undefined" value in additional to the valid values > described below. Do we need float? We don't have any float fields right now. I guess if it doesn't complicate things then it doesn't matter too much whether we have it or not. > [Open question: Should integer fields be available in signed and > unsigned varieties?] No. They should be signed only. > [Open question: Should Bugzilla transparently offer large-integer > semantics?] No. This is an unnecessary complication. > Bugzilla may emit client-side scripting code onto any pages that > request custom-field input that will abort form submission if an > integer field's submitted value is out of range. Hmm. Maybe. But we should never depend on its existence. > + an optional exponent, expressed as an 'E' or 'e' character, > followed by an optional plus sign ('+') or minus sign ('-'), > followed by a sequence of digits Do we really need to go this far? If the parsing library gives us this for free, then OK, but who would really store massive floats in a Bugzilla field? > [Open question: Should Bugzilla reject attempts to store arbitrary > binary data in a string field?] No. String data should be 8-bit safe, for l10n reasons if no others. > Each string field is flagged as belonging to one of two varieties: > short and long. A short string field can hold a maximum of 255 > characters, and may contain no vertical whitespace characters > (carriage return, newline, or vertical tab). It is represented on > Bugzilla's Web interface using a single-line text form element. A > long string field can hold large amounts of text, possibly consisting > of several lines. It is represented on Bugzilla's Web interface as a > multiline textarea form element. Is there a max size for the long field? I think 32K should be OK. > Date > ---- > [Open question: Is the "time of day" subtype really necessary?] No, IMO, unless you can think of a very good use for it. > [Open question: Is this too busy? Should a simple text-entry widget > suffice for all date types?] I'd say it's too busy. A text widget which takes only 2003-03-03 format dates would be fine. That's much quicker and easier to use, once learned, than multiple widgets. > [Open question: Should there be a limit on the size of the set of > valid strings? If so, should this limit be global or per-component?] Why would one need a limit? > Each selection field's set of allowed values may be specified in one > of two ways. A "local" selection field's values are defined by the > Bugzilla administrator, and are managed by Bugzilla itself. A > "remote" selection field's values are taken from a table in a database > which need not be the same database used by Bugzilla. This is all very snazzy, but does anyone have a use for it? :-) > [Open question: Should the field subtypes described above really be > their own top-level types?] Makes sense to me. Multi-select and single-select. > Presentation > ============ > > Custom fields are to be presented on each Bugzilla page that presents > the standard Bugzilla fields. These pages include at least the > following: > > On "show_bug.cgi" and "post_bug.cgi", the custom fields should be > shown just prior to the list of attachments. > > On "enter_bug.cgi" and "long_list.cgi", the custom fields should be > shown just after the "Description" text box. I don't think the custom fields design has to specify how the fields are represented on the page. But, if you want to discuss it, I think it depends what sort of field it is. For example, on the show_bug page, String fields would be below the other four/five String fields (QA, URL etc.) Moving to a CSS-based layout should make it much easier to add and remove fields. Also, while the default templates should contain generic code for displaying any custom fields, it should also be possible for admins to hard-code the position of the field themselves, and flag in the template that they've done so so that the template doesn't print it again. > The query.cgi page requires more extensive modifications. Not necessarily; you could just add them to Boolean charts, and say that admins have to edit the template to get better support. That would be a valid position. > Here is an alternate approach. A button is to be added to the query > page, to the right of the "Product", "Component", and "Version" > listboxes, labelled "Show custom fields for these components". If the > user clicks it, the query form is redisplayed, augmented with all > custom fields in all of the selected components. If no components > were selected, or if no selected component has any custom fields, the > page is simply redisplayed as it was before. Hmm. If a custom field is global, it would always be shown, of course. If there are no non-global custom fields, the button would not appear. Or, you could just display UI for all custom fields, and return zarro boogs if they queried on a custom field value in a Product for which it was not available. It depends how many custom fields people might want; if it's loads, this approach might not scale. Anyway, I think this UI needs a lot more thought. Now, I'm going to go and read what everyone else said :-) Gerv From etzwane at schwag.org Thu Apr 10 23:44:39 2003 From: etzwane at schwag.org (Sean McAfee) Date: Thu, 10 Apr 2003 19:44:39 -0400 Subject: New custom fields proposal In-Reply-To: <20030410080313.GA1288@mango.home> Message-ID: <20030410234439.5A705BC51@diggity.schwag.org> Bradley Baetz wrote: >On Wed, Apr 09, 2003 at 09:55:36PM -0400, Sean McAfee wrote: >> I'm not so familiar with real-world use of Bugzilla yet. It was my >> perception that "Product" and "Component" formed a two-level hierarchy >> within which bug categories could be arbitrarily placed. You seem to be >> saying that Components within a Product are necessarily related in some way. >> Correct? >Well, its a hierarchy. So the stuff lower down is related to the stuff >higher up, sort of by definition. I'd been thinking about the product/component relationship more like a filesystem, which is also a hierarchy, but with no particular relationship between levels. >IT may be useful to do this on a per >component basis, but lets start with per product. OK, I don't mind starting with per-product. (And global, which some folks seem to like.) >> >No, an entry should always have to be selected. If people want a none >> >option, then they can add it to teh select list. It makes the code a >> >lost timpler, not to mention the ui. >> As long as a "None" option is provided by default when a custom selection >> field is created, I suppose I have no objection. >We'll probbaly insert something just to make things easier, and refuse >to allow the last element to be removed - it makes stuff easier. Can "None" (or a similar word) be a special, reserved selection value? I'm thinking ahead to when I might want to programmatically determine whether a particular field has been set by a user yet. This won't be easy if each selection field gets its own notion of what being "unset" is called. >> >Show them all, or at least those which are avliable on products the user >> >has privs to see. >> Well, first of all, some of the projects I have here which I plan to >> convert from TeamTrack to Bugzilla contain dozens of custom fields. The >> query page would quickly become very long if they were all always shown. >> >> Secondly, it's misleading to present query elements which may have no >> bearing on the final query. What should Bugzilla do if the user enters a >> query term for project Foo, but then searches project Bar? Raise an error? >> Silently ignore? >Well, this doesn't solve that problem - what if you search on (product >is a or product is b) and (custfield-a is ? or custfield-b is ?)? You >still need an answer for that... According to my proposal, the user would select projects "a" and "b" at the top of the page, press the "Show custom fields" button, and be presented with all of the custom fields for projects "a" and "b". At this point the situation is the same as your "always show all custom fields in all projects" approach, since fields in projects other than "a" and "b" are irrelevant. Another option which since occurred to me is to use Javascript. Include all custom fields, but group them in per-project
elements which initially have the style "display: none". An event handler attached to the "Project" selection element would dynamically toggle the display styles between "inline" and "none". Is this reasonable? Is there some minimum level of scriptability we should expect from Bugzilla web clients? --Sean From bugreport at peshkin.net Thu Apr 10 23:51:46 2003 From: bugreport at peshkin.net (Joel Peshkin) Date: Thu, 10 Apr 2003 16:51:46 -0700 Subject: New custom fields proposal In-Reply-To: <3E95FDC9.3020207@mozilla.org> References: <20030405013338.5BC22C2CC@diggity.schwag.org> <3E95FDC9.3020207@mozilla.org> Message-ID: <3E960392.2030503@peshkin.net> Gervase Markham wrote: >> Each selection field's set of allowed values may be specified in one >> of two ways. A "local" selection field's values are defined by the >> Bugzilla administrator, and are managed by Bugzilla itself. A >> "remote" selection field's values are taken from a table in a database >> which need not be the same database used by Bugzilla. > > > This is all very snazzy, but does anyone have a use for it? :-) > There is a use I have, but I need to figure out if it goes far enough..... My company maintains a "product hierarchy" in an Oracle database and would want many of the selections of Bugzilla fields to be tied to that foreign data source. The problem is that just referencing that source may not be enough. Which values I can choose from for a given field may be a function of a number of things (like who I am and what product I am in). I have not yet figured out a way to generalize this. From bbaetz at acm.org Fri Apr 11 07:44:52 2003 From: bbaetz at acm.org (Bradley Baetz) Date: Fri, 11 Apr 2003 17:44:52 +1000 Subject: New custom fields proposal In-Reply-To: <20030410234439.5A705BC51@diggity.schwag.org> References: <20030410080313.GA1288@mango.home> <20030410234439.5A705BC51@diggity.schwag.org> Message-ID: <20030411074452.GA1202@mango.home> On Thu, Apr 10, 2003 at 07:44:39PM -0400, Sean McAfee wrote: > Can "None" (or a similar word) be a special, reserved selection value? I'm > thinking ahead to when I might want to programmatically determine whether a > particular field has been set by a user yet. This won't be easy if each > selection field gets its own notion of what being "unset" is called. Well, we can have NULL (in the db side). That would work with the left join rather well, actually. > According to my proposal, the user would select projects "a" and "b" at the > top of the page, press the "Show custom fields" button, and be presented > with all of the custom fields for projects "a" and "b". At this point the > situation is the same as your "always show all custom fields in all projects" > approach, since fields in projects other than "a" and "b" are irrelevant. Look at how the component/milestone/version stuff is done, depending on which products you click on. I'm imagining something like that, except we can just set .disabled, or something. > > Another option which since occurred to me is to use Javascript. Include all > custom fields, but group them in per-project
elements which initially > have the style "display: none". An event handler attached to the "Project" > selection element would dynamically toggle the display styles between > "inline" and "none". Is this reasonable? Is there some minimum level of > scriptability we should expect from Bugzilla web clients? > You can't _require_ any JS at all. You can start out with them all being visible, hide then in an onload, and then use js as people click on appropriate items. Bradley From bbaetz at acm.org Fri Apr 11 07:53:49 2003 From: bbaetz at acm.org (Bradley Baetz) Date: Fri, 11 Apr 2003 17:53:49 +1000 Subject: New custom fields proposal In-Reply-To: <3E960392.2030503@peshkin.net> References: <20030405013338.5BC22C2CC@diggity.schwag.org> <3E95FDC9.3020207@mozilla.org> <3E960392.2030503@peshkin.net> Message-ID: <20030411075349.GA1427@mango.home> On Thu, Apr 10, 2003 at 04:51:46PM -0700, Joel Peshkin wrote: > My company maintains a "product hierarchy" in an Oracle database and > would want many of the selections of Bugzilla fields to be tied to that > foreign data source. The problem is that just referencing that source > may not be enough. Which values I can choose from for a given field may > be a function of a number of things (like who I am and what product I am > in). I have not yet figured out a way to generalize this. What you do is: a) Port bugzilla to oracle b) Create a VIEW which does the filtering you want, and presents the data with the same format bugzilla uses. Use an application context for the 'current user' info, or reference a package var manually, or whatever. c) Use that instead of the table, defining triggers to handle updating if you want to (which you probably don't want to allow from the bz end). You can s/oracle/postgres/, but then you'll need a stored proc returning a set instead of the view, which will mean bugzilla hooks, and less flexibility. You can also do dblinks with oracle, and you can't with pg. Or did you mean something simpler? :) You could manually have a script to push updates from one db to the other... Bradley From gerv at mozilla.org Fri Apr 11 07:58:28 2003 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 11 Apr 2003 08:58:28 +0100 Subject: New custom fields proposal In-Reply-To: <20030410234439.5A705BC51@diggity.schwag.org> References: <20030410234439.5A705BC51@diggity.schwag.org> Message-ID: <3E9675A4.2000800@mozilla.org> > Can "None" (or a similar word) be a special, reserved selection value? I'm > thinking ahead to when I might want to programmatically determine whether a > particular field has been set by a user yet. This won't be easy if each > selection field gets its own notion of what being "unset" is called. A quick comment - no "reserved words" for localisation reasons. > According to my proposal, the user would select projects "a" and "b" at the > top of the page, press the "Show custom fields" button, and be presented > with all of the custom fields for projects "a" and "b". At this point the > situation is the same as your "always show all custom fields in all projects" > approach, since fields in projects other than "a" and "b" are irrelevant. I still think this is clunky; I'll think about a better proposal. > Another option which since occurred to me is to use Javascript. Include all As bbaetz says, you need to remember that Bugzilla has a policy of not _requiring_ it. Gerv From etzwane at schwag.org Fri Apr 11 22:42:30 2003 From: etzwane at schwag.org (Sean McAfee) Date: Fri, 11 Apr 2003 18:42:30 -0400 Subject: New custom fields proposal In-Reply-To: <3E95FDC9.3020207@mozilla.org> Message-ID: <20030411224230.841A9BC51@diggity.schwag.org> Gervase Markham wrote: >Sean McAfee wrote: >> Each string field is flagged as belonging to one of two varieties: >> short and long. A short string field can hold a maximum of 255 >> characters, and may contain no vertical whitespace characters >> (carriage return, newline, or vertical tab). It is represented on >> Bugzilla's Web interface using a single-line text form element. A >> long string field can hold large amounts of text, possibly consisting >> of several lines. It is represented on Bugzilla's Web interface as a >> multiline textarea form element. >Is there a max size for the long field? I think 32K should be OK. I was thinking long strings would be stored as mediumtexts, but yeah, a 32K text is probably plenty. >> [Open question: Should there be a limit on the size of the set of >> valid strings? If so, should this limit be global or per-component?] >Why would one need a limit? I was thinking in terms of sanity checking, but that's probably more the domain of the admins. >> [Open question: Should the field subtypes described above really be >> their own top-level types?] >Makes sense to me. Multi-select and single-select. I meant it more as a question of terminology. Assuming float fields are eliminated (as everyone seems to prefer), should one say "There are four field types: integer, string, date, and selection" or "There are five field types: integer, string, date, single-selection, and multi-selection"? >> Presentation >> ============ > >Moving to a CSS-based layout should make it much easier to add and >remove fields. How so? >Also, while the default templates should contain generic code for >displaying any custom fields, it should also be possible for admins to >hard-code the position of the field themselves, and flag in the template >that they've done so so that the template doesn't print it again. Makes sense. --Sean From etzwane at schwag.org Fri Apr 11 23:57:41 2003 From: etzwane at schwag.org (Sean McAfee) Date: Fri, 11 Apr 2003 19:57:41 -0400 Subject: New custom fields proposal In-Reply-To: <3E95FDC9.3020207@mozilla.org> Message-ID: <20030411235741.D24E6BC51@diggity.schwag.org> Whoops, missed something-- Gervase Markham wrote: >Sean McAfee wrote: >> Each string field is flagged as belonging to one of two varieties: >> short and long. A short string field can hold a maximum of 255 >> characters, and may contain no vertical whitespace characters >> (carriage return, newline, or vertical tab). It is represented on >> Bugzilla's Web interface using a single-line text form element. A >> long string field can hold large amounts of text, possibly consisting >> of several lines. It is represented on Bugzilla's Web interface as a >> multiline textarea form element. >Is there a max size for the long field? I think 32K should be OK. Why 32K? A "text" column, which would be the natural choice for a "long, but not TOO long" string, has a maximum length 64K characters. Did you have some other column type in mind, or did you misremember the maximum size of a "text" column? Or did you mean to restrict the size for other reasons? --Sean From etzwane at schwag.org Sat Apr 12 01:19:04 2003 From: etzwane at schwag.org (Sean McAfee) Date: Fri, 11 Apr 2003 21:19:04 -0400 Subject: New custom fields proposal In-Reply-To: <3E9675A4.2000800@mozilla.org> Message-ID: <20030412011904.01C11BC51@diggity.schwag.org> Gervase Markham wrote: >> Can "None" (or a similar word) be a special, reserved selection value? I'm >> thinking ahead to when I might want to programmatically determine whether a >> particular field has been set by a user yet. This won't be easy if each >> selection field gets its own notion of what being "unset" is called. >A quick comment - no "reserved words" for localisation reasons. OK, then how about allowing sites to define a local "undefined" label for single-select custom fields? The default label might be "None" in English-speaking countries, "Rien" in French-speaking countries, etc. A reasonable default to ship Bugzilla with might be something less textual, like "-----". To get slightly more ambitious, each single-select custom field might have its own notion of what it should display when it's conceptually unset, and, during field creation, would initially inherit from the sitewide default. An administrator could decide that some fields' "undefined" status is best described by the word "Unknown", others' by "Unavailable", and so on. --Sean From bbaetz at acm.org Sat Apr 12 01:53:00 2003 From: bbaetz at acm.org (Bradley Baetz) Date: Sat, 12 Apr 2003 11:53:00 +1000 Subject: New custom fields proposal In-Reply-To: <20030412011904.01C11BC51@diggity.schwag.org> References: <3E9675A4.2000800@mozilla.org> <20030412011904.01C11BC51@diggity.schwag.org> Message-ID: <20030412015300.GA14789@mango.home> On Fri, Apr 11, 2003 at 09:19:04PM -0400, Sean McAfee wrote: > > OK, then how about allowing sites to define a local "undefined" label > for single-select custom fields? The default label might be "None" > in English-speaking countries, "Rien" in French-speaking countries, etc. > A reasonable default to ship Bugzilla with might be something less textual, > like "-----". Just ue NULL in the db, and then you can have a mapping in the templates: [% IF foo.defined %] [% foo FILTER html %] [% ELSE %] None [% END IF %] ok, a bit more complicated, since you want the none option first, but the generating script can handle that, plus handlenot having the none option where its not wanted. > To get slightly more ambitious, each single-select custom field might have > its own notion of what it should display when it's conceptually unset, and, > during field creation, would initially inherit from the sitewide default. > An administrator could decide that some fields' "undefined" status is best > described by the word "Unknown", others' by "Unavailable", and so on. 'Hack the template' :) Or don't use an udnefined option, and just have an option called whatever, which is the default one. Thats probably a better way... Bradley From gerv at mozilla.org Sat Apr 12 06:42:49 2003 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 12 Apr 2003 07:42:49 +0100 Subject: New custom fields proposal In-Reply-To: <20030411235741.D24E6BC51@diggity.schwag.org> References: <20030411235741.D24E6BC51@diggity.schwag.org> Message-ID: <3E97B569.9070405@mozilla.org> > Why 32K? A "text" column, which would be the natural choice for a "long, > but not TOO long" string, has a maximum length 64K characters. Did you have > some other column type in mind, or did you misremember the maximum size of a > "text" column? Or did you mean to restrict the size for other reasons? The second one :-) My point, indirectly, was that we have a bug open on reducing the number of mediumtexts in Bugzilla in favour of texts. Gerv From gerv at mozilla.org Sat Apr 12 06:51:32 2003 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 12 Apr 2003 07:51:32 +0100 Subject: New custom fields proposal In-Reply-To: <20030411224230.841A9BC51@diggity.schwag.org> References: <20030411224230.841A9BC51@diggity.schwag.org> Message-ID: <3E97B774.3070705@mozilla.org> > I meant it more as a question of terminology. Assuming float fields are > eliminated (as everyone seems to prefer), should one say "There are four > field types: integer, string, date, and selection" or "There are five field > types: integer, string, date, single-selection, and multi-selection"? I think that sounds very sensible. People would easily get the idea that single-sel and multi-sel are different data types (even if they share some implementation under the hood.) >>Moving to a CSS-based layout should make it much easier to add and >>remove fields. > > How so? #milestone { display: none; } :-) Seriously, it's much easier to add and remove bits of a page from a CSS-based layout than a table, which needs rowspan and colspan adjustments, etc. Gerv From bbaetz at acm.org Sat Apr 12 08:37:44 2003 From: bbaetz at acm.org (Bradley Baetz) Date: Sat, 12 Apr 2003 18:37:44 +1000 Subject: HTTP redirects vs Refresh: 0 Message-ID: <20030412083744.GA16876@mango.home> Several places in the code put out a "Refresh: 0; URL=..." header. These places normally print out a message such as "Resubmitting your query with new columns..." or "Loading your query. Click here if the page does not redisplay automatically" Whilst I guess that this is informative, is there any reason that we shouldn't just redirect? The only reason that we ever see this is because of speed/latency issues (plus the browser may have a lower bound on the timeout) We should still put out the message, so that if the redirect fails teh user can still see stuff, but apart from that... Thoughts? Bradley From dberlin at dberlin.org Sat Apr 12 16:21:02 2003 From: dberlin at dberlin.org (Daniel Berlin) Date: Sat, 12 Apr 2003 12:21:02 -0400 Subject: Weekly bug summary report In-Reply-To: Message-ID: On Tuesday, April 8, 2003, at 02:49 PM, Andy Galewsky wrote: > I find this very interesting and would like to se it! Okay, i made a bug and put the files there: http://bugzilla.mozilla.org/show_bug.cgi?id=201756 From justdave at syndicomm.com Sat Apr 12 17:59:55 2003 From: justdave at syndicomm.com (David Miller) Date: Sat, 12 Apr 2003 13:59:55 -0400 Subject: HTTP redirects vs Refresh: 0 In-Reply-To: <20030412083744.GA16876@mango.home> References: <20030412083744.GA16876@mango.home> Message-ID: On 4/12/03 6:37 PM +1000, Bradley Baetz wrote: > Several places in the code put out a "Refresh: 0; URL=..." header. These > places normally print out a message such as "Resubmitting your query > with new columns..." or "Loading your query. Click here if the page does > not redisplay automatically" > > Whilst I guess that this is informative, is there any reason that we > shouldn't just redirect? The only reason that we ever see this is > because of speed/latency issues (plus the browser may have a lower > bound on the timeout) We should still put out the message, so that if > the redirect fails teh user can still see stuff, but apart from that... > > Thoughts? Posted to a Zippy bug after their QA reported that the refresh pages weren't refreshing in IE 6: Doing some quick research, I discovered that the Refresh header (both as an HTTP header and when used in a META html tag) is Netscape-specific, and not defined by any standard, which means to be standards-compliant, we really should be setting the cookie and issuing a 302 redirect instead of having an intermediate page. The question is whether or not we can alter the QUERY_STRING portion of the URL during the redirect... I can't find any clear declaration of whether that's legal or not in RFC2616... we may have to just try it and see if it works. Sources: HTTP/1.1 protocol specification (which doesn't define Refresh) http://www.rfc-editor.org/rfc/rfc2616.txt The IETF's HTTP-WG mailing list (which states Refresh isn't standard - poke around the entire thread) http://ftp.ics.uci.edu/pub/ietf/http/hypermail/1997q3/0079.html Dictionary of HTML META tags (which includes references to the specifications which define them, and shows that Refresh was invented by Netscape and not a standard) http://vancouver-webpages.com/META/metatags.detail.html -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From sergeyli at pisem.net Sat Apr 12 15:39:16 2003 From: sergeyli at pisem.net (Sergey) Date: Sat, 12 Apr 2003 11:39:16 -0400 Subject: Weekly bug summary report In-Reply-To: <02FA74A6-69F1-11D7-8BB4-000393575BCC@dberlin.org> References: <02FA74A6-69F1-11D7-8BB4-000393575BCC@dberlin.org> Message-ID: <3E983324.2090809@pisem.net> Daniel Berlin wrote: > I ported gnome's weekly bug summary report to Bugzilla 2.17.3 for use in > GCC's bugzilla. > > See http://gcc.gnu.org/bugzilla/weekly-bug-summary.cgi > > > Anyone else interested in it? > If so, i'll throw it in a bug at bugzilla.mozilla.org > Please please do, this would be terrific! Could you also drop a short note with a new bug number here? Sergey. -- Section maintainer, Source Mage GNU/Linux. From dberlin at dberlin.org Sat Apr 12 18:31:46 2003 From: dberlin at dberlin.org (Daniel Berlin) Date: Sat, 12 Apr 2003 14:31:46 -0400 Subject: Rewriting improved gnats converter Message-ID: <044010A2-6D15-11D7-8598-000393575BCC@dberlin.org> Just so no one else attempts it (or if anyone wants the WIP), I'm rewriting my vastly improved gnats converter. The current perl version is in gcc's cvs. See http://gcc.gnu.org/cgi-bin/cvsweb.cgi/wwwdocs/bugzilla/contrib/ gnats2bz.pl I'm rewriting it in python, for a few reasons: 1. The perl memory leaks memory like a sieve, with no internally caused memory leaks visible. I've run all the perl memory leak checkers, and nothing is marked as leaking. Yet the process grows to roughly half the size of the gnats db it's converting. For GCC's 600 meg gnats database, this means it grows to 300 meg, quite quickly, and stays around there. Every variable is undef'd when it's done, every file is closed. Still, no dice. The python version just doesn't leak at all. 2. It is badly in need of cleanup, and it's hard to modularize/OOify it in a nice way in perl. The python version has two main classes, GNATSbug and Bugzillabug. It builds the GNATSbug from a file, then creates Bugzillabug from it (The BugzillaBug constructor does the conversion), then writes out the Bugzillabug. The perl version has all these pieces mixed in together. 3. The python version is actually 2x-3x faster (overall) than the perl version (which was ~10x faster than the original gnats2bz.pl bugzilla comes with) because it's 2x-3x faster (average) in parsing the GNATS bugs. The code is the same in both versions (this part is a direct copy/paste/convert) if you account for language syntax differences. The gnats parsing is bounded by the speed of string concatenation in both python and perl, and the python version is just faster at it. One 21 meg PR takes 19 seconds in Perl to parse, and 2 seconds in python. The whole 600 meg, 10000 PR gnats db takes 3 minutes to convert with the python script. 4. I'm a python person (have been for a long time), so i've just been meaning to do this anyway for a while. If anyone wants the WIP, let me know. --Dan From preed at sigkill.com Sat Apr 12 18:59:18 2003 From: preed at sigkill.com (J. Paul Reed) Date: Sat, 12 Apr 2003 11:59:18 -0700 Subject: Rewriting improved gnats converter In-Reply-To: <044010A2-6D15-11D7-8598-000393575BCC@dberlin.org>; from dberlin@dberlin.org on Sat, Apr 12, 2003 at 02:31:46PM -0400 References: <044010A2-6D15-11D7-8598-000393575BCC@dberlin.org> Message-ID: <20030412115918.C9034@sigkill.com> On 12 Apr 2003 at 14:31:46, Daniel Berlin moved bits on my disk to say: > I'm rewriting it in python, for a few reasons: This brings up a good question which I don't think has been discussed before: Will Bugzilla-the-project accept code which uses a platform/language other than perl into the official CVS tree? I don't mean for this to degenerate into a language war; I'm asking only because there are infrastructure requirements by virtue of having Bugzilla installed (certain perl version, certain DBI version, etc.). I don't know if gnats is in Python (I tried looking for a few seconds, but didn't find an answer), but what are the ramifications of accepting code into the tree that's not perl? Will there be more documentation issues? Support issues? Will people who can't get gnats2bz.py working start asking us questions we may (or probably won't) be able to answer? I do not at all mean to discourage your rewrite, Dan; I'm just wondering about where your code should live when it's done. Later, Paul ------------------------------------------------------------------------ J. Paul Reed -- 0xDF8708F8 || preed at sigkill.com || web.sigkill.com/preed To hold on to sanity too tight is insane. -- Nick Falzone, Pushing Tin I use PGP; you should use PGP too... if only to piss off John Ashcroft From justdave at syndicomm.com Sat Apr 12 19:02:48 2003 From: justdave at syndicomm.com (David Miller) Date: Sat, 12 Apr 2003 15:02:48 -0400 Subject: Rewriting improved gnats converter In-Reply-To: <20030412115918.C9034@sigkill.com> References: <044010A2-6D15-11D7-8598-000393575BCC@dberlin.org> <20030412115918.C9034@sigkill.com> Message-ID: On 4/12/03 11:59 AM -0700, J. Paul Reed wrote: > On 12 Apr 2003 at 14:31:46, Daniel Berlin moved bits on my disk to say: > >> I'm rewriting it in python, for a few reasons: > > This brings up a good question which I don't think has been discussed > before: Will Bugzilla-the-project accept code which uses a > platform/language other than perl into the official CVS tree? For the primary code, no we won't. However, there's not really any rules about the content of the contrib directory, and there's already non-perl stuff in there in fact (I think we have at least one Ruby script). -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From preed at sigkill.com Sat Apr 12 19:07:40 2003 From: preed at sigkill.com (J. Paul Reed) Date: Sat, 12 Apr 2003 12:07:40 -0700 Subject: Rewriting improved gnats converter In-Reply-To: ; from justdave@syndicomm.com on Sat, Apr 12, 2003 at 03:02:48PM -0400 References: <044010A2-6D15-11D7-8598-000393575BCC@dberlin.org> <20030412115918.C9034@sigkill.com> Message-ID: <20030412120740.A9197@sigkill.com> On 12 Apr 2003 at 15:02:48, David Miller moved bits on my disk to say: > However, there's not really any rules about the content of the contrib > directory, and there's already non-perl stuff in there in fact (I think > we have at least one Ruby script). I guess I should've looked in contrib before asking. ;-) Later, Paul ------------------------------------------------------------------------ J. Paul Reed -- 0xDF8708F8 || preed at sigkill.com || web.sigkill.com/preed To hold on to sanity too tight is insane. -- Nick Falzone, Pushing Tin I use PGP; you should use PGP too... if only to piss off John Ashcroft From dberlin at dberlin.org Sat Apr 12 19:34:27 2003 From: dberlin at dberlin.org (Daniel Berlin) Date: Sat, 12 Apr 2003 15:34:27 -0400 Subject: Rewriting improved gnats converter In-Reply-To: Message-ID: On Saturday, April 12, 2003, at 03:02 PM, David Miller wrote: > On 4/12/03 11:59 AM -0700, J. Paul Reed wrote: > >> On 12 Apr 2003 at 14:31:46, Daniel Berlin moved bits on my disk to >> say: >> >>> I'm rewriting it in python, for a few reasons: >> >> This brings up a good question which I don't think has been discussed >> before: Will Bugzilla-the-project accept code which uses a >> platform/language other than perl into the official CVS tree? > > For the primary code, no we won't. > Which is why, as much as i want to, i won't rewrite the email handling into python, since it's going to eventually be integrated into the main dir, no? > However, there's not really any rules about the content of the contrib > directory, and there's already non-perl stuff in there in fact (I > think we > have at least one Ruby script). > > From preed at sigkill.com Sat Apr 12 19:55:19 2003 From: preed at sigkill.com (J. Paul Reed) Date: Sat, 12 Apr 2003 12:55:19 -0700 Subject: Rewriting improved gnats converter In-Reply-To: ; from dberlin@dberlin.org on Sat, Apr 12, 2003 at 03:34:27PM -0400 References: Message-ID: <20030412125519.A9480@sigkill.com> On 12 Apr 2003 at 15:34:27, Daniel Berlin moved bits on my disk to say: > Which is why, as much as i want to, i won't rewrite the email handling > into python, since it's going to eventually be integrated into the main > dir, no? If you're talking about bug 94850, then yes. Later, Paul ------------------------------------------------------------------------ J. Paul Reed -- 0xDF8708F8 || preed at sigkill.com || web.sigkill.com/preed To hold on to sanity too tight is insane. -- Nick Falzone, Pushing Tin I use PGP; you should use PGP too... if only to piss off John Ashcroft From dberlin at dberlin.org Sat Apr 12 20:56:44 2003 From: dberlin at dberlin.org (Daniel Berlin) Date: Sat, 12 Apr 2003 16:56:44 -0400 Subject: Rewriting improved gnats converter In-Reply-To: <20030412125519.A9480@sigkill.com> Message-ID: <45052739-6D29-11D7-8598-000393575BCC@dberlin.org> On Saturday, April 12, 2003, at 03:55 PM, J. Paul Reed wrote: > On 12 Apr 2003 at 15:34:27, Daniel Berlin moved bits on my disk to say: > >> Which is why, as much as i want to, i won't rewrite the email handling >> into python, since it's going to eventually be integrated into the >> main >> dir, no? > > If you're talking about bug 94850, then yes. Yup. From bbaetz at acm.org Sat Apr 12 23:07:38 2003 From: bbaetz at acm.org (Bradley Baetz) Date: Sun, 13 Apr 2003 09:07:38 +1000 Subject: HTTP redirects vs Refresh: 0 In-Reply-To: References: <20030412083744.GA16876@mango.home> Message-ID: <20030412230738.GA1228@mango.home> On Sat, Apr 12, 2003 at 01:59:55PM -0400, David Miller wrote: > Posted to a Zippy bug after their QA reported that the refresh pages > weren't refreshing in IE 6: > > Doing some quick research, I discovered that the Refresh header (both as an > HTTP > header and when used in a META html tag) is Netscape-specific, and not defined > by any standard, which means to be standards-compliant, we really should be > setting the cookie and issuing a 302 redirect instead of having an intermediate > page. The question is whether or not we can alter the QUERY_STRING portion of > the URL during the redirect... I can't find any clear declaration of whether > that's legal or not in RFC2616... we may have to just try it and see if it > works. Yes, you can change the query string when the next response is a GET (ie 301/302/303 response) The issue is that the resulting query string may be too long for a GET, but we can't really redirect if we want a POST. That issue affectes refresh too, though, so its not a new issue. Theres one place with refresh: 10 (the error you get if you don't have any params for buglist.cgi). What should we do with that? We can drop the refresh entirely, or leave it in for NS browsers. Bradley From bbaetz at acm.org Sat Apr 12 23:10:29 2003 From: bbaetz at acm.org (Bradley Baetz) Date: Sun, 13 Apr 2003 09:10:29 +1000 Subject: Rewriting improved gnats converter In-Reply-To: References: Message-ID: <20030412231029.GB1228@mango.home> On Sat, Apr 12, 2003 at 03:34:27PM -0400, Daniel Berlin wrote: > > Which is why, as much as i want to, i won't rewrite the email handling > into python, since it's going to eventually be integrated into the > main dir, no? Yeah, and its also going to eventually just become a call to Bug::process, or something (after parsing the data from teh email, and doing authentication, and so on). Thats hard to do in python, at least until parrot comes along. Bradley From dberlin at dberlin.org Sat Apr 12 23:37:39 2003 From: dberlin at dberlin.org (Daniel Berlin) Date: Sat, 12 Apr 2003 19:37:39 -0400 (EDT) Subject: Rewriting improved gnats converter In-Reply-To: <20030412231029.GB1228@mango.home> References: <20030412231029.GB1228@mango.home> Message-ID: On Sun, 13 Apr 2003, Bradley Baetz wrote: > On Sat, Apr 12, 2003 at 03:34:27PM -0400, Daniel Berlin wrote: > > > > Which is why, as much as i want to, i won't rewrite the email handling > > into python, since it's going to eventually be integrated into the > > main dir, no? > > Yeah, and its also going to eventually just become a call to > Bug::process, or something (after parsing the data from teh email, and > doing authentication, and so on). > > Thats hard to do in python, at least until parrot comes along. Not really. See pyperl. It works just fine (I tried it). --Dan From bbaetz at acm.org Sat Apr 12 23:51:03 2003 From: bbaetz at acm.org (Bradley Baetz) Date: Sun, 13 Apr 2003 09:51:03 +1000 Subject: Rewriting improved gnats converter In-Reply-To: References: <20030412231029.GB1228@mango.home> Message-ID: <20030412235103.GA2030@mango.home> On Sat, Apr 12, 2003 at 07:37:39PM -0400, Daniel Berlin wrote: > > Not really. > See pyperl. > It works just fine (I tried it). > "oh dear" :) I am curious why python is faster than perl, though, since I'd asume that most of the gnats parsing is regular expressions, and perl does those quite well. Bradley From dberlin at dberlin.org Sun Apr 13 00:12:15 2003 From: dberlin at dberlin.org (Daniel Berlin) Date: Sat, 12 Apr 2003 20:12:15 -0400 (EDT) Subject: Rewriting improved gnats converter In-Reply-To: <20030412235103.GA2030@mango.home> References: <20030412231029.GB1228@mango.home> <20030412235103.GA2030@mango.home> Message-ID: On Sun, 13 Apr 2003, Bradley Baetz wrote: > On Sat, Apr 12, 2003 at 07:37:39PM -0400, Daniel Berlin wrote: > > > > Not really. > > See pyperl. > > It works just fine (I tried it). > > > > "oh dear" :) > > I am curious why python is faster than perl, though, since I'd asume > that most of the gnats parsing is regular expressions, No, it's mostly string concatenation. The re's aren't a factor at the speed they run in both languages. > and perl does > those quite well. String concatenation speed difference. > > Bradley > ---- > To view or change your list settings, click here: > > From preed at sigkill.com Sun Apr 13 00:18:27 2003 From: preed at sigkill.com (J. Paul Reed) Date: Sat, 12 Apr 2003 17:18:27 -0700 Subject: Rewriting improved gnats converter In-Reply-To: ; from dberlin@dberlin.org on Sat, Apr 12, 2003 at 08:12:15PM -0400 References: <20030412231029.GB1228@mango.home> <20030412235103.GA2030@mango.home> Message-ID: <20030412171827.A11255@sigkill.com> On 12 Apr 2003 at 20:12:15, Daniel Berlin moved bits on my disk to say: > String concatenation speed difference. Please 'splain. Later, Paul ------------------------------------------------------------------------ J. Paul Reed -- 0xDF8708F8 || preed at sigkill.com || web.sigkill.com/preed To hold on to sanity too tight is insane. -- Nick Falzone, Pushing Tin I use PGP; you should use PGP too... if only to piss off John Ashcroft From dberlin at dberlin.org Sun Apr 13 00:43:38 2003 From: dberlin at dberlin.org (Daniel Berlin) Date: Sat, 12 Apr 2003 20:43:38 -0400 (EDT) Subject: Rewriting improved gnats converter In-Reply-To: <20030412171827.A11255@sigkill.com> References: <20030412231029.GB1228@mango.home> <20030412235103.GA2030@mango.home> <20030412171827.A11255@sigkill.com> Message-ID: On Sat, 12 Apr 2003, J. Paul Reed wrote: > On 12 Apr 2003 at 20:12:15, Daniel Berlin moved bits on my disk to say: > > > String concatenation speed difference. > > Please 'splain. The re's run roughly the same speed in either language. Besides the re's, the time is bounded by the time it takes to add lines to multiline fields. The python version is faster at this. From preed at sigkill.com Sun Apr 13 00:55:05 2003 From: preed at sigkill.com (J. Paul Reed) Date: Sat, 12 Apr 2003 17:55:05 -0700 Subject: Rewriting improved gnats converter In-Reply-To: ; from dberlin@dberlin.org on Sat, Apr 12, 2003 at 08:43:38PM -0400 References: <20030412231029.GB1228@mango.home> <20030412235103.GA2030@mango.home> <20030412171827.A11255@sigkill.com> Message-ID: <20030412175505.A11395@sigkill.com> On 12 Apr 2003 at 20:43:38, Daniel Berlin moved bits on my disk to say: > > Please 'splain. > > The re's run roughly the same speed in either language. > Besides the re's, the time is bounded by the time it takes > to add lines to multiline fields. > The python version is faster at this. Maybe I'm missing someting here; could you show an example of string concatenation in perl that is slower than when done in Python? Later, Paul ------------------------------------------------------------------------ J. Paul Reed -- 0xDF8708F8 || preed at sigkill.com || web.sigkill.com/preed To hold on to sanity too tight is insane. -- Nick Falzone, Pushing Tin I use PGP; you should use PGP too... if only to piss off John Ashcroft From dberlin at dberlin.org Sun Apr 13 01:57:22 2003 From: dberlin at dberlin.org (Daniel Berlin) Date: Sat, 12 Apr 2003 21:57:22 -0400 (EDT) Subject: Rewriting improved gnats converter In-Reply-To: <20030412175505.A11395@sigkill.com> References: <20030412231029.GB1228@mango.home> <20030412235103.GA2030@mango.home> <20030412171827.A11255@sigkill.com> <20030412175505.A11395@sigkill.com> Message-ID: On Sat, 12 Apr 2003, J. Paul Reed wrote: > On 12 Apr 2003 at 20:43:38, Daniel Berlin moved bits on my disk to say: > > > > Please 'splain. > > > > The re's run roughly the same speed in either language. > > Besides the re's, the time is bounded by the time it takes > > to add lines to multiline fields. > > The python version is faster at this. > > Maybe I'm missing someting here; could you show an example of string > concatenation in perl that is slower than when done in Python? Wish i could, i can't get smallprof to work anymore, so i'm guessing. 1. I know the re's run roughly the same speed, i ripped out the actual storing of the stringscode (IE just left the re's), and the times are comparable for both languages. The re's are only ever run on the input strings anyway in the speed tester. 2. The only other operation left is a huge number of string concatenation, and a small number of string comparison, since it's all the the parsing routine does. 3. The perl code to simply do re + storing takes a much larger amount of memory in PERL for the one 21 meg PR. Since the number of string comparisons is too small to affect anything, the only thing left is string concatenation. It could also be the overhead of perl doing type-f*cking and all that jazz it does behind the scenes when nobody is looking, that python doesn't do. It could also be the cache effects of whatever the hell perl is doing allocating so much more memory + the larger overhead for most perl operations is the difference. Note I don't do string concatenation the same way in both languages, however, since python strings are immutable (It would be deadly to performance on large PR's). Generally, you append to a list in pieces and join the list together at the end. Or use the array module to get an array of char's which is mutable to do this on. IE a = "" for x in xrange(300000): a += 'b' * 80 will take many minutes a = [] for x in xrange(300000): a.append('b' * 80) string = "".join(a) will take ~4 seconds Not that any of this matters, the python code is just plain easier to read, cleaner, and doesn't leak for no reason. The fact that it's faster is just icing. > > Later, > Paul > ------------------------------------------------------------------------ > J. Paul Reed -- 0xDF8708F8 || preed at sigkill.com || web.sigkill.com/preed > To hold on to sanity too tight is insane. -- Nick Falzone, Pushing Tin > > I use PGP; you should use PGP too... if only to piss off John Ashcroft > ---- > To view or change your list settings, click here: > > From gerv at mozilla.org Sun Apr 13 22:09:50 2003 From: gerv at mozilla.org (Gervase Markham) Date: Sun, 13 Apr 2003 23:09:50 +0100 Subject: HTTP redirects vs Refresh: 0 In-Reply-To: References: <20030412083744.GA16876@mango.home> Message-ID: <3E99E02E.3020005@mozilla.org> > Posted to a Zippy bug after their QA reported that the refresh pages > weren't refreshing in IE 6: You do realise it's possible to turn off Refresh in IE 6? As far as I know, it supports it fine (as evidenced by the lack of bug reports about Bugzilla being broken under IE 6 in b.m.o.) [ I should say that, having said that, I have no particular problem with replacing this mechanism with one which produces exactly the same result.] Gerv From JWilmoth at starbucks.com Mon Apr 14 18:29:29 2003 From: JWilmoth at starbucks.com (Jon Wilmoth) Date: Mon, 14 Apr 2003 11:29:29 -0700 Subject: Repeated login prompt Message-ID: I thought I'd try the developer community at large for help with http://bugzilla.mozilla.org/show_bug.cgi?id=179770. Using 2.17.3, I've run into the problem of being prompted for a login at almost every page. I have two bugzilla instances running under the same apache server and I believe this to be near the problem area. I say this because I'm running a single copy of 2.17.3 on a second server that does not suffer from this problem. Taking a look at the logincookies table, I see the same user id creating multiple cookies for 1)same ip and 2)different ip. '640','41','204.238.150.159','20030414115527' '639','41','204.238.150.162','20030414115305' '638','41','204.238.150.162','20030414115045' '637','41','204.238.150.162','20030414114717' '636','41','204.238.150.162','20030414113703' '635','41','204.238.150.162','20030414113630' '634','41','204.238.150.162','20030414113533' Anyone else experiencing this? Any solutions? Thanks, Jon From jon at vmware.com Mon Apr 14 20:30:45 2003 From: jon at vmware.com (Jonathan Schatz) Date: 14 Apr 2003 13:30:45 -0700 Subject: Rewriting improved gnats converter In-Reply-To: <044010A2-6D15-11D7-8598-000393575BCC@dberlin.org> References: <044010A2-6D15-11D7-8598-000393575BCC@dberlin.org> Message-ID: <1050352245.30993.1.camel@jonschatz-lx.vmware.com> On Sat, 2003-04-12 at 11:31, Daniel Berlin wrote: > The whole 600 meg, 10000 PR gnats db takes 3 minutes to convert with > the python script. > If anyone wants the WIP, let me know. i'm incredibly interested. here, my code takes ~2 hours to import a 25000 pr gnats db into bugzilla. granted, there is a lot of processing that happens, and we're not doing anything remotely close to a 1:1 mapping between the gnats + bugzilla schemas, but still. -jon -- Jonathan Schatz Engineering System Administrator VMware, Inc "Te occidere possunt sed te edere non possunt nefas est." From sergeyli at pisem.net Mon Apr 14 20:26:26 2003 From: sergeyli at pisem.net (Sergey A. Lipnevich) Date: Mon, 14 Apr 2003 16:26:26 -0400 Subject: Repeated login prompt In-Reply-To: References: Message-ID: In the Bugzilla 'params' area (have to log in as administrator), set cookiepath (or something like that) parameter to be longer than '/'. Flush cookies for your Bugzilla sites before testing. You might want to flush the cookies twice: once before you go to params setting page (to work around your current problem) and then after the job is done (to make sure you only get new cookies). Have some cookie afterwards ;-) Jon Wilmoth wrote: > I thought I'd try the developer community at large for help with > http://bugzilla.mozilla.org/show_bug.cgi?id=179770. Using 2.17.3, I've > run into the problem of being prompted for a login at almost every page. > I have two bugzilla instances running under the same apache server and I > believe this to be near the problem area. I say this because I'm > running a single copy of 2.17.3 on a second server that does not suffer > from this problem. > From dberlin at dberlin.org Mon Apr 14 20:56:17 2003 From: dberlin at dberlin.org (Daniel Berlin) Date: Mon, 14 Apr 2003 16:56:17 -0400 (EDT) Subject: Rewriting improved gnats converter In-Reply-To: <1050352245.30993.1.camel@jonschatz-lx.vmware.com> References: <044010A2-6D15-11D7-8598-000393575BCC@dberlin.org> <1050352245.30993.1.camel@jonschatz-lx.vmware.com> Message-ID: On Mon, 14 Apr 2003, Jonathan Schatz wrote: > On Sat, 2003-04-12 at 11:31, Daniel Berlin wrote: > > The whole 600 meg, 10000 PR gnats db takes 3 minutes to convert with > > the python script. > > If anyone wants the WIP, let me know. > > i'm incredibly interested. here, my code takes ~2 hours to import a > 25000 pr gnats db into bugzilla. This is not uncommon for the current-in-contrib gnats2bz.pl. The interesting part being, of course, that what i use (my rewrite+additions of gnats2bz.pl) and am rewriting in python, does so much more than the included script, so much faster. What you see at gcc.gnu.org/bugzilla, including attachments, seperated comments from followup emails, duplicate marking, bug activity, keywords, etc, are all a result of the converter script, not human intervention. I should have a version to post to bugzilla.mozilla.org (I believe there is a bug for a very old version of my improved gnats2bz.pl script on bugzilla.mozilla.org, which i'll just attach the python one to) > > granted, there is a lot of processing that happens, and we're not doing > anything remotely close to a 1:1 mapping between the gnats + bugzilla > schemas, but still. > We don't either. --Dan From gerv at mozilla.org Mon Apr 14 21:05:49 2003 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 14 Apr 2003 22:05:49 +0100 Subject: Migrate Bugzilla 2.12 to 2.17 (MySQL) In-Reply-To: References: Message-ID: <3E9B22AD.6080106@mozilla.org> > Thanks for that - couldnt find any mention in the manual 2.17.4 (in the > install section or the upgrade section)- but you're right it does work! I doubt very much that checksetup.pl is not mentioned in the manual :-) > There are a few references to "attachstatusdefs" that really ought to be > qualified with "if TableExists" - but other than that it's all good. Please feel free to file a bug about that. Gerv From jon at vmware.com Mon Apr 14 21:25:34 2003 From: jon at vmware.com (Jonathan Schatz) Date: 14 Apr 2003 14:25:34 -0700 Subject: Rewriting improved gnats converter In-Reply-To: References: <044010A2-6D15-11D7-8598-000393575BCC@dberlin.org> <1050352245.30993.1.camel@jonschatz-lx.vmware.com> Message-ID: <1050355533.31427.10.camel@jonschatz-lx.vmware.com> On Mon, 2003-04-14 at 13:56, Daniel Berlin wrote: > > i'm incredibly interested. here, my code takes ~2 hours to import a > > 25000 pr gnats db into bugzilla. > > This is not uncommon for the current-in-contrib gnats2bz.pl. i actually wrote the code from scratch. our gnats installation is hacked up beyond belief, and nothing stock would work with it. > I should have a version to post to bugzilla.mozilla.org (I believe there > is a bug for a very old version of my improved gnats2bz.pl script on > bugzilla.mozilla.org, which i'll just attach the python one to) awesome. > > granted, there is a lot of processing that happens, and we're not doing > > anything remotely close to a 1:1 mapping between the gnats + bugzilla > > schemas, but still. > > > We don't either. i profiled my code with dprof, and it didn't tell me anything i didn't know (ie, 95% of cpu time was spent in VMware::Gnats->convert_pr_to_bugzilla). i think most of the slowness comes from reading gnats pr's off of a nfs mounted hd. anyway, i'd love to glance through your code, although the chance of rewriting mine right before launch is pretty slim :-) -jon -- Jonathan Schatz Engineering System Administrator VMware, Inc "Te occidere possunt sed te edere non possunt nefas est." From jcorbett at center7.com Mon Apr 14 21:50:29 2003 From: jcorbett at center7.com (Jason Corbett) Date: Mon, 14 Apr 2003 15:50:29 -0600 Subject: Integration Message-ID: <3E9B2D25.8010209@center7.com> Hello Bugzilla developers, I've been reading through the lists and looking at several requests for a backend interface and several responses saying "Bugzilla isn't a library, its an application." I can appreciate your point of view, so I'm asking for advice on integration with bugzilla. I maintain a project called the tcdb (Test Case Database http://tcdb.sourceforge.net). I am looking at updates, and possible rewriting. I think it's vital to integrate with a bug database because of the duplication of information (users, projects, components, target/milestone/builds, etc). However I'm not sure what you would consider the best course of action. I thought of several possibilities: 1. wait for the sometimes mentioned xml-rpc type interface (not really possible since I'm trying to do a rewrite now) 2. write my own interface in perl (can become complicated, ie I couldn't use some of the libraries you have because the error handling is mapped to a html page.) can you think of any other way of doing the integration? We already use bugzilla, and I would like to use the information already there in my new version of the test case database. Thanks for any help you can give. Jason Corbett From jason at pyeron.com Mon Apr 14 22:11:07 2003 From: jason at pyeron.com (Jason Pyeron) Date: Mon, 14 Apr 2003 18:11:07 -0400 (EDT) Subject: Integration In-Reply-To: <3E9B2D25.8010209@center7.com> Message-ID: I disagree with the principle that Bugzilla should be an application not a library. This is a different issue. Looking at your screen shots, the add defect to testcase record could simply execute a submit to the bz page, which has had the proper components set up. All your app would have to do is maintain the bug numbers which have been filed in bz, then it would be a simple click through. You also may want to have a way to list titles of bugs [no ideas here] associated with a test case. p.s., As Bugzilla matures, it is becoming more and more inappropriate for the "web" aspects of it to be tied to the "engine" aspects. It would be a very [external] popular move to break bz into 2 projects. A Perl module for Bugzilla engine with a well specified API. And the cgi applications which use the API. Sincerely, Jason Pyeron On Mon, 14 Apr 2003, Jason Corbett wrote: Hello Bugzilla developers, I've been reading through the lists and looking at several requests for a backend interface and several responses saying "Bugzilla isn't a library, its an application." I can appreciate your point of view, so I'm asking for advice on integration with bugzilla. I maintain a project called the tcdb (Test Case Database http://tcdb.sourceforge.net). I am looking at updates, and possible rewriting. I think it's vital to integrate with a bug database because of the duplication of information (users, projects, components, target/milestone/builds, etc). However I'm not sure what you would consider the best course of action. I thought of several possibilities: 1. wait for the sometimes mentioned xml-rpc type interface (not really possible since I'm trying to do a rewrite now) 2. write my own interface in perl (can become complicated, ie I couldn't use some of the libraries you have because the error handling is mapped to a html page.) can you think of any other way of doing the integration? We already use bugzilla, and I would like to use the information already there in my new version of the test case database. Thanks for any help you can give. Jason Corbett ---- To view or change your list settings, click here: -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron http://www.pyerotechnics.com - - Owner & Lead Pyerotechnics Development, Inc. - - +1 410 808 6646 (c) 500 West University Parkway #1S - - +1 410 467 2266 (f) Baltimore, Maryland 21210-3253 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, purge the message from your system and notify the sender immediately. Any other use of the email by you is prohibited. From etzwane at schwag.org Tue Apr 15 00:39:01 2003 From: etzwane at schwag.org (Sean McAfee) Date: Mon, 14 Apr 2003 20:39:01 -0400 Subject: Revised custom fields requirements & schema Message-ID: <20030415003901.CB9ECBC51@diggity.schwag.org> Hi folks-- I've revised my requirements document in response to discussions here. I've also taken a first stab at a custom-fields-supporting database schema which will be the core of a forthcoming design document. I couldn't find any mention of whether attachments are allowed on the developers' list, but a random scan of the archives *seemed* to suggest that they're OK, so I'm attaching the two files to this message. If the message if rejected, or if people yell at me to stop, I'll resend them as two regular messages. Let me know what you think! Thanks. --Sean -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: bugzilla-custom-fields-requirements.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: bugzilla-custom-fields-schema.txt URL: From bbaetz at acm.org Tue Apr 15 08:32:55 2003 From: bbaetz at acm.org (Bradley Baetz) Date: Tue, 15 Apr 2003 18:32:55 +1000 Subject: Integration In-Reply-To: <3E9B2D25.8010209@center7.com> References: <3E9B2D25.8010209@center7.com> Message-ID: <20030415083254.GA1318@mango.home> We're slowly getting that way. See show_bug.cgi in CVS, for example. Also see buglist.cgi, although thats not as good an example quite yet. Bradley From gerv at mozilla.org Tue Apr 15 11:12:50 2003 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 15 Apr 2003 12:12:50 +0100 Subject: Integration In-Reply-To: <3E9B2D25.8010209@center7.com> References: <3E9B2D25.8010209@center7.com> Message-ID: <3E9BE932.3020407@mozilla.org> Jason Corbett wrote: > 1. wait for the sometimes mentioned xml-rpc type interface (not really > possible since I'm trying to do a rewrite now) It depends what you mean by an XML-RPC interface. Even today, you can send HTTP GET requests to Bugzilla to make it do things, and often get the results (e.g. of buglists, or bugs) back as XML. Jason Pyeron wrote: > p.s., As Bugzilla matures, it is becoming more and more inappropriate > for the "web" aspects of it to be tied to the "engine" aspects. It > would be a very [external] popular move to break bz into 2 projects. A > Perl module for Bugzilla engine with a well specified API. And the > cgi applications which use the API. We are already moving in the direction of splitting the back end from the front end, and have been for over a year now. But I don't see why that requires splitting Bugzilla into two projects. What evidence do you have to support your assertion that such a project split would be very popular? Gerv From jcorbett at center7.com Tue Apr 15 17:53:37 2003 From: jcorbett at center7.com (Jason Corbett) Date: Tue, 15 Apr 2003 11:53:37 -0600 Subject: Integration Message-ID: <3E9C4721.6090406@center7.com> Thanks for the hints. Gervase Markham mentioned: It depends what you mean by an XML-RPC interface. Even today, you can send HTTP GET requests to Bugzilla to make it do things, and often get the results (e.g. of buglists, or bugs) back as XML. Is this documented anywhere? I saw the xml.cgi, and it looks like a good interface to get a single bug in xml, but how would you get a list / query in xml. And is there any way to get a list of the different parameters, etc. I once wrote a program that logged into bugzilla, so I'm pretty sure that I could write an interface that can submit the correct values, but is there any way to get the results in a non-html format? xml.cgi should work for a single bug, but how about doing queries? If you do have these things, this is all I would need. I could write a simple Java library to access a remote bugzilla server. Jason Corbett From nabin.chaturvedi at bhilwarainfo.com Tue Apr 15 08:07:59 2003 From: nabin.chaturvedi at bhilwarainfo.com (Nabin Chaturvedi) Date: Tue, 15 Apr 2003 13:37:59 +0530 Subject: need help in bugzilla mail configuration Message-ID: Hello, I am using win2000.I have changed all the sys call to system ("perl processmail.pl", at ARGLIST).I am getting the following error ""perl processmail.pl"' is not recognized as an internal or external command, operable program or batch file". How can I solve this problem Thanks. From preed at sigkill.com Tue Apr 15 18:27:32 2003 From: preed at sigkill.com (J. Paul Reed) Date: Tue, 15 Apr 2003 11:27:32 -0700 Subject: need help in bugzilla mail configuration In-Reply-To: ; from nabin.chaturvedi@bhilwarainfo.com on Tue, Apr 15, 2003 at 01:37:59PM +0530 References: Message-ID: <20030415112732.A5702@sigkill.com> On 15 Apr 2003 at 13:37:59, Nabin Chaturvedi moved bits on my disk to say: > I am using win2000.I have changed all the sys call to system ("perl > processmail.pl", at ARGLIST).I am getting the following error > ""perl processmail.pl"' is not recognized as an internal or external > command, operable program or batch file". > How can I solve this problem The easiest solution is: don't use Windows. Win32 is not supported in the 2.16 version. Win32 is not supported in the 2.17 version (yet). If we're lucky, Win32 will be supported in the (as yet unreleased) 2.18 version. The answer to your question is in the Win32 installation guide: http://www.bugzilla.org/docs216/html/win32.html, specifically steps 10 and 11. Later, Paul ------------------------------------------------------------------------ J. Paul Reed -- 0xDF8708F8 || preed at sigkill.com || web.sigkill.com/preed To hold on to sanity too tight is insane. -- Nick Falzone, Pushing Tin I use PGP; you should use PGP too... if only to piss off John Ashcroft From Paul_Bennett at nrgn.com Tue Apr 15 18:38:11 2003 From: Paul_Bennett at nrgn.com (Bennett, Paul) Date: Tue, 15 Apr 2003 14:38:11 -0400 Subject: Net::LDAP & Groups Message-ID: I just set up Bugzilla v2.16.2 and revamped the code in CGI.pl to use Net::LDAP to hit an OpenLDAP server. It works pretty good, but I'm having troubles with the UserInGroup(). In particular the tweakparams & creategroups groups although there may be other groups. Using mysql commands, I can see that my user is in userregexp field of the groups table and the isactive bit is set. Also my user matches the one displayed at the bottom right. Even if I put ".*" in the User RegExp field it doesn't allow access. But it works going to the editusers.cgi. Any suggestions? Thanks, Paul From myk at mozilla.org Tue Apr 15 19:45:11 2003 From: myk at mozilla.org (Myk Melez) Date: Tue, 15 Apr 2003 12:45:11 -0700 Subject: Integration In-Reply-To: <3E9C4721.6090406@center7.com> References: <3E9C4721.6090406@center7.com> Message-ID: <3E9C6147.4010000@mozilla.org> Jason Corbett wrote: > Thanks for the hints. Gervase Markham mentioned: > > It depends what you mean by an XML-RPC interface. Even today, you can > send HTTP GET requests to Bugzilla to make it do things, and often get > the results (e.g. of buglists, or bugs) back as XML. > > Is this documented anywhere? I saw the xml.cgi, and it looks like a > good interface to get > a single bug in xml, but how would you get a list / query in xml. And > is there any way to get > a list of the different parameters, etc. I once wrote a program that > logged into bugzilla, so > I'm pretty sure that I could write an interface that can submit the > correct values, but is > there any way to get the results in a non-html format? xml.cgi should > work for a single bug, > but how about doing queries? If you do have these things, this is all > I would need. I could > write a simple Java library to access a remote bugzilla server. Any query to buglist.cgi can return data in content types other than HTML. Bugzilla natively supports RDF (an XML language), CSV, and JavaScript (the latter just went in recently), and you can add support for additional content types by creating a file that generates that type and dropping it into template/en/default/list/ with the name list.EXT.tmpl, where EXT is the customary filename suffix for files of that type (f.e. for RDF it's "rdf"). Then, make sure your localconfig file has a filename suffix -> content type mapping for that type, and add "&ctype=EXT" to a query string to get results back in that type. At some point perhaps this should be encapsulated into a web service. As things are going now I suspect that probably will be SOAP and/or XML over HTTP more than XML-RPC. -myk From arvind at pixim.com Tue Apr 15 21:07:47 2003 From: arvind at pixim.com (Arvind Singh) Date: Tue, 15 Apr 2003 14:07:47 -0700 Subject: How to debug Bugzilla code Message-ID: <16020FEDDBAF5440A59EB485AC75B2BB310C5D@exchange.pixim.com> Hi, I am a new user of Bugzilla. I am using Bugzilla 2.16.1. It's running on RedHat Linux 7.1. I am trying to make changes in the processmail, process_bug.cgi, show_bug.cgi & template files. How do I debug my changes ? Looking forward to hearing from you all. Thanks, Arvind. > -----Original Message----- > From: Myk Melez [mailto:myk at mozilla.org] > Sent: Tuesday, April 15, 2003 12:45 PM > To: developers at bugzilla.org > Subject: Re: Integration > > > Jason Corbett wrote: > > > Thanks for the hints. Gervase Markham mentioned: > > > > It depends what you mean by an XML-RPC interface. Even > today, you can > > send HTTP GET requests to Bugzilla to make it do things, > and often get > > the results (e.g. of buglists, or bugs) back as XML. > > > > Is this documented anywhere? I saw the xml.cgi, and it > looks like a > > good interface to get > > a single bug in xml, but how would you get a list / query > in xml. And > > is there any way to get > > a list of the different parameters, etc. I once wrote a > program that > > logged into bugzilla, so > > I'm pretty sure that I could write an interface that can submit the > > correct values, but is > > there any way to get the results in a non-html format? > xml.cgi should > > work for a single bug, > > but how about doing queries? If you do have these things, > this is all > > I would need. I could > > write a simple Java library to access a remote bugzilla server. > > Any query to buglist.cgi can return data in content types other than > HTML. Bugzilla natively supports RDF (an XML language), CSV, and > JavaScript (the latter just went in recently), and you can > add support > for additional content types by creating a file that > generates that type > and dropping it into template/en/default/list/ with the name > list.EXT.tmpl, where EXT is the customary filename suffix for > files of > that type (f.e. for RDF it's "rdf"). Then, make sure your > localconfig > file has a filename suffix -> content type mapping for that type, and > add "&ctype=EXT" to a query string to get results back in that type. > > At some point perhaps this should be encapsulated into a web > service. > As things are going now I suspect that probably will be SOAP > and/or XML > over HTTP more than XML-RPC. > > -myk > > > ---- > To view or change your list settings, click here: > > From jcorbett at center7.com Tue Apr 15 22:48:59 2003 From: jcorbett at center7.com (Jason Corbett) Date: Tue, 15 Apr 2003 16:48:59 -0600 Subject: Integration Message-ID: <3E9C8C5B.9010400@center7.com> The different interfaces look ok, but the only one implimented in all the spots is html. Unfortunately bug_list (template list/list) has html, csv, and rdf. show_bug (template bug/show) has xml, and html. It would be a little easier if say rdf or xml were supported on both of those pages. I tried looking at how hard it would be to make a rdf template for show_bug, but I don't know rdf, or this templating language and had no success. I guess I could use xml for a single bug and either rdf or csv for queries, but this would suck. Jason Corbett From dberlin at dberlin.org Wed Apr 16 02:16:22 2003 From: dberlin at dberlin.org (Daniel Berlin) Date: Tue, 15 Apr 2003 22:16:22 -0400 Subject: Integration In-Reply-To: <3E9C8C5B.9010400@center7.com> Message-ID: <6AFC9EB2-6FB1-11D7-9DB9-000393575BCC@dberlin.org> On Tuesday, April 15, 2003, at 06:48 PM, Jason Corbett wrote: > The different interfaces look ok, but the only one implimented in all > the spots is html. Unfortunately bug_list (template list/list) has > html, csv, and rdf. show_bug (template bug/show) has xml, and html. > It would be a little easier if say rdf or xml were supported on both > of those pages. I tried looking at how hard it would be to make a rdf > template for show_bug, but I don't know rdf, or this templating > language and had no success. > > I guess I could use xml for a single bug and either rdf or csv for > queries, but this would suck. Or you could just make an xml version of list/list, which would solve your problem, and contribute it, which solves it for everyone. From gerv at mozilla.org Wed Apr 16 07:01:21 2003 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 16 Apr 2003 08:01:21 +0100 Subject: Integration In-Reply-To: <3E9C8C5B.9010400@center7.com> References: <3E9C8C5B.9010400@center7.com> Message-ID: <3E9CFFC1.6060209@mozilla.org> Jason Corbett wrote: > The different interfaces look ok, but the only one implimented in all > the spots is html. Unfortunately bug_list (template list/list) has > html, csv, and rdf. show_bug (template bug/show) has xml, and html. It > would be a little easier if say rdf or xml were supported on both of > those pages. rdf is xml. Right tool for the right job - RDF is an XML-based language particularly suitable for bug lists and other tabular data. For individual bugs, we already had an XML schema, so we used that. A bug as RDF doesn't make all that much sense; a buglist as XML is something we already have - inventing a new schema won't solve anything. Gerv From bbaetz at acm.org Wed Apr 16 13:42:34 2003 From: bbaetz at acm.org (Bradley Baetz) Date: Wed, 16 Apr 2003 23:42:34 +1000 Subject: Integration In-Reply-To: <3E9C8C5B.9010400@center7.com> References: <3E9C8C5B.9010400@center7.com> Message-ID: <20030416134234.GA1535@mango.home> On Tue, Apr 15, 2003 at 04:48:59PM -0600, Jason Corbett wrote: > > I guess I could use xml for a single bug and either rdf or csv for > queries, but this would suck. You can query on bug numbers, and just use that... As a matter of fact, the xml stuff may move from show_bug to long_list at some point Bradley From myk at mozilla.org Wed Apr 16 13:48:56 2003 From: myk at mozilla.org (Myk Melez) Date: Wed, 16 Apr 2003 06:48:56 -0700 Subject: Integration In-Reply-To: <3E9CFFC1.6060209@mozilla.org> References: <3E9C8C5B.9010400@center7.com> <3E9CFFC1.6060209@mozilla.org> Message-ID: <3E9D5F48.9020102@mozilla.org> Gervase Markham wrote: > Jason Corbett wrote: > >> The different interfaces look ok, but the only one implimented in all >> the spots is html. Unfortunately bug_list (template list/list) has >> html, csv, and rdf. show_bug (template bug/show) has xml, and html. >> It would be a little easier if say rdf or xml were supported on both >> of those pages. > > > rdf is xml. Right tool for the right job - RDF is an XML-based > language particularly suitable for bug lists and other tabular data. > For individual bugs, we already had an XML schema, so we used that. In particular, RDF is good for expressing relationships between bugs and bug lists. > A bug as RDF doesn't make all that much sense; a buglist as XML is > something we already have - inventing a new schema won't solve anything. Actually bug reports as RDF do make some sense as a complement to RDF bug lists. RDF was built to support the aggregation of multiple files (or data sources) into a single data structure (specifically, a graph in the mathematical sense of the term), and RDF-savvy parsers can take advantage of that support to merge RDF bug lists with RDF bug reports in ways that aren't possible with RDF bug lists and some generic XML format. Bug lists as XML are less likely to be useful, since the RDF version of bug lists is standard XML and can be parsed and manipulated by generic XML parsers just as easily as any other XML format. Still, there's benefit to being able to reuse parsing code for both bug reports and bug lists, so we should strive to implement an RDF version of bug reports that third-party applications can use in lieu of the current XML format. -myk From stalione at avarachen.net Wed Apr 16 15:36:15 2003 From: stalione at avarachen.net (Vijay Avarachen) Date: Wed, 16 Apr 2003 10:36:15 -0500 Subject: Login in user without a prompt Message-ID: <3E9D786F.1080500@avarachen.net> Hello, I am trying to set-up a page which users will access directly (without getting prompted for a login and password) and enter their trouble ticked in there. This page will be customized to the product they are using and they won't have to worry about the various options that usually are presented when accessing enter_bug.cgi (these options will be pre-select and hidden from them). How can I do this? I am not a perl/cgi guru and goign through the mailing list archive didn't help much. We are using version 2.14.2. My first concern is how can I get the user to enter_bug.cg without the password prompt. Then I would try to figure out passing hidden values to the various options specific to the user/product. Thanks in advance. Vijay Avarachen From jcorbett at center7.com Wed Apr 16 17:36:05 2003 From: jcorbett at center7.com (Jason Corbett) Date: Wed, 16 Apr 2003 11:36:05 -0600 Subject: Integration Message-ID: <3E9D9485.2070206@center7.com> Thanks for all the responses. I won't pretend to know which interface is the correct one for the buglist and showbug parts. I can see some disagreement, and point of views on both sides. Good luck trying to figure it out. The main point I would like to focus on is being able to use a common parser framework for the automated client. It makes integration much more difficult if for every contact with bugzilla I have to use a different parsing framework / different way of getting the information. So since the first bit of information was to write the xml one for buglist, that's what I've done. I've attached it here. It is basically just a copy of the showbug xml template, but with using the columns instead. I realize you may want to use rdf as the common, and I'll work on a rdf for showbug. There is probably alot of template code that won't ever be reached, and feal free to remove it. I did this quickly so I didn't make it perfect, but it did seem to work on my system. Jason Corbett Jason Corbett -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: list.xml.tmpl URL: From dberlin at dberlin.org Wed Apr 16 17:51:06 2003 From: dberlin at dberlin.org (Daniel Berlin) Date: Wed, 16 Apr 2003 13:51:06 -0400 Subject: Rewriting improved gnats converter In-Reply-To: <1050355533.31427.10.camel@jonschatz-lx.vmware.com> Message-ID: On Monday, April 14, 2003, at 05:25 PM, Jonathan Schatz wrote: > >>> granted, there is a lot of processing that happens, and we're not >>> doing >>> anything remotely close to a 1:1 mapping between the gnats + bugzilla >>> schemas, but still. >>> >> We don't either. > > i profiled my code with dprof, and it didn't tell me anything i didn't > know (ie, 95% of cpu time was spent in > VMware::Gnats->convert_pr_to_bugzilla). i think most of the slowness > comes from reading gnats pr's off of a nfs mounted hd. Unlikely, i've actually done this before with no speed problems. If your gnats pr parser is used in convert_pr_to_bugzilla (i'm not sure which functions do what in your version, of course :P) looks anything like read_pr in contrib/gnats2bz.pl , that might be the cause of your slowdown. 1. The way it's written is just very slow. For every line, it tries to match every possible field against it. 2. Worse, the way the re's are written (/^$field:\s*$/) means they are compiled and thrown away once for every field and every line, rather than reused, because they are dependent on the value of $field. 3. The parse_pr code from gnatsweb was cleaner and smaller and faster, so i had borrowed that in my gnats2bz.pl. > > anyway, i'd love to glance through your code, although the chance of > rewriting mine right before launch is pretty slim :-) > It's been attached to bug 126252 on bugzilla.mozilla.org --Dan From arvind at pixim.com Wed Apr 16 17:54:31 2003 From: arvind at pixim.com (Arvind Singh) Date: Wed, 16 Apr 2003 10:54:31 -0700 Subject: Customizing Templates Message-ID: <16020FEDDBAF5440A59EB485AC75B2BB310C65@exchange.pixim.com> I tried to make one property as hiddenin templates, but it always reset the values. Example: code changes in edit.html.tmpl [% FOREACH group = groups %]     
[% END %] I tried to make the group property as hidden, but whenever I do a commit it reset the groupset value. For example earlier the groupset value was 32768, but it reset to 163840. I tried making the values as readonly : but it did n't work. Is there a way to do it. Thanks, Arvind. > -----Original Message----- > From: Gervase Markham [mailto:gerv at mozilla.org] > Sent: Tuesday, April 15, 2003 4:17 AM > To: Arvind Singh > Subject: Re: Customizing Templates > > > > > I get the following error when I add comments and do a commit. > > > > Bug processed > > Bugzilla has suffered an internal error. Please save this > page and send it to arvind at pixim.com with details of what you > were doing at the time this message appeared. > > A legal Priority was not set. > > > > I assume the problem is because of [% PROCESS select > selname = "rep_platform" %] > > No, it's because "a legal Priority was not set", as the error message > says :-) > > The problem you have is that Bugzilla expects every field to be > submitted; if you don't submit e.g. priority, it complains. > Instead of > removing the fields, you could make them type="hidden">, but then > people could see the values by viewing the source of the page. > Otherwise, you'll need to change process_bug to Do The Right Thing if > various form fields aren't submitted. > > Gerv > > From myk at mozilla.org Thu Apr 17 00:41:45 2003 From: myk at mozilla.org (Myk Melez) Date: Wed, 16 Apr 2003 17:41:45 -0700 Subject: getting MySQL AB using Bugzilla Message-ID: <3E9DF849.9000807@mozilla.org> Last week I went to the MySQL users conference. I got a bunch of information about MySQL plans for the future that I'll summarize in a writeup shortly. I also demoed Bugzilla to Tom Basil, MySQL AB Director of Support, and Jim Winstead, MySQL AB Web Developer (MySQL AB is the company responsible for almost all development work on MySQL). They are looking for a system to replace several different systems they use to track bugs and IT support issues. Getting MySQL AB to use Bugzilla would be a big win for our project, since they would probably straighten out any MySQL optimization issues in short order. Jim is familiar with Bugzilla and has used it before. He liked the templatization work we've done and is looking forward to the current modularization drive. Tom wasn't familiar with it and asked what other companies have chosen Bugzilla, so I showed him the list (thanks Gerv and others for that very timely compilation). Jim's main question was the state of the email to bug engine, since Monty (MySQL AB co-founder and MySQL technical lead) uses the current one religiously. What's the status of that? -myk From preed at sigkill.com Thu Apr 17 01:01:36 2003 From: preed at sigkill.com (J. Paul Reed) Date: Wed, 16 Apr 2003 18:01:36 -0700 Subject: getting MySQL AB using Bugzilla In-Reply-To: <3E9DF849.9000807@mozilla.org>; from myk@mozilla.org on Wed, Apr 16, 2003 at 05:41:45PM -0700 References: <3E9DF849.9000807@mozilla.org> Message-ID: <20030416180136.A15146@sigkill.com> On 16 Apr 2003 at 17:41:45, Myk Melez moved bits on my disk to say: > Jim's main question was the state of the email to bug engine, since Monty > (MySQL AB co-founder and MySQL technical lead) uses the current one > religiously. What's the status of that? If you're talking about bug 94850, it's on my radar as the first thing to tackle after 84876 goes in. Granted, I haven't had much time to work on BZ lately... graduating, as bbaetz knows, can be a real bitch. But I plan to block some time out this summer, if not before, to work on these things, if no one beats me to it. I've been holding off on feature requests and such because 84876 and 124174 are such foundation-changing bugs... so anyone who might work on this should take that into account (even if 94850 doesn't directly fall into the email notification... there was a thread on this list about that, IIRC). But, 94850 is a 2.18 blocker and an oft-requested feature, so... we know about it and it looks like we're committed to providing it for 2.18... whenever *that* release happens... ;-) Later, Paul ------------------------------------------------------------------------ J. Paul Reed -- 0xDF8708F8 || preed at sigkill.com || web.sigkill.com/preed To hold on to sanity too tight is insane. -- Nick Falzone, Pushing Tin I use PGP; you should use PGP too... if only to piss off John Ashcroft From gerv at mozilla.org Thu Apr 17 07:33:20 2003 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 17 Apr 2003 08:33:20 +0100 Subject: getting MySQL AB using Bugzilla In-Reply-To: <20030416180136.A15146@sigkill.com> References: <3E9DF849.9000807@mozilla.org> <20030416180136.A15146@sigkill.com> Message-ID: <3E9E58C0.2040905@mozilla.org> J. Paul Reed wrote: > I've been holding off on feature requests and such because 84876 and 124174 > are such foundation-changing bugs... With respect, 84876 isn't particularly foundation-changing, unless you engineer it to be. My patch was pretty simple and _a_ reasonable approach (though not the only one), and we've just passed the 1 year anniversary of me attaching it to the bug. In addition, configuring email is by far the #1 support request we get. Making it easier by using a Perl module would reduce that load immensely, and provide a much better user experience for admins; again, my patch does that. I realise there's some history here, and I've been holding off that bug in order to avoid another conflict, but given that it's been over a year, JP, I do think it's time you either commit to a deadline (soon) for doing the patch or allow someone else to take the bug and drive it to checkin. > But, 94850 is a 2.18 blocker and an oft-requested feature, so... we know > about it and it looks like we're committed to providing it for 2.18... > whenever *that* release happens... ;-) At the current rate, we certainly won't be providing it by 2.18. I believe the current thinking is (and I support) doing 2.18 in short order after 2.17.4, because we need a newer stable release. Gerv From bbaetz at acm.org Thu Apr 17 07:38:11 2003 From: bbaetz at acm.org (Bradley Baetz) Date: Thu, 17 Apr 2003 17:38:11 +1000 Subject: getting MySQL AB using Bugzilla In-Reply-To: <3E9DF849.9000807@mozilla.org> References: <3E9DF849.9000807@mozilla.org> Message-ID: <20030417073811.GA1281@mango.home> I take it that that means that dropping mysql support won't go down too well? :) If they fix the issues we have in a version which is stable now, rather than in pre-alpha development, then I guess it'd be good, though. Bradley From preed at sigkill.com Thu Apr 17 14:04:01 2003 From: preed at sigkill.com (J. Paul Reed) Date: Thu, 17 Apr 2003 07:04:01 -0700 Subject: getting MySQL AB using Bugzilla In-Reply-To: <3E9E58C0.2040905@mozilla.org>; from gerv@mozilla.org on Thu, Apr 17, 2003 at 08:33:20AM +0100 References: <3E9DF849.9000807@mozilla.org> <20030416180136.A15146@sigkill.com> <3E9E58C0.2040905@mozilla.org> Message-ID: <20030417070401.A17792@sigkill.com> On 17 Apr 2003 at 08:33:20, Gervase Markham moved bits on my disk to say: > but given that it's been over a year, JP, I do think it's time you either > commit to a deadline (soon) for doing the patch or allow someone else to > take the bug and drive it to checkin. What would be a good deadline for you? Later, Paul ------------------------------------------------------------------------ J. Paul Reed -- 0xDF8708F8 || preed at sigkill.com || web.sigkill.com/preed To hold on to sanity too tight is insane. -- Nick Falzone, Pushing Tin I use PGP; you should use PGP too... if only to piss off John Ashcroft From gerv at mozilla.org Thu Apr 17 21:21:52 2003 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 17 Apr 2003 22:21:52 +0100 Subject: getting MySQL AB using Bugzilla In-Reply-To: <20030417070401.A17792@sigkill.com> References: <3E9DF849.9000807@mozilla.org> <20030416180136.A15146@sigkill.com> <3E9E58C0.2040905@mozilla.org> <20030417070401.A17792@sigkill.com> Message-ID: <3E9F1AF0.3060802@mozilla.org> J. Paul Reed wrote: > On 17 Apr 2003 at 08:33:20, Gervase Markham moved bits on my disk to say: > >>but given that it's been over a year, JP, I do think it's time you either >>commit to a deadline (soon) for doing the patch or allow someone else to >>take the bug and drive it to checkin. > > What would be a good deadline for you? When do you think you can manage? :-) Gerv From preed at sigkill.com Thu Apr 17 21:43:39 2003 From: preed at sigkill.com (J. Paul Reed) Date: Thu, 17 Apr 2003 14:43:39 -0700 Subject: getting MySQL AB using Bugzilla In-Reply-To: <3E9F1AF0.3060802@mozilla.org>; from gerv@mozilla.org on Thu, Apr 17, 2003 at 10:21:52PM +0100 References: <3E9DF849.9000807@mozilla.org> <20030416180136.A15146@sigkill.com> <3E9E58C0.2040905@mozilla.org> <20030417070401.A17792@sigkill.com> <3E9F1AF0.3060802@mozilla.org> Message-ID: <20030417144339.A20455@sigkill.com> On 17 Apr 2003 at 22:21:52, Gervase Markham moved bits on my disk to say: > When do you think you can manage? :-) Two months. I could *manage* earlier than this, but I'd rather not. I talked to justdave on IRC this morning and he said that such an estimate is mostly compatible with how long 2.18 is *likely* to take in real time to get out ("probably 3 to 4 months yet though", with the admission that it could be sooner). So, such an estimate should be fine, I think. The fact that it's "by far the #1 support request" is irrelevant; most people aren't going to upgrade until there's a new stable release anyway, so an answer of "Oh, mail configuration is *much* easier in 2.17.5" isn't helpful to lots (the majority?) of people. Later, Paul ------------------------------------------------------------------------ J. Paul Reed -- 0xDF8708F8 || preed at sigkill.com || web.sigkill.com/preed To hold on to sanity too tight is insane. -- Nick Falzone, Pushing Tin I use PGP; you should use PGP too... if only to piss off John Ashcroft From cbryanos at voicesignal.com Thu Apr 17 21:45:29 2003 From: cbryanos at voicesignal.com (Bryanos, Costa) Date: Thu, 17 Apr 2003 17:45:29 -0400 Subject: Setting up the UI in a particular way. Message-ID: I'm new to Bugzilla (2.16.2) My company's software is added to about 150 products and growing. I want to break down the products into a hierarchy so that the user won't have to look through 150 or more products. I have two ideas about setting this up and would very much appreciate any feedback on the best way to approach this. Approach one Click on "Enter a new bug report", this page generally has your list of products in which you select and enter. I was thinking that I could add pull down menus labeled as general areas. Each pull down menu would have the products, which relate to that area. I'm not sure the level of hacking I would need to do to accomplish this. Approach two Click on "Enter a new bug report". Now click on a Product Area link. On this page you can select a specific platform under the Platform pull down menu. I would have to make each Platform pull down menu different within each Product Area link. I don't know how I would do that. How can I specify a different Platform list for each Product Area? Is there an easy way to do this that I don't know about? Also, I believe that there is a limit of 55 products within Bugzilla. Is this true? If so how can I get around this constraint? I'm looking to get this done ASAP. Thank you for any input. Costa Bryanos From bugreport at peshkin.net Fri Apr 18 00:46:15 2003 From: bugreport at peshkin.net (Joel Peshkin) Date: Thu, 17 Apr 2003 17:46:15 -0700 Subject: Setting up the UI in a particular way. In-Reply-To: References: Message-ID: <3E9F4AD7.9010502@peshkin.net> Bryanos, Costa wrote: > >Approach two >Click on "Enter a new bug report". Now click on a Product Area link. On this >page you can select a specific platform under the Platform pull down menu. I >would have to make each Platform pull down menu different within each >Product Area link. I don't know how I would do that. How can I specify a >different Platform list for each Product Area? > >Is there an easy way to do this that I don't know about? Also, I believe >that there is a limit of 55 products within Bugzilla. Is this true? If so >how can I get around this constraint? >I'm looking to get this done ASAP. > Costa, If you are using access groups for products, you will need to use 2.17.* which permits an arbitrary (well, 32000 anyway) groups. Your categorization issue will require a bit of hacking, but I do have a crude patch (against 2.17.1-ish code) that adds a field called "Menugroup" to the product. When a user creates a bug, if they would be able to enter bugs into products with more than one distinct menugroup, then they are prompted to first select which menugroup. There are no descriptions for the menugroups, but the names themselves can be descriptive. If you start down the 2.17 path and want this, I can dust it off and provide it to you. Since I would have to update it to the current tip, please get your other steps out of the way before asking me for this. -Joel From myk at mozilla.org Fri Apr 18 02:26:08 2003 From: myk at mozilla.org (Myk Melez) Date: Thu, 17 Apr 2003 19:26:08 -0700 Subject: MySQL user's Conference Message-ID: <3E9F6240.50009@mozilla.org> Last week I attended the MySQL user's conference. I attended a number of technical sessions on features and how to use them. I also attended sessions on open source licensing strategies and the MySQL development methodology and business model, and I got to demonstrate Bugzilla to some MySQL AB employees looking into replacements for their current bug tracking systems. Here's a summary of important things I learned: State of the Code & Future Plans The project is working on four releases right now: 3.23 (the older stable release), 4.0 (the current stable release), 4.1 (in alpha, scheduled for beta later this year), and 5.0 (pre-alpha, scheduled for alpha soon after 4.1 goes beta). The 3.23 stable release is still supported but will only be updated to fix critical bugs. 3.23 introduced a number of major features including transactions (in the "max" distribution), replication (for mirroring databases on multiple machines), and full-text search (Google-like searches). 4.0 expands on these with transactions available in the default distribution, much easier replication, and boolean full-text search ("+some_word -some_other_word") along with multi-table delete (DELETE FROM ... JOIN ...). 4.1 will include partial sub-query support, SSL encryption for connections to the server, full-text search optimizations, and prepared statements (increases efficiency of multiple syntactically-equivalent queries run consecutively). 5.0 will have full sub-query support and optimizations, referential integrity for MyISAM tables, and possibly stored procedures. 5.0 is the first release that will be targeted at the enterprise market. Planning for 5.1 is underway. Development Methodology & Goals Their four "commitments" in order of highest to lowest priority are speed, reliability, ease of use, and economy. Developers can't check in code without checking in documentation for it. Their release cycle has four stages: * pre-alpha (anything goes); * alpha (stable, but features and API may change); * beta (no changes to features and API except by request of important paying customer); * production/stable (only bug fixes). They have a 30 day development cycle with five objectives for each developer per month. They are looking to shorten their release cycles. They use Bitkeeper for source code and revision control because Monty (the lead developer) thinks it's better than CVS. Business MySQL AB is the company developing MySQL. They have 65 employees and 12 full-time developers. Innobase OY is the company developing the InnoDB storage engine. They have one and a half employees, one of whom is the founder. Because of their dual GPL/commercial license, they get very little community development, a common problem with such licenses. They are a developer-driven company, but sales is gaining influence over time. User-Defined Functions User-defined functions are useful for things MySQL doesn't provide, especially when extracting data from the database, processing it, and then putting it back into the database is expensive. Can be written in C++, Perl, or presumably other languages, but doesn't make much sense to write them in scripted languages; you might as well just do them in your app. Simple API with f.e. Init(), Request() (called once per row), DeInit() functions. Used by Slashdot to improve performance, f.e. by implementing customized high-performance full-text search. http://software.tangent.org/ Subqueries There are two kinds of subqueries: dependent/correlated, which rely on tables/columns from parent query (and execute once for each row of the parent query), and independent/noncorrelated, which don't and tend to be more efficient. Joins are generally more performant than subqueries at the moment in 4.1; subquery optimization is scheduled for 5.0. Types & Examples (in pseudo-code): * derived tables: SELECT * FROM foo, (SELECT ...) (cannot be dependent) * expressions (single values or rows): SELECT * FROM addresses WHERE state = (SELECT abbr FROM states WHERE name = 'California') * booleans: EXISTS, IN, ALL, ANY, SOME (synonym for ANY) * UNIQUE, MATCH, and FOR are currently unimplemented InnoDB InnoDB is a table type with full ACID (transactional) compliance. It was built for speed by a former mathematician who thought he could beat commercial enterprise-class databases at the game. Unofficial benchmarks show up to 2-4 times improvement over commercial alternatives. 4.1 will bring performance improvements in edge cases, 5.0 will bring transaction savepoints. Developers may implement multiple tablespaces so tables can be spread across multiple disks, and other plans include BLOB prefix indexes, 2-phase commit, full-text indexes, and auto lockless failover in replication. InnoDB apparently has some transaction isolation options PostGreSQL doesn't have (don't have details on this). Perl DBI (Tim Bunce) Perl DBI was built for speed and is pretty efficient, but you have to know how to use it right. For speed: * use prepare() (doesn't work until MySQL 4.1, but you should use it in preparation) * use prepare() and execute() in speed-critical loops instead of do() * select as reference, especially if columns increase * try fetchall_arrayref to see if it's faster * use RaiseError instead of checking return values * bind columns * beware copying data into functions * use operators (grep, map) where possible instead of loops * profile with # DBI_PROFILE=x test.pl where "x" is 1-6 For reliability: * use DBI->connect_cached * don't use DBD::mysql < 2.1026 with locks (because of its auto-reconnect feature, which you can't disable without recompiling) Misc: * use $h->{TraceLevel} = x where x = 0,1,2,3 etc. to trace execution * use Taint, TaintIn, TaintOut settings to turn on/off tainting * use $dbh->quote_identifier(space, table, column, attributes) to quote "space.table.column" references * use DBD::Multiplex to deal with mirrors * use $dbh->clone for new database handles * finish() is most misunderstood method in API; really means discard_pending_results Optimizing MySQL (Jeremy Zawodny) * MySQL is tuned for small-medium data sets and systems by default. If you have lots of memory you need to configure it to use it. * Use MySQL super smack for benchmarking. * Don't use bigger columns than you need, use NOT NULL (helps in edge cases) and fixed sizes where possible. * Compress data if possible. gzip is quick, cheap, and makes things faster, but you can't use it if you want to search the data. * InnoDB can be slower with large data than MyISAM, but it's generally about as fast. * Understand the leftmost prefix rule for indexes, and note that MySQL will only ever use one index per table, so you need to create compound column indexes if you want it to use two indexes (f.e. how about product_id and bug_status in Bugzilla?) * Index hashes instead of large values (f.e. URLs). * Don't store computable data. * Keep clients near the server, since network latency can be a killer. * Keep primary keys short for InnoDB. * Pick the fastest driver. * Simplify WHERE clauses and don't compute in them. * The most important variables to tune are the query cache, table buffer, and table cache. * 2.4.10 - 2.4.15 of Linux kernel are bad for MySQL. * Use SQL_CALC_ROWS() and SELECT_FOUND_ROWS(). * Use a UNION to break a query not using two indexes into two, each using one. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bbaetz at acm.org Fri Apr 18 02:59:59 2003 From: bbaetz at acm.org (Bradley Baetz) Date: Fri, 18 Apr 2003 12:59:59 +1000 Subject: MySQL user's Conference In-Reply-To: <3E9F6240.50009@mozilla.org> References: <3E9F6240.50009@mozilla.org> Message-ID: <20030418025959.GA2565@mango.home> On Thu, Apr 17, 2003 at 07:26:08PM -0700, Myk Melez wrote: > > 4.0 expands on these with transactions available in the default > distribution, much easier replication, and boolean full-text search > ("+some_word -some_other_word") along with multi-table delete (DELETE > FROM ... JOIN ...). multi-table delete isn't really useful for us, bccase its not portable. If you have subselects, then you can get teh same functionality trivially. > > 4.1 will include partial sub-query support, SSL encryption for > connections to the server, full-text search optimizations, and prepared > statements (increases efficiency of multiple syntactically-equivalent > queries run consecutively). Prepared statements do sound interesting. Postgres has them, but not at the protocol level, although thats planned for the next release. > User-Defined Functions > > User-defined functions are useful for things MySQL doesn't provide, > especially when extracting data from the database, processing it, and > then putting it back into the database is expensive. Can be written in > C++, Perl, or presumably other languages, but doesn't make much sense to > write them in scripted languages; you might as well just do them in your > app. thats not actually true. Its useful for abstraction, plus you can run teh comparison at the DB level, eg as part of a VIEW column, or as a constraint on the query. If its not speed criticial, then perl would be a lot easier than c++. PL/SQL would be easier, mind you - are they planning PL/SQL support (or some varient)? If it is speed critical, a functional index would be nice. > Subqueries > > There are two kinds of subqueries: dependent/correlated, which rely on > tables/columns from parent query (and execute once for each row of the > parent query), and independent/noncorrelated, which don't and tend to be > more efficient. Joins are generally more performant than subqueries at > the moment in 4.1; subquery optimization is scheduled for 5.0. Hmm. That makes it sound like subqueries won't be usable until 5.0. This is similar to the problems postges has (but which are fixed in CVS), where it does a full nested loop join for subqueries. > > Types & Examples (in pseudo-code): > > * derived tables: SELECT * FROM foo, (SELECT ...) (cannot be dependent) Are they allowing SELECT a, (SELECT name FROM lookup_tab WHERE id=b) FROM table? ie with the subselect in the from clause? > InnoDB > > InnoDB is a table type with full ACID (transactional) compliance. It > was built for speed by a former mathematician who thought he could beat > commercial enterprise-class databases at the game. Unofficial > benchmarks show up to 2-4 times improvement over commercial > alternatives. > InnoDB apparently > has some transaction isolation options PostGreSQL doesn't have (don't > have details on this). I suspect that they're talking about READ UNCOMMITTED mode, which means that you can see uncommitted transactions which may end up rolled back later. Its not exactly something which is very useful from a data concurrency PoV. > > Perl DBI was built for speed and is pretty efficient, but you have to > know how to use it right. For speed: We do most of that now, at least in the new code. > For reliability: > > * use DBI->connect_cached I'm planning to use Apache::DBI instead, mainly because it'll detect dead connections on startup for you, and do ->rollback, plus you can set up the connections when the server is forked. Its aso theoretically possible to share connections if using a threaded mod_perl on apache2, but thats not supported ATM by the DBI stuff, and we don't support mod_perl, so its not really important ATM. There is talk of margine Apache::DBI support into the main DBI code, and abstracting the 'pool' interface. Our current connect stuff is abstracted enough that its really really easy to change, anyway. > * don't use DBD::mysql < 2.1026 with locks (because of its > auto-reconnect feature, which you can't disable without recompiling) Hmmm. Do we need to up our requirements, or is that only an issue if you use connect_cached/Apache::DBI ? > Optimizing MySQL > (Jeremy Zawodny) > > * MySQL is tuned for small-medium data sets and systems by default. > If you have lots of memory you need to configure it to use it. Is there tuning we can do? bmo has massive ammounts of RAM, right - its just CPU bound. > * Compress data if possible. gzip is quick, cheap, and makes things > faster, but you can't use it if you want to search the data. That doesn't apply to us, except for attachments, and I don't think that that woudl help anything we do. > * InnoDB can be slower with large data than MyISAM, but it's > generally about as fast. I have that test case from a while back - someone want to point the mysql folks to it? http://bugzilla.org/cgi-bin/mj_wwwusr?list=developers&brief=on&func=archive-get-part&extra=200302/118 I am very interested to see if this can be tuned, or if 4.0 improves that. > * Understand the leftmost prefix rule for indexes, and note that > MySQL will only ever use one index per table, so you need to > create compound column indexes if you want it to use two indexes > (f.e. how about product_id and bug_status in Bugzilla?) We do too many ad-hoc queries for that to work. (Or, more precisly, its the ad-hoc queries which are the ones with the problem) This is a very serious limitation of mysql. Its not important if you only have one join, but we have lots. The fact that mysql only appears to be doing nested loop joins (at least in 3.23.x) also shows up as a problem on some of the buglist.cgi stuff. What happened to the plan to give developers access to the bmo data? I'd love to run some real pg vs mysql comparision tests. > * Don't store computable data. *cough* votes/keywords cache *cough*. Which, btw, is where a function to get the sorted list of keywords from a bug_id (for display) would be very useful. We can't use a join because that won't sort it, so we could just SELECT bug_id, get_keyword_string(bug_id), .... where get_keyword_string just concatentates SELECT name FROM keywords WHERE bug_id=aBugId ORDER BY UPPER(name), or something along those lines. > * Use a UNION to break a query not using two indexes into two, each > using one. We really can't do that for buglist.cgi. Plus UNION is a new 4.0 thing, so we can't use it at all yet. Bradley From dberlin at dberlin.org Fri Apr 18 06:50:31 2003 From: dberlin at dberlin.org (Daniel Berlin) Date: Fri, 18 Apr 2003 02:50:31 -0400 Subject: MySQL user's Conference In-Reply-To: <20030418025959.GA2565@mango.home> Message-ID: <0BE52D7D-716A-11D7-BB9C-000393575BCC@dberlin.org> > > >> Optimizing MySQL >> (Jeremy Zawodny) >> >> * MySQL is tuned for small-medium data sets and systems by default. >> If you have lots of memory you need to configure it to use it. > > Is there tuning we can do? bmo has massive ammounts of RAM, right - its > just CPU bound. Well, if you are cpu bound, and are using 4.x, among other things, you should turn on the query cache (It's disabled by default). Particularly since invalidating the cache (IE inserts) are much rarer than searches (IE selects), i would imagine, and there is probably some common queries that people always run that the cache would help with. Add "set-variable = query_cache_size=32M" (or whatever size you like) to your my.cnf under [mysqld]. If you have multiple CPU's, you probably also want to add: set-variable = thread_cache=8 # Try number of CPU's*2 for thread_concurrency set-variable = thread_concurrency=8 I dunno if anyone ever tuned the mysql on b.m.o. If not, you probably want to look at the my-(huge, large).cnf files that exist somewhere (it's in /usr/share/mysql on my machine). They are generally the settings you should be using as a starting point to tune from (huge is for 1G-2G mainly mysql running machines, large is for 512M mainly mysql running machines) > >> * Compress data if possible. gzip is quick, cheap, and makes >> things >> faster, but you can't use it if you want to search the data. > > That doesn't apply to us, except for attachments, and I don't think > that > that woudl help anything we do. For GCC, our attachments are mainly huge preprocessed source files, so it helps quite a bit. We get about a 70% reduction in attachment size. If attachments are mainly text, compression might help. The changes to do it are trivial. > >> * InnoDB can be slower with large data than MyISAM, but it's >> generally about as fast. > > I have that test case from a while back - someone want to point the > mysql folks to it? > > http://bugzilla.org/cgi-bin/ > mj_wwwusr?list=developers&brief=on&func=archive-get-part&extra=200302/ > 118 > > I am very interested to see if this can be tuned, or if 4.0 improves > that. It might, there were some problems in the range optimizer of 3.x with InnoDB, i believe. At least, for me, on my bug db of 10500 bugs and 44463 comments, the query takes 12 seconds on InnoDB, and 4 seconds on MyISAM. Explain tells me the *InnoDB* one uses the assigned_to index, while the MyISAM one doesn't, which is the opposite of what i would expect. InnoDB: +-----------+-------+---------------+-------------+--------- +------------------+-------+------------------------------+ | table | type | possible_keys | key | key_len | ref | rows | Extra | +-----------+-------+---------------+-------------+--------- +------------------+-------+------------------------------+ | bugs | index | assigned_to | assigned_to | 3 | NULL | 10148 | Using index; Using temporary | | longdescs | ref | bug_id | bug_id | 3 | bugs.bugs.bug_id | 2 | Using where; Distinct | +-----------+-------+---------------+-------------+--------- +------------------+-------+------------------------------+ 2 rows in set (0.02 sec) MyISAM: +-----------+------+---------------+--------+--------- +------------------+-------+-----------------------+ | table | type | possible_keys | key | key_len | ref | rows | Extra | +-----------+------+---------------+--------+--------- +------------------+-------+-----------------------+ | bugs | ALL | assigned_to | NULL | NULL | NULL | 10417 | Using temporary | | longdescs | ref | bug_id | bug_id | 3 | bugs.bugs.bug_id | 4 | Using where; Distinct | +-----------+------+---------------+--------+--------- +------------------+-------+-----------------------+ 2 rows in set (0.00 sec) Maybe the MyISAM query decides it's not worth using the index. Maybe its right. I can tell you it's consistently *not* using an index in the MyISAM one. I'll also note that if I create a bug_id, who index, like so: create index bug_id_who on longdescs(bug_id, who); then both database types use the new index for the query, and the query takes 0.1 on either MyISAM or InnoDB. If this query is common, we should probably add this index. --Dan From bbaetz at acm.org Fri Apr 18 07:10:46 2003 From: bbaetz at acm.org (Bradley Baetz) Date: Fri, 18 Apr 2003 17:10:46 +1000 Subject: MySQL user's Conference In-Reply-To: <0BE52D7D-716A-11D7-BB9C-000393575BCC@dberlin.org> References: <20030418025959.GA2565@mango.home> <0BE52D7D-716A-11D7-BB9C-000393575BCC@dberlin.org> Message-ID: <20030418071046.GA3038@mango.home> On Fri, Apr 18, 2003 at 02:50:31AM -0400, Daniel Berlin wrote: > Well, if you are cpu bound, and are using 4.x, among other things, you > should turn on the query cache (It's disabled by default). bmo is 3.23.x. > I dunno if anyone ever tuned the mysql on b.m.o. If not, you probably > want to look at the my-(huge, large).cnf files that exist somewhere > (it's in /usr/share/mysql on my machine). > They are generally the settings you should be using as a starting point > to tune from (huge is for 1G-2G mainly mysql running machines, large is > for 512M mainly mysql running machines) I have this vague recollection that its a 4G machine, but I'm not too sure. > For GCC, our attachments are mainly huge preprocessed source files, so > it helps quite a bit. > We get about a 70% reduction in attachment size. Yeah, it would help with the size, but since its on a separate table which we really don't look at that often I don't think it would save anything apart from diskspace. > It might, there were some problems in the range optimizer of 3.x with > InnoDB, i believe. > It could be. I think the plans were teh same, though, but I can't really remember. > I'll also note that if I create a bug_id, who index, like so: > > create index bug_id_who on longdescs(bug_id, who); > > then both database types use the new index for the query, and the query > takes 0.1 on either MyISAM or InnoDB. Well, thats a mysql limitation again. :) > If this query is common, we should probably add this index. Its not; it was just an example in a bug somewhere which was easy to set up a simple test for. Thats the issue; buglist.cgi is basically completely ad-hoc, so its hard to tune correctly. Bradley From cbryanos at voicesignal.com Fri Apr 18 18:01:36 2003 From: cbryanos at voicesignal.com (Bryanos, Costa) Date: Fri, 18 Apr 2003 14:01:36 -0400 Subject: Setting up the UI in a particular way. Message-ID: Hi Joel, I just finished updating to 2.17.3. I want to thank you for responding and would very much appreciate that patch. I'll let you know if I find any problems with this patch on 2.17.3. Thanks again -Costa -----Original Message----- From: Joel Peshkin [mailto:bugreport at peshkin.net] Sent: Thursday, April 17, 2003 8:46 PM To: developers at bugzilla.org Subject: Re: Setting up the UI in a particular way. Bryanos, Costa wrote: > >Approach two >Click on "Enter a new bug report". Now click on a Product Area link. On this >page you can select a specific platform under the Platform pull down menu. I >would have to make each Platform pull down menu different within each >Product Area link. I don't know how I would do that. How can I specify a >different Platform list for each Product Area? > >Is there an easy way to do this that I don't know about? Also, I believe >that there is a limit of 55 products within Bugzilla. Is this true? If so >how can I get around this constraint? >I'm looking to get this done ASAP. > Costa, If you are using access groups for products, you will need to use 2.17.* which permits an arbitrary (well, 32000 anyway) groups. Your categorization issue will require a bit of hacking, but I do have a crude patch (against 2.17.1-ish code) that adds a field called "Menugroup" to the product. When a user creates a bug, if they would be able to enter bugs into products with more than one distinct menugroup, then they are prompted to first select which menugroup. There are no descriptions for the menugroups, but the names themselves can be descriptive. If you start down the 2.17 path and want this, I can dust it off and provide it to you. Since I would have to update it to the current tip, please get your other steps out of the way before asking me for this. -Joel ---- To view or change your list settings, click here: From myk at mozilla.org Fri Apr 18 18:41:49 2003 From: myk at mozilla.org (Myk Melez) Date: Fri, 18 Apr 2003 11:41:49 -0700 Subject: MySQL user's Conference In-Reply-To: <20030418025959.GA2565@mango.home> References: <3E9F6240.50009@mozilla.org> <20030418025959.GA2565@mango.home> Message-ID: <3EA046ED.30307@mozilla.org> Bradley Baetz wrote: >>User-Defined Functions >> >>User-defined functions are useful for things MySQL doesn't provide, >>especially when extracting data from the database, processing it, and >>then putting it back into the database is expensive. Can be written in >>C++, Perl, or presumably other languages, but doesn't make much sense to >>write them in scripted languages; you might as well just do them in your >>app. >> >> > >thats not actually true. Its useful for abstraction, plus you can run >teh comparison at the DB level, eg as part of a VIEW column, or as a >constraint on the query. If its not speed criticial, then perl would be >a lot easier than c++. PL/SQL would be easier, mind you - are they >planning PL/SQL support (or some varient)? If it is speed critical, a >functional index would be nice. > > Well, I didn't say it makes no sense. The speaker suggested that one good use for them would be to implement stored procedures. I didn't hear anything about PL/SQL at the conference, but stored procedure support is going to be multi-language, although they are starting with their own language for testing purposes. >>Subqueries >> >>There are two kinds of subqueries: dependent/correlated, which rely on >>tables/columns from parent query (and execute once for each row of the >>parent query), and independent/noncorrelated, which don't and tend to be >>more efficient. Joins are generally more performant than subqueries at >>the moment in 4.1; subquery optimization is scheduled for 5.0. >> >> > >Hmm. That makes it sound like subqueries won't be usable until 5.0. This >is similar to the problems postges has (but which are fixed in CVS), >where it does a full nested loop join for subqueries. > > I think it's more the case that certain kinds of subqueries won't be usable until 5.0, while other kinds will be just fine. >>Types & Examples (in pseudo-code): >> >> * derived tables: SELECT * FROM foo, (SELECT ...) (cannot be dependent) >> >> > >Are they allowing SELECT a, (SELECT name FROM lookup_tab WHERE id=b) >FROM table? ie with the subselect in the from clause? > > I think I saw an example of that in the presentation. >> * don't use DBD::mysql < 2.1026 with locks (because of its >> auto-reconnect feature, which you can't disable without recompiling) >> >> > >Hmmm. Do we need to up our requirements, or is that only an issue if you >use connect_cached/Apache::DBI ? > I think we have to up our requirements, but maybe we should email Tim about this. >>Optimizing MySQL >>(Jeremy Zawodny) >> >> * MySQL is tuned for small-medium data sets and systems by default. >> If you have lots of memory you need to configure it to use it. >> >> > >Is there tuning we can do? bmo has massive ammounts of RAM, right - its >just CPU bound. > Right, I think. It's hard to tell because Solaris grabs all free memory to use as disk cache, so it's hard to know how much memory we have free or what would happen if we took it away from disk cache and gave it to MySQL. >> * Compress data if possible. gzip is quick, cheap, and makes things >> faster, but you can't use it if you want to search the data. >> >> > >That doesn't apply to us, except for attachments, and I don't think that >that woudl help anything we do. > Actually, I think it would. Currently we search the attachments table in attachment flag queries, which happen all the time. Compressing the data would make that table much smaller and easier to scan (although perhaps indexes work around this problem). This could also be solved by putting the attachment data in a separate table, of course. The other way it would help is that I wouldn't always be having to deal with the Solaris 2GB+ bug that prevents me from operating on a DB tar file with common system utilities (like gzip and scp). >> * Understand the leftmost prefix rule for indexes, and note that >> MySQL will only ever use one index per table, so you need to >> create compound column indexes if you want it to use two indexes >> (f.e. how about product_id and bug_status in Bugzilla?) >> >> > >We do too many ad-hoc queries for that to work. > I think we probably have some common patterns that could be exploited, f.e. many queries select a product and one or more statuses. >What happened to the plan to give developers access to the bmo data? I'd >love to run some real pg vs mysql comparision tests. > > It got stalled on privacy issues. Everyone who gets to see the data has to agree to keep it private, which involves work if that group is everyone with access to landfill. Our other option is to make a legal determination that the rules do not apply in our case, which also involves work. >> * Use a UNION to break a query not using two indexes into two, each >> using one. >> >> > >We really can't do that for buglist.cgi. Plus UNION is a new 4.0 thing, >so we can't use it at all yet. > > No. My thinking is that Bugzilla 2.18 should support 3.23, and then we should move to 4.0 for 2.19+. -myk -------------- next part -------------- An HTML attachment was scrubbed... URL: From myk at mozilla.org Fri Apr 18 18:47:34 2003 From: myk at mozilla.org (Myk Melez) Date: Fri, 18 Apr 2003 11:47:34 -0700 Subject: MySQL user's Conference In-Reply-To: <20030418071046.GA3038@mango.home> References: <20030418025959.GA2565@mango.home> <0BE52D7D-716A-11D7-BB9C-000393575BCC@dberlin.org> <20030418071046.GA3038@mango.home> Message-ID: <3EA04846.2080507@mozilla.org> Bradley Baetz wrote: >I have this vague recollection that its [bmo] a 4G machine, but I'm not >too sure. > > That's right. I did some tuning at one point based on the "huge" example, but it didn't seem to do much good. >>For GCC, our attachments are mainly huge preprocessed source files, so >>it helps quite a bit. >>We get about a 70% reduction in attachment size. >> >> > >Yeah, it would help with the size, but since its on a separate table >which we really don't look at that often I don't think it would save >anything apart from diskspace. > > Except that we do look at it a lot for request queue queries. -myk -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerv at gerv.net Fri Apr 18 17:10:51 2003 From: gerv at gerv.net (Gervase Markham) Date: Fri, 18 Apr 2003 18:10:51 +0100 Subject: getting MySQL AB using Bugzilla In-Reply-To: <20030417144339.A20455@sigkill.com> References: <3E9DF849.9000807@mozilla.org> <20030416180136.A15146@sigkill.com> <3E9E58C0.2040905@mozilla.org> <20030417070401.A17792@sigkill.com> <3E9F1AF0.3060802@mozilla.org> <20030417144339.A20455@sigkill.com> Message-ID: <3EA0319B.1080603@gerv.net> J. Paul Reed wrote: >>When do you think you can manage? :-) > > Two months. 18th of June, then. > I talked to justdave on IRC this morning and he said that such an estimate > is mostly compatible with how long 2.18 is *likely* to take in real time to > get out ("probably 3 to 4 months yet though", with the admission that it > could be sooner). Perhaps we should have that discussion. I expected us to release 2.17.4, whenever that happens, fix the obvious bugs in that, and call it 2.18. We've done enough already that it's worth another stable release. > So, such an estimate should be fine, I think. The fact that it's "by far > the #1 support request" is irrelevant; most people aren't going to upgrade > until there's a new stable release anyway, Actually, it seems that quite a few people in the newsgroup are using 2.17.3 - another sign that we should do a stable release soon. Gerv From bbaetz at acm.org Fri Apr 18 23:44:42 2003 From: bbaetz at acm.org (Bradley Baetz) Date: Sat, 19 Apr 2003 09:44:42 +1000 Subject: MySQL user's Conference In-Reply-To: <3EA046ED.30307@mozilla.org> References: <3E9F6240.50009@mozilla.org> <20030418025959.GA2565@mango.home> <3EA046ED.30307@mozilla.org> Message-ID: <20030418234442.GA1502@mango.home> On Fri, Apr 18, 2003 at 11:41:49AM -0700, Myk Melez wrote: > I think it's more the case that certain kinds of subqueries won't be > usable until 5.0, while other kinds will be just fine. They kind I'm interested in is changing all the inner/outer joins in buglist.cgi into subselects. This makes lots of our outer joins (which we have to do for the OR case) become inner joins most of the time. > Right, I think. It's hard to tell because Solaris grabs all free memory > to use as disk cache, so it's hard to know how much memory we have free > or what would happen if we took it away from disk cache and gave it to > MySQL. I don't think it would matter that much. With 4G of RAM, given that most of bmo's data is attachments, and we don't really need those cached, if mysql caches data instead of the os, it would theoretically be better. > Actually, I think it would. Currently we search the attachments table > in attachment flag queries, which happen all the time. Compressing the > data would make that table much smaller and easier to scan (although > perhaps indexes work around this problem). This could also be solved by > putting the attachment data in a separate table, of course. The other > way it would help is that I wouldn't always be having to deal with the > Solaris 2GB+ bug that prevents me from operating on a DB tar file with > common system utilities (like gzip and scp). Eww. You mean that BLOB'd data is stored inline with the rest of the data? Is that true even for innodb? (For comparison, oracle will store <4K worth inline, but if its larger than that its all placed out of line. PG just stores all LOB datatypes separately. I don't _think_ it inlines small ones, but I'm not sure) > >We do too many ad-hoc queries for that to work. > > > I think we probably have some common patterns that could be exploited, > f.e. many queries select a product and one or more statuses. Sure, but once status move off into a different table, it wouldn't work, because you'd have to join on two differnet tables with the same index. Also, that won't work if the user selects more than one status, because mysql doesn't optimise OR evne if it could use the same index. (which is why we convert to IN in buglist.cgi, but I don't think that works if there are multiple columns involved.) > It got stalled on privacy issues. Everyone who gets to see the data has > to agree to keep it private, which involves work if that group is > everyone with access to landfill. Our other option is to make a legal > determination that the rules do not apply in our case, which also > involves work. Can't you just munge the data, though? There was that script I hacked up for doing exactly that... > No. My thinking is that Bugzilla 2.18 should support 3.23, and then we > should move to 4.0 for 2.19+. Hmm. IF we get to use innodb then, and use transactions, I'm definately for it. > > -myk > Bradley From bbaetz at acm.org Fri Apr 18 23:48:25 2003 From: bbaetz at acm.org (Bradley Baetz) Date: Sat, 19 Apr 2003 09:48:25 +1000 Subject: MySQL user's Conference In-Reply-To: <3EA04846.2080507@mozilla.org> References: <20030418025959.GA2565@mango.home> <0BE52D7D-716A-11D7-BB9C-000393575BCC@dberlin.org> <20030418071046.GA3038@mango.home> <3EA04846.2080507@mozilla.org> Message-ID: <20030418234825.GB1502@mango.home> On Fri, Apr 18, 2003 at 11:47:34AM -0700, Myk Melez wrote: > Bradley Baetz wrote: > > >I have this vague recollection that its [bmo] a 4G machine, but I'm not > >too sure. > > > > > That's right. I did some tuning at one point based on the "huge" > example, but it didn't seem to do much good. Yeah, I suspect we're just too CPU bound. It is apache taking most of the time, right? FWIW, I have mod_perl working locally now for show_bug, with a combination of patches. After my User.pm patches go in, I'll tidy my patchset up (and remove some of the more disgusting hacks), and then we can try it on bmo.... mod_perl/1.0 now, mind you, but still. > Except that we do look at it a lot for request queue queries. Those are slow because it uses the 'old' way of detecting bug visibility. Theres a bug on speeding that up, FWIW. Theres another bug on just making the queue a buglist.cgi format, too, but that requires a bit of backedn work to get teh roght data out, and would be a lot easier with subselects (ie "SELECT from attachments, requests WHERE attachments.bug_id IN (" . $search->getSQL() . ") AND ...") > -myk Bradley From jake at bugzilla.org Sun Apr 20 00:59:23 2003 From: jake at bugzilla.org (Jake) Date: Sat, 19 Apr 2003 20:59:23 -0400 Subject: MySQL user's Conference In-Reply-To: <3E9F6240.50009@mozilla.org> References: <3E9F6240.50009@mozilla.org> Message-ID: <3EA1F0EB.4040204@bugzilla.org> Myk Melez wrote: > Optimizing MySQL > (Jeremy Zawodny) Is this stuff on a website somewhere (like at mysql.com)? It may be useful to have a small section on optomizations in the guide :) From jake at bugzilla.org Sun Apr 20 01:04:53 2003 From: jake at bugzilla.org (Jake) Date: Sat, 19 Apr 2003 21:04:53 -0400 Subject: MySQL user's Conference In-Reply-To: <20030418025959.GA2565@mango.home> References: <3E9F6240.50009@mozilla.org> <20030418025959.GA2565@mango.home> Message-ID: <3EA1F235.9050402@bugzilla.org> Bradley Baetz wrote: >I'm planning to use Apache::DBI instead, mainly because it'll detect >dead connections on startup for you, and do ->rollback, plus you can set >up the connections when the server is forked. Its aso theoretically >possible to share connections if using a threaded mod_perl on apache2, >but thats not supported ATM by the DBI stuff, and we don't support >mod_perl, so its not really important ATM. There is talk of margine >Apache::DBI support into the main DBI code, and abstracting the 'pool' >interface. > > The name of that module seems to imply a reliance on Apache which we've been avoiding to date. Is that a misleading name or would having |use Apache::DBI| in the code cause those who don't use Apache some heartache? >Our current connect stuff is abstracted enough that its really really >easy to change, anyway. > >> * Compress data if possible. gzip is quick, cheap, and makes things >> faster, but you can't use it if you want to search the data. >> >> > >That doesn't apply to us, except for attachments, and I don't think that >that woudl help anything we do. > > IIRC bmo has had some problems with disk space in the past, has that been solved now? With the amount of HTML and patch attachments I would think that compression would reduce the size of that table signifigantly. From bbaetz at acm.org Sun Apr 20 02:33:35 2003 From: bbaetz at acm.org (Bradley Baetz) Date: Sun, 20 Apr 2003 12:33:35 +1000 Subject: MySQL user's Conference In-Reply-To: <3EA1F235.9050402@bugzilla.org> References: <3E9F6240.50009@mozilla.org> <20030418025959.GA2565@mango.home> <3EA1F235.9050402@bugzilla.org> Message-ID: <20030420023334.GA1289@mango.home> On Sat, Apr 19, 2003 at 09:04:53PM -0400, Jake wrote: > The name of that module seems to imply a reliance on Apache which we've > been avoiding to date. Is that a misleading name or would having |use > Apache::DBI| in the code cause those who don't use Apache some heartache? Apache::DBI isn't actually used from our code, but rather from the httpd perl conf stuff. Peristent connections require perssistent server processes, which implies mod_perl on Apache, or PerlEx on iis. I've never used PerlEx (and don't have window machines to test on), so after mod_perl goes in, anyone who wants PerlEx support wil have to hack it in themselves. The persistent server APIs are all different... Bradley From arvind at pixim.com Mon Apr 21 07:45:26 2003 From: arvind at pixim.com (Arvind Singh) Date: Mon, 21 Apr 2003 00:45:26 -0700 Subject: Making fields hidden in edit.html.tmpl Message-ID: <16020FEDDBAF5440A59EB485AC75B2BB0612D6@exchange.pixim.com> I've a basic question regarding how to make some of the fields in edit.html.tmpl hidden & readonly. In the html syntax we use for making it hidden and for readonly But I am not able to make the priority field in the edit.html.tmpl hidden or readonly. Priority: [% PROCESS select selname => "priority" %] Thanks a lot for all the help. With Regards, Arvind. From etzwane at schwag.org Mon Apr 21 08:07:58 2003 From: etzwane at schwag.org (Sean McAfee) Date: Mon, 21 Apr 2003 04:07:58 -0400 Subject: More custom field revisions Message-ID: <20030421080758.5CA5EBC51@diggity.schwag.org> Hi, folks-- Well, there've been no responses to my custom field comments of a week ago, which I will optimistically interpret as a general endorsement. Here are some additional revisions. The major addition to the requirements document is a description of a custom fields administrative interface, an example of which can be seen in the attached file cfadmin.html. The custom fields schema, contained in the design document, has been updated to account for per-project field ordering. Let me know what you think. Thanks. -- Sean McAfee -- etzwane at schwag.org -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: bz-cf-requirements.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: bz-cf-design.txt URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerv at mozilla.org Mon Apr 21 08:56:51 2003 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 21 Apr 2003 09:56:51 +0100 Subject: More custom field revisions In-Reply-To: <20030421080758.5CA5EBC51@diggity.schwag.org> References: <20030421080758.5CA5EBC51@diggity.schwag.org> Message-ID: <3EA3B253.6080908@mozilla.org> Sean McAfee wrote: > Hi, folks-- > > Well, there've been no responses to my custom field comments of a week ago, > which I will optimistically interpret as a general endorsement. Well, it's a big proposal, and it takes time to read (note how long it took me to read the last one) and it's Easter weekend - which means something to Dave and I, if not to anyone else :-) So sending round a revised version is no problem, but please be aware that I, for one, haven't read version 2 yet :-) Gerv From preed at sigkill.com Mon Apr 21 11:51:59 2003 From: preed at sigkill.com (J. Paul Reed) Date: Mon, 21 Apr 2003 04:51:59 -0700 Subject: Status Update Snippets Message-ID: <20030421045159.D12833@sigkill.com> Hey all: If you haven't heard, we're currently in the 2.16.3/2.17.4 release push. I'm writing the status update for the release, so if you have any "New Feature" snippets (a la http://www.bugzilla.org/status_updates/2003-01-02.html#newfeatures) you want to go into the status update, you need to get them to me by midnight PDT on Tuesday, April 22nd (that's roughly 19 hours in the PDT from now). This email address is fine. Later, Paul ------------------------------------------------------------------------ J. Paul Reed -- 0xDF8708F8 || preed at sigkill.com || web.sigkill.com/preed To hold on to sanity too tight is insane. -- Nick Falzone, Pushing Tin I use PGP; you should use PGP too... if only to piss off John Ashcroft From bugreport at peshkin.net Mon Apr 21 13:26:01 2003 From: bugreport at peshkin.net (Joel Peshkin) Date: Mon, 21 Apr 2003 06:26:01 -0700 Subject: More custom field revisions In-Reply-To: <20030421080758.5CA5EBC51@diggity.schwag.org> References: <20030421080758.5CA5EBC51@diggity.schwag.org> Message-ID: <3EA3F169.60003@peshkin.net> One item that is missing for me is the ability to designate group controls on who gets to see a custom field and who gets to edit it. Is this something that is of general interest or a strange local hack for me? -Joel From cheiny at synaptics.com Mon Apr 21 14:49:32 2003 From: cheiny at synaptics.com (Christopher Heiny) Date: Mon, 21 Apr 2003 6:49:32 PST Subject: More custom field revisions Message-ID: <200304211439.h3LEd0n19089@synaptics.com> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From myk at mozilla.org Mon Apr 21 14:45:37 2003 From: myk at mozilla.org (Myk Melez) Date: Mon, 21 Apr 2003 07:45:37 -0700 Subject: MySQL user's Conference In-Reply-To: <3EA1F0EB.4040204@bugzilla.org> References: <3E9F6240.50009@mozilla.org> <3EA1F0EB.4040204@bugzilla.org> Message-ID: <3EA40411.9060103@mozilla.org> Jake wrote: > Myk Melez wrote: > >> Optimizing MySQL >> (Jeremy Zawodny) > > > Is this stuff on a website somewhere (like at mysql.com)? It may be > useful to have a small section on optomizations in the guide :) The author has an older version of the presentation available online: http://jeremy.zawodny.com/mysql/mysql-optimization.html And other stuff: http://jeremy.zawodny.com/mysql/ http://jeremy.zawodny.com/ -myk From JWilmoth at starbucks.com Mon Apr 21 20:53:29 2003 From: JWilmoth at starbucks.com (Jon Wilmoth) Date: Mon, 21 Apr 2003 13:53:29 -0700 Subject: More custom field revisions Message-ID: I've attached example of the admin screen in an attempt to "simplify" what was already there and also adds a couple of things present in the spec that weren't present on the ui. On the db structure: 1)Shouldn't custom_fields.project be an integer foreign key? 2)Wouldn't the custom_fields.field_id be the PK? 3)Shouldn't custom_field_defs have a "required" Boolean column? 4)Perhaps renaming custom_fields.field_index to custom_fields.display_order to be more intention revealing. 5)Perhaps rename custom_field_defs.field_name to custom_field_defs.ui_label to be more intention revealing. Perhaps a validation table as well? If so, the "edit" section of the admin screen I've attached would have to be dynamic according to the field type. custom_field_constraints ------------------------ constraint_id primary key, field_id integer not null, min integer, min_error_code tinytext, max integer, max_error_code tinytext, mask tinytext, mask_error_code tinytext, ...? ...? This table would define the additional constraints to enforce on a field value (probably more applicable for open text box type fields) before saving to the db. The "_error_code" field would refer to a template variable defined in "global/error_codes.html.tmpl". Mask could be a regular expression outlining for example a date format. -----Original Message----- From: Sean McAfee [mailto:etzwane at schwag.org] Sent: Monday, April 21, 2003 1:08 AM To: developers at bugzilla.org Subject: More custom field revisions Hi, folks-- Well, there've been no responses to my custom field comments of a week ago, which I will optimistically interpret as a general endorsement. Here are some additional revisions. The major addition to the requirements document is a description of a custom fields administrative interface, an example of which can be seen in the attached file cfadmin.html. The custom fields schema, contained in the design document, has been updated to account for per-project field ordering. Let me know what you think. Thanks. -- Sean McAfee -- etzwane at schwag.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From etzwane at schwag.org Mon Apr 21 22:39:09 2003 From: etzwane at schwag.org (Sean McAfee) Date: Mon, 21 Apr 2003 18:39:09 -0400 Subject: More custom field revisions In-Reply-To: <200304211439.h3LEd0n19089@synaptics.com> Message-ID: <20030421223909.577E4BC51@diggity.schwag.org> Christopher Heiny wrote: >Sean - I'm not sure if it's you or Mozilla (1.3) or Emu Webmail, but that >message rendered as red (or maybe pink) text on a brilliant yellow >background when I viewed it. Could you tone the formatting down a bit? I didn't intentionally introduce any such formatting. There were three text/plain attachments and one text/html attachment in the message, and the last (modified from a page served by Bugzilla's query.cgi) doesn't appear to refer to the color red, either by name or by hex RGB code. I think it must be your client. Did anyone else experience anything like this? -- Sean McAfee -- etzwane at schwag.org From JWilmoth at starbucks.com Mon Apr 21 22:42:33 2003 From: JWilmoth at starbucks.com (Jon Wilmoth) Date: Mon, 21 Apr 2003 15:42:33 -0700 Subject: More custom field revisions Message-ID: I did NOT. -----Original Message----- From: Sean McAfee [mailto:etzwane at schwag.org] Sent: Monday, April 21, 2003 3:39 PM To: developers at bugzilla.org Subject: Re: More custom field revisions Christopher Heiny wrote: >Sean - I'm not sure if it's you or Mozilla (1.3) or Emu Webmail, but that >message rendered as red (or maybe pink) text on a brilliant yellow >background when I viewed it. Could you tone the formatting down a bit? I didn't intentionally introduce any such formatting. There were three text/plain attachments and one text/html attachment in the message, and the last (modified from a page served by Bugzilla's query.cgi) doesn't appear to refer to the color red, either by name or by hex RGB code. I think it must be your client. Did anyone else experience anything like this? -- Sean McAfee -- etzwane at schwag.org ---- To view or change your list settings, click here: From etzwane at schwag.org Mon Apr 21 23:59:51 2003 From: etzwane at schwag.org (Sean McAfee) Date: Mon, 21 Apr 2003 19:59:51 -0400 Subject: More custom field revisions In-Reply-To: Message-ID: <20030421235951.6E04BBC51@diggity.schwag.org> "Jon Wilmoth" wrote: >I've attached example of the admin screen in an attempt to "simplify" >what was already there and also adds a couple of things present in the >spec that weren't present on the ui. The new page looks cleaner in some ways, and I originally envisioned the page looking something like that. However, this format presents several opportunities for the administrator to enter incorrect or irrelevant data. * Suppose the admin sets the Display Order for all of the fields to "1", checks them all, and presses "Reorder Selected". What should happen? * How should Bugzilla treat fields whose Display Order has been changed, but which are not checked? * In order to move the first field to the end of the list, the admin would need to reset the Display Order of every field in the project. This would be awkward for only a few fields, and downright onerous (not to mention error-prone) if there were dozens. * Actually, any kind of nontrivial field rearrangement is going to present similar difficulties. My proposed page layout eliminates the ambiguities and additional error handling introduced by the first two items, and avoids the burden imposed on the administrator by the last two. >On the db structure: > >1)Shouldn't custom_fields.project be an integer foreign key? Yes. I didn't think to check whether projects had integer indices defined in some other table. Oops...This reopens the question of how to designate the global scope. A project of NULL is the obvious choice, but project's primary-key-ness disallows that approach. Maybe project should be a key, but not a primary key. Incidentally, I left foreign key constraints out of the schema, since it was my understanding that MySQL doesn't enforce them. Is this true? Is there any value in including them anyway? >2)Wouldn't the custom_fields.field_id be the PK? Possibly, but I expected that the custom_fields table would most often be used to get a complete field list: SELECT field_id FROM custom_fields WHERE project = ? Probably this would be better: custom_fields ------------- field_id integer primary key, project smallint, display_index integer not null, index (project) But wait, if field_id is now going to be the primary key of custom_fields AND custom_field_defs, then there doesn't seem to be any more reason to have two separate tables. So then: custom_fields ------------- field_id integer primary key, project smallint, display_index integer not null, field_name tinytext not null, field_type char not null, required bool not null, extended bool not null, selection_id integer, index (project) >3)Shouldn't custom_field_defs have a "required" Boolean column? It can. There wasn't much discussion of it, but I'll add it provisionally (see above). >4)Perhaps renaming custom_fields.field_index to >custom_fields.display_order to be more intention revealing. I don't usually think of a single number as being an "order", but how about "display_index" instead? (Again, see above.) >5)Perhaps rename custom_field_defs.field_name to >custom_field_defs.ui_label to be more intention revealing. Your modified cfadmin.html page appears to draw a distinction between a field's "name" and its "display label". Why are two identifiers necessary? I envisioned that a single string would serve as both. Similarly, why draw a distinction between a selection field's "true" value (eg, "foo", "bar") and its UI value ("Foo Choice", "Bar Choice")? >Perhaps a validation table as well? If so, the "edit" section of the >admin screen I've attached would have to be dynamic according to the >field type. I'd rather leave this as a separate enhancement to be addressed after the basic custom field functionality is in place. Does anyone else feel differently? -- Sean McAfee -- etzwane at schwag.org From chicks at chicks.net Tue Apr 22 12:49:08 2003 From: chicks at chicks.net (Christopher Hicks) Date: Tue, 22 Apr 2003 08:49:08 -0400 (EDT) Subject: [Perl Jobs] Lead Perl Developer (contract) (onsite), United States, CA, Mountain View (fwd) Message-ID: Anybody need work in California? Maybe this will be helpful. (It's too bad I'm on the wrong coast. 4 months to do this sounds like major overkill. Sigh.) -- The death of democracy is not likely to be an assassination from ambush. It will be a slow extinction from apathy, indifference, and undernourishment. -Robert Maynard Hutchins, educator (1899-1977) ---------- Forwarded message ---------- Date: 22 Apr 2003 00:26:42 -0000 From: Perl Jobs To: jobs at perl.org Subject: [Perl Jobs] Lead Perl Developer (contract) (onsite), United States, CA, Mountain View Online URL for this job: http://jobs.perl.org/job/752 To subscribe to this list, send mail to jobs-subscribe at perl.org. To unsubscribe, send mail to jobs-unsubscribe at perl.org. Posted: April 21, 2003 Job title: Lead Perl Developer (contract) Company name: Techlink Systems Location: United States, CA, Mountain View Pay rate: 30 - 50/hr Travel: 0% Terms of employment: Independent contractor (hourly) Length of employment: 4 months Hours: Full time Onsite: yes Description: Work on location at the Netscape campus in Mountain View to deliver a customized bug tracking system. From my understanding, the project is to make integrate Bugzilla into Sybase and Cognos Report Server. Previous experience upgrading/customizing bugzilla or development of a bug tracking system in Perl is a strong plus. Required skills: Perl (CGI Script, DBI, DBD) MySQL Apache/SSL Desired skills: Report Generation (cognos or homegrown) DHTML, XBHTML, JavaScript Release Engineering UI Contact information: George Rider grider at techlinksystems.com (415) 732-7580 x 124 office From willy at lukoil.uu.ru Tue Apr 22 18:31:04 2003 From: willy at lukoil.uu.ru (Vitaly Fedrushkov) Date: Wed, 23 Apr 2003 00:31:04 +0600 (YEKST) Subject: More custom field revisions In-Reply-To: <20030421235951.6E04BBC51@diggity.schwag.org> Message-ID: Good $daytime, > Date: Mon, 21 Apr 2003 19:59:51 -0400 > From: Sean McAfee > To: developers at bugzilla.org > Subject: Re: More custom field revisions > >5)Perhaps rename custom_field_defs.field_name to > >custom_field_defs.ui_label to be more intention revealing. > Your modified cfadmin.html page appears to draw a distinction > between a field's "name" and its "display label". Why are two > identifiers necessary? I envisioned that a single string would > serve as both. > Similarly, why draw a distinction between a selection field's "true" > value (eg, "foo", "bar") and its UI value ("Foo Choice", "Bar > Choice")? Localizer's note: If we really plan to _store_ UI presentation of a field instead of decoding it from "true" value within customized template, then perhaps we need "locale" field added to PK, with values according to ISO 3166. Looking back from the future: Let custom fields be already implemented and now we're to consider move of existing fields to a new framework. Actually we see a number of fields that are either project specific (e.g. 'URL') and/or easily movable ('Keywords', 'Priority', 'Platform' -- all fields not used except for entry and search). [Other fields like 'Status' and 'CC' are used somewhere in the code and Bugzilla logic more or less depends on their values.] What do we see? There's no obvious use for "UI presentation" field, as its values already belong to templates. "True" values for selection type fields like 'Platform' and 'Priority' are already stored elsewhere and all UI needs are addressed within templates again. What do we do? If our intent is to reduce complexity, we move fields' names and values to custom fields metadata and happily simplify many edit, search and report templates. To make result localizable, we need to store multiple instances of field name and selection values, one per locale. Or we leave things as they are, storing only "true" values, and leaving the rest to templates? Regards, Willy. -- No easy hope or lies | Vitaly "Willy the Pooh" Fedrushkov Shall bring us to our goal, | Control Systems and Processes Division But iron sacrifice | LUKOIL Company, Chelyabinsk Branch Of Body, Will and Soul. | willy at lukoil.uu.ru +7 3512 620367 R.Kipling | VVF1-RIPE From justdave at syndicomm.com Tue Apr 22 19:47:17 2003 From: justdave at syndicomm.com (David Miller) Date: Tue, 22 Apr 2003 15:47:17 -0400 Subject: [Perl Jobs] Lead Perl Developer (contract) (onsite), United In-Reply-To: References: Message-ID: On 4/22/2003 8:49 AM -0400, Christopher Hicks wrote: > Anybody need work in California? Maybe this will be helpful. > > (It's too bad I'm on the wrong coast. 4 months to do this sounds like > major overkill. Sigh.) You haven't met their QA department. :) They will find things for you to fix, no matter how perfect you thought the code was. :) The Sybase conversion is already completed, fwiw. There are several new features they want that have not been implemented yet. > Onsite: yes FWIW, I already have this job (they just approved an additional position, and we also need to replace another contractor who is leaving), so you'd be working with me :) -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From jake at bugzilla.org Tue Apr 22 20:40:09 2003 From: jake at bugzilla.org (Jake) Date: Tue, 22 Apr 2003 16:40:09 -0400 Subject: More custom field revisions In-Reply-To: <20030421223909.577E4BC51@diggity.schwag.org> References: <20030421223909.577E4BC51@diggity.schwag.org> Message-ID: <3EA5A8A9.40806@bugzilla.org> Sean McAfee wrote: >Christopher Heiny wrote: > > >>Sean - I'm not sure if it's you or Mozilla (1.3) or Emu Webmail, but that >>message rendered as red (or maybe pink) text on a brilliant yellow >>background when I viewed it. Could you tone the formatting down a bit? >> >> > >I didn't intentionally introduce any such formatting. There were three >text/plain attachments and one text/html attachment in the message, and >the last (modified from a page served by Bugzilla's query.cgi) doesn't >appear to refer to the color red, either by name or by hex RGB code. >I think it must be your client. > >Did anyone else experience anything like this? > > > > No, in my mail reader (Mozilla 1.something nightly) everything was black text on a white background. From JWilmoth at starbucks.com Tue Apr 22 21:14:13 2003 From: JWilmoth at starbucks.com (Jon Wilmoth) Date: Tue, 22 Apr 2003 14:14:13 -0700 Subject: Attachments Error in 2.17.3? Message-ID: I'm getting the same error attaching files with all three installations of 2.17.3 I have. Instead of the %mailresults% one would expect in the attachment\created.html.tmpl I'm getting the following line: Status: 400 Bad request (malformed multipart POST) Below are the two lines in apache's error_log file produced for a single attachment creation. [Tue Apr 22 14:01:06 2003] [error] [client 10.3.5.154] Undefined subroutine &main::ThrowCodeError called at Bugzilla/CGI.pm line 78., referer: http://seasl024/bugzilla/attachment.cgi?bugid=361&action=enter [Tue Apr 22 14:01:06 2003] [error] [client 10.3.5.154] Compilation failed in require at ./processmail line 31., referer: http://seasl024/bugzilla/attachment.cgi?bugid=361&action=enter I tried this on http://landfill.bugzilla.org/bugzilla-tip/attachment.cgi but wasn't able to reproduce the error. Thoughts? From justdave at syndicomm.com Tue Apr 22 21:33:15 2003 From: justdave at syndicomm.com (David Miller) Date: Tue, 22 Apr 2003 17:33:15 -0400 Subject: Attachments Error in 2.17.3? In-Reply-To: References: Message-ID: On 4/22/2003 2:14 PM -0700, Jon Wilmoth wrote: > I'm getting the same error attaching files with all three installations > of 2.17.3 I have. Instead of the %mailresults% one would expect in the > attachment\created.html.tmpl I'm getting the following line: > > Status: 400 Bad request (malformed multipart POST) > > Below are the two lines in apache's error_log file produced for a single > attachment creation. > > [Tue Apr 22 14:01:06 2003] [error] [client 10.3.5.154] Undefined > subroutine &main::ThrowCodeError called at Bugzilla/CGI.pm line 78., > referer: http://seasl024/bugzilla/attachment.cgi?bugid=361&action=enter > > [Tue Apr 22 14:01:06 2003] [error] [client 10.3.5.154] Compilation > failed in require at ./processmail line 31., referer: > http://seasl024/bugzilla/attachment.cgi?bugid=361&action=enter > > I tried this on http://landfill.bugzilla.org/bugzilla-tip/attachment.cgi > but wasn't able to reproduce the error. > > Thoughts? It's been fixed in CVS. bugzilla-tip on landfill is running cvs tip. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From JWilmoth at starbucks.com Tue Apr 22 21:39:41 2003 From: JWilmoth at starbucks.com (Jon Wilmoth) Date: Tue, 22 Apr 2003 14:39:41 -0700 Subject: Attachments Error in 2.17.3? Message-ID: Is there a bug number I could get a patch from? If not can you let me know the corrected file(s) and I'll log it, create and attach a patch. -----Original Message----- From: David Miller [mailto:justdave at syndicomm.com] Sent: Tuesday, April 22, 2003 2:33 PM To: developers at bugzilla.org Subject: Re: Attachments Error in 2.17.3? On 4/22/2003 2:14 PM -0700, Jon Wilmoth wrote: > I'm getting the same error attaching files with all three installations > of 2.17.3 I have. Instead of the %mailresults% one would expect in the > attachment\created.html.tmpl I'm getting the following line: > > Status: 400 Bad request (malformed multipart POST) > > Below are the two lines in apache's error_log file produced for a single > attachment creation. > > [Tue Apr 22 14:01:06 2003] [error] [client 10.3.5.154] Undefined > subroutine &main::ThrowCodeError called at Bugzilla/CGI.pm line 78., > referer: http://seasl024/bugzilla/attachment.cgi?bugid=361&action=enter > > [Tue Apr 22 14:01:06 2003] [error] [client 10.3.5.154] Compilation > failed in require at ./processmail line 31., referer: > http://seasl024/bugzilla/attachment.cgi?bugid=361&action=enter > > I tried this on http://landfill.bugzilla.org/bugzilla-tip/attachment.cgi > but wasn't able to reproduce the error. > > Thoughts? It's been fixed in CVS. bugzilla-tip on landfill is running cvs tip. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ ---- To view or change your list settings, click here: From preed at sigkill.com Tue Apr 22 21:48:31 2003 From: preed at sigkill.com (J. Paul Reed) Date: Tue, 22 Apr 2003 14:48:31 -0700 Subject: Attachments Error in 2.17.3? In-Reply-To: ; from JWilmoth@starbucks.com on Tue, Apr 22, 2003 at 02:39:41PM -0700 References: Message-ID: <20030422144831.A22578@sigkill.com> On 22 Apr 2003 at 14:39:41, Jon Wilmoth moved bits on my disk to say: > Is there a bug number I could get a patch from? If not can you let me > know the corrected file(s) and I'll log it, create and attach a patch. If you give us 24 hours or so, you can install 2.17.4, which should have the fix. :-) Later, Paul ------------------------------------------------------------------------ J. Paul Reed -- 0xDF8708F8 || preed at sigkill.com || web.sigkill.com/preed To hold on to sanity too tight is insane. -- Nick Falzone, Pushing Tin I use PGP; you should use PGP too... if only to piss off John Ashcroft From justdave at syndicomm.com Tue Apr 22 21:55:23 2003 From: justdave at syndicomm.com (David Miller) Date: Tue, 22 Apr 2003 17:55:23 -0400 Subject: Attachments Error in 2.17.3? In-Reply-To: References: Message-ID: On 4/22/2003 2:39 PM -0700, Jon Wilmoth wrote: > Is there a bug number I could get a patch from? If not can you let me > know the corrected file(s) and I'll log it, create and attach a patch. I kinda doubt if you want to apply the patch manually. It was huge and depends on a lot of surrounding code. We basically removed processmail and created a perl module which handles sending the mail now. See http://bugzilla.mozilla.org/show_bug.cgi?id=187861 However, 2.17.4 will be out tomorrow. :) -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From JWilmoth at starbucks.com Tue Apr 22 22:29:05 2003 From: JWilmoth at starbucks.com (Jon Wilmoth) Date: Tue, 22 Apr 2003 15:29:05 -0700 Subject: More custom field revisions Message-ID: I agree the format does introduce the requirement for additional validation logic. My impression is that Administrators will appreciate the "compact"ness of this design over the cost of having to make corrections to their form values. Below are proposed validations/recourse. -----Original Message----- From: Sean McAfee [mailto:etzwane at schwag.org] Sent: Monday, April 21, 2003 5:00 PM To: developers at bugzilla.org Subject: Re: More custom field revisions "Jon Wilmoth" wrote: >I've attached example of the admin screen in an attempt to "simplify" >what was already there and also adds a couple of things present in the >spec that weren't present on the ui. The new page looks cleaner in some ways, and I originally envisioned the page looking something like that. However, this format presents several opportunities for the administrator to enter incorrect or irrelevant data. * Suppose the admin sets the Display Order for all of the fields to "1", checks them all, and presses "Reorder Selected". What should happen? Display Order must be unique within the product. The cgi script would have to return an error indicating the display order couldn't be the same for all entries. * How should Bugzilla treat fields whose Display Order has been changed, but which are not checked? It's a web based application. The simple less-user friendly answer is: there are certain concessions made in the web world, loss of data input into forms is one. We don't prompt the user to save bug modification (if any) when they navigate away from the page. I say this is the same. Alternatively, effort could be spent to "protect" the user from themselves with javascript. * In order to move the first field to the end of the list, the admin would need to reset the Display Order of every field in the project. This would be awkward for only a few fields, and downright onerous (not to mention error-prone) if there were dozens. This is a much more severe problem. If there are any more than 5 fields, I'd get annoyed at trying to rearrange them. Attached is a variation of the previous admin screen to * Actually, any kind of nontrivial field rearrangement is going to present similar difficulties. AGREED. Please see new version. My proposed page layout eliminates the ambiguities and additional error handling introduced by the first two items, and avoids the burden imposed on the administrator by the last two. >On the db structure: >3)Shouldn't custom_field_defs have a "required" Boolean column? It can. There wasn't much discussion of it, but I'll add it provisionally (see above). I think this will be an important addition for transitioning to a generic field validation model for all fields (stock and custom). >4)Perhaps renaming custom_fields.field_index to >custom_fields.display_order to be more intention revealing. I don't usually think of a single number as being an "order", but how about "display_index" instead? (Again, see above.) Sounds good. >5)Perhaps rename custom_field_defs.field_name to >custom_field_defs.ui_label to be more intention revealing. Your modified cfadmin.html page appears to draw a distinction between a field's "name" and its "display label". Why are two identifiers necessary? I envisioned that a single string would serve as both. The name is a admin/developer friendly identifier. The display label is what would be displayed to the user. Similarly, why draw a distinction between a selection field's "true" value (eg, "foo", "bar") and its UI value ("Foo Choice", "Bar Choice")? Perhaps it's just my experience, but I've never seen domain values stored as user friendly strings. Typically there's been a code and a decode value. The distinction simply follows this model. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerv at mozilla.org Tue Apr 22 22:43:14 2003 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 22 Apr 2003 23:43:14 +0100 Subject: More custom field revisions In-Reply-To: <3EA3F169.60003@peshkin.net> References: <20030421080758.5CA5EBC51@diggity.schwag.org> <3EA3F169.60003@peshkin.net> Message-ID: <3EA5C582.7040007@mozilla.org> Joel Peshkin wrote: > One item that is missing for me is the ability to designate group > controls on who gets to see a custom field and who gets to edit it. Is > this something that is of general interest or a strange local hack for me? I'd consider it pretty weird if you had the rights to see the bug but not the field within it. As I understand it, we seem to be trying to avoid ("insiders" excepted) having different bits of individual bugs appear and disappear. Gerv From etzwane at schwag.org Wed Apr 23 01:51:42 2003 From: etzwane at schwag.org (Sean McAfee) Date: Tue, 22 Apr 2003 21:51:42 -0400 Subject: More custom field revisions In-Reply-To: Message-ID: <20030423015142.AC1CEBC50@diggity.schwag.org> "Jon Wilmoth" wrote: >* Suppose the admin sets the Display Order for all of the fields to >"1", > checks them all, and presses "Reorder Selected". What should happen? >Display Order must be unique within the product. The cgi script would >have to return an error indicating the display order couldn't be the >same for all entries. Better if the form can be laid out in such a way that it is impossible to submit erroneous input. >* How should Bugzilla treat fields whose Display Order has been >changed, > but which are not checked? >It's a web based application. The simple less-user friendly answer is: >there are certain concessions made in the web world, loss of data input >into forms is one. We don't prompt the user to save bug modification >(if any) when they navigate away from the page. I say this is the same. >Alternatively, effort could be spent to "protect" the user from >themselves with javascript. Unfortunately, as has been pointed out to me, the presence of Javascript can't be depended on. >Your modified cfadmin.html page appears to draw a distinction between a >field's "name" and its "display label". Why are two identifiers >necessary? >I envisioned that a single string would serve as both. >The name is a admin/developer friendly identifier. The display label is >what would be displayed to the user. I understand, but I just don't see what's gained by this approach. In what way is an additional label like txtCustomStringField1 "friendly" to the administrator or developer? In what situations would it be used? As an administrator, I would find it very confusing to have to supply two names for every field and selection value, when all I really care about is what's presented to the user. What kind of interface did you have in mind for specifying label pairs for selection fields? Side-by-side textareas? Or a single textarea, one label per line, with a reserved character separating the "developer" label with the "user" label? It seems needlessly complicated. Regarding your new cfadmin.html page, it seems very unintuitive to me. I can't easily tell what functions are served by most of the form elements. There are four "broken image" icons to the left of the selection box in the "Display Order" column; they refer to images that don't exist in my 2.17.3 installation. So, it's hard to tell how one would alter a field's display order using this page. I'm *guessing* that the upper table is used for editing an individual field, and that clicking the "Name" hyperlinks on the lower table will reload the page with the chosen field at the top. Is this correct? What does the "Clear" button do? I assume that the "Reorder Selected" button is no longer supposed to be there. I think it would be better to dispense with the "Delete Selected" button as well. Deleting a single field is such a potentially destructive operation to begin with; I don't think we need to facilitate bulk deletes. -- Sean McAfee -- etzwane at schwag.org From justdave at syndicomm.com Wed Apr 23 06:35:34 2003 From: justdave at syndicomm.com (David Miller) Date: Wed, 23 Apr 2003 02:35:34 -0400 Subject: What lies ahead Message-ID: Bugzilla 2.17.4 will be posted within the next 24 hours. It's time to start reviewing our goals for 2.18 and deciding what's important for us to keep on the list and what we might want to push off. As far as timing goes, I'm not going to set a date, we've been bit by that too many times in the past. The answer to "when is 2.18 coming out?" will continue to be "When it's done." However, we probably do need to do it sooner rather than later, so reducing our list of goals is probably a good idea at this point. If we can pare this down appropriately, I'm thinking along the lines of 2.17.5 being the last developer release prior to 2.18 release candidates. That may or may not be realistic, but we'll see. A quick query of bzbot in IRC tells me that we have 1096 bugs currently targeted at 2.18, with 478 of those fixed so far, leaving 618 still to be done. Oof. For comparison, we fixed 550 bugs for version 2.16. The current "2.18 goals" taken from http://www.bugzilla.org/roadmap.html (with completed items removed, and comments by me added): * Integrate inbound email into the mainline Bugzilla code (currently it's in contrib and very messy, if it even still works). (94850) Matt Barnson says he's currently working on this, so it might get done before then after all. :) * HTML 4.01 Transitional compliance for all administrative pages. * Templatization of all administrative pages. * Enable Perl's taint mode for all administrative pages. These three are pretty much lumped together as a complete rewrite of the administration pages (because they need it badly). Templatization and rewrite of the admin pages, while a lofty goal, and something we really should do, seems to be going really slow. I'd really like to see this stay on the list, but we're going to have to push somebody into doing it I think. :) * Customizable statuses and resolutions. This doesn't seem to be going anywhere lately, I'm leaning towards pushing this one off. * Compatibility with Postgres SQL. (98304) Though not listed here, it's quite possible that Sybase support will actually make it (although it may be checked in partially incomplete and labelled as unsupported, due to some quirks in Sybase that sites are just going to have to live with if they decide they really want to use Sybase with Bugzilla - I did the Sybase conversion, and I personally would not recommend it, because Sybase sucks for web-based apps, but hey, they paid me for it :) I have no clue of the current status of Postgres support. It was pretty close to landing at one point, but it's quite bitrotted now, and I haven't seen anything done with it lately. Sybase may end up landing first, surprisingly. * Out-of-the-box compatibility with Win32. Personally, I'd like to see this stay on the list. As much as we all hate it, there's a lot of PHBs out there that won't let people do anything if you can't do it on Windows... and we're so close now anyway... * An optional way to pick users from a list for the assignee and QAContact fields. (52557 and/or 102942) I've seen a lot of activity on this front lately. I think it'll make it. * Continue to catch up with contributed patches from the backlog generated when we had the tree locked down during the 2.14 development cycle. I think we may be at a point where we can drop this from the list. There's a lot of stuff queued for review out there now with the new review system. :) Nowhere near as much stuff left in the queue as there was when we finished the user-facing templatization. And the entire architecture of Bugzilla has been changing so fast lately. Comments from the peanut gallery? :) -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From preed at sigkill.com Wed Apr 23 07:26:20 2003 From: preed at sigkill.com (J. Paul Reed) Date: Wed, 23 Apr 2003 00:26:20 -0700 Subject: What lies ahead In-Reply-To: ; from justdave@syndicomm.com on Wed, Apr 23, 2003 at 02:35:34AM -0400 References: Message-ID: <20030423002620.A25831@sigkill.com> On 23 Apr 2003 at 02:35:34, David Miller moved bits on my disk to say: > * Out-of-the-box compatibility with Win32. > > Personally, I'd like to see this stay on the list. As much as we all > hate it, there's a lot of PHBs out there that won't let people do > anything if you can't do it on Windows... and we're so close now > anyway... If we're going to make this a goal, then bug 84876 automatically becomes a 2.18 goal. This really shouldn't come as a surprise, as Gerv has been chomping on the bit to get this in, and we've been promising 2.18 will deliver non-suckiness in the SMTP-department for some time now. Thus, the goals related to that, as I see them, are: * Easier MTA config (84876) * Templatized email headers * All email output templatized Bug 84876 *technically* only covers the first one; I haven't filed bugs on the other ones, since I've been toying with the idea of just rolling goals 2 and 3 into the patch for 84876... but the more I think about that, the more I don't know if that's such a good idea. As for Win32, when you are triaging bugs, if you find that a bug is necessary to make BZ work on Win32, *PLEASE* add "[needed for Win32bz]" to the status whiteboard, so we can make that query as accurate as we can make it for the Win32-ers. Later, Paul ------------------------------------------------------------------------ J. Paul Reed -- 0xDF8708F8 || preed at sigkill.com || web.sigkill.com/preed To hold on to sanity too tight is insane. -- Nick Falzone, Pushing Tin I use PGP; you should use PGP too... if only to piss off John Ashcroft From bbaetz at acm.org Wed Apr 23 08:09:01 2003 From: bbaetz at acm.org (Bradley Baetz) Date: Wed, 23 Apr 2003 18:09:01 +1000 Subject: What lies ahead In-Reply-To: References: Message-ID: <20030423080901.GA1475@mango.home> As you've probably all noticved, I've been rather busy on non-bz things recently (like job-hunting) :) I would like mod_perl support, but I'm not sure how far away that is. I have it running locally for show_bug, but its not in a state where I'd even consider running it on bmo. Having User.pm go in would be nice, though, since thats the last reorg patch required I believe. Bradley From preed at sigkill.com Wed Apr 23 09:21:57 2003 From: preed at sigkill.com (J. Paul Reed) Date: Wed, 23 Apr 2003 02:21:57 -0700 Subject: Your status report needs you! Message-ID: <20030423022157.A26107@sigkill.com> Hey all: I'm working on the status report, and would like to see write-ups on the following improvements; if you know something about these bugs and can contribute, that'd be a huge help. -- The authentication module/LDAP improvements (bbaetz?) -- JS versions of buglists (Gerv?) -- Move from /usr/bonsaitools to /usr/bin/perl (Jake?) (I include this 'feature' only because it was an oft-requested one and a nice 'marketing' thing to point out...) -- All of the documentation updates (seems like there's been a lot) (Jake?) -- Web browser changes; looks like we updated Safari and IBM web browser handling; again, a marketing thing mostly -- New support for localized templates (Burnus?) Also, the current draft of the status report, if you'd like to take a gander, is available at: http://landfill.bugzilla.org/preed/bugzilla-org/status_updates/2003-04-23.html Later, Paul ------------------------------------------------------------------------ J. Paul Reed -- 0xDF8708F8 || preed at sigkill.com || web.sigkill.com/preed To hold on to sanity too tight is insane. -- Nick Falzone, Pushing Tin I use PGP; you should use PGP too... if only to piss off John Ashcroft From Rohit_Shankar at satyam.com Wed Apr 23 11:22:47 2003 From: Rohit_Shankar at satyam.com (Rohit_Shankar) Date: Wed, 23 Apr 2003 16:52:47 +0530 Subject: No subject Message-ID: Hi All, I am using Bugzilla for tracking Bugs in one my Projects. Now I have a similar kind of Project also needs Bugzilla support. Can I use the same Bugzilla instance for tracking bugs on two different Projects by doing some partitioning . Or can I install a separate instance of Bugzilla on the same Solaris Machine. Regards Rohit ************************************************************************** This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated. ************************************************************************** From tobias.burnus at physik.fu-berlin.de Wed Apr 23 11:41:00 2003 From: tobias.burnus at physik.fu-berlin.de (Tobias Burnus) Date: Wed, 23 Apr 2003 13:41:00 +0200 (CEST) Subject: your mail In-Reply-To: Message-ID: Hi, On Wed, 23 Apr 2003, Rohit_Shankar wrote: > Can I use the same Bugzilla instance for tracking bugs on two different > Projects by doing some partitioning. Well, you can either use the category "products" (if you have restricted yourself to one product (and several components) for the previous project). > Or can I install a separate instance of Bugzilla on the same Solaris Machine. Yes, you can. We do so---and http://landfill.bugzilla.org/ does too. It should be enough to untar another bugzilla and change the name of that bugzilla database from "bugs" to something else (in localconfig). Tobias From myk at mozilla.org Wed Apr 23 11:41:37 2003 From: myk at mozilla.org (Myk Melez) Date: Wed, 23 Apr 2003 04:41:37 -0700 Subject: getting MySQL AB using Bugzilla In-Reply-To: <3EA0319B.1080603@gerv.net> References: <3E9DF849.9000807@mozilla.org> <20030416180136.A15146@sigkill.com> <3E9E58C0.2040905@mozilla.org> <20030417070401.A17792@sigkill.com> <3E9F1AF0.3060802@mozilla.org> <20030417144339.A20455@sigkill.com> <3EA0319B.1080603@gerv.net> Message-ID: <3EA67BF1.6060200@mozilla.org> Gervase Markham wrote: > Actually, it seems that quite a few people in the newsgroup are using > 2.17.3 - another sign that we should do a stable release soon. Well, that was the purpose of doing developer's releases--to let semi-conservative installations update to "semi-stable" releases more regularly--so lots of people using 2.17.3 is more indicative of the success of the developer's releases than any pressure to release something "stable." Still, in general I agree that we should release 2.18 sooner than later, modulo meeting the most important goals on our list. Even with successful developer's releases, there's marketing value in shipping a new production release periodically (it keeps us in the public eye), not to mention the value of getting to define a new stable development branch so we can stop supporting the old one. -myk From Rohit_Shankar at satyam.com Wed Apr 23 12:56:14 2003 From: Rohit_Shankar at satyam.com (Rohit_Shankar) Date: Wed, 23 Apr 2003 18:26:14 +0530 Subject: your mail Message-ID: So for just creating another instance on the same machine ... we need to untar the Bugzilla tar on some different folder and just change the database name -----Original Message----- From: Tobias Burnus [mailto:tobias.burnus at physik.fu-berlin.de] Sent: Wednesday, April 23, 2003 5:11 PM To: 'developers at bugzilla.org' Cc: Utpal_Mukherjee Subject: Re: your mail Hi, On Wed, 23 Apr 2003, Rohit_Shankar wrote: > Can I use the same Bugzilla instance for tracking bugs on two different > Projects by doing some partitioning. Well, you can either use the category "products" (if you have restricted yourself to one product (and several components) for the previous project). > Or can I install a separate instance of Bugzilla on the same Solaris Machine. Yes, you can. We do so---and http://landfill.bugzilla.org/ does too. It should be enough to untar another bugzilla and change the name of that bugzilla database from "bugs" to something else (in localconfig). Tobias ---- To view or change your list settings, click here: ************************************************************************** This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated. ************************************************************************** From bbaetz at acm.org Wed Apr 23 13:13:26 2003 From: bbaetz at acm.org (Bradley Baetz) Date: Wed, 23 Apr 2003 23:13:26 +1000 Subject: Your status report needs you! In-Reply-To: <20030423022157.A26107@sigkill.com> References: <20030423022157.A26107@sigkill.com> Message-ID: <20030423131326.GA2057@mango.home> Auth reorg ---------- As part of the ongoing preparation for mod_perl, Bugzilla's authentication mechanisms were modularised. This makes dropping in a new authentication scheme easy. Both the existing DB and LDAP systems were modified to this format. As well, the CGI part of the backend was split up to allow for authentication from other sources, such as emails. This is still theoretical, but the design does allow it. As part of this conversion, LDAP logins now use the standard Net::LDAP module (using openldap), rather than the Mozilla::LDAP modules (using the Mozilla project's LDAP configuration). mod_perl -------- Work continues on mod_perl support. As well as the authentication reorganisation, there is a patch pending (not present in 2.17.4) to move user handling into a module. With this patch (as well as some other patches), mod_perl has been implemented for show_bug.cgi (as wlel as minor pages such as index.cgi). Times to show a simple bug with 5 comments (via wget -O /dev/null) go from 0.5-0.6 seconds to 0.1-0.15 seconds on an unloaded P4-2.4GHz machine. [note to self - test on landfill when I have time and when Dave is around to keep restarting Apache for me] This is not yet ready for prime time, however. Lots of the work is very 'hacked up', and the patches only support mod_perl installations. At this time only mod_perl v1 is being supported. mod_perlv2 is still experimental, and several bugs in v2 have been found (including server crashes now fixed in mod_perl-cvs). No deliberate mod_perl v2 incompatabilities are being introduced, however, and v2 support will be added at a later stage. The major factor inhibiting mod_perl support ATM is the lack of development time, and the lack of time for other bugzilla developers to review patches. Who wants to tidy that up for me? ;) Bradley From JWilmoth at starbucks.com Wed Apr 23 23:26:43 2003 From: JWilmoth at starbucks.com (Jon Wilmoth) Date: Wed, 23 Apr 2003 16:26:43 -0700 Subject: Limit to Search Values? Message-ID: Running 2.17.3 with IE 6.x I'm experiencing a problem with the query page. Selecting more than 52 components as search criteria causes the "Search" button to do nothing. Simply deselecting any one component returns normal functioning to the Search submit button. From jake at bugzilla.org Thu Apr 24 02:26:04 2003 From: jake at bugzilla.org (Jake) Date: Wed, 23 Apr 2003 22:26:04 -0400 Subject: More custom field revisions In-Reply-To: <3EA5C582.7040007@mozilla.org> References: <20030421080758.5CA5EBC51@diggity.schwag.org> <3EA3F169.60003@peshkin.net> <3EA5C582.7040007@mozilla.org> Message-ID: <3EA74B3C.4030609@bugzilla.org> Gervase Markham wrote: > Joel Peshkin wrote: > >> One item that is missing for me is the ability to designate group >> controls on who gets to see a custom field and who gets to edit it. >> Is this something that is of general interest or a strange local hack >> for me? > > > I'd consider it pretty weird if you had the rights to see the bug but > not the field within it. As I understand it, we seem to be trying to > avoid ("insiders" excepted) having different bits of individual bugs > appear and disappear. > > Gerv There may be fringe cases where that's necessary :) FE, the time tracking information. I'm not sure if it works that way now or not, but I can certainly see where a person or company may wish to have a public bugzilla but keep their resource expenditure information secret. Also, the second part of that bug is important: who gets to edit it. Even if it's as simple as does it require editbugs? But as long as the field is custom anyway (eg, may or may not exist) and you have to have some way to define some kind of permissions, it doesn't seem like it'd be terribly difficult to add the first half (or last keep it in mind). From jake at bugzilla.org Thu Apr 24 02:39:07 2003 From: jake at bugzilla.org (Jake) Date: Wed, 23 Apr 2003 22:39:07 -0400 Subject: More custom field revisions In-Reply-To: <20030421235951.6E04BBC51@diggity.schwag.org> References: <20030421235951.6E04BBC51@diggity.schwag.org> Message-ID: <3EA74E4B.7000905@bugzilla.org> Sean McAfee wrote: >* Suppose the admin sets the Display Order for all of the fields to "1", > checks them all, and presses "Reorder Selected". What should happen? >* How should Bugzilla treat fields whose Display Order has been changed, > but which are not checked? >* In order to move the first field to the end of the list, the admin would > need to reset the Display Order of every field in the project. This > would be awkward for only a few fields, and downright onerous (not to > mention error-prone) if there were dozens. >* Actually, any kind of nontrivial field rearrangement is going to present > similar difficulties. > > My thought would be to change the "reorder selected" button to a normal submit or maybe even reorder and have a layout someting like: +--------+------------+ | Order | Field Name | +--------+------------+ | [ 1 v] | Cust_A | | [ 2 v] | Cust_B | | [ 3 v] | Cust_C | | [ 4 v] | Cust_D | | [ 5 V] | Cust_E | +-| 1 |-+------------+ | 1.5| | 2 | | 2.5| | 3 | | 3.5| | ...| +----+ When you get a form submitted w/the same value twice you can either try and be smart about which one goes first or return an error (I don't care which, others might). Then you simply renumber them to integers. So if I change Cust_E to 2.5 and submit it the new form would be: +--------+------------+ | Order | Field Name | +--------+------------+ | [ 1 v] | Cust_A | | [ 2 v] | Cust_B | | [ 3 v] | Cust_E | | [ 4 v] | Cust_C | | [ 5 v] | Cust_D | +--------+------------+ This should make it obvious that it's possible to "insert" one field in front of the others without needing to change every sort field. From preed at sigkill.com Thu Apr 24 07:17:54 2003 From: preed at sigkill.com (J. Paul Reed) Date: Thu, 24 Apr 2003 00:17:54 -0700 Subject: Your status report needs you! In-Reply-To: <20030423022157.A26107@sigkill.com>; from preed@sigkill.com on Wed, Apr 23, 2003 at 02:21:57AM -0700 References: <20030423022157.A26107@sigkill.com> Message-ID: <20030424001754.A32364@sigkill.com> On 23 Apr 2003 at 02:21:57, J. Paul Reed moved bits on my disk to say: > is available at: > > http://landfill.bugzilla.org/preed/bugzilla-org/status_updates/2003-04-23.html THIRD draft is ready... I have yet to hear from Gerv and Justdave, but I bet I'll talk to Dave tomorrow... ;-) Sections that you should probably overload include: the intro's treatment of the security bugs; not that we have a good security announcement in hand, I'll redo parts of the intro. -- Checkins that happened after I ran the scrubbing script; I'll update that tomorrow. -- The date; I'll change that when I confirm with Justdave that we're releasing tomorrow. Later, Paul ------------------------------------------------------------------------ J. Paul Reed -- 0xDF8708F8 || preed at sigkill.com || web.sigkill.com/preed To hold on to sanity too tight is insane. -- Nick Falzone, Pushing Tin I use PGP; you should use PGP too... if only to piss off John Ashcroft From preed at sigkill.com Thu Apr 24 07:21:13 2003 From: preed at sigkill.com (J. Paul Reed) Date: Thu, 24 Apr 2003 00:21:13 -0700 Subject: Your status report needs you! In-Reply-To: <20030424001754.A32364@sigkill.com>; from preed@sigkill.com on Thu, Apr 24, 2003 at 12:17:54AM -0700 References: <20030423022157.A26107@sigkill.com> <20030424001754.A32364@sigkill.com> Message-ID: <20030424002113.B32364@sigkill.com> On 24 Apr 2003 at 00:17:54, J. Paul Reed moved bits on my disk to say: > Sections that you should probably overload include: Over*look*, that is. Damn I need to sleep. Later, Paul ------------------------------------------------------------------------ J. Paul Reed -- 0xDF8708F8 || preed at sigkill.com || web.sigkill.com/preed To hold on to sanity too tight is insane. -- Nick Falzone, Pushing Tin I use PGP; you should use PGP too... if only to piss off John Ashcroft From gerv at mozilla.org Thu Apr 24 09:02:32 2003 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 24 Apr 2003 10:02:32 +0100 Subject: Your status report needs you! In-Reply-To: <20030424001754.A32364@sigkill.com> References: <20030423022157.A26107@sigkill.com> <20030424001754.A32364@sigkill.com> Message-ID: <3EA7A828.9040208@mozilla.org> >> http://landfill.bugzilla.org/preed/bugzilla-org/status_updates/2003-04-23.html > Bugzilla Status Update > The Bugzilla Team is pleased to announce the release of Bugzilla > 2.16.3, a maintainence release and 2.17.4, a new developers' release. "maintenance". > that many organizations--Mozilla.org included--are using 2.17 without > incident). Small m on mozilla.org - it's a domain. Possibly a comma after "play with". > If you're wondering about the Win32 situation, it is still, > unfortunately, unchanged. However, the Bugzilla Team is currently > discussing confirming the goal of "out of box Win32 support" for > 2.18. "discussing confirming"? :-| How about "discussing whether to confirm"? > 87406) * New makefile-based installation system (Bug 104660, Bug > 105854, Bug 105855, and Bug 105856) Is anyone working on this at all? * Generic charting. Allows users > to define arbitrary data sets for which historical data will be > recorded, and then plot those data sets. Bug 16009. "Bug 16009" needs brackets. > a package, has finally landed. This bug moves bug mail handling (mail > from bug submissions/changes) from the venerable external processmail > script, the source of much porting pain and security holes, That seems like an unwarranted slur. What security holes? > As part of this conversion, LDAP logins now use Perl's standard > Net::LDAP module, which in turn relies on OpenLDAP. This is a > departure from using the Mozilla::LDAP modules which were using the > Mozilla project's LDAP configuration. That last sentence makes no sense. The Mozilla project has no "LDAP configuration"; we don't use LDAP. Mozilla::LDAP is a generic Perl LDAP module like Net::LDAP; it just doesn't seem to be maintained any more. > JS versions of buglists > > (Gerv?) Buglists are now available as JavaScript structures as well as HTML and RDF. This allows things like the "update buglinks" bookmarklet: http://bugzilla.mozilla.org/attachment.cgi?id=119087&action=view which updates the status of all the buglinks in a page to have the correct strikeout/tooltip etc. > expects be changed from that to the more standard /usr/bin. This > request was never fulfiled because Bugzilla's primary installation, > bugzilla.mozilla.org, This is improperly closed, meaning it runs on for the rest of the paragraph. > XUL Chrome should use |content| over |_content|. > (caillon) Which file did this change? The sidebar? It seems like a Mozilla change. Gerv From preed at sigkill.com Thu Apr 24 09:42:30 2003 From: preed at sigkill.com (J. Paul Reed) Date: Thu, 24 Apr 2003 02:42:30 -0700 Subject: Your status report needs you! In-Reply-To: <3EA7A828.9040208@mozilla.org>; from gerv@mozilla.org on Thu, Apr 24, 2003 at 10:02:32AM +0100 References: <20030423022157.A26107@sigkill.com> <20030424001754.A32364@sigkill.com> <3EA7A828.9040208@mozilla.org> Message-ID: <20030424024230.E32364@sigkill.com> On 24 Apr 2003 at 10:02:32, Gervase Markham moved bits on my disk to say: > "maintenance". I haven't spell-checked yet. That comes last. > > 87406) * New makefile-based installation system (Bug 104660, Bug > > 105854, Bug 105855, and Bug 105856) > > Is anyone working on this at all? I thought Zach was. > > a package, has finally landed. This bug moves bug mail handling (mail > > from bug submissions/changes) from the venerable external processmail > > script, the source of much porting pain and security holes, > > That seems like an unwarranted slur. What security holes? As I remember, there were a number of holes plugged over the months due to the way variables were passed and interpretted on the open() to sendmail in processmail. Do I need to find specifics? The "porting pain" should be obvious. > > As part of this conversion, LDAP logins now use Perl's standard > > Net::LDAP module, which in turn relies on OpenLDAP. This is a > > departure from using the Mozilla::LDAP modules which were using the > > Mozilla project's LDAP configuration. > > That last sentence makes no sense. The Mozilla project has no "LDAP > configuration"; we don't use LDAP. Mozilla::LDAP is a generic Perl LDAP > module like Net::LDAP; it just doesn't seem to be maintained any more. Gerv: I didn't write that sentance. I'm not always the ones that writes the sentances that make "no sense." bbaetz: can you clarify what you meant? > > XUL Chrome should use |content| over |_content|. > > (caillon) > > Which file did this change? The sidebar? It seems like a Mozilla change. Yes, the sidebar: http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla/webtools/bugzilla/template/en/default&command=DIFF_FRAMESET&root=/cvsroot&file=sidebar.xul.tmpl&rev1=1.7&rev2=1.8 Later, Paul ------------------------------------------------------------------------ J. Paul Reed -- 0xDF8708F8 || preed at sigkill.com || web.sigkill.com/preed To hold on to sanity too tight is insane. -- Nick Falzone, Pushing Tin I use PGP; you should use PGP too... if only to piss off John Ashcroft From bbaetz at acm.org Thu Apr 24 11:12:22 2003 From: bbaetz at acm.org (Bradley Baetz) Date: Thu, 24 Apr 2003 21:12:22 +1000 Subject: Your status report needs you! In-Reply-To: <20030424024230.E32364@sigkill.com> References: <20030423022157.A26107@sigkill.com> <20030424001754.A32364@sigkill.com> <3EA7A828.9040208@mozilla.org> <20030424024230.E32364@sigkill.com> Message-ID: <20030424111222.GA669@mango.home> On Thu, Apr 24, 2003 at 02:42:30AM -0700, J. Paul Reed wrote: > > > As part of this conversion, LDAP logins now use Perl's standard > > > Net::LDAP module, which in turn relies on OpenLDAP. This is a > > > departure from using the Mozilla::LDAP modules which were using the > > > Mozilla project's LDAP configuration. > > > > That last sentence makes no sense. The Mozilla project has no "LDAP > > configuration"; we don't use LDAP. Mozilla::LDAP is a generic Perl LDAP > > module like Net::LDAP; it just doesn't seem to be maintained any more. We do use LDAP for authentication, if you configure it. Now you can use it without having to change source code and stuff, and its been tidied up. Mozilla::LDAP uses the mozilla projects' LDAP libraries. Net::LDAP uses OpenLDAP. They both talk LDAP, but thats about it for similarities. Net::LDAP is also maintained, while I don't think anyone is working on Mozilla::LDAP. Net::LDAP is also standard with most linux installs (and openldap almost certainly is). The Mozilla::lLDAP stuf isn't. Maybe s/configuration/libraries/ ? Bradley From gerv at mozilla.org Thu Apr 24 12:46:17 2003 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 24 Apr 2003 13:46:17 +0100 Subject: Your status report needs you! In-Reply-To: <20030424024230.E32364@sigkill.com> References: <20030423022157.A26107@sigkill.com> <20030424001754.A32364@sigkill.com> <3EA7A828.9040208@mozilla.org> <20030424024230.E32364@sigkill.com> Message-ID: <3EA7DC99.8080303@mozilla.org> J. Paul Reed wrote: > On 24 Apr 2003 at 10:02:32, Gervase Markham moved bits on my disk to say: > >>"maintenance". > > I haven't spell-checked yet. That comes last. Oh, OK. >>That seems like an unwarranted slur. What security holes? > > As I remember, there were a number of holes plugged over the months due to > the way variables were passed and interpretted on the open() to sendmail in > processmail. > > Do I need to find specifics? Well, mentioning "security holes" in a non-specific way might just give people the jitters. How about just "the source of much pain"? > The "porting pain" should be obvious. Oh, I agree with the porting pain :-) >>That last sentence makes no sense. The Mozilla project has no "LDAP >>configuration"; we don't use LDAP. Mozilla::LDAP is a generic Perl LDAP >>module like Net::LDAP; it just doesn't seem to be maintained any more. > > Gerv: I didn't write that sentance. I'm not always the ones that writes the > sentances that make "no sense." I didn't say you wrote it, or imply you were to blame for its incorrectness - no need to be so touchy :-) >>>XUL Chrome should use |content| over |_content|. >>>(caillon) >> >>Which file did this change? The sidebar? It seems like a Mozilla change. > > Yes, the sidebar: > http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla/webtools/bugzilla/template/en/default&command=DIFF_FRAMESET&root=/cvsroot&file=sidebar.xul.tmpl&rev1=1.7&rev2=1.8 So how come there isn't a bug number associated with the checkin? Did caillon screw up? Gerv From Narendra_Dukkipati at satyam.com Thu Apr 24 12:46:47 2003 From: Narendra_Dukkipati at satyam.com (Narendra_Dukkipati) Date: Thu, 24 Apr 2003 18:16:47 +0530 Subject: Bugzilla Instance Message-ID: Hi All I have a Bugzilla server running on one of the Solaris machines,i wanted to use this Bugzilla for another site,can i create another instance of Bugzilla,if so how do i do it..kindly provide step by step explanation of the configuration. regards Naren ************************************************************************** This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated. ************************************************************************** From gerv at mozilla.org Thu Apr 24 12:47:54 2003 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 24 Apr 2003 13:47:54 +0100 Subject: Your status report needs you! In-Reply-To: <20030424111222.GA669@mango.home> References: <20030423022157.A26107@sigkill.com> <20030424001754.A32364@sigkill.com> <3EA7A828.9040208@mozilla.org> <20030424024230.E32364@sigkill.com> <20030424111222.GA669@mango.home> Message-ID: <3EA7DCFA.2080000@mozilla.org> Bradley Baetz wrote: > On Thu, Apr 24, 2003 at 02:42:30AM -0700, J. Paul Reed wrote: > >>>>As part of this conversion, LDAP logins now use Perl's standard >>>>Net::LDAP module, which in turn relies on OpenLDAP. This is a >>>>departure from using the Mozilla::LDAP modules which were using the >>>>Mozilla project's LDAP configuration. >>> >>>That last sentence makes no sense. The Mozilla project has no "LDAP >>>configuration"; we don't use LDAP. Mozilla::LDAP is a generic Perl LDAP >>>module like Net::LDAP; it just doesn't seem to be maintained any more. > > We do use LDAP for authentication, if you configure it. "We" in that sentence was the Mozilla project - mozilla.org. We don't use LDAP. > Mozilla::LDAP uses the mozilla projects' LDAP libraries. Net::LDAP uses > OpenLDAP. They both talk LDAP, but thats about it for similarities. > Net::LDAP is also maintained, while I don't think anyone is working on > Mozilla::LDAP. Net::LDAP is also standard with most linux installs (and > openldap almost certainly is). The Mozilla::lLDAP stuf isn't. > > Maybe s/configuration/libraries/ ? Sounds good to me. Gerv From Utpal_Mukherjee at satyam.com Thu Apr 24 12:11:57 2003 From: Utpal_Mukherjee at satyam.com (Utpal_Mukherjee) Date: Thu, 24 Apr 2003 17:41:57 +0530 Subject: Bugzilla Installation Message-ID: Hi we have installed bugzilla for our previous project which is in development stage. we want to have a new instance of bugzilla for a new project at the same m/c without affecting the previous configurations. I have got the information that we can have two instances of bugzilla in the same machine but I don't know how to do that... what are the steps I need to follow to configure a new instance of bugzilla without affecting the previous one. Kindly let me know as soon as posible.Your response will help me to configure bugzilla. waiting for your respone. Regards Utpal ************************************************************************** This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated. ************************************************************************** From jon at vmware.com Thu Apr 24 18:23:34 2003 From: jon at vmware.com (Jonathan Schatz) Date: 24 Apr 2003 11:23:34 -0700 Subject: Your status report needs you! In-Reply-To: <20030424024230.E32364@sigkill.com> References: <20030423022157.A26107@sigkill.com> <20030424001754.A32364@sigkill.com> <3EA7A828.9040208@mozilla.org> <20030424024230.E32364@sigkill.com> Message-ID: <1051208614.23011.1.camel@jonschatz-lx.vmware.com> On Thu, 2003-04-24 at 02:42, J. Paul Reed wrote: > > That seems like an unwarranted slur. What security holes? > > As I remember, there were a number of holes plugged over the months due to > the way variables were passed and interpretted on the open() to sendmail in > processmail. > > Do I need to find specifics? and this one: http://bugzilla.mozilla.org/show_bug.cgi?id=197153 -jon -- Jonathan Schatz Engineering System Administrator VMware, Inc "Te occidere possunt sed te edere non possunt nefas est." From preed at sigkill.com Thu Apr 24 19:33:23 2003 From: preed at sigkill.com (J. Paul Reed) Date: Thu, 24 Apr 2003 12:33:23 -0700 Subject: Your status report needs you! In-Reply-To: <3EA7DC99.8080303@mozilla.org>; from gerv@mozilla.org on Thu, Apr 24, 2003 at 01:46:17PM +0100 References: <20030423022157.A26107@sigkill.com> <20030424001754.A32364@sigkill.com> <3EA7A828.9040208@mozilla.org> <20030424024230.E32364@sigkill.com> <3EA7DC99.8080303@mozilla.org> Message-ID: <20030424123323.A2750@sigkill.com> On 24 Apr 2003 at 13:46:17, Gervase Markham moved bits on my disk to say: > Well, mentioning "security holes" in a non-specific way might just give > people the jitters. How about just "the source of much pain"? I changed it to "the source of much porting pain and some security issues." > So how come there isn't a bug number associated with the checkin? Did > caillon screw up? According to caillon in IRC, no, no bug number with that.. 4TH DRAFT is available, BTW; new URL: http://landfill.bugzilla.org/preed/bugzilla-org/status_updates/2003-04-24.html Later, Paul ------------------------------------------------------------------------ J. Paul Reed -- 0xDF8708F8 || preed at sigkill.com || web.sigkill.com/preed To hold on to sanity too tight is insane. -- Nick Falzone, Pushing Tin I use PGP; you should use PGP too... if only to piss off John Ashcroft From etzwane at schwag.org Thu Apr 24 22:09:36 2003 From: etzwane at schwag.org (Sean McAfee) Date: Thu, 24 Apr 2003 18:09:36 -0400 Subject: Bug ID domain? Message-ID: <20030424220936.BF98FBC51@diggity.schwag.org> Hi, all-- What is the domain of possible values for bug IDs? I get the idea that IDs are positive integers, but is this codified somewhere? I ask because I've just realized I haven't yet allowed for storage of field default values in my custom fields schema. For a table like this: cf_integer ---------- bug_id integer not null, field_id integer not null, value integer, primary key (bug_id, field_id) ...I'd like to use a special bug_id to store the default value for a given field_id. NULL is out, unfortunately, because I need that primary key. Would using a number like 0 or -1 be safe? -- Sean McAfee -- etzwane at schwag.org From gerv at mozilla.org Thu Apr 24 22:44:19 2003 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 24 Apr 2003 23:44:19 +0100 Subject: Bug ID domain? In-Reply-To: <20030424220936.BF98FBC51@diggity.schwag.org> References: <20030424220936.BF98FBC51@diggity.schwag.org> Message-ID: <3EA868C3.7090108@mozilla.org> > What is the domain of possible values for bug IDs? I get the idea that IDs > are positive integers, but is this codified somewhere? Well, currently they are auto-allocated by the database, starting at 1 and going upwards, so it's codified like that. The domain is 1 -> 2^31 at least. > ...I'd like to use a special bug_id to store the default value for a given > field_id. NULL is out, unfortunately, because I need that primary key. > Would using a number like 0 or -1 be safe? Both would probably be safe, but I think bbaetz normally has things to say about hacks like this... Gerv From gerv at mozilla.org Thu Apr 24 22:47:39 2003 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 24 Apr 2003 23:47:39 +0100 Subject: Limit to Search Values? In-Reply-To: References: Message-ID: <3EA8698B.6060709@mozilla.org> Jon Wilmoth wrote: > Running 2.17.3 with IE 6.x I'm experiencing a problem with the query > page. Selecting more than 52 components as search criteria causes the > "Search" button to do nothing. Simply deselecting any one component > returns normal functioning to the Search submit button. Please file a bug; then we can record the discussion :-) Gerv From bbaetz at acm.org Thu Apr 24 22:48:50 2003 From: bbaetz at acm.org (Bradley Baetz) Date: Fri, 25 Apr 2003 08:48:50 +1000 Subject: Bug ID domain? In-Reply-To: <3EA868C3.7090108@mozilla.org> References: <20030424220936.BF98FBC51@diggity.schwag.org> <3EA868C3.7090108@mozilla.org> Message-ID: <20030424224850.GA2046@mango.home> On Thu, Apr 24, 2003 at 11:44:19PM +0100, Gervase Markham wrote: > >What is the domain of possible values for bug IDs? I get the idea that IDs > >are positive integers, but is this codified somewhere? > > Well, currently they are auto-allocated by the database, starting at 1 > and going upwards, so it's codified like that. The domain is 1 -> 2^31 > at least. and we could make it unsigned and go to 2^32. > > >...I'd like to use a special bug_id to store the default value for a given > >field_id. NULL is out, unfortunately, because I need that primary key. > >Would using a number like 0 or -1 be safe? Why not store the default as a column in the table which defines all of the fields? thats the sensible place for it. Bradley From jason at pyeron.com Thu Apr 24 22:57:09 2003 From: jason at pyeron.com (Jason Pyeron) Date: Thu, 24 Apr 2003 18:57:09 -0400 (EDT) Subject: Bug ID domain? In-Reply-To: <20030424220936.BF98FBC51@diggity.schwag.org> Message-ID: On Thu, 24 Apr 2003, Sean McAfee wrote: >I ask because I've just realized I haven't yet allowed for storage of >field default values in my custom fields schema. For a table like this: > >cf_integer >---------- >bug_id integer not null, >field_id integer not null, >value integer, >primary key (bug_id, field_id) > >...I'd like to use a special bug_id to store the default value for a >given field_id. NULL is out, unfortunately, because I need that primary key. >Would using a number like 0 or -1 be safe? Why would you need to store defaults this way? That appears to be a DATA table. And hacks are bad. IMHO: cf_integer_metadata ------------------- field_id int not null, defval int, columndesc varchar(63), primary key (filed_id) On Thu, 24 Apr 2003, Gervase Markham wrote: >Well, currently they are auto-allocated by the database, starting at 1 >and going upwards, so it's codified like that. The domain is 1 -> 2^31 >at least. I have seen several times where MySQL has started with zero [user intervention maybe?] -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron http://www.pyerotechnics.com - - Owner & Lead Pyerotechnics Development, Inc. - - +1 410 808 6646 (c) 500 West University Parkway #1S - - +1 410 467 2266 (f) Baltimore, Maryland 21210-3253 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, purge the message from your system and notify the sender immediately. Any other use of the email by you is prohibited. From gerv at mozilla.org Thu Apr 24 22:59:57 2003 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 24 Apr 2003 23:59:57 +0100 Subject: Your status report needs you! In-Reply-To: <20030424123323.A2750@sigkill.com> References: <20030423022157.A26107@sigkill.com> <20030424001754.A32364@sigkill.com> <3EA7A828.9040208@mozilla.org> <20030424024230.E32364@sigkill.com> <3EA7DC99.8080303@mozilla.org> <20030424123323.A2750@sigkill.com> Message-ID: <3EA86C6D.7030202@mozilla.org> > 4TH DRAFT is available, BTW; new URL: > http://landfill.bugzilla.org/preed/bugzilla-org/status_updates/2003-04-24.html First line: comma after "maintenance release". "a number of small bug and important security fixes", while being valid English, is a bit twisted. How about "fixes for a number of security and other bugs"? Comma after "and refine". Mismatched closing bracket after "incident". "2.14.x users aren't affected by these security vulnerabilties," - "vulnerabilities" (yes, I know), but also at least one of them does affect 2.14 IIRC - the advisory says "all previous versions of Bugzilla". "Win32 support" in 2.18 and it will probably remain a release goal." - isn't that jumping the gun on the discussion a little bit? ',' - this isn't showing up due to the mismatched quote on the opening tag. "which will update the status of all the buglinks in a page to have the correct status and tooltip." - sorry, that's poor repetition of status. Please change the first instance to "state". "needed to have perl installed" - I'd probably use a capital P in this sense, and other places in that paragraph. Gerv From etzwane at schwag.org Thu Apr 24 23:12:52 2003 From: etzwane at schwag.org (Sean McAfee) Date: Thu, 24 Apr 2003 19:12:52 -0400 Subject: Bug ID domain? In-Reply-To: <20030424224850.GA2046@mango.home> Message-ID: <20030424231252.E9FA0BC52@diggity.schwag.org> Bradley Baetz wrote: >> >...I'd like to use a special bug_id to store the default value for a given >> >field_id. NULL is out, unfortunately, because I need that primary key. >> >Would using a number like 0 or -1 be safe? >Why not store the default as a column in the table which defines all of >the fields? thats the sensible place for it. You mean, augmenting the custom_fields table like so: custom_fields ------------- field_id integer primary key, product smallint, display_index integer not null, field_name tinytext not null, field_type char not null, required bool not null, extended bool not null, selection_id integer, # new columns follow: default_integer integer, default_shortstr tinytext, default_longstr text, default_date date, default_selection_label_id integer ...where exactly one of the new default_* columns is populated for any given field, depending on its type? That strikes me as a considerably worse hack than what I proposed. Hmmm. Or did you mean, add a single extra column--called simply "default", say--that holds the defaults for all field types? It would have to be a text column, to accomodate the largest custom field type. Even a text column isn't large enough for all cases, though. The default value for a multiselection would have to be serialized in some way; to a string like "1,2,3,4", presumably. But the earlier consensus was that the number of possible selection values should be unlimited, so the serialization of a large multiselect default could exceed 64K characters. Sure, probably no one *would* create such a huge default value, but the design should allow for that possibility. Besides which, I'd find it much more elegant if data of all kinds are stored in the DB in their most compact representation, with no munging required. -- Sean McAfee -- etzwane at schwag.org From preed at sigkill.com Thu Apr 24 23:21:12 2003 From: preed at sigkill.com (J. Paul Reed) Date: Thu, 24 Apr 2003 16:21:12 -0700 Subject: Your status report needs you! In-Reply-To: <3EA86C6D.7030202@mozilla.org>; from gerv@mozilla.org on Thu, Apr 24, 2003 at 11:59:57PM +0100 References: <20030423022157.A26107@sigkill.com> <20030424001754.A32364@sigkill.com> <3EA7A828.9040208@mozilla.org> <20030424024230.E32364@sigkill.com> <3EA7DC99.8080303@mozilla.org> <20030424123323.A2750@sigkill.com> <3EA86C6D.7030202@mozilla.org> Message-ID: <20030424162112.A3978@sigkill.com> On 24 Apr 2003 at 23:59:57, Gervase Markham moved bits on my disk to say: > "Win32 support" in 2.18 and it will probably remain a release goal." - > isn't that jumping the gun on the discussion a little bit? Is it? I don't think so... it seems like a release goal everyone who's spoken up on the issue is interested in keeping. Later, Paul ------------------------------------------------------------------------ J. Paul Reed -- 0xDF8708F8 || preed at sigkill.com || web.sigkill.com/preed To hold on to sanity too tight is insane. -- Nick Falzone, Pushing Tin I use PGP; you should use PGP too... if only to piss off John Ashcroft From preed at sigkill.com Thu Apr 24 23:26:10 2003 From: preed at sigkill.com (J. Paul Reed) Date: Thu, 24 Apr 2003 16:26:10 -0700 Subject: Your status report needs you! In-Reply-To: <3EA86C6D.7030202@mozilla.org>; from gerv@mozilla.org on Thu, Apr 24, 2003 at 11:59:57PM +0100 References: <20030423022157.A26107@sigkill.com> <20030424001754.A32364@sigkill.com> <3EA7A828.9040208@mozilla.org> <20030424024230.E32364@sigkill.com> <3EA7DC99.8080303@mozilla.org> <20030424123323.A2750@sigkill.com> <3EA86C6D.7030202@mozilla.org> Message-ID: <20030424162610.B3978@sigkill.com> On 24 Apr 2003 at 23:59:57, Gervase Markham moved bits on my disk to say: > "2.14.x users aren't affected by these security vulnerabilties," - > "vulnerabilities" (yes, I know), but also at least one of them does > affect 2.14 IIRC - the advisory says "all previous versions of Bugzilla". Thanks for catching this, BTW; that was a big (and important) error on my part. Later, Paul ------------------------------------------------------------------------ J. Paul Reed -- 0xDF8708F8 || preed at sigkill.com || web.sigkill.com/preed To hold on to sanity too tight is insane. -- Nick Falzone, Pushing Tin I use PGP; you should use PGP too... if only to piss off John Ashcroft From etzwane at schwag.org Thu Apr 24 23:31:35 2003 From: etzwane at schwag.org (Sean McAfee) Date: Thu, 24 Apr 2003 19:31:35 -0400 Subject: Bug ID domain? In-Reply-To: Message-ID: <20030424233135.16E9FBC51@diggity.schwag.org> Jason Pyeron wrote: >On Thu, 24 Apr 2003, Sean McAfee wrote: >>I ask because I've just realized I haven't yet allowed for storage of >>field default values in my custom fields schema. For a table like this: >> >>cf_integer >>---------- >>bug_id integer not null, >>field_id integer not null, >>value integer, >>primary key (bug_id, field_id) >> >>...I'd like to use a special bug_id to store the default value for a >>given field_id. NULL is out, unfortunately, because I need that primary key. >>Would using a number like 0 or -1 be safe? >Why would you need to store defaults this way? That appears to be a DATA >table. And hacks are bad. > >IMHO: >cf_integer_metadata >------------------- >field_id int not null, >defval int, >columndesc varchar(63), >primary key (filed_id) Sure, that'd be the most straightforward way to handle the issue. However, the tables I've already proposed have swollen the number of tables in the Bugzilla schema by almost 50%. I'd be happier if those existing tables could be leveraged to hold default data as well, rather than introduce five new ones. (I admit that this is more of an aesthetic thing for me.) -- Sean McAfee -- etzwane at schwag.org From jason at pyeron.com Thu Apr 24 23:46:16 2003 From: jason at pyeron.com (Jason Pyeron) Date: Thu, 24 Apr 2003 19:46:16 -0400 (EDT) Subject: Bug ID domain? In-Reply-To: <20030424233135.16E9FBC51@diggity.schwag.org> Message-ID: On Thu, 24 Apr 2003, Sean McAfee wrote: >Sure, that'd be the most straightforward way to handle the issue. >However, the tables I've already proposed have swollen the number of >tables in the Bugzilla schema by almost 50%. I'd be happier if those >existing tables could be leveraged to hold default data as well, rather >than introduce five new ones. (I admit that this is more of an aesthetic >thing for me.) I personally don't worry about the number of tables AS LONG AS the names are well formatted and obvious. i.e. cf_*, cf_type*, etc. To address the 'hack' issue. The domain of the bugids is db driven. It cannot be assumed that 0 will always be unused. Further to go negative would provide future issues. This is true if the column def is changed to unsigned in the future. If you are worried about table bloat, then make use of the comment feature at creation time for tables. Jason Pyeron -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron http://www.pyerotechnics.com - - Owner & Lead Pyerotechnics Development, Inc. - - +1 410 808 6646 (c) 500 West University Parkway #1S - - +1 410 467 2266 (f) Baltimore, Maryland 21210-3253 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, purge the message from your system and notify the sender immediately. Any other use of the email by you is prohibited. From Narendra_Dukkipati at satyam.com Fri Apr 25 06:42:36 2003 From: Narendra_Dukkipati at satyam.com (Narendra_Dukkipati) Date: Fri, 25 Apr 2003 12:12:36 +0530 Subject: BugZilla Installation Document Message-ID: Hi All Can any of you please send me a detailed document on installing & configuring Bugzilla.This is pretty important and urgent.please do the needful. regards Narendra ************************************************************************** This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated. ************************************************************************** From justdave at syndicomm.com Fri Apr 25 06:50:16 2003 From: justdave at syndicomm.com (David Miller) Date: Fri, 25 Apr 2003 02:50:16 -0400 Subject: BugZilla Installation Document In-Reply-To: References: Message-ID: On 4/25/2003 12:12 PM +0530, Narendra_Dukkipati wrote: > Can any of you please send me a detailed document on installing & > configuring Bugzilla.This is pretty important and urgent.please do the > needful. http://www.bugzilla.org/documentation.html (or look in the docs directory of your Bugzilla) -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From jason at pyeron.com Fri Apr 25 06:59:36 2003 From: jason at pyeron.com (Jason Pyeron) Date: Fri, 25 Apr 2003 02:59:36 -0400 (EDT) Subject: BugZilla Installation Document In-Reply-To: Message-ID: Thanks Dave for the reply, I just canceled my message. It was along the lines of: It is urgent to RTFM or at least give a few details. On Fri, 25 Apr 2003, David Miller wrote: On 4/25/2003 12:12 PM +0530, Narendra_Dukkipati wrote: > Can any of you please send me a detailed document on installing & > configuring Bugzilla.This is pretty important and urgent.please do the > needful. http://www.bugzilla.org/documentation.html (or look in the docs directory of your Bugzilla) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron http://www.pyerotechnics.com - - Owner & Lead Pyerotechnics Development, Inc. - - +1 410 808 6646 (c) 500 West University Parkway #1S - - +1 410 467 2266 (f) Baltimore, Maryland 21210-3253 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, purge the message from your system and notify the sender immediately. Any other use of the email by you is prohibited. From bbaetz at acm.org Fri Apr 25 07:13:36 2003 From: bbaetz at acm.org (Bradley Baetz) Date: Fri, 25 Apr 2003 17:13:36 +1000 Subject: Bug ID domain? In-Reply-To: <20030424231252.E9FA0BC52@diggity.schwag.org> References: <20030424224850.GA2046@mango.home> <20030424231252.E9FA0BC52@diggity.schwag.org> Message-ID: <20030425071336.GA15993@mango.home> On Thu, Apr 24, 2003 at 07:12:52PM -0400, Sean McAfee wrote: > Bradley Baetz wrote: > >> >...I'd like to use a special bug_id to store the default value for a given > >> >field_id. NULL is out, unfortunately, because I need that primary key. > >> >Would using a number like 0 or -1 be safe? > > >Why not store the default as a column in the table which defines all of > >the fields? thats the sensible place for it. > > You mean, augmenting the custom_fields table like so: > # new columns follow: > default_integer integer, > default_shortstr tinytext, > default_longstr text, > default_date date, > default_selection_label_id integer Sort of. Here (and here _only_), you can get away with a single text value. This is because we've never going to query on this value, and all we are going to do with it is display it to the user (on enter_bug) as text anyway. > Hmmm. Or did you mean, add a single extra column--called simply "default", > say--that holds the defaults for all field types? It would have to be a > text column, to accomodate the largest custom field type. Right. > Even a text column isn't large enough for all cases, though. The default > value for a multiselection would have to be serialized in some way; > to a string like "1,2,3,4", presumably. I thought mulitselects were out of the first version? I really need to look at the next draft of the proposal - I just haven't had time recently. Hopefully this weekend. Hmm. Maybe putting it into the data table will work. You'd have to use NULL (not 0, or anything else) so that FKs will work. (Besides, NULL is the 'correct' thing here) > But the earlier consensus was > that the number of possible selection values should be unlimited, so the > serialization of a large multiselect default could exceed 64K characters. > Sure, probably no one *would* create such a huge default value, but the > design should allow for that possibility. Besides which, I'd find it > much more elegant if data of all kinds are stored in the DB in their > most compact representation, with no munging required. But it does't matter here, because theres no querying involved. It matters for the real data since that affects the indexing/comparison operations. Anyway, I've changed my mind; NULLs in the data table should be fine. Thoughts? Bradley From jason at pyeron.com Fri Apr 25 07:23:27 2003 From: jason at pyeron.com (Jason Pyeron) Date: Fri, 25 Apr 2003 03:23:27 -0400 (EDT) Subject: Bug ID domain? In-Reply-To: <20030425071336.GA15993@mango.home> Message-ID: On Fri, 25 Apr 2003, Bradley Baetz wrote: >On Thu, Apr 24, 2003 at 07:12:52PM -0400, Sean McAfee wrote: > >> Even a text column isn't large enough for all cases, though. The default >> value for a multiselection would have to be serialized in some way; >> to a string like "1,2,3,4", presumably. > >I thought mulitselects were out of the first version? I really need to >look at the next draft of the proposal - I just haven't had time >recently. Hopefully this weekend. > >Hmm. Maybe putting it into the data table will work. You'd have to use >NULL (not 0, or anything else) so that FKs will work. (Besides, NULL is >the 'correct' thing here) > Yes that is right but he has it set such that the pk is (null,val) that is why he said they could not be used and was looking for a hack. What needs to be done is: do a unique index on (null,val) and have an ID pk not null column. [sorry it is too late to remember column names and correct syntax] >> But the earlier consensus was >> that the number of possible selection values should be unlimited, so the >> serialization of a large multiselect default could exceed 64K characters. >> Sure, probably no one *would* create such a huge default value, but the >> design should allow for that possibility. Besides which, I'd find it >> much more elegant if data of all kinds are stored in the DB in their >> most compact representation, with no munging required. > >But it does't matter here, because theres no querying involved. It >matters for the real data since that affects the indexing/comparison >operations. > >Anyway, I've changed my mind; NULLs in the data table should be fine. >Thoughts? Got a penny? [Java SQL DB Engine = Evil & NoSleep] Jason Pyeron -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron http://www.pyerotechnics.com - - Owner & Lead Pyerotechnics Development, Inc. - - +1 410 808 6646 (c) 500 West University Parkway #1S - - +1 410 467 2266 (f) Baltimore, Maryland 21210-3253 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, purge the message from your system and notify the sender immediately. Any other use of the email by you is prohibited. From bbaetz at acm.org Fri Apr 25 07:41:46 2003 From: bbaetz at acm.org (Bradley Baetz) Date: Fri, 25 Apr 2003 17:41:46 +1000 Subject: Bug ID domain? In-Reply-To: References: <20030425071336.GA15993@mango.home> Message-ID: <20030425074146.GA16921@mango.home> On Fri, Apr 25, 2003 at 03:23:27AM -0400, Jason Pyeron wrote: > On Fri, 25 Apr 2003, Bradley Baetz wrote: > > >Hmm. Maybe putting it into the data table will work. You'd have to use > >NULL (not 0, or anything else) so that FKs will work. (Besides, NULL is > >the 'correct' thing here) > > > > Yes that is right but he has it set such that the pk is (null,val) that is > why he said they could not be used and was looking for a hack. Ah, right, I missed that. > > What needs to be done is: > > do a unique index on (null,val) and have an ID pk not null column. Well, you don't need a PK. Have the field id be non-null, and add unique constraint on (bug, field). Think about the 'multiple' bit - there is no PK there since (bug, field) isn't unique. Bradley From gerv at mozilla.org Fri Apr 25 07:52:13 2003 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 25 Apr 2003 08:52:13 +0100 Subject: What lies ahead In-Reply-To: <20030423002620.A25831@sigkill.com> References: <20030423002620.A25831@sigkill.com> Message-ID: <3EA8E92D.3040609@mozilla.org> J. Paul Reed wrote: > If we're going to make this a goal, then bug 84876 automatically becomes a > 2.18 goal. This bug is also necessary for full user-facing templatisation, which was a 2.16 goal. > Thus, the goals related to that, as I see them, are: > > * Easier MTA config (84876) > * Templatized email headers > * All email output templatized > > Bug 84876 *technically* only covers the first one; I haven't filed bugs on > the other ones, since I've been toying with the idea of just rolling goals > 2 and 3 into the patch for 84876... but the more I think about that, the > more I don't know if that's such a good idea. No, please don't do that! :-) IMO the best thing is to get a working patch in for the current scope of 84876 ASAP. Gerv From jason at pyeron.com Fri Apr 25 07:52:13 2003 From: jason at pyeron.com (Jason Pyeron) Date: Fri, 25 Apr 2003 03:52:13 -0400 (EDT) Subject: Bug ID domain? In-Reply-To: <20030425074146.GA16921@mango.home> Message-ID: On Fri, 25 Apr 2003, Bradley Baetz wrote: >On Fri, Apr 25, 2003 at 03:23:27AM -0400, Jason Pyeron wrote: > >Well, you don't need a PK. Have the field id be non-null, and add unique >constraint on (bug, field). > >Think about the 'multiple' bit - there is no PK there since (bug, field) >isn't unique. I just assumed that he had PK(bug,field,row) for that. I don't like not having a identity column. It just makes every thing easier. So the results are in? UNIQUE (bug,field,etc) PK(ID) -- or don't have ID Jason Pyeron -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron http://www.pyerotechnics.com - - Owner & Lead Pyerotechnics Development, Inc. - - +1 410 808 6646 (c) 500 West University Parkway #1S - - +1 410 467 2266 (f) Baltimore, Maryland 21210-3253 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, purge the message from your system and notify the sender immediately. Any other use of the email by you is prohibited. From gerv at mozilla.org Fri Apr 25 07:57:24 2003 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 25 Apr 2003 08:57:24 +0100 Subject: What lies ahead In-Reply-To: References: Message-ID: <3EA8EA64.1080307@mozilla.org> > The current "2.18 goals" taken from http://www.bugzilla.org/roadmap.html > (with completed items removed, and comments by me added): > > * Integrate inbound email into the mainline Bugzilla code (currently > it's in contrib and very messy, if it even still works). (94850) > > Matt Barnson says he's currently working on this, so it might get done > before then after all. :) I don't think it should be a stated priority. There are a few sites (e.g. Debian) which won't consider Bugzilla until this is fixed and fixed well, but most sites don't care. If it happens, great. > Templatization and rewrite of the admin pages, while a lofty goal, and > something we really should do, seems to be going really slow. I'd really > like to see this stay on the list, but we're going to have to push somebody > into doing it I think. :) I say we should push it out. I'm seriously considering this as my next big project; I did a large part of the user templatisation, so it's probably a bit easier for me than anyone else. But it probably won't be for 2.18. I'm more concerned with finishing the user-facing stuff. > * Customizable statuses and resolutions. > > This doesn't seem to be going anywhere lately, I'm leaning towards pushing > this one off. Indeed. Although isn't Cust Res much simpler than Cust Sta? Might one make it but not the other? They don't have to be lumped together. > * Out-of-the-box compatibility with Win32. > > Personally, I'd like to see this stay on the list. As much as we all hate > it, there's a lot of PHBs out there that won't let people do anything if > you can't do it on Windows... and we're so close now anyway... It's worth having a go at, certainly - but we need a developer who develops on Win32 to make sure we don't keep breaking it. > * An optional way to pick users from a list for the assignee and > QAContact fields. (52557 and/or 102942) > > I've seen a lot of activity on this front lately. I think it'll make it. Yep; I plan to do a well-architected patch for this one too. > Comments from the peanut gallery? :) Having someone review the new charting module would be nice. It took a massive effort to write it, and I'd rather it didn't sit there rotting. Even reviewing the integration points would allow me to check it in and make it much easier to fix other issues without worrying about breaking the rest of the code. (That's roughly what we did with the report rewrite anyway.) Gerv From preed at sigkill.com Fri Apr 25 07:59:27 2003 From: preed at sigkill.com (J. Paul Reed) Date: Fri, 25 Apr 2003 00:59:27 -0700 Subject: What lies ahead In-Reply-To: <3EA8E92D.3040609@mozilla.org>; from gerv@mozilla.org on Fri, Apr 25, 2003 at 08:52:13AM +0100 References: <20030423002620.A25831@sigkill.com> <3EA8E92D.3040609@mozilla.org> Message-ID: <20030425005927.B6035@sigkill.com> On 25 Apr 2003 at 08:52:13, Gervase Markham moved bits on my disk to say: > No, please don't do that! :-) IMO the best thing is to get a working > patch in for the current scope of 84876 ASAP. The problem is, the patch for the first part will most likely involve templates... and if we check in the first part without the other two, email notifications will be broken on the tip for a bit, unless we do some weird hack to not "turn on" the new code until parts 2 and 3 go in... in which case... why did we push part 1 in in such a hurry? Later, Paul ------------------------------------------------------------------------ J. Paul Reed -- 0xDF8708F8 || preed at sigkill.com || web.sigkill.com/preed To hold on to sanity too tight is insane. -- Nick Falzone, Pushing Tin I use PGP; you should use PGP too... if only to piss off John Ashcroft From bbaetz at acm.org Fri Apr 25 08:00:19 2003 From: bbaetz at acm.org (Bradley Baetz) Date: Fri, 25 Apr 2003 18:00:19 +1000 Subject: Bug ID domain? In-Reply-To: References: <20030425074146.GA16921@mango.home> Message-ID: <20030425080019.GA18443@mango.home> On Fri, Apr 25, 2003 at 03:52:13AM -0400, Jason Pyeron wrote: > I just assumed that he had PK(bug,field,row) for that. We're talking about the data table, not hte definition table - there isn't any ordering from that POV. > > I don't like not having a identity column. It just makes every thing > easier. Well, not necessarily. The main issue with UNIQUE(NULL, x) is thatyou can then have multiple values for x, eg (NULL, 1), (NULL, 1) is valid with a unique constraint, since NULL != NULL. On second throuhgs, maybe a separate 'defaults' table is better, but shared for all types. Its not like creating a table costs us or anything, and we won't be using this in a context where it would be an extra join, I think - it'll just be a different one. Bradley From bbaetz at acm.org Fri Apr 25 08:01:50 2003 From: bbaetz at acm.org (Bradley Baetz) Date: Fri, 25 Apr 2003 18:01:50 +1000 Subject: What lies ahead In-Reply-To: <3EA8EA64.1080307@mozilla.org> References: <3EA8EA64.1080307@mozilla.org> Message-ID: <20030425080150.GB18443@mango.home> On Fri, Apr 25, 2003 at 08:57:24AM +0100, Gervase Markham wrote: > Having someone review the new charting module would be nice. I've alrady done that - see my last comment in the bug. I'll need to re-review it for bit-rottage, but that shouldn't be much of an issue. Bradley From jason at pyeron.com Fri Apr 25 08:17:22 2003 From: jason at pyeron.com (Jason Pyeron) Date: Fri, 25 Apr 2003 04:17:22 -0400 (EDT) Subject: What lies ahead In-Reply-To: <3EA8EA64.1080307@mozilla.org> Message-ID: On Fri, 25 Apr 2003, Gervase Markham wrote: >> * Out-of-the-box compatibility with Win32. >> >> Personally, I'd like to see this stay on the list. As much as we all hate >> it, there's a lot of PHBs out there that won't let people do anything if >> you can't do it on Windows... and we're so close now anyway... > >It's worth having a go at, certainly - but we need a developer who >develops on Win32 to make sure we don't keep breaking it. What would be entailed in this? Are there automated tests? How frequent would it have to be checked? Jason Pyeron -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron http://www.pyerotechnics.com - - Owner & Lead Pyerotechnics Development, Inc. - - +1 410 808 6646 (c) 500 West University Parkway #1S - - +1 410 467 2266 (f) Baltimore, Maryland 21210-3253 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, purge the message from your system and notify the sender immediately. Any other use of the email by you is prohibited. From preed at sigkill.com Fri Apr 25 09:41:02 2003 From: preed at sigkill.com (J. Paul Reed) Date: Fri, 25 Apr 2003 02:41:02 -0700 Subject: What lies ahead In-Reply-To: ; from jason@pyeron.com on Fri, Apr 25, 2003 at 04:17:22AM -0400 References: <3EA8EA64.1080307@mozilla.org> Message-ID: <20030425024102.A6579@sigkill.com> On 25 Apr 2003 at 04:17:22, Jason Pyeron moved bits on my disk to say: > >It's worth having a go at, certainly - but we need a developer who > >develops on Win32 to make sure we don't keep breaking it. We had Jouni helping us with this... Jouni: are you still able to do this? > What would be entailed in this? Someone who's willing to maintain a test Win32 installation. > Are there automated tests? There are automated tests, but I don't think they're ported to Win32, and they're probably not as comprehensive as what you're thinking of as "automated tests." > How frequent would it have to be checked? Whenever a specific [needed for Win32bz] bug gets checked in, and probably also at release time. Later, Paul ------------------------------------------------------------------------ J. Paul Reed -- 0xDF8708F8 || preed at sigkill.com || web.sigkill.com/preed To hold on to sanity too tight is insane. -- Nick Falzone, Pushing Tin I use PGP; you should use PGP too... if only to piss off John Ashcroft From gerv at mozilla.org Fri Apr 25 13:17:08 2003 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 25 Apr 2003 14:17:08 +0100 Subject: What lies ahead In-Reply-To: <20030425005927.B6035@sigkill.com> References: <20030423002620.A25831@sigkill.com> <3EA8E92D.3040609@mozilla.org> <20030425005927.B6035@sigkill.com> Message-ID: <3EA93554.9070309@mozilla.org> J. Paul Reed wrote: > On 25 Apr 2003 at 08:52:13, Gervase Markham moved bits on my disk to say: > >>No, please don't do that! :-) IMO the best thing is to get a working >>patch in for the current scope of 84876 ASAP. > > The problem is, the patch for the first part will most likely involve > templates... There's no reason why this should be true. Without wanting to sound like a broken record, check my patch for a way to implement the requirements of 84876 without doing any templatisation. Gerv From preed at sigkill.com Fri Apr 25 13:38:29 2003 From: preed at sigkill.com (J. Paul Reed) Date: Fri, 25 Apr 2003 06:38:29 -0700 Subject: What lies ahead In-Reply-To: <3EA93554.9070309@mozilla.org>; from gerv@mozilla.org on Fri, Apr 25, 2003 at 02:17:08PM +0100 References: <20030423002620.A25831@sigkill.com> <3EA8E92D.3040609@mozilla.org> <20030425005927.B6035@sigkill.com> <3EA93554.9070309@mozilla.org> Message-ID: <20030425063829.D6579@sigkill.com> On 25 Apr 2003 at 14:17:08, Gervase Markham moved bits on my disk to say: > Without wanting to sound like a broken record, Then please stop reminding us. *I* hate to bring it up, but there *were* people other than me who didn't agree with your solution and/or design and who couldn't understand your obsession with Mail::Bulkmail, especially when we're not sending "bulkmail" and that module doesn't get us anything but a weird dependency. (This is not an invitation to start up that discussion again, BTW). But don't paint the picture that I'm the "lone obstacle" to your patch for 84876. > check my patch for a way to implement the requirements of 84876 without > doing any templatisation. Now that I think about it more, it should be possible to decouple the two... I think I was in the mindset of keeping them together because some of the necessary patchwork to do so had already been done in 84876; bbaetz and I had a conversation about somewhere in there, IIRC. It looks like there's already a separate bug for mail templatization: bug 100089. And before you complain about comment 7, all I meant was that whatever architecture we design for 84876 should make it easy to fix 100089. Later, Paul ------------------------------------------------------------------------ J. Paul Reed -- 0xDF8708F8 || preed at sigkill.com || web.sigkill.com/preed To hold on to sanity too tight is insane. -- Nick Falzone, Pushing Tin I use PGP; you should use PGP too... if only to piss off John Ashcroft From gerv at mozilla.org Fri Apr 25 14:49:30 2003 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 25 Apr 2003 15:49:30 +0100 Subject: What lies ahead In-Reply-To: <20030425063829.D6579@sigkill.com> References: <20030423002620.A25831@sigkill.com> <3EA8E92D.3040609@mozilla.org> <20030425005927.B6035@sigkill.com> <3EA93554.9070309@mozilla.org> <20030425063829.D6579@sigkill.com> Message-ID: <3EA94AFA.6010009@mozilla.org> J. Paul Reed wrote: > On 25 Apr 2003 at 14:17:08, Gervase Markham moved bits on my disk to say: > >>Without wanting to sound like a broken record, > > Then please stop reminding us. *I* hate to bring it up, but there *were* > people other than me who didn't agree with your solution and/or design I am not arguing that we should use my patch; I was merely using it to prove my point that the requirements of 84876 could be achieved without templatisation work. > and > who couldn't understand your obsession with Mail::Bulkmail, especially when > we're not sending "bulkmail" ...but we are sending a lot of mail, which is why the module is thus named. Discounting it because of its name, rather than its function, always seemed odd to me. But never mind. > (This is not an invitation to start up that discussion > again, BTW). But don't paint the picture that I'm the "lone obstacle" to > your patch for 84876. You place "lone obstacle" in quotes, but they are not a quote from me. Please do not falsely attribute motives or opinions to me. > It looks like there's already a separate bug for mail templatization: bug > 100089. Fab. :-) Gerv From etzwane at schwag.org Fri Apr 25 22:17:12 2003 From: etzwane at schwag.org (Sean McAfee) Date: Fri, 25 Apr 2003 18:17:12 -0400 Subject: Bug ID domain? In-Reply-To: <20030425074146.GA16921@mango.home> Message-ID: <20030425221712.E2BE8BC51@diggity.schwag.org> Bradley Baetz wrote: >On Fri, Apr 25, 2003 at 03:23:27AM -0400, Jason Pyeron wrote: >> What needs to be done is: >> do a unique index on (null,val) and have an ID pk not null column. >Well, you don't need a PK. Have the field id be non-null, and add unique >constraint on (bug, field). Like this? cf_integer ---------- bug_id integer, -- was "not null" field_id integer not null, value integer, unique key (bug_id, field_id) -- was "primary key" I hadn't known that uniqueness was available as a key (ie, something that speeds up queries), and not just as a constraint. Back when I did a lot of Oracle programming, I only ever used uniqueness as a constraint--if it also functioned as a key in that environment, I wasn't aware of it. >Think about the 'multiple' bit - there is no PK there since (bug, field) >isn't unique. That's true for Selection fields--there's one row per selected value--but not for the scalar types. -- Sean McAfee -- etzwane at schwag.org From bbaetz at acm.org Sat Apr 26 00:03:26 2003 From: bbaetz at acm.org (Bradley Baetz) Date: Sat, 26 Apr 2003 10:03:26 +1000 Subject: Bug ID domain? In-Reply-To: <20030425221712.E2BE8BC51@diggity.schwag.org> References: <20030425074146.GA16921@mango.home> <20030425221712.E2BE8BC51@diggity.schwag.org> Message-ID: <20030426000326.GA1307@mango.home> On Fri, Apr 25, 2003 at 06:17:12PM -0400, Sean McAfee wrote: > I hadn't known that uniqueness was available as a key (ie, something that > speeds up queries), and not just as a constraint. Back when I did a lot > of Oracle programming, I only ever used uniqueness as a constraint--if > it also functioned as a key in that environment, I wasn't aware of it. It uses an index to enforce it. However, note that oracle 'cheats', and will not allow (NULL, 1), (NULL, 1) as two separate entries in a uniqueindex. That doesn't amtter for what we want, though. > >Think about the 'multiple' bit - there is no PK there since (bug, field) > >isn't unique. > > That's true for Selection fields--there's one row per selected value--but > not for the scalar types. Sure, but you want multiple values for selection types. But see my later followup comments. Bradley From gerv at mozilla.org Sat Apr 26 10:11:18 2003 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 26 Apr 2003 11:11:18 +0100 Subject: Net::LDAP & Groups In-Reply-To: References: Message-ID: <3EAA5B46.9010205@mozilla.org> Bennett, Paul wrote: > I just set up Bugzilla v2.16.2 and revamped the code in CGI.pl to use > Net::LDAP to hit an OpenLDAP server. It works pretty good, but I'm having > troubles with the UserInGroup(). In particular the tweakparams & > creategroups groups although there may be other groups. Using mysql > commands, I can see that my user is in userregexp field of the groups table > and the isactive bit is set. Also my user matches the one displayed at the > bottom right. Even if I put ".*" in the User RegExp field it doesn't allow > access. But it works going to the editusers.cgi. The UserRegexp field in 2.16.2 applies only at account creation time. You need to add your users to tweakparams manually. Gerv From gerv at mozilla.org Sat Apr 26 10:13:16 2003 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 26 Apr 2003 11:13:16 +0100 Subject: How to debug Bugzilla code In-Reply-To: <16020FEDDBAF5440A59EB485AC75B2BB310C5D@exchange.pixim.com> References: <16020FEDDBAF5440A59EB485AC75B2BB310C5D@exchange.pixim.com> Message-ID: <3EAA5BBC.5070208@mozilla.org> Arvind Singh wrote: > I am a new user of Bugzilla. I am using Bugzilla 2.16.1. > It's running on RedHat Linux 7.1. > I am trying to make changes in the processmail, process_bug.cgi, > show_bug.cgi & template files. > How do I debug my changes ? print(""); ? :-) Adding extra values to $vars and printing them in the template is also good. And the Apache error log will tell you if your changes don't compile or have warnings. Gerv From gerv at mozilla.org Sat Apr 26 10:20:23 2003 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 26 Apr 2003 11:20:23 +0100 Subject: Login in user without a prompt In-Reply-To: <3E9D786F.1080500@avarachen.net> References: <3E9D786F.1080500@avarachen.net> Message-ID: <3EAA5D67.20509@mozilla.org> Vijay Avarachen wrote: > Hello, > I am trying to set-up a page which users will access directly > (without getting prompted for a login and password) and enter their > trouble ticked in there. This page will be customized to the product > they are using and they won't have to worry about the various options > that usually are presented when accessing enter_bug.cgi (these options > will be pre-select and hidden from them). How can I do this? I am not > a perl/cgi guru and goign through the mailing list archive didn't help > much. We are using version 2.14.2. My first concern is how can I get > the user to enter_bug.cg without the password prompt. Then I would try > to figure out passing hidden values to the various options specific to > the user/product. Thanks in advance. Removing the password prompt is a problem because Bugzilla assumes that everyone entering a bug will have an account. You could change the call in enter_bug.cgi from confirm_login() to quietly_check_login(), but then you'd probably end up with a reporter of "__UNKNOWN__", which would be a bit ugly. If you want hidden default values on a bug entry form, you just use Gerv From gerv at mozilla.org Sat Apr 26 10:39:35 2003 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 26 Apr 2003 11:39:35 +0100 Subject: MySQL user's Conference In-Reply-To: <20030418025959.GA2565@mango.home> References: <3E9F6240.50009@mozilla.org> <20030418025959.GA2565@mango.home> Message-ID: <3EAA61E7.1050504@mozilla.org> > *cough* votes/keywords cache *cough*. Which, btw, is where a function to > get the sorted list of keywords from a bug_id (for display) would be > very useful. We can't use a join because that won't sort it, so we could > just SELECT bug_id, get_keyword_string(bug_id), .... where > get_keyword_string just concatentates SELECT name FROM keywords WHERE > bug_id=aBugId ORDER BY UPPER(name), or something along those lines. Shouldn't the display templates be responsible for sorting them anyway? So we can use a JOIN? Gerv From gerv at mozilla.org Sat Apr 26 10:43:44 2003 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 26 Apr 2003 11:43:44 +0100 Subject: MySQL user's Conference In-Reply-To: <3E9F6240.50009@mozilla.org> References: <3E9F6240.50009@mozilla.org> Message-ID: <3EAA62E0.8020901@mozilla.org> > Perl DBI was built for speed and is pretty efficient, but you have to > know how to use it right. For speed: > > * use prepare() (doesn't work until MySQL 4.1, but you should use it > in preparation) > * use prepare() and execute() in speed-critical loops instead of do() > * select as reference, especially if columns increase > * try fetchall_arrayref to see if it's faster At first glance, this seems to contradict some advice bbaetz gave me about not using fetchall at all. What's the story there? Gerv From gerv at mozilla.org Sat Apr 26 11:30:34 2003 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 26 Apr 2003 12:30:34 +0100 Subject: More custom field revisions In-Reply-To: <3EA74B3C.4030609@bugzilla.org> References: <20030421080758.5CA5EBC51@diggity.schwag.org> <3EA3F169.60003@peshkin.net> <3EA5C582.7040007@mozilla.org> <3EA74B3C.4030609@bugzilla.org> Message-ID: <3EAA6DDA.3010901@mozilla.org> Jake wrote: > Gervase Markham wrote: >> I'd consider it pretty weird if you had the rights to see the bug but >> not the field within it. As I understand it, we seem to be trying to >> avoid ("insiders" excepted) having different bits of individual bugs >> appear and disappear. > > > There may be fringe cases where that's necessary :) > FE, the time tracking information. I'm not sure if it works that way now > or not, but I can certainly see where a person or company may wish to > have a public bugzilla but keep their resource expenditure information > secret. In this case, they can use insiders, and just put [% IF UserInInsiderGroup() %] or whatever around the timetracking display stuff. Same for any field which only requires a binary split like that. My worry is that having per-field granularity will add to the complexity without making things more useful. > Also, the second part of that bug is important: who gets to edit it. That's an orthogonal problem to custom fields IMO. Gerv From gerv at mozilla.org Sat Apr 26 12:00:46 2003 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 26 Apr 2003 13:00:46 +0100 Subject: More custom field revisions In-Reply-To: <20030421080758.5CA5EBC51@diggity.schwag.org> References: <20030421080758.5CA5EBC51@diggity.schwag.org> Message-ID: <3EAA74EE.8080407@mozilla.org> Sean McAfee wrote: > Here are some additional revisions. OK, here are my comments. Sorry for the delay :-) > Each custom field has a name, consisting of up to 255 characters. A > field's name may not contain any vertical whitespace characters > (carriage return, newline, and vertical tab), nor may it begin or end > with whitespace. There are two things we need - a name to refer to it internally, and a display name. The display name should be solely the preserve of templates (with the internal name used if none is defined) and the internal name should be suitable for use as a form field name and database table/column name. This means that, for max compatibility, it should be alphanumeric only, with no whitespace. > Each field also has a type: one of Integer, String, > Date, or Selection. The Integer, String, and Date types are > collectively referred to as "scalar" types. I still think we should have single-select (a scalar type) and multi-select. This prevents the need for "sub-types" for the Selection type. Well, I suppose other types have sub-types too... Did we decide to leave Email Address until version 2? > If the users enters no text at all (including whitespace) into a > String form element, the field will be set to the undefined value. Is this right? Surely the empty string is a better representation in this case? > A Date field describes a particular moment of time. It is represented > on Bugzilla's web interface as a single-line text form element. I don't think you should specify this explicitly. It should be possible to have a variety of representations for Date fields - i.e. you do [% INCLUDE date_field date = "10035356674" type="date-time" %] or similar and the template defines the representation. > Each Date field is flagged as belonging to one of two varieties: > date-only and date/time. A date-only Date field is represented using > the format 'YYYY-MM-DD'; a date/time Date field is represented using > the format 'YYYY-MM-DD HH24:MM:SS'. (Arbitrary whitespace may > separate the two components in the latter case.) When a user enters > text into a Date form element, it must conform to the appropriate > format, or Bugzilla will signal an error condition. I think that dates should always be displayed as above, but dates should be able to be input in any format which can be unambiguously understood by Date::Parse. Let's not enforce restrictions we don't need. > A single-selection field's value is a subset of the field's value set > of size either zero or one. It is represented on Bugzilla's web > interface as a drop-down listbox form element. A field whose value is > the empty set is represented on the Web interface by a special "unset" > string which is defined when the field is created. Again, this is a display issue that should be defined by templates, with the default if none is defined being the empty string. > A multiselection field's value is an arbitrary subset of the field's > value set. It is represented on Bugzilla's web interface as a > multiline listbox in which multiple simultaneous selections are > allowed. The listbox's vertical size is equal to the value set's size > or five, whichever is smaller. The current ones on query.cgi are 7, which seems like a nice size to me. And they are all the same size even if some have less than seven elements, which looks better. But this is a minor display issue. > Whenever a user edits a bug and changes one or more custom fields, the > changes must be logged. Are all these requirements met by the existing Bug Activity system? > On "enter_bug.cgi" and "long_list.cgi", the custom fields will be > shown just after the "Description" text box. It's not an automatic given that the custom field will be needed on enter_bug. In fact, an argument could be made for not including any of them by default. > Here is an alternate approach. Global custom fields are always > displayed. A button is to be added to the query page, to the right of > the "Product", "Component", and "Version" listboxes, labelled "Show > custom fields for these projects". If the user clicks it, the query > form is redisplayed, augmented with all custom fields in all of the > selected projects. _Any_ of the selected projects? > If no projects were selected, or if no selected > project has any custom fields, the page is simply redisplayed as it > was before. The button should never appear if there are no product-specific custom fields. Helper JS should disable the button if the selected products have no custom fields. Remember to display all possible custom fields if no products are selected. :-) The appearing/disappearing should be done using JS and CSS without a page reload if the browser supports JS, by having an onsubmit="doIt(); return false" on the button. > When custom fields are being shown, a second button is to be added > below the "Show custom fields" button, labelled "Hide custom fields". > When it is clicked, the query page is redisplayed as it was > originally, showing only custom fields in the global scope (if any). Why is this needed? They can always just ignore them. > It is an error for the user to select one or more target projects, > show the custom fields for those components, change the target > projects, and begin a search. In this case Bugzilla will redisplay > the query page with an appropriate error message at the top. It should not be an error unless the user has set search values for custom fields which apply to none of the products concerned - and even then, the message is more informational than error. > Different projects may define different custom fields with the same > name. No; this is an error. That's fine, because the display name is separated from the internal name. They could define the same display name for two fields, but any confusion caused is their fault :-) Hmm... there's a bit of info missing in my mind. Is it possible to have a custom field which is part of projects A, B and C but not D or E? > Custom fields in the > global scope (if any) are grouped together under the italicized label > "Global fields" No need for that; they should be treated like any other hard-coded field, and not singled out for special attention. > (The open versions of the latter two inequalities--ie, strictly > earlier than or strictly later than--are probably not worth including.) Agreed. > Administration > ============== > > A new CGI program for managing custom fields, cdadmin.cgi, will be > created. The program is only accessible to the Bugzilla > administrator. editcustomfields.cgi would be a name fitting with the rest of our admin CGIs. A critique of the editing UI will follow. > Editing a custom field > ---------------------- > > The only aspect of a string, integer, and date field that may be > edited (other than its name, handled by a separate Rename operation) > is its default value. And which products it belongs to? > For a new String field, the first page presented includes only a pair > of radiobuttons, labelled "Long string (multiline, up to 64K > characters)" Remind me again why we need this long string type? > Moving a field to a different position > -------------------------------------- > > This action is performed immediately. The field ordering for the > selected project (or for the global scope) is rearranged so that the > fields appear in the new order specified by the administrator. The > initial cfadmin.cgi page is redisplayed, showing the fields in their > new order. What does this ordering affect? If it's display ordering, this is the wrong place for it - such configuration belongs in templates. > [Open question: Since this is such a potentially damaging operation, > maybe it should not be available via the web interface at all. > Perhaps the administrator should be required to run, from the command > line, a special program provided for this purpose. Or perhaps deleted > field data should be retained for a time to make an undo operation > possible.] Normally, we allow people to shoot themselves in the foot if they like. :-) But perhaps you are right; this might need to be a command-line operation. > ------------------------------------------------------------------------ > > The following three tables provide definitions for all custom fields > in the Bugzilla installation. > > custom_fields > ------------- > project tinytext primary key, > field_id integer not null, > field_index integer not null > > This table defines which fields belong to which projects, and the > order in which those fields should be presented to users. The global > scope is described by the project "" (ie, the zero-length string). You should be using product_ids here, not "project" strings. And again, the field_index function is something that should be decided in templates. > custom_field_defs > ----------------- > field_id integer primary key, > field_name tinytext not null, > field_type char not null, > extended bool not null, > selection_id integer > > The field_type column is 'I' for integer fields, 'C' for string > fields, 'D' for date fields, and 'S' for selection fields. > > The extended column is always false for Integer fields. It has the > following meanings for other fields: > > Field type | extended is "true" | extended is "false" > -----------+---------------------+------------------------ > String | long string (text) | short string (tinytext) > Date | date/time | date only > Selection | multiselection | single-selection This looks like a hack to me. Even if you expose it in the UI as types and subtypes, it seems that in the database, it makes sense to have a single field_type field with seven values. > cf_selection_defs > ----------------- > selection_id integer primary key, > unset tinytext not null > > The unset column is the text which represents the "empty set" value of > single-selection fields. Again, this should be decided in UI templates. > [Open question: Should this table be split into two: > cf_selection_single and cf_selection_multi?] One seems fine. > The following six tables hold bug activity data. What's wrong with the current activity system? Gerv From bbaetz at acm.org Sat Apr 26 12:38:47 2003 From: bbaetz at acm.org (Bradley Baetz) Date: Sat, 26 Apr 2003 22:38:47 +1000 Subject: MySQL user's Conference In-Reply-To: <3EAA61E7.1050504@mozilla.org> References: <3E9F6240.50009@mozilla.org> <20030418025959.GA2565@mango.home> <3EAA61E7.1050504@mozilla.org> Message-ID: <20030426123847.GA10431@mango.home> On Sat, Apr 26, 2003 at 11:39:35AM +0100, Gervase Markham wrote: > >*cough* votes/keywords cache *cough*. Which, btw, is where a function to > >get the sorted list of keywords from a bug_id (for display) would be > >very useful. We can't use a join because that won't sort it, so we could > >just SELECT bug_id, get_keyword_string(bug_id), .... where > >get_keyword_string just concatentates SELECT name FROM keywords WHERE > >bug_id=aBugId ORDER BY UPPER(name), or something along those lines. > > Shouldn't the display templates be responsible for sorting them anyway? > So we can use a JOIN? But then you get an extra set of rows on teh other side of the join, which you don't need. Besides, its quicker to have the db sort it for you, since it can use indexes. > > Gerv Bradley From bbaetz at acm.org Sat Apr 26 12:55:35 2003 From: bbaetz at acm.org (Bradley Baetz) Date: Sat, 26 Apr 2003 22:55:35 +1000 Subject: MySQL user's Conference In-Reply-To: <3EAA62E0.8020901@mozilla.org> References: <3E9F6240.50009@mozilla.org> <3EAA62E0.8020901@mozilla.org> Message-ID: <20030426125535.GB10431@mango.home> On Sat, Apr 26, 2003 at 11:43:44AM +0100, Gervase Markham wrote: > >Perl DBI was built for speed and is pretty efficient, but you have to > >know how to use it right. For speed: > > * try fetchall_arrayref to see if it's faster > > At first glance, this seems to contradict some advice bbaetz gave me > about not using fetchall at all. What's the story there? Well, it depends what you're doing. Ideally, what we should be doing is doing the ->prepare/->execute in perl, and then passing the iterator through into the template. That avoids all the intermediate stuff-it-into-a-datastructure thing. TT doesn't support that, though, and writing a TT iterator plugin is hampered by the fact that tied stuff doesn't work with the XS stash. Plus we often have to do extra queries anyway. If all you're going to do is get the data, and pass it to a template, then fetchall is better. If you're going to process it one at a time, and templates aren't involved, then just ->fetch one by one, to avoid materialising the data.[1] If you're going to process it one by one, but then pass it to the template somehow (eg create a new perl object based on the values), then I'd guess that ->fetch is still better (since the client libraries should handle fetching data in batches anyway), but it would need timing. I tried to get Apache::DProf working on my mod_perl install earlier today, so that I can get some timings w/o the load time. It didn't seem to like Apache::Registry, though - I may have to make a handler out of the script temporarily. > > Gerv > Bradley [1] Note that in _practice_, this happens anyway - mysql grabs all the data at once to avoid tying up the tables with read locks (by default, anyway), and postgres' current client<->server protocol only supports grabbing all the data at once, although thats being fixed in CVS. I don't know if that still applies for mysql's innodb stuff, and pg is currently fixing it (as in, wire protocol changes are in CVS, but no client library updates to use the new functionality yet) From gerv at mozilla.org Sat Apr 26 13:13:03 2003 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 26 Apr 2003 14:13:03 +0100 Subject: More custom field revisions In-Reply-To: <3EAA74EE.8080407@mozilla.org> References: <20030421080758.5CA5EBC51@diggity.schwag.org> <3EAA74EE.8080407@mozilla.org> Message-ID: <3EAA85DF.7030207@mozilla.org> > A critique of the editing UI will follow. Actually, I'd just be repeating a lot of the stuff I said, so I'll leave this until the next round :-) Gerv From gerv at mozilla.org Sat Apr 26 13:29:37 2003 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 26 Apr 2003 14:29:37 +0100 Subject: [Fwd: [Templates] Version 2.09 Released] Message-ID: <3EAA89C1.8050904@mozilla.org> TT 2.09 has just been released, which has a patch from me to work around some deficiencies in GD::Graph as used by TT. Does anyone object to us bumping the required version to 2.09 at some point soon? Gerv -------- Original Message -------- Subject: [Templates] Version 2.09 Released Date: Wed, 23 Apr 2003 14:30:48 +0100 From: Andy Wardley To: templates at template-toolkit.org The latest stable version of the Template Toolkit, 2.09 has been released. Nothing has changed since 2.08e, except the version number and a few email addresses. Should be available from CPAN soon, or right now from: http://www.template-toolkit.org/download.html Enjoy! A _______________________________________________ templates mailing list templates at template-toolkit.org http://lists.template-toolkit.org/mailman/listinfo/templates From bbaetz at acm.org Sat Apr 26 14:00:54 2003 From: bbaetz at acm.org (Bradley Baetz) Date: Sun, 27 Apr 2003 00:00:54 +1000 Subject: [Fwd: [Templates] Version 2.09 Released] In-Reply-To: <3EAA89C1.8050904@mozilla.org> References: <3EAA89C1.8050904@mozilla.org> Message-ID: <20030426140054.GA10700@mango.home> On Sat, Apr 26, 2003 at 02:29:37PM +0100, Gervase Markham wrote: > TT 2.09 has just been released, which has a patch from me to work around > some deficiencies in GD::Graph as used by TT. Does anyone object to us > bumping the required version to 2.09 at some point soon? > > Gerv It doesn't work on 5.6.1 apparently. Bradley From jake at bugzilla.org Sat Apr 26 16:27:31 2003 From: jake at bugzilla.org (Jake) Date: Sat, 26 Apr 2003 12:27:31 -0400 Subject: How to debug Bugzilla code In-Reply-To: <3EAA5BBC.5070208@mozilla.org> References: <16020FEDDBAF5440A59EB485AC75B2BB310C5D@exchange.pixim.com> <3EAA5BBC.5070208@mozilla.org> Message-ID: <3EAAB373.30504@bugzilla.org> Gervase Markham wrote: > Arvind Singh wrote: > >> I am a new user of Bugzilla. I am using Bugzilla 2.16.1. >> It's running on RedHat Linux 7.1. >> I am trying to make changes in the processmail, process_bug.cgi, >> show_bug.cgi & template files. >> How do I debug my changes ? > > > print(""); ? :-) > Adding extra values to $vars and printing them in the template is also > good. And the Apache error log will tell you if your changes don't > compile or have warnings. > warn "My value is $value"; Can also be helpful... it'll output its information to the Apache error log. From list at list.dk Sun Apr 27 01:48:10 2003 From: list at list.dk (Thor List) Date: Sat, 26 Apr 2003 21:48:10 -0400 Subject: MySQL 4 and Perl problem Message-ID: Hi all, I just installed MySQL 4 and discovered to my surprise that the Perl DBD module does not run, because the new MySQL version comes with libmysqlclient.so.12 instead of libmysqlclient.so.10 and all the problems that comes with this like other so files that depend on 10 vs. 12, etc. This means that I cannot use Bugzilla anymore and I am a bit sad about this, since it is a great tool. I am hoping that others out there has encountered the same problem and have found a solution. For more information, I am running the new Redhat 9 with the new glibc and can therefore not install the old version of MySQL, since it does not come with the MySQL-shared objects for version 3 compatible with the new glibc. Please, somebody tell me that this problem is solvable... Best regards, Thor List ----------------------------------------------------------------------- Thor List Email: list at list.dk This message contains information which is confidential and/or privileged. Unless you are the addressee (or authorized to receive for the addressee), you may not use, copy or disclose to anyone the message or any information contained in the message. If you have received the message in error, please advise the sender by reply e-mail and delete the message. Thank you. From chicks at chicks.net Sun Apr 27 14:45:59 2003 From: chicks at chicks.net (Christopher Hicks) Date: Sun, 27 Apr 2003 10:45:59 -0400 (EDT) Subject: MySQL 4 and Perl problem In-Reply-To: Message-ID: On Sat, 26 Apr 2003, Thor List wrote: > I just installed MySQL 4 and discovered to my surprise that the Perl DBD > module does not run, because the new MySQL version comes with > libmysqlclient.so.12 instead of libmysqlclient.so.10 and all the > problems that comes with this like other so files that depend on 10 vs. > 12, etc. Reinstalling DBD::mysql will let it recompile against the proper libmysqlclient.so. My bugzilla is using the off-the-shelf DBD::mysql with MySQL 4.0 on RedHat 8 without any problems. -- The death of democracy is not likely to be an assassination from ambush. It will be a slow extinction from apathy, indifference, and undernourishment. -Robert Maynard Hutchins, educator (1899-1977) From caseyg at chsamerica.com Mon Apr 28 13:16:09 2003 From: caseyg at chsamerica.com (Casey Gregoire) Date: Mon, 28 Apr 2003 09:16:09 -0400 Subject: New custom fields proposal Message-ID: Does this custom fields approach have its own bug number or is it the same as the original custom fields bug number? Thanks, Casey Gregoire -----Original Message----- From: Jon Wilmoth [mailto:JWilmoth at starbucks.com] Sent: Tuesday, April 08, 2003 7:40 PM To: developers at bugzilla.org Subject: Re: New custom fields proposal Thoughts/question inline... -----Original Message----- From: Sean McAfee [mailto:etzwane at schwag.org] Sent: Friday, April 04, 2003 5:34 PM To: developers at bugzilla.org Subject: New custom fields proposal Hi, folks-- Enclosed is my proposal for new custom field functionality to be added to Bugzilla. Please read, discuss, criticize, etc., especially the "Open questions". Note that this is a requirements document, and describes only WHAT I'd like to see implemented, not HOW it is to be implemented. The "how" will be left for a future document, when we've settled on the "what". Also note that I've omitted any reference to how custom fields will be administered. This is obviously important, but I found myself getting bogged down in the details, so I decided to just go ahead and send the part I'd completed. --Sean McAfee ---------------------------------------------------------------------- Definition ========== Currently, Bugzilla offers a fixed number of named fields to describe bugs. These fields are shared across every component in the system. The proposed additional functionalty is the ability to define additional fields on a per-component basis. These additional fields are called "custom fields". I assume your talking about "component" being a broad system module (i.e. search, creation, reporting, etc.). I'd suggest you use a different term so as not to be confused with a Product component. Custom fields will be available in five major varieties: integer, float, string, date, and selection. The first four of these types are collectively referred to as "scalar" types. All scalar fields can be set to a special "undefined" value in additional to the valid values described below. Integer ------- An integer custom field contains values which are integers. Such fields must be able to store at least the range of integers which are typically represented as a signed four-byte quantity. [Open question: Should integer fields be available in signed and unsigned varieties?] Bugzilla should signal an error condition if a user attempts to store an integer outside of the allowed range into an integer field. [Open question: Should Bugzilla transparently offer large-integer semantics?] Bugzilla may emit client-side scripting code onto any pages that request custom-field input that will abort form submission if an integer field's submitted value is out of range. Float ----- A float custom fields contains values which are floating-point numbers. Such fields must be able to store at least the range of floating-point numbers which are typically represented as an eight-byte double-precision quantity. When a user enters a text string which is intended to be stored in a float field, it must match the usual pattern: * an optional leading plus sign ('+') or minus sign ('-'); * an integer part consisting only of digits; * an fractional part matching the following pattern: + a period character ('.'); + an optional sequence of digits; + an optional exponent, expressed as an 'E' or 'e' character, followed by an optional plus sign ('+') or minus sign ('-'), followed by a sequence of digits Either the integer part or the fractional part may be omitted, but not both. Bugzilla should signal an error condition if a user attempts to store a floating-point number outside of the allowed range into a float field. String ------ This type of field contains human-readable text. [Open question: Should Bugzilla reject attempts to store arbitrary binary data in a string field?] Each string field is flagged as belonging to one of two varieties: short and long. A short string field can hold a maximum of 255 characters, and may contain no vertical whitespace characters (carriage return, newline, or vertical tab). It is represented on Bugzilla's Web interface using a single-line text form element. A long string field can hold large amounts of text, possibly consisting of several lines. It is represented on Bugzilla's Web interface as a multiline textarea form element. Date ---- A date field contains either a date (ie, a specific day of a specific month in a specific year), a time of day (ie, an hour from 0-23 inclusive, and a minute and second, both from 0-59 inclusive), or both. Each date field is flagged as containing one of these three subsets of data. [Open question: Is the "time of day" subtype really necessary?] Bugzilla should signal an error condition if a user attempts to store an illegal date value in a date field. Examples: * An invalid day of the month: March 50, February 30 * An invalid date: February 29, 2001 * An invalid time: 12:66:00 Date fields are represented on Bugzilla's web interface using a pair of drop-down listbox form elements (for the month and day) and a single-line text-entry element (for the year) for the date portion of the field's value (if appropriate), and a single-line text entry widget for the time portion (if appropriate). Bugzilla should signal an error if an invalid date or time is submitted. [Open question: Is this too busy? Should a simple text-entry widget suffice for all date types?] IMHO, yes...it's too busy. If it's a date field it would be more useful to have a popup calendar (bottom of which could also include time elements). I would think a date field should have a input pattern that could vary on a field by field basis. This can be compared to java's simple date format (http://java.sun.com/j2se/1.4.1/docs/api/java/text/SimpleDateFormat.html ) class or oracle's to_date fuction that allow for a pattern (i.e. MM/dd/yyyy HH:mm:ss aa zz to define a date input valid for 04/08/2003 16:25:30 pm PDT) Selection --------- A selection field takes its value from a set of distinct string values. No string value in any selection field's set of valid values may contain vertical whitespace, contain leading or trailing whitespace, or exceed 255 characters in length. [Open question: Should there be a limit on the size of the set of valid strings? If so, should this limit be global or per-component?] The main issue here is screen real-estate which is a global issue. Having unlimited select lists can throw the html tables out of wack. I'd suggest a global limit set to the largest possible value for the UI where custom fields will be added. Each selection field comes in one of two varieties: "single-selection" and "multiselection". A single-selection field's value is a subset of the field's possible values of size either zero or one. It is represented on Bugzilla's web interface as a drop-down listbox form element. A multiselection field's value is an arbitrary subset of the field's possible values. It is represented on Bugzilla's web interface as a multiline listbox in which multiple simultaneous selections are allowed. Each selection field's set of allowed values may be specified in one of two ways. A "local" selection field's values are defined by the Bugzilla administrator, and are managed by Bugzilla itself. A "remote" selection field's values are taken from a table in a database which need not be the same database used by Bugzilla. The administrator defines the remote database in the form of a DBI connect string, a username and password with which to log in to the other database, a table name, and a column name. Bugzilla generates the set of allowed values by logging in to the remote database using the supplied username and password, and issuing the following query: While the "remote" concept is cool, I think it should receive a lower priority and perhaps even be treated as a separate release of "custom fields". There's a lot of work to do as is to manage "local" custom fields. SELECT DISTINCT source_column FROM source_table WHERE source_column IS NOT NULL; Bugzilla should apply the following modifications to each element of the result set, in the order given: * Delete all characters after and including the first vertical whitespace character, if any * Trim leading and trailing whitespace * Truncate to a maximum length of 255 characters After this, duplicate elements should be eliminated, and the remaining elements should be sorted alphabetically before the set is presented to the user. [Open question: Should other sorting criteria be supported? If so, how?] Since such queries may be expensive, Bugzilla may cache the results for up to one hour. Since any given selection field's allowed values may change over time, due to administrator action or variation in a remote data source, Bugzilla should not signal an error if "invalid" field values are found in the database. Enforcement of a selection field's valid values is to be done only on the client side. If a bug containing a selection field whose value is no longer valid is edited by the user, the invalid field's value should be presented as being the null set. It should be possible to share the definitions of selection fields among multiple Bugzilla components, such that a change to one field's data source is reflected in all other fields which share that source. [Open question: Should the field subtypes described above really be their own top-level types?] Logging ======= Whenever a custom field's value is changed, this change should be logged. Log information should include the identity of the user who made the change, the time the change took place, the field's old value, and the field's new value. Presentation ============ Custom fields are to be presented on each Bugzilla page that presents the standard Bugzilla fields. These pages include at least the following: On "show_bug.cgi" and "post_bug.cgi", the custom fields should be shown just prior to the list of attachments. On "enter_bug.cgi" and "long_list.cgi", the custom fields should be shown just after the "Description" text box. When a bug is being created or edited, custom fields are represented as per the field type descriptions above. When a bug is being shown but not edited, scalar fields and single-selection fields are represented as simple text; multiselection fields are represented using disabled multiline listboxes. The query.cgi page requires more extensive modifications. Currently query.cgi knows only about Bugzilla's standard fields. Since all components share the same set of standard fields, these fields can be displayed before the user has chosen a Product and Component at the top of the page. To add the capability to search on custom fields, a straightforward approach would be to require the user to first specify the projects and components within which to search, then display the usual query page augmented with the custom fields which exist in those components. However, this is too invasive for components which don't use custom fields, and also for queries which don't care about custom fields. Here is an alternate approach. A button is to be added to the query page, to the right of the "Product", "Component", and "Version" listboxes, labelled "Show custom fields for these components". If the user clicks it, the query form is redisplayed, augmented with all custom fields in all of the selected components. If no components were selected, or if no selected component has any custom fields, the page is simply redisplayed as it was before. The user may freely change the target components and press the "Show custom fields" button again. The query page will be redisplayed with new form elements for the most recently chosen components. When custom fields are being shown, a second button is to be added below the "Show custom fields" button, labelled "Hide custom fields". When it is clicked, the query page is redisplayed as it was originally, without any custom field elements. It is an error for the user to select one or more target components, show the custom fields for those components, change the target components, and begin a search. In this case Bugzilla should redisplay the query page with an appropriate error message at the top. Different components may define different custom fields with the same name. Therefore, custom field form elements for custom fields belonging to the same component will need to be grouped together, clearly labelled as belonging to that component. I'd like to see two levels of scoping global and by product for custom fields. Anything else is gravy. Custom string fields may be queried in the same manner as the stock fields "Comment" and "URL". That is, they may be matched against a user-supplied string using any of the following predicates: * contains all of the words/strings * contains any of the words/strings * contains the string * contains the string (exact case) * contains all of the words * contains any of the words * matches the regexp * doesn't match the regexp Custom integer and float fields may be queried against a user-supplied string (which must look like an integer or a floating-point number, respectively) using the following predicates: * is equal to * is less than * is greater than * is less than or equal to * is greater than or equal to Custom date fields may be queried using a group of selection elements representing the year/month/year and/or the hour/minute/second (as appropriate) using the following predicates: * is exactly * is at or earlier than * is at or later than (The open versions of the latter two inequalities--ie, strictly earlier than or strictly later than--are probably not worth including.) Custom single-selection selection fields may be queried against a multiline listbox containing all valid values for the field. Multiple selections within this listbox are allowed. A bug matches this query term if this field's value is equal to ANY of the user-selected values. Custom multiselection selection fields may be queried against a multiline listbox containing all valid values for the fields. Multiple selections within this listbox are allowed. A pair of radiobuttons is placed next to the listbox which present two choices: "Any" and "All". Initially, "Any" is selected. If the "Any" button is selected at the time the query is initiated, then a bug matches this query term if any of the selected values are set in this field. If the "All" button is selected instead, then a bug matches this query term if all of the selected values are set in this field. Security - Assign access to custom fields to groups. Assignment would hide fields from being displayed. Validation - Required vs. not required. In addition to the type checking described above, a required flag should be included in the definition of the field. Presentation - Error messages, Labels and references to the custom field names (i.e. contextual help pages) should allow for the displaying of a system admin controlled term. Consistency - It would be nice to have a uniform approach to field definitions (security, validation, and presentation) for both stock and custom fields alike. ---------------------------------------------------------------------- ---- To view or change your list settings, click here: ---- To view or change your list settings, click here: From arvind at pixim.com Mon Apr 28 17:17:45 2003 From: arvind at pixim.com (Arvind Singh) Date: Mon, 28 Apr 2003 10:17:45 -0700 Subject: How to debug Bugzilla code Message-ID: <16020FEDDBAF5440A59EB485AC75B2BB310CB3@exchange.pixim.com> Thanks Gerv. Arvind. > -----Original Message----- > From: Gervase Markham [mailto:gerv at mozilla.org] > Sent: Saturday, April 26, 2003 3:13 AM > To: developers at bugzilla.org > Subject: Re: How to debug Bugzilla code > > > Arvind Singh wrote: > > I am a new user of Bugzilla. I am using Bugzilla 2.16.1. > > It's running on RedHat Linux 7.1. > > I am trying to make changes in the processmail, process_bug.cgi, > > show_bug.cgi & template files. > > How do I debug my changes ? > > print(""); ? :-) > Adding extra values to $vars and printing them in the > template is also > good. And the Apache error log will tell you if your changes don't > compile or have warnings. > > Gerv > > ---- > To view or change your list settings, click here: > > From JWilmoth at starbucks.com Mon Apr 28 17:43:53 2003 From: JWilmoth at starbucks.com (Jon Wilmoth) Date: Mon, 28 Apr 2003 10:43:53 -0700 Subject: More custom field revisions Message-ID: Sean McAfee wrote: > Here are some additional revisions. > A Date field describes a particular moment of time. It is represented > on Bugzilla's web interface as a single-line text form element. I don't think you should specify this explicitly. It should be possible to have a variety of representations for Date fields - i.e. you do [% INCLUDE date_field date = "10035356674" type="date-time" %] or similar and the template defines the representation. I think this is fine for a default...just so long as the implementation doesn't prohibit the template from defining the representation. > Each Date field is flagged as belonging to one of two varieties: > date-only and date/time. A date-only Date field is represented using > the format 'YYYY-MM-DD'; a date/time Date field is represented using > the format 'YYYY-MM-DD HH24:MM:SS'. (Arbitrary whitespace may > separate the two components in the latter case.) When a user enters > text into a Date form element, it must conform to the appropriate > format, or Bugzilla will signal an error condition. I think that dates should always be displayed as above, but dates should be able to be input in any format which can be unambiguously understood by Date::Parse. Let's not enforce restrictions we don't need. Obviously there needs to be some validation to ensure the string representation can be understood by Date::Parse. I'd like to propose the following: Add additional BZ params, "dateFormat", "dateTimeFormat" that define the format for all dates input into the system. To aid users, the templates could/should display the input format near the input field. This also allows for a common rendering technique for date values. Furthermore, it aids localization. > A multiselection field's value is an arbitrary subset of the field's > value set. It is represented on Bugzilla's web interface as a > multiline listbox in which multiple simultaneous selections are > allowed. The listbox's vertical size is equal to the value set's size > or five, whichever is smaller. The current ones on query.cgi are 7, which seems like a nice size to me. And they are all the same size even if some have less than seven elements, which looks better. But this is a minor display issue. I agree that the consistency of the multi-select fields adds to the aesthetics of the tool. > Whenever a user edits a bug and changes one or more custom fields, the > changes must be logged. Are all these requirements met by the existing Bug Activity system? > On "enter_bug.cgi" and "long_list.cgi", the custom fields will be > shown just after the "Description" text box. It's not an automatic given that the custom field will be needed on enter_bug. In fact, an argument could be made for not including any of them by default. Agreed. Our user's appreciate the less is more theory. However, this could be addressed by assigning the field to a group and wrapping the display in isUserInGroup('') block. > Different projects may define different custom fields with the same > name. No; this is an error. That's fine, because the display name is separated from the internal name. They could define the same display name for two fields, but any confusion caused is their fault :-) Hmm... there's a bit of info missing in my mind. Is it possible to have a custom field which is part of projects A, B and C but not D or E? Yes! I intend to have several products (i.e. A,B,C and D), which have one group of people for accountability, share one or more custom fields (i.e. need by date). Other products (i.e. E,F?and G), with accountability belonging to another group, may not have a "need by date", but may have a common "test lab" field. > Custom fields in the > global scope (if any) are grouped together under the italicized label > "Global fields" No need for that; they should be treated like any other hard-coded field, and not singled out for special attention. Agreed for the default, this will reduce unnecessary UI complication. However, I could see the "custom field" object exposing the scope through a variable to the template so people that wanted to differentiate could. For example: [% IF custom_field.global == 'true' %] Custom Field Label [% END %] > Administration > ============== > Editing a custom field > ---------------------- > > The only aspect of a string, integer, and date field that may be > edited (other than its name, handled by a separate Rename operation) > is its default value. And which products it belongs to? > For a new String field, the first page presented includes only a pair > of radiobuttons, labelled "Long string (multiline, up to 64K > characters)" Remind me again why we need this long string type? Text Area vs. Text box fields > [Open question: Since this is such a potentially damaging operation, > maybe it should not be available via the web interface at all. > Perhaps the administrator should be required to run, from the command > line, a special program provided for this purpose. Or perhaps deleted > field data should be retained for a time to make an undo operation > possible.] Normally, we allow people to shoot themselves in the foot if they like. :-) But perhaps you are right; this might need to be a command-line operation. At the very least, it should come up in a Sanity Check as an error. From Paul_Bennett at nrgn.com Mon Apr 28 18:19:44 2003 From: Paul_Bennett at nrgn.com (Bennett, Paul) Date: Mon, 28 Apr 2003 14:19:44 -0400 Subject: Net::LDAP & Groups Message-ID: Thanks Gerv, I think I screwed up the admin user def when I installed. A re-install cured it. Thanks again, Paul -----Original Message----- From: Gervase Markham [mailto:gerv at mozilla.org] Sent: Saturday, April 26, 2003 6:11 AM To: developers at bugzilla.org Subject: Re: Net::LDAP & Groups Bennett, Paul wrote: > I just set up Bugzilla v2.16.2 and revamped the code in CGI.pl to use > Net::LDAP to hit an OpenLDAP server. It works pretty good, but I'm having > troubles with the UserInGroup(). In particular the tweakparams & > creategroups groups although there may be other groups. Using mysql > commands, I can see that my user is in userregexp field of the groups table > and the isactive bit is set. Also my user matches the one displayed at the > bottom right. Even if I put ".*" in the User RegExp field it doesn't allow > access. But it works going to the editusers.cgi. The UserRegexp field in 2.16.2 applies only at account creation time. You need to add your users to tweakparams manually. Gerv ---- To view or change your list settings, click here: From gerv at mozilla.org Mon Apr 28 19:45:58 2003 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 28 Apr 2003 20:45:58 +0100 Subject: More custom field revisions In-Reply-To: References: Message-ID: <3EAD84F6.6080305@mozilla.org> Jon Wilmoth wrote: > > I think that dates should always be displayed as above, but dates > > should be able to be input in any format which can be unambiguously > > understood by Date::Parse. Let's not enforce restrictions we don't > > need. > > Obviously there needs to be some validation to ensure the string > representation can be understood by Date::Parse. Er... Date::Parse would attempt to understand the string, and we'd throw an error if it failed, just like we do for invalid input of any other sort. > I'd like to propose > the following: > > Add additional BZ params, "dateFormat", "dateTimeFormat" that define > the format for all dates input into the system. Why restrict users to one date format? >> Whenever a user edits a bug and changes one or more custom fields, >> the changes must be logged. > > > > Are all these requirements met by the existing Bug Activity system? > >> On "enter_bug.cgi" and "long_list.cgi", the custom fields will be > >> shown just after the "Description" text box. > > > > It's not an automatic given that the custom field will be needed on > > enter_bug. In fact, an argument could be made for not including any > > of them by default. > > Agreed. Our user's appreciate the less is more theory. However, > this could be addressed by assigning the field to a group and > wrapping the display in isUserInGroup('') block. As I've said elsewhere, I am not convinced that we need a mechanism any more complex than 'insiders' for restricting bug data on a per-field basis. Fear unnecessary complexity. :-) But, even if we accept the premise, how does it solve the issue I raise? My point was that we should not have any mechanism for displaying custom fields on the bug entry page. Admins could add them to the templates by hand if they want them (after enter_bug and process_bug unite.) >> Different projects may define different custom fields with the same >> name. > > > No; this is an error. That's fine, because the display name is > separated from the internal name. They could define the same display > name for two fields, but any confusion caused is their fault :-) > > Hmm... there's a bit of info missing in my mind. Is it possible to > have a custom field which is part of projects A, B and C but not D or > E? > > Yes! I intend to have several products (i.e. A,B,C and D), which > have one group of people for accountability, share one or more custom > fields (i.e. need by date). Other products (i.e. E,F and G), with > accountability belonging to another group, may not have a "need by > date", but may have a common "test lab" field. Right, fine. But then it should definitely be an error to have two custom fields with the same internal name. >> Editing a custom field ---------------------- >> >> The only aspect of a string, integer, and date field that may be >> edited (other than its name, handled by a separate Rename >> operation) is its default value. > > And which products it belongs to? :-) >> For a new String field, the first page presented includes only a >> pair of radiobuttons, labelled "Long string (multiline, up to 64K >> characters)" > > Remind me again why we need this long string type? > > Text Area vs. Text box fields Remind me again why we need fields which are textareas, but which aren't comments? I can't think of a use for them. Gerv From Doug at Royer.com Mon Apr 28 19:59:46 2003 From: Doug at Royer.com (Doug Royer) Date: Mon, 28 Apr 2003 13:59:46 -0600 Subject: After 2.16.3 upgrate - can not add new users. Message-ID: <3EAD8832.7040904@Royer.com> I upgraded from 2.16.2 to 2.16.3 and everything seemed to work, until I tried to add a new user. Not being a perl expert I just do not see anything obvious when looking at gobals.pl or createaccount.cgi . The apache logs show: Uncaught exception from user code: Quantifier follows nothing before HERE mark in regex m/* << HERE @*/ at globals.pl line 691. main::InsertNewUser('username at inet-consulting.com', 'User Name') called at /home/consulting/public_html/bugzilla/createaccount.cgi line 79 ==> /var/log/httpd/INET-Consulting.com-error_log <== Uncaught exception from user code: Quantifier follows nothing before HERE mark in regex m/* << HERE @*/ at globals.pl line 691. main::InsertNewUser('username at inet-consulting.com', 'User Name') called at /home/consulting/public_html/bugzilla/createaccount.cgi line 79 -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug at Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards From preed at sigkill.com Mon Apr 28 20:14:27 2003 From: preed at sigkill.com (J. Paul Reed) Date: Mon, 28 Apr 2003 13:14:27 -0700 Subject: After 2.16.3 upgrate - can not add new users. In-Reply-To: <3EAD8832.7040904@Royer.com>; from Doug@Royer.com on Mon, Apr 28, 2003 at 01:59:46PM -0600 References: <3EAD8832.7040904@Royer.com> Message-ID: <20030428131427.B606@sigkill.com> On 28 Apr 2003 at 13:59:46, Doug Royer moved bits on my disk to say: > I upgraded from 2.16.2 to 2.16.3 and everything seemed to work, until I > tried to add a new user. Not being a perl expert I just do not see > anything obvious when looking at gobals.pl or createaccount.cgi . Doug: I'm investigating this right now... but would you please file a bug at bmo (make sure the product is Bugzilla, component should be... User accounts) so we can track this? Thanks! Later, Paul ------------------------------------------------------------------------ J. Paul Reed -- 0xDF8708F8 || preed at sigkill.com || web.sigkill.com/preed To hold on to sanity too tight is insane. -- Nick Falzone, Pushing Tin I use PGP; you should use PGP too... if only to piss off John Ashcroft From etzwane at schwag.org Mon Apr 28 21:05:37 2003 From: etzwane at schwag.org (Sean McAfee) Date: Mon, 28 Apr 2003 17:05:37 -0400 Subject: More custom field revisions In-Reply-To: <3EAA74EE.8080407@mozilla.org> Message-ID: <20030428210538.04E38BCAE@diggity.schwag.org> First, a quick note to let everyone know where I'm coming from: Our current incident-tracking system is administered by someone in Human Resources--ie, a non-programmer. Ideally I'd like for Bugzilla administration to be turned over to the same person after our migration. Therefore, one of my aims (which I haven't stated directly before now) has been to make custom field administration as simple as possible. Some groups within my company have expressed an interest in having me do more advanced work, like auto-populating certain form elements based on a query against a local database, but IMHO, everyday administrative tasks--like renaming or rearranging fields--shouldn't require a grounding in the Template Toolkit to achieve. Gervase Markham wrote: >> Each custom field has a name, consisting of up to 255 characters. A >> field's name may not contain any vertical whitespace characters >> (carriage return, newline, and vertical tab), nor may it begin or end >> with whitespace. >There are two things we need - a name to refer to it internally, and a >display name. The display name should be solely the preserve of >templates (with the internal name used if none is defined) and the >internal name should be suitable for use as a form field name and >database table/column name. This means that, for max compatibility, it >should be alphanumeric only, with no whitespace. My design doesn't call for any database entities (tables or columns) to share names with fields, so that reason's moot. I hadn't given any thought yet to how custom field form elements should be named, but surely it's straightforward to name them with either the corresponding field's name or its numeric ID, right? I discuss the template issue a bit later in this message. >> Each field also has a type: one of Integer, String, >> Date, or Selection. The Integer, String, and Date types are >> collectively referred to as "scalar" types. >I still think we should have single-select (a scalar type) and >multi-select. This prevents the need for "sub-types" for the Selection type. > >Well, I suppose other types have sub-types too... It can be argued either way. I had them unified because they're administered similarly, and are represented similarly in the database. >Did we decide to leave Email Address until version 2? It was only mentioned once, briefly, that I recall. Would this be a string-like field that is checked for RFC822 validity when submitted, or one which offers a choice of all known users? >> If the users enters no text at all (including whitespace) into a >> String form element, the field will be set to the undefined value. >Is this right? Surely the empty string is a better representation in >this case? I wasn't making a statement on representations; I meant that the field would be conceptually undefined, from the user's POV. >> A Date field describes a particular moment of time. It is represented >> on Bugzilla's web interface as a single-line text form element. >I don't think you should specify this explicitly. It should be possible >to have a variety of representations for Date fields - i.e. you do >[% INCLUDE date_field date = "10035356674" type="date-time" %] >or similar and the template defines the representation. Sure, template-twiddling should be possible, but I think I've described a reasonable default. >> Each Date field is flagged as belonging to one of two varieties: >> date-only and date/time. A date-only Date field is represented using >> the format 'YYYY-MM-DD'; a date/time Date field is represented using >> the format 'YYYY-MM-DD HH24:MM:SS'. (Arbitrary whitespace may >> separate the two components in the latter case.) When a user enters >> text into a Date form element, it must conform to the appropriate >> format, or Bugzilla will signal an error condition. >I think that dates should always be displayed as above, but dates should >be able to be input in any format which can be unambiguously understood >by Date::Parse. Let's not enforce restrictions we don't need. That's reasonable. >> A multiselection field's value is an arbitrary subset of the field's >> value set. It is represented on Bugzilla's web interface as a >> multiline listbox in which multiple simultaneous selections are >> allowed. The listbox's vertical size is equal to the value set's size >> or five, whichever is smaller. >The current ones on query.cgi are 7, which seems like a nice size to me. > And they are all the same size even if some have less than seven >elements, which looks better. But this is a minor display issue. 7 is fine with me. >> Whenever a user edits a bug and changes one or more custom fields, the >> changes must be logged. > >Are all these requirements met by the existing Bug Activity system? I hadn't considered the existing system, since I've been attempting to keep the custom field implementation as orthogonal as possible to the core. Are you suggesting that the existing activity system could be leveraged to hold custom field activity data? >> On "enter_bug.cgi" and "long_list.cgi", the custom fields will be >> shown just after the "Description" text box. >It's not an automatic given that the custom field will be needed on >enter_bug. In fact, an argument could be made for not including any of >them by default. This seems a bit counterintuitive to me. What is the argument for not including any of them? >> Here is an alternate approach. Global custom fields are always >> displayed. A button is to be added to the query page, to the right of >> the "Product", "Component", and "Version" listboxes, labelled "Show >> custom fields for these projects". If the user clicks it, the query >> form is redisplayed, augmented with all custom fields in all of the >> selected projects. >_Any_ of the selected projects? Er, no. All of them. >> If no projects were selected, or if no selected >> project has any custom fields, the page is simply redisplayed as it >> was before. >The button should never appear if there are no product-specific custom >fields. Helper JS should disable the button if the selected products >have no custom fields. OK, makes sense. >Remember to display all possible custom fields if >no products are selected. :-) Why? >The appearing/disappearing should be done using JS and CSS without a >page reload if the browser supports JS, by having an onsubmit="doIt(); >return false" on the button. >> When custom fields are being shown, a second button is to be added >> below the "Show custom fields" button, labelled "Hide custom fields". >> When it is clicked, the query page is redisplayed as it was >> originally, showing only custom fields in the global scope (if any). >Why is this needed? They can always just ignore them. Because there may be a lot of fields, and they may be distracting. >> It is an error for the user to select one or more target projects, >> show the custom fields for those components, change the target >> projects, and begin a search. In this case Bugzilla will redisplay >> the query page with an appropriate error message at the top. >It should not be an error unless the user has set search values for >custom fields which apply to none of the products concerned - and even >then, the message is more informational than error. OK. >> Different projects may define different custom fields with the same >> name. > >No; this is an error. That's fine, because the display name is separated >from the internal name. They could define the same display name for two >fields, but any confusion caused is their fault :-) > >Hmm... there's a bit of info missing in my mind. Is it possible to have >a custom field which is part of projects A, B and C but not D or E? Definitely not, at least according to my proposal. We seem to have stumbled onto a fundamental difference in our two conceptions of how custom fields should work. In my view, each product *contains* zero or more custom fields, which are not shared with any other product. There's no concept of "hard linking" between products. It may be that two different products both want a date field called (say) "Date Received", and they can have them, just as two distinct fields. >> Administration >> ============== >> >> A new CGI program for managing custom fields, cdadmin.cgi, will be >> created. The program is only accessible to the Bugzilla >> administrator. >editcustomfields.cgi would be a name fitting with the rest of our admin >CGIs. OK. >A critique of the editing UI will follow. > >> Editing a custom field >> ---------------------- >> The only aspect of a string, integer, and date field that may be >> edited (other than its name, handled by a separate Rename operation) >> is its default value. >And which products it belongs to? Again, my custom field concept calls for a field to belong to exactly one parent product. Since creating scalar fields is so trivial, it's not necessary to provide an interface to copy or move them between products. >> For a new String field, the first page presented includes only a pair >> of radiobuttons, labelled "Long string (multiline, up to 64K >> characters)" >Remind me again why we need this long string type? First, to provide two different form elements, single-line and multiline. Second, because I can easily imagine needing to enter a detailed report of some kind that could run over 255 characters. I occasionally do so with my company's current issue-tracking system. >> Moving a field to a different position >> -------------------------------------- >> This action is performed immediately. The field ordering for the >> selected project (or for the global scope) is rearranged so that the >> fields appear in the new order specified by the administrator. The >> initial cfadmin.cgi page is redisplayed, showing the fields in their >> new order. >What does this ordering affect? If it's display ordering, this is the >wrong place for it - such configuration belongs in templates. Templates are static; field ordering is dynamic. I can't think of any way of putting field ordering into a template that isn't clearly the Wrong Thing. I'm still a newbie with the Template Toolkit, but this is the only way I can think of to do this: [% IF product == 'Product Foo'; ordering = [ 'Foo Field One', 'Foo Field Two', 'Foo Field Three' ]; ELSIF product == 'Product Bar'; ordering = [ 'Bar Field One', 'Bar Field Two' ]; ELSIF ...; ...; # previous two lines repeated N times END %] [% FOREACH field = ordering %] ( generate HTML for field ) [% END %] Not only does this require the administrator to regularly edit templates-- which, as I said, I'm trying to avoid--but it unnecessarily duplicates information from the database and creates the potential for typos. >> custom_fields >> ------------- >> project tinytext primary key, >> field_id integer not null, >> field_index integer not null >You should be using product_ids here, not "project" strings. Yeah, I changed that in the latest revision. I was unconsciously using our existing system's lingo ("project" instead of "product"). >> custom_field_defs >> ----------------- >> The field_type column is 'I' for integer fields, 'C' for string >> fields, 'D' for date fields, and 'S' for selection fields. >> >> Field type | extended is "true" | extended is "false" >> -----------+---------------------+------------------------ >> String | long string (text) | short string (tinytext) >> Date | date/time | date only >> Selection | multiselection | single-selection >This looks like a hack to me. Even if you expose it in the UI as types >and subtypes, it seems that in the database, it makes sense to have a >single field_type field with seven values. Yeah, maybe so. A MySQL enum would be good here, but I seem to recall reading somewhere that developers are supposed to avoid MySQL-specific features to make it easier to port Bugzilla to other databases in the future. Is this right? >> cf_selection_defs >> ----------------- >> selection_id integer primary key, >> unset tinytext not null >> >> The unset column is the text which represents the "empty set" value of >> single-selection fields. >Again, this should be decided in UI templates. The idea of putting dynamic data in a static template is one which leaves me scratching my head in puzzlement. I honestly can't figure out why this is a good thing. -- Sean McAfee -- etzwane at schwag.org From gerv at mozilla.org Mon Apr 28 21:41:22 2003 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 28 Apr 2003 22:41:22 +0100 Subject: More custom field revisions In-Reply-To: <20030428210538.04E38BCAE@diggity.schwag.org> References: <20030428210538.04E38BCAE@diggity.schwag.org> Message-ID: <3EADA002.9090401@mozilla.org> Sean McAfee wrote: > Our current incident-tracking system is administered by someone in > Human Resources--ie, a non-programmer. Wow. What do Human Resources have to do with incident tracking? > Ideally I'd like for Bugzilla > administration to be turned over to the same person after our migration. > Therefore, one of my aims (which I haven't stated directly before now) > has been to make custom field administration as simple as possible. > Some groups within my company have expressed an interest in having me > do more advanced work, like auto-populating certain form elements based > on a query against a local database, but IMHO, everyday administrative > tasks--like renaming or rearranging fields--shouldn't require a grounding > in the Template Toolkit to achieve. One of the reasons we chose Template Toolkit is that the template language is reasonably easy to learn and edit. Also, how is rearranging the UI of your bug system an everyday administrative task? :-) If by renaming fields you mean changing the UI label on them, then again that shouldn't happen very often, but also it should merely be changing the relevant text string in a template. Even if it's surrounded by incomprehensible gibberish, I think most people could manage that. And, if they can't, you could write some scripts to help them out. > My design doesn't call for any database entities (tables or columns) > to share names with fields, so that reason's moot. I hadn't given any > thought yet to how custom field form elements should be named, but surely > it's straightforward to name them with either the corresponding field's > name or its numeric ID, right? They can't be named with the name if the name contains spaces. And naming them with a numeric ID is ugly, opaque, and inconsistent with the other fields. All of our fields have well-known alphabetic identifiers (bug_status, qa_contact, bug_file_loc) which are used to refer to that field through the code and in forms. The custom fields should not be an exception to this rule. >>Did we decide to leave Email Address until version 2? > > It was only mentioned once, briefly, that I recall. Would this be a > string-like field that is checked for RFC822 validity when submitted, > or one which offers a choice of all known users? It would be a string-like field which is checked for being a valid user email address (in the same way as e.g. QA Contact is), and who is emailed (according to preference settings) when there are any changes to the bug. But feel free to leave this until version 2. >>Are all these requirements met by the existing Bug Activity system? > > I hadn't considered the existing system, since I've been attempting to keep > the custom field implementation as orthogonal as possible to the core. Are > you suggesting that the existing activity system could be leveraged to hold > custom field activity data? I would be surprised if any other course of action was considered! :-) If I ask for bug activity in the UI, I want it all. The user doesn't care how particular fields are implemented. And if I'm implementing the bug activity page, I don't want to have to query two sets of tables and merge the data. Have a look at the existing bug activity system; it may require a small amount of enhancement to meet your needs. Don't be afraid to not reinvent the wheel :-) >>It's not an automatic given that the custom field will be needed on >>enter_bug. In fact, an argument could be made for not including any of >>them by default. > > This seems a bit counterintuitive to me. What is the argument for not > including any of them? Our current enter_bug page (the normal one, not format=guided) doesn't include several of the more advanced fields, on the basis that bug entry should be a reasonably low barrier-to-entry process. In addition, we have "bug entry templates" (see the manual) which is a way of asking for structured information to be formatted into the comment. This is, in my view, all you need to enter a basic bug report. Optionally, we could make it possible to add UI for individual custom fields to the entry templates by hand, but I don't think that displaying all of them by default is the right way to go. (In the long term, the bug entry and bug editing processes will be unified, and then you'll have total freedom about what fields to include.) >>>Here is an alternate approach. Global custom fields are always >>>displayed. A button is to be added to the query page, to the right of >>>the "Product", "Component", and "Version" listboxes, labelled "Show >>>custom fields for these projects". If the user clicks it, the query >>>form is redisplayed, augmented with all custom fields in all of the >>>selected projects. > >>_Any_ of the selected projects? > > Er, no. All of them. So if you select products A, B, and C, and custom field Q is only available in Products A and B, it doesn't appear? >>Remember to display all possible custom fields if >>no products are selected. :-) > > Why? Because no products being selected means you are searching all products. But this is the same discussion as the one above. >>>When custom fields are being shown, a second button is to be added >>>below the "Show custom fields" button, labelled "Hide custom fields". >>>When it is clicked, the query page is redisplayed as it was >>>originally, showing only custom fields in the global scope (if any). >> >>Why is this needed? They can always just ignore them. > > Because there may be a lot of fields, and they may be distracting. Well, the user pressed the button to display them in the first place! And they can always reload the page, or select different products and re-show, if it really bugs them. >>Hmm... there's a bit of info missing in my mind. Is it possible to have >>a custom field which is part of projects A, B and C but not D or E? > > Definitely not, at least according to my proposal. We seem to have stumbled > onto a fundamental difference in our two conceptions of how custom fields > should work. In my view, each product *contains* zero or more custom > fields, which are not shared with any other product. There's no concept > of "hard linking" between products. It may be that two different products > both want a date field called (say) "Date Received", and they can have them, > just as two distinct fields. I see what you are saying. But this doesn't fit with the current model, where if two products have a field Foo, it's the same field (admittedly, all our fields are global, but the point remains.) And, it makes querying much more of a pain. Imagine I had five products, four of which were software and one was hardware. The software ones all had a custom field for a particular purpose - frobinage level, or something. In your scheme, you would have to create this custom field four times, and the search page would have four different widgets for it if you selected products A, B, C and D, because fields are not shared. A better model, in my view, is allowing a custom field to belong to any number of products between 1 and N, where an N-product field is a global one. This makes the querying much more intuitive, because you can select A, B, C and D products, and get a single widget for querying them all for frobinage level. >>>For a new String field, the first page presented includes only a pair >>>of radiobuttons, labelled "Long string (multiline, up to 64K >>>characters)" > >>Remind me again why we need this long string type? > > > First, to provide two different form elements, single-line and multiline. Rephrase: why do we need multiline custom fields? (I have a sense of deja vu asking this question.) > Second, because I can easily imagine needing to enter a detailed report of > some kind that could run over 255 characters. I occasionally do so with my > company's current issue-tracking system. Into a custom field, as opposed to into a comment or a new bug? >>What does this ordering affect? If it's display ordering, this is the >>wrong place for it - such configuration belongs in templates. > > Templates are static; field ordering is dynamic. Related question: Do you need fine control over relative field positioning? Take our current bug UI - does it really matter if Priority is above or below Severity, as long as it's consistent from product to product? > I can't think of any > way of putting field ordering into a template that isn't clearly the > Wrong Thing. Discussing this issue will probably make more sense after we've resolved the products-sharing-fields issue. > Yeah, maybe so. A MySQL enum would be good here, but I seem to recall > reading somewhere that developers are supposed to avoid MySQL-specific > features to make it easier to port Bugzilla to other databases in the > future. Is this right? Indeed :-) Gerv From chicks at chicks.net Mon Apr 28 23:54:41 2003 From: chicks at chicks.net (Christopher Hicks) Date: Mon, 28 Apr 2003 19:54:41 -0400 (EDT) Subject: More custom field revisions In-Reply-To: <3EADA002.9090401@mozilla.org> Message-ID: On Mon, 28 Apr 2003, Gervase Markham wrote: > > First, to provide two different form elements, single-line and multiline. > > Rephrase: why do we need multiline custom fields? (I have a sense of > deja vu asking this question.) I think so. We have a client tracking bugs in a non-bugzilla system and one of their 'critical needs' is to have a few free form overview fields. The question "Why couldn't you just put those things in the comments since you're not putting that information into reports?" hasn't gotten me anywhere. > > Second, because I can easily imagine needing to enter a detailed report of > > some kind that could run over 255 characters. I occasionally do so with my > > company's current issue-tracking system. > > Into a custom field, as opposed to into a comment or a new bug? As with the aforementioned client, rationally or otherwise people want to give certain chunks of text 'extraspecial emphasis'. Being able to add titles to comments might help this for some. > Related question: Do you need fine control over relative field > positioning? Take our current bug UI - does it really matter if Priority > is above or below Severity, as long as it's consistent from product to > product? Yes. And being able to store this information in the database instead of the templates to help automation seems like a good idea. > > I can't think of any > > way of putting field ordering into a template that isn't clearly the > > Wrong Thing. > > Discussing this issue will probably make more sense after we've resolved > the products-sharing-fields issue. The choices seem to me: - deal with occasionally having certain fields duplicated in the custom fields system - deal with an extra table to relate custom fields to products The first choice might not be so bad if there was some way to manage the duplicates as if they weren't stored that way, but what's so wrong with the second choice? -- The death of democracy is not likely to be an assassination from ambush. It will be a slow extinction from apathy, indifference, and undernourishment. -Robert Maynard Hutchins, educator (1899-1977) From etzwane at schwag.org Tue Apr 29 00:48:02 2003 From: etzwane at schwag.org (Sean McAfee) Date: Mon, 28 Apr 2003 20:48:02 -0400 Subject: More custom field revisions In-Reply-To: <3EADA002.9090401@mozilla.org> Message-ID: <20030429004802.78330BCAE@diggity.schwag.org> Gervase Markham wrote: >Sean McAfee wrote: >> Our current incident-tracking system is administered by someone in >> Human Resources--ie, a non-programmer. >Wow. What do Human Resources have to do with incident tracking? They also handle various administrative tasks. >> Ideally I'd like for Bugzilla >> administration to be turned over to the same person after our migration. >> Therefore, one of my aims (which I haven't stated directly before now) >> has been to make custom field administration as simple as possible. >> Some groups within my company have expressed an interest in having me >> do more advanced work, like auto-populating certain form elements based >> on a query against a local database, but IMHO, everyday administrative >> tasks--like renaming or rearranging fields--shouldn't require a grounding >> in the Template Toolkit to achieve. >One of the reasons we chose Template Toolkit is that the template >language is reasonably easy to learn and edit. It was easy for me to pick up, but I was a programmer to start with. >Also, how is rearranging the UI of your bug system an everyday >administrative task? :-) Well, maybe not everyDAY, but I can easily imagine a request like "It turns out we're using Field Z a lot more than we originally thought; please move it up above Field C" coming up. >> I hadn't given any >> thought yet to how custom field form elements should be named, but surely >> it's straightforward to name them with either the corresponding field's >> name or its numeric ID, right? >They can't be named with the name if the name contains spaces. Why not? ...OK, I just checked the HTML spec and found that CDATA attributes get twiddled a bit: ---BEGIN QUITE--- User agents should interpret attribute values as follows: * Replace character entities with characters, * Ignore line feeds, * Replace each carriage return or tab with a single space. User agents may ignore leading and trailing white space in CDATA attribute values (e.g., " myval " may be interpreted as "myval"). ---END QUOTE--- I had already disallowed carriage returns, line feeds, and leading and trailing whitespace. The tab conversion is a problem, but it can be solved by the reasonable step of disallowing tab characters in field names. >And >naming them with a numeric ID is ugly, opaque, and inconsistent with the >other fields. Ugly and opaque, perhaps. I wasn't so worried about inconsistency, since I had envisioned custom fields as a different kind of beast than the standard fields. >All of our fields have well-known alphabetic identifiers (bug_status, >qa_contact, bug_file_loc) which are used to refer to that field through >the code and in forms. The custom fields should not be an exception to >this rule. I'm not so concerned with breaking this rule, since custom fields are by their very nature site-specific and nonstandard. >>>It's not an automatic given that the custom field will be needed on >>>enter_bug. In fact, an argument could be made for not including any of >>>them by default. >> This seems a bit counterintuitive to me. What is the argument for not >> including any of them? >Our current enter_bug page (the normal one, not format=guided) doesn't >include several of the more advanced fields, on the basis that bug entry >should be a reasonably low barrier-to-entry process. That's probably true for most Bugzilla installations, but the one I intend to set up here will be strictly internal to the company and used only by people who are very familiar with the products they'll be using. Perhaps a sitewide parameter always_show_all_custom_fields or somesuch? >>>Remember to display all possible custom fields if >>>no products are selected. :-) >> Why? >Because no products being selected means you are searching all products. >But this is the same discussion as the one above. It had never occurred to me that one might want to search all products at once. A product represents one particular class of incidents, which doesn't necessarily have anything in common with any other class of incidents, right? (Except, necessarily, the fixed, global fields.) >> We seem to have stumbled >> onto a fundamental difference in our two conceptions of how custom fields >> should work. In my view, each product *contains* zero or more custom >> fields, which are not shared with any other product. There's no concept >> of "hard linking" between products. It may be that two different products >> both want a date field called (say) "Date Received", and they can have them, >> just as two distinct fields. >I see what you are saying. But this doesn't fit with the current model, >where if two products have a field Foo, it's the same field (admittedly, >all our fields are global, but the point remains.) >And, it makes querying much more of a pain. Imagine I had five products, >four of which were software and one was hardware. The software ones all >had a custom field for a particular purpose - frobinage level, or >something. In your scheme, you would have to create this custom field >four times, and the search page would have four different widgets for it >if you selected products A, B, C and D, because fields are not shared. >A better model, in my view, is allowing a custom field to belong to any >number of products between 1 and N, where an N-product field is a global >one. This makes the querying much more intuitive, because you can select >A, B, C and D products, and get a single widget for querying them all >for frobinage level. Imagine this scenario. A company is ready to bring its new Bugzilla installation on-line. Some group has come up with a list of ten products (call them "A" through "J") each of which will require ten custom fields ("A1" through "A10", "B1" through "B10", etc). If custom fields are not shared, the administrator simply creates the required products, then creates the fields within those products, working down the list he was given. If custom fields ARE shared, the administrator must search the entire list of fields for common purpose. For example, the set of fields { A1, B2, F7, G3 } might all logically refer to the same thing, and so be represented by a single custom field. Other such sets might be { A10, B10, ..., G10 }, { E4, G5 }, etc. Hopefully they were assigned the same or similar names to start with, but maybe not. Creating a single additional product with its own custom fields would require an intimate knowledge of every custom field in every product, so that the new custom fields can be merged with the existing set. Also, perhaps "frobinage level" means different things in the context of products Foo and Bar. If fields are shared, and names must be unique across the entire Bugzilla installation, one of them must be renamed. >Rephrase: why do we need multiline custom fields? (I have a sense of >deja vu asking this question.) Imposing a limit of one line on custom string data seems quite arbitrary to me. >Related question: Do you need fine control over relative field >positioning? Sure. More important fields should show up before less important ones. ...By the way, I hope I'm not coming across like some kind of know-it-all. My expectations for how custom fields should work is doubtlessly heavily influenced by my experience with my company's current solution (Team Track), which isn't really that bad, except for the speed. (And the price...and the closed source...and the convoluted schema...everything except the user interface, really.) I'm hoping to offer the users here as seamless a transition as possible, when it happens, but I'll try to keep an open mind about adapting to more traditional Bugzilla ways of doing things. -- Sean McAfee -- etzwane at schwag.org From chicks at chicks.net Tue Apr 29 13:53:15 2003 From: chicks at chicks.net (Christopher Hicks) Date: Tue, 29 Apr 2003 09:53:15 -0400 (EDT) Subject: More custom field revisions In-Reply-To: <20030429004802.78330BCAE@diggity.schwag.org> Message-ID: On Mon, 28 Apr 2003, Sean McAfee wrote: > Imagine this scenario. A company is ready to bring its new Bugzilla > installation on-line. Some group has come up with a list of ten products > (call them "A" through "J") each of which will require ten custom fields > ("A1" through "A10", "B1" through "B10", etc). Imagine your 10 products where half of the fields are needed in common between them all. Then 40 entries would simply be boring reentry of information already available. Imagine the same 10 products where (shockingly) all 10 fields are shared across all 10 products. 9 out of 10 times you go through the form you're reentering the same information over and over again. That sounds very dull and error prone to me. > If custom fields are not shared, the administrator simply creates the > required products, then creates the fields within those products, > working down the list he was given. Or working down a common list over and over and over again. > If custom fields ARE shared, the administrator must search the entire list > of fields for common purpose. For example, the set of fields { A1, B2, > F7, G3 } might all logically refer to the same thing, and so be represented > by a single custom field. Other such sets might be { A10, B10, ..., G10 }, > { E4, G5 }, etc. Hopefully they were assigned the same or similar names > to start with, but maybe not. Or when adding custom fields give the admin a list of products to add them to. > Creating a single additional product with its own custom fields would > require an intimate knowledge of every custom field in every product, > so that the new custom fields can be merged with the existing set. Not if you turn the problem the other way around as I just mentioned. It's easy enough to have a drop down when adding/editing a given custom field that lists the available products and hopefully includes a "global" product. Consider an organization where some of the custom fields are global custom fields. Each time you add a product someone has to rememeber which fields those are and what their paramaters are and manually readd them in. Or you automatically get the "global" custom fields. The only danger I see possibly being caused here by lack of intimate knowledge is that somebody might end up with two custom fields meaning the same thing. Most of the time this shouldn't cause a problem and if it does it should be a single simple SQL update to fix it. This danger is also mitigated by sharable custom fields since there will probably be fewer fields to worry about. > Also, perhaps "frobinage level" means different things in the context of > products Foo and Bar. If fields are shared, and names must be unique across > the entire Bugzilla installation, one of them must be renamed. Or frobinage level means the same thing across the 10 products and now you have prod A frobinage level and prod B frobinage level and prod C frobinage level and prod D frobinage level and prod E frobinage level and prod F frobinage level and prod G frobinage level and prod H frobinage level and prod I frobinage level and prod J frobinage level. Each of these has been carefully entered so as to otherwise be consistent. Hopefully there won't be much acrimony when prod C guys get 88 characters of frobinage and the rest only get 8, but it seems best to avoid it. :) And then a new methodology cult arrives on the doorstep and proclaims that frobinage is pagan idolotry (or evil or passe -- pick one) and must now be called chromeplatinage instead. You're stuck fixing 10 things instead of one thing. I've worked places where this sort of thing happened regularly, but thankfully not in a long time. Hopefully at some point we'll have access to these things in bug lists, so now you have 10 columns for the same field. Bah! My personal bugzilla has a dozen products in it. Each represents a major client so I can give that client access to just their issues without the other clients getting to see. ("Why is Chris fixing other people's problems before mine? Oh no.") One of my desired custom fields is to be able to have a server name field so that I could try to do all the work on a given server at the same time. Having to search 12 fields for this wouldn't help much. -- The death of democracy is not likely to be an assassination from ambush. It will be a slow extinction from apathy, indifference, and undernourishment. -Robert Maynard Hutchins, educator (1899-1977) From JWilmoth at starbucks.com Tue Apr 29 18:00:35 2003 From: JWilmoth at starbucks.com (Jon Wilmoth) Date: Tue, 29 Apr 2003 11:00:35 -0700 Subject: More custom field revisions Message-ID: -----Original Message----- From: Sean McAfee [mailto:etzwane at schwag.org] Sent: Mon 4/28/2003 5:48 PM To: developers at bugzilla.org Cc: Subject: Re: More custom field revisions >And >naming them with a numeric ID is ugly, opaque, and inconsistent with the >other fields. Ugly and opaque, perhaps. I wasn't so worried about inconsistency, since I had envisioned custom fields as a different kind of beast than the standard fields. I think it's important to realize that this custom field change has tremendous potential for refactoring the standard fields into an even stronger implementation. As I've found, familiar termanology is key to software acceptance by a user community. Being able to change the display name of fields (as done with the cf proposal) is very useful. Other site based required fields are another key aspect that have cross over potential. I know this has the potential of increasing the scope of this bug, but I'd like to do as much as possible to not prohibit a very flexible application wide field implementation. At the very least, using numbers for form field names will also make it very difficult to debug. All-in-all, it's not alot of work to allow users/developers refer to a human friendly field name. There are some issues to deal with though: 1) The name, being an identifier, shouldn't be modifiable. 2) The name, being an identifier should be unique. >>>It's not an automatic given that the custom field will be needed on >>>enter_bug. In fact, an argument could be made for not including any of >>>them by default. >> This seems a bit counterintuitive to me. What is the argument for not >> including any of them? >Our current enter_bug page (the normal one, not format=guided) doesn't >include several of the more advanced fields, on the basis that bug entry >should be a reasonably low barrier-to-entry process. That's probably true for most Bugzilla installations, but the one I intend to set up here will be strictly internal to the company and used only by people who are very familiar with the products they'll be using. Perhaps a sitewide parameter always_show_all_custom_fields or somesuch? I think UI simplification is important and could be accomplished by identifying a group that has access to this field. The template could then wrap the fields in a "isUserInGroup" check. >>>Remember to display all possible custom fields if >>>no products are selected. :-) >> Why? >Because no products being selected means you are searching all products. >But this is the same discussion as the one above. It had never occurred to me that one might want to search all products at once. A product represents one particular class of incidents, which doesn't necessarily have anything in common with any other class of incidents, right? (Except, necessarily, the fixed, global fields.) I see this happening more in the reporting screens where executive level reports would be generated across products (i.e. a engineering mgr). >> We seem to have stumbled >> onto a fundamental difference in our two conceptions of how custom fields >> should work. In my view, each product *contains* zero or more custom >> fields, which are not shared with any other product. There's no concept >> of "hard linking" between products. It may be that two different products >> both want a date field called (say) "Date Received", and they can have them, >> just as two distinct fields. >I see what you are saying. But this doesn't fit with the current model, >where if two products have a field Foo, it's the same field (admittedly, >all our fields are global, but the point remains.) >And, it makes querying much more of a pain. Imagine I had five products, >four of which were software and one was hardware. The software ones all >had a custom field for a particular purpose - frobinage level, or >something. In your scheme, you would have to create this custom field >four times, and the search page would have four different widgets for it >if you selected products A, B, C and D, because fields are not shared. >A better model, in my view, is allowing a custom field to belong to any >number of products between 1 and N, where an N-product field is a global >one. This makes the querying much more intuitive, because you can select >A, B, C and D products, and get a single widget for querying them all >for frobinage level. Imagine this scenario. A company is ready to bring its new Bugzilla installation on-line. Some group has come up with a list of ten products (call them "A" through "J") each of which will require ten custom fields ("A1" through "A10", "B1" through "B10", etc). If custom fields are not shared, the administrator simply creates the required products, then creates the fields within those products, working down the list he was given. If custom fields ARE shared, the administrator must search the entire list of fields for common purpose. For example, the set of fields { A1, B2, F7, G3 } might all logically refer to the same thing, and so be represented by a single custom field. Other such sets might be { A10, B10, ..., G10 }, { E4, G5 }, etc. Hopefully they were assigned the same or similar names to start with, but maybe not. Creating a single additional product with its own custom fields would require an intimate knowledge of every custom field in every product, so that the new custom fields can be merged with the existing set. First of all, I don't believe there will be a large volume of custom fields, so an "intimate knowledge" wouldn't be difficult, especially for someone in an admin role. Perhaps the custom field could include a description which would aid in this. Also, a view of what products a particular CF has been associated with would make this admin very easy. The proposed schema already supports multiple projects sharing a single CF. Without sharing fields, searching becomes MUCH less reliable. custom_fields ------------- project tinytext primary key, field_id integer not null, field_index integer not null Also, perhaps "frobinage level" means different things in the context of products Foo and Bar. If fields are shared, and names must be unique across the entire Bugzilla installation, one of them must be renamed. Agreed. I believe the consistency of reporting acheived by sharing by in far outweighs this small inconvenience. >Rephrase: why do we need multiline custom fields? (I have a sense of >deja vu asking this question.) Imposing a limit of one line on custom string data seems quite arbitrary to me. ...By the way, I hope I'm not coming across like some kind of know-it-all. My expectations for how custom fields should work is doubtlessly heavily influenced by my experience with my company's current solution (Team Track), which isn't really that bad, except for the speed. (And the price...and the closed source...and the convoluted schema...everything except the user interface, really.) I'm hoping to offer the users here as seamless a transition as possible, when it happens, but I'll try to keep an open mind about adapting to more traditional Bugzilla ways of doing things. That's the beauty of open source...software design influenced by multiple experiences! -- Sean McAfee -- etzwane at schwag.org ---- To view or change your list settings, click here: From etzwane at schwag.org Tue Apr 29 23:58:39 2003 From: etzwane at schwag.org (Sean McAfee) Date: Tue, 29 Apr 2003 19:58:39 -0400 Subject: More custom field revisions In-Reply-To: Message-ID: <20030429235839.85AD6BCAE@diggity.schwag.org> OK, so the picture I'm getting is this: - When many products are related, it's better that custom fields be shared. - When products are mostly or entirely isolated from one another, it's better that custom fields be unshared. So, is there any way to make everybody happy? Well, here are some thoughts. It appears that what proponents of shared custom fields are describing is similar to my own concept of global custom fields. One approach, then, might be to keep my proposal mostly intact, but to additionally give global custom fields the semantics suggested by shared-field proponents, including the unique alphanumeric identifier. Another approach might be to flag each product as "open" or "closed". Open products share all of their fields with all other open products; closed products don't share their fields at all. Each site could set its own default value for this flag. A generalization of the previous approach would be to allow products to be grouped together. Every product within a group would share the same custom fields. Groups would necessarily be disjoint, and there would be no special global scope. Approaching from the opposite direction, perhaps custom fields could be arranged into named groups. Someone previously cited an example of a Bugzilla installation with four software-related products and one hardware-related product; the software products shared many fields, and one would often want to search one or more of these fields without needing to duplicate search terms. Suppose, then, that one could create a field group called "sw-fields", with members like "Library Version", "Compiler", "Delivery Date", etc, and then include this group into each of the software products. One could even give each product some private fields as well: Product Foo Product Bar Product Baz Product Bletch ----------- ----------- ----------- -------------- group:sw-fields group:sw-fields group:sw-fields group:sw-fields Foo Field 1 Bar Field 1 Bletch Field 1 Foo Field 2 If Product Bletch were related to the hardware product in some way, another group called "hw-fields" could be created, and exported into both products--or, more likely, hw-fields would be created as a subset of the hardware product's fields, and then exported into Bletch. I'm starting to like this last approach more and more, although it does introduce a nontrivial amount of complexity. Any opinions? -- Sean McAfee -- etzwane at schwag.org From gerv at mozilla.org Wed Apr 30 07:52:42 2003 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 30 Apr 2003 08:52:42 +0100 Subject: More custom field revisions In-Reply-To: References: Message-ID: <3EAF80CA.1090701@mozilla.org> Christopher Hicks wrote: > One of my desired custom fields is to be able to have a server name > field so that I could try to do all the work on a given server at the same > time. Having to search 12 fields for this wouldn't help much. It seems to me that the most natural model for custom fields is this: When you create a field, you select a number of products, between 1 and N, to which it applies. If you select 1, it's the same as the current concept of a custom field. If you select N, it's the same as the current concept of a global custom field. If you select any number in between, it's the subset. This way, you have one mechanism for managing the fields - in a lot of code, they can all be treated the same rather than via this false dichotomy of global vs. product-specific. The key thing is that this doesn't remove any abilities from the proposal - those who want only single-product and global fields can still have them. It also, I strongly suspect, makes the implementation simpler because 1-product and n-product fields have more in common internally. Gerv From gerv at mozilla.org Wed Apr 30 07:52:41 2003 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 30 Apr 2003 08:52:41 +0100 Subject: More custom field revisions In-Reply-To: <20030429004802.78330BCAE@diggity.schwag.org> References: <20030429004802.78330BCAE@diggity.schwag.org> Message-ID: <3EAF80C9.7000307@mozilla.org> >>They can't be named with the name if the name contains spaces. OK, that was rubbish. But the argument from consistency still holds. > I had already disallowed carriage returns, line feeds, and leading and > trailing whitespace. The tab conversion is a problem, but it can be solved > by the reasonable step of disallowing tab characters in field names. The other thing is that people often read Bugzilla URLs. As spaces get encoded as %20, using them in field names makes them much harder to read. query.cgi?Wibble%20Fish=Something&%3FFoo%20Field%41=Something%20Else c.f.: query.cgi?product=Something&component=Something%20Else > Ugly and opaque, perhaps. I wasn't so worried about inconsistency, since I > had envisioned custom fields as a different kind of beast than the standard > fields. We have to get away from this idea, then :-) Principle: Custom fields should appear to the user, as much as possible, in the same way as non-custom fields. If a field stopped being hard-coded and started being global custom, they should not notice. Principle: Custom fields should use and leverage as many of the existing Bugzilla mechanisms for doing things as possible. E.g. bug change tracking. >>All of our fields have well-known alphabetic identifiers (bug_status, >>qa_contact, bug_file_loc) which are used to refer to that field through >>the code and in forms. The custom fields should not be an exception to >>this rule. > > I'm not so concerned with breaking this rule, since custom fields are by > their very nature site-specific and nonstandard. "Well-known" also means well-known within a site. And see above thoughts about URL readability. >>Our current enter_bug page (the normal one, not format=guided) doesn't >>include several of the more advanced fields, on the basis that bug entry >>should be a reasonably low barrier-to-entry process. > > That's probably true for most Bugzilla installations, but the one I intend > to set up here will be strictly internal to the company and used only by > people who are very familiar with the products they'll be using. > > Perhaps a sitewide parameter always_show_all_custom_fields or somesuch? Let's not dodge the issue with a pref - anyway, it's a display issue, so people should edit templates to move away from the default. I can see the conflicting demands here. Let's start by including them; I suppose people can comment out the generating code in the templates if necessary. > It had never occurred to me that one might want to search all products > at once. Trust me, it happens a lot. For example, on b.m.o., people commonly search in both Browser and MailNews. Or on all products at once if they are lazy. > A product represents one particular class of incidents, which > doesn't necessarily have anything in common with any other class of > incidents, right? (Except, necessarily, the fixed, global fields.) It doesn't _necessarily_, but it may well. > Imagine this scenario. A company is ready to bring its new Bugzilla > installation on-line. Some group has come up with a list of ten products > (call them "A" through "J") each of which will require ten custom fields > ("A1" through "A10", "B1" through "B10", etc). I think Chris Hicks has replied to this well. I'll comment on what he says. > ...By the way, I hope I'm not coming across like some kind of know-it-all. Not at all. I think you're engaging in this debate in an exemplary fashion :-) Gerv From gerv at mozilla.org Wed Apr 30 07:59:22 2003 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 30 Apr 2003 08:59:22 +0100 Subject: More custom field revisions In-Reply-To: <20030429235839.85AD6BCAE@diggity.schwag.org> References: <20030429235839.85AD6BCAE@diggity.schwag.org> Message-ID: <3EAF825A.7080607@mozilla.org> Sean McAfee wrote: > So, is there any way to make everybody happy? Well, here are some > thoughts. > > One approach, then, > might be to keep my proposal mostly intact, but to additionally give > global custom fields the semantics suggested by shared-field proponents, > including the unique alphanumeric identifier... > > Another approach might be to flag each product as "open" or "closed"... > > A generalization of the previous approach would be to allow products to > be grouped together... > > Approaching from the opposite direction, perhaps custom fields could > be arranged into named groups... Your four paragraphs in this mail each add an extra bit of complexity to the implementation; I believe my suggestion, by making it more general and flexible, actually simplifies the use and implementation. To summarise, then, there are a few things I really feel I need to insist on :-): - That it be possible to make a custom field apply, to 1, 2, .... N products. - That the custom field have an alphanumeric internal name, defined at creation time, which is unique to it and is used in form field names and anywhere else a unique identifier is required. This would not be the display name (although it could be a default for it.) - The separation of content from presentation by moving the definition of how and where the fields are displayed to the templates. Gerv From bbaetz at acm.org Wed Apr 30 08:06:13 2003 From: bbaetz at acm.org (Bradley Baetz) Date: Wed, 30 Apr 2003 18:06:13 +1000 Subject: More custom field revisions In-Reply-To: <3EAF825A.7080607@mozilla.org> References: <20030429235839.85AD6BCAE@diggity.schwag.org> <3EAF825A.7080607@mozilla.org> Message-ID: <20030430080613.GA1268@mango.home> On Wed, Apr 30, 2003 at 08:59:22AM +0100, Gervase Markham wrote: > > To summarise, then, there are a few things I really feel I need to > insist on :-): > > - That it be possible to make a custom field apply, to 1, 2, .... N > products. Just have an inclusions table > > - That the custom field have an alphanumeric internal name, defined at > creation time, which is unique to it and is used in form field names and > anywhere else a unique identifier is required. This would not be the > display name (although it could be a default for it.) > Why not use an id for form field names? That saves us a name->id lookup, and is something I've been considering doing for a while. > - The separation of content from presentation by moving the definition > of how and where the fields are displayed to the templates. > Right, as far as is possible. Hopefully this weekend i'll have time to actually read all of this thread's mails... Bradley From christian.masopust at siemens.com Wed Apr 30 10:31:06 2003 From: christian.masopust at siemens.com (Masopust Christian) Date: Wed, 30 Apr 2003 12:31:06 +0200 Subject: looking for a way to backup and/or remove a product from the bugs -database Message-ID: dear all, i'm looking for a way to backup and/or remove all entries from the bugs-database which are belonging to a given product. i'm not a sql-specialist, so i would be glad if there are any ready-to-run scripts ;-)) regards, chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.masopust at siemens.com Wed Apr 30 10:48:11 2003 From: christian.masopust at siemens.com (Masopust Christian) Date: Wed, 30 Apr 2003 12:48:11 +0200 Subject: looking for a way to backup and/or remove a product from the Message-ID: maybe i wasn't clear.... i don't want a simple backup-delete, what i want is an export-import - function with the possibility of additional delete after export... thanks, chris -----Urspr?ngliche Nachricht----- Von: Masopust Christian [mailto:christian.masopust at siemens.com] Gesendet: Mittwoch, 30. April 2003 12:31 An: 'developers at bugzilla.org' Betreff: looking for a way to backup and/or remove a product from the bugs -database dear all, i'm looking for a way to backup and/or remove all entries from the bugs-database which are belonging to a given product. i'm not a sql-specialist, so i would be glad if there are any ready-to-run scripts ;-)) regards, chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerv at mozilla.org Wed Apr 30 11:05:06 2003 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 30 Apr 2003 12:05:06 +0100 Subject: More custom field revisions In-Reply-To: <20030430080613.GA1268@mango.home> References: <20030429235839.85AD6BCAE@diggity.schwag.org> <3EAF825A.7080607@mozilla.org> <20030430080613.GA1268@mango.home> Message-ID: <3EAFADE2.30205@mozilla.org> > Why not use an id for form field names? That saves us a name->id lookup, > and is something I've been considering doing for a while. What, numeric IDs? Because it would make URLs much less readable, and debugging a lot harder. Gerv From gerv at mozilla.org Wed Apr 30 11:07:52 2003 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 30 Apr 2003 12:07:52 +0100 Subject: looking for a way to backup and/or remove a product from the In-Reply-To: References: Message-ID: <3EAFAE88.8040206@mozilla.org> Masopust Christian wrote: > maybe i wasn't clear.... i don't want a simple backup-delete, what i want is > an export-import - function > with the possibility of additional delete after export... Have a look at the documentation for mysqldump - that does export and import, in a "whole database" sense. If you want it more fine-grained, then you can request bugs as XML and store that data, later importing them using importxml.pl. But we don't support bug deletion from databases - it causes all sorts of problems. Gerv From bbaetz at acm.org Wed Apr 30 11:07:18 2003 From: bbaetz at acm.org (Bradley Baetz) Date: Wed, 30 Apr 2003 21:07:18 +1000 Subject: More custom field revisions In-Reply-To: <3EAFADE2.30205@mozilla.org> References: <20030429235839.85AD6BCAE@diggity.schwag.org> <3EAF825A.7080607@mozilla.org> <20030430080613.GA1268@mango.home> <3EAFADE2.30205@mozilla.org> Message-ID: <20030430110718.GA2042@mango.home> On Wed, Apr 30, 2003 at 12:05:06PM +0100, Gervase Markham wrote: > >Why not use an id for form field names? That saves us a name->id lookup, > >and is something I've been considering doing for a while. > > What, numeric IDs? Because it would make URLs much less readable, and > debugging a lot harder. It also has the advantage that when you change, say, the name of a product from 'Chimera' to 'Camino', saved queries still work :) > Gerv Bradley From gerv at mozilla.org Wed Apr 30 12:13:49 2003 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 30 Apr 2003 13:13:49 +0100 Subject: More custom field revisions In-Reply-To: <20030430110718.GA2042@mango.home> References: <20030429235839.85AD6BCAE@diggity.schwag.org> <3EAF825A.7080607@mozilla.org> <20030430080613.GA1268@mango.home> <3EAFADE2.30205@mozilla.org> <20030430110718.GA2042@mango.home> Message-ID: <3EAFBDFD.9080304@mozilla.org> Bradley Baetz wrote: > On Wed, Apr 30, 2003 at 12:05:06PM +0100, Gervase Markham wrote: > >>>Why not use an id for form field names? That saves us a name->id lookup, >>>and is something I've been considering doing for a while. >> >>What, numeric IDs? Because it would make URLs much less readable, and >>debugging a lot harder. > > It also has the advantage that when you change, say, the name of a > product from 'Chimera' to 'Camino', saved queries still work :) You appear to have got a bit confused (or I have.) We currently have URLs like: product=Bugzilla&... He's proposing (as I understand it): 37=Bugzilla&... (where 37 is the ID of a custom field) You are proposing: product=12&... (where 12 is the ID of a product) Regarding your point (and not his), is that disadvantage (having to update stored queries when product names change, which is a fairly rare event) outweighed by the advantage of being able to do: bzbot: query product=Bugzilla&target_milestone=2.18 as opposed to: bzbot: product=3&target_milestone=2.18 ? Gerv From bbaetz at acm.org Wed Apr 30 12:20:22 2003 From: bbaetz at acm.org (Bradley Baetz) Date: Wed, 30 Apr 2003 22:20:22 +1000 Subject: More custom field revisions In-Reply-To: <3EAFBDFD.9080304@mozilla.org> References: <20030429235839.85AD6BCAE@diggity.schwag.org> <3EAF825A.7080607@mozilla.org> <20030430080613.GA1268@mango.home> <3EAFADE2.30205@mozilla.org> <20030430110718.GA2042@mango.home> <3EAFBDFD.9080304@mozilla.org> Message-ID: <20030430122022.GB2174@mango.home> On Wed, Apr 30, 2003 at 01:13:49PM +0100, Gervase Markham wrote: > You appear to have got a bit confused (or I have.) > > We currently have URLs like: > > product=Bugzilla&... > > He's proposing (as I understand it): > > 37=Bugzilla&... (where 37 is the ID of a custom field) Well, field-37, anyway - I don't think that keys can be entirely numbers, although I'd have to check specs to be sure. > > You are proposing: > > product=12&... (where 12 is the ID of a product) Yes. > > Regarding your point (and not his), is that disadvantage (having to > update stored queries when product names change, which is a fairly rare > event) outweighed by the advantage of being able to do: > Well, it also allows you to do stuff like just stick the new value into the bug table in process_bug, and then just error out with teh appropriate message if there was a foreign key violation. (I didn't say I wanted to do this soon...) > bzbot: query product=Bugzilla&target_milestone=2.18 > > as opposed to: > > bzbot: product=3&target_milestone=2.18 > Well, bzbot is a special case. Most people don't construct query strings themselves. The fact that #mozwebtools does is sort of abnormal :) don't forget utf8 stuff. Those can't be done via GET, at least not portably. I think. So we really have to use numbers. Bradley From chicks at chicks.net Wed Apr 30 14:39:41 2003 From: chicks at chicks.net (Christopher Hicks) Date: Wed, 30 Apr 2003 10:39:41 -0400 (EDT) Subject: More custom field revisions In-Reply-To: <20030430122022.GB2174@mango.home> Message-ID: On Wed, 30 Apr 2003, Bradley Baetz wrote: > On Wed, Apr 30, 2003 at 01:13:49PM +0100, Gervase Markham wrote: > > You appear to have got a bit confused (or I have.) > > 37=Bugzilla&... (where 37 is the ID of a custom field) > > Well, field-37, anyway - I don't think that keys can be entirely > numbers, although I'd have to check specs to be sure. The name= attribute on is CDATA according to the XHTML DTD, but that doesn't make a number a good variable name: 1) As Gerv points out this is inconsistant with historical practice. 2) It's nice to have variables names the same across the HTML FORM and in code. So having the names correspond to Perl's variable name syntax can make life easier. I can accept that this particular issue may not effect the current conceptualization of adding custom fields to bz, but it's a good principle and there doesn't seem to be that much advantage to ignoring it. 3) Debugging these things often includes examining what inputs causes what bugs and looking at the generated HTML. I'd much rather have a comprehensible name there than some random number. 4) Moving custom fields between databases would seem to be easier if they were identified by a name instead of a number. Collisions are much more likely if every bz install starts with custom field #1. Except for the third point I don't think any of this is particularly persuasive, but it's not clear what overwhelms these things about going with numeric ids any place that humans might run into them. -- The death of democracy is not likely to be an assassination from ambush. It will be a slow extinction from apathy, indifference, and undernourishment. -Robert Maynard Hutchins, educator (1899-1977) From stalione at avarachen.net Wed Apr 30 16:16:13 2003 From: stalione at avarachen.net (Vijay Avarachen) Date: Wed, 30 Apr 2003 11:16:13 -0500 Subject: Login in user without a prompt In-Reply-To: <3EAA5D67.20509@mozilla.org> References: <3E9D786F.1080500@avarachen.net> <3EAA5D67.20509@mozilla.org> Message-ID: <3EAFF6CD.7010302@avarachen.net> Greg thanks for your response. Actually I had already done the hidden trick and it works pretty well. I just embedd the password in the html and pass it to post_bug.cgi. Its not the end of the world for the end user to find out the password since its a very restricted account. Vijay Gervase Markham wrote: > Vijay Avarachen wrote: > >> Hello, >> I am trying to set-up a page which users will access directly >> (without getting prompted for a login and password) and enter their >> trouble ticked in there. This page will be customized to the product >> they are using and they won't have to worry about the various options >> that usually are presented when accessing enter_bug.cgi (these >> options will be pre-select and hidden from them). How can I do >> this? I am not a perl/cgi guru and goign through the mailing list >> archive didn't help much. We are using version 2.14.2. My first >> concern is how can I get the user to enter_bug.cg without the >> password prompt. Then I would try to figure out passing hidden >> values to the various options specific to the user/product. Thanks >> in advance. > > > Removing the password prompt is a problem because Bugzilla assumes > that everyone entering a bug will have an account. You could change > the call in enter_bug.cgi from confirm_login() to > quietly_check_login(), but then you'd probably end up with a reporter > of "__UNKNOWN__", which would be a bit ugly. > > If you want hidden default values on a bug entry form, you just use > > > Gerv > > ---- > To view or change your list settings, click here: > > From myk at mozilla.org Wed Apr 30 16:38:16 2003 From: myk at mozilla.org (Myk Melez) Date: Wed, 30 Apr 2003 09:38:16 -0700 Subject: More custom field revisions In-Reply-To: <3EAF80CA.1090701@mozilla.org> References: <3EAF80CA.1090701@mozilla.org> Message-ID: <3EAFFBF8.2020007@mozilla.org> Gervase Markham wrote: > The key thing is that this doesn't remove any abilities from the > proposal - those who want only single-product and global fields can > still have them. It also, I strongly suspect, makes the implementation > simpler because 1-product and n-product fields have more in common > internally. Also, there's precedent for doing this and even sample code in the flag feature, so you don't have to start from scratch. In fact, you might consider piggybacking on the current implementation for flags and factoring out its code for reuse in both flags and custom fields. -myk From myk at mozilla.org Wed Apr 30 16:51:01 2003 From: myk at mozilla.org (Myk Melez) Date: Wed, 30 Apr 2003 09:51:01 -0700 Subject: More custom field revisions In-Reply-To: <20030430122022.GB2174@mango.home> References: <20030429235839.85AD6BCAE@diggity.schwag.org> <3EAF825A.7080607@mozilla.org> <20030430080613.GA1268@mango.home> <3EAFADE2.30205@mozilla.org> <20030430110718.GA2042@mango.home> <3EAFBDFD.9080304@mozilla.org> <20030430122022.GB2174@mango.home> Message-ID: <3EAFFEF5.4000209@mozilla.org> Bradley Baetz wrote: >On Wed, Apr 30, 2003 at 01:13:49PM +0100, Gervase Markham wrote: > > >>Regarding your point (and not his), is that disadvantage (having to >>update stored queries when product names change, which is a fairly rare >>event) outweighed by the advantage of being able to do: >> >> > >Well, it also allows you to do stuff like just stick the new value into >the bug table in process_bug, and then just error out with teh >appropriate message if there was a foreign key violation. (I didn't say >I wanted to do this soon...) > > Maybe the solution is to move to numeric identifiers internally but let users enter names and implicitly convert them to their corresponding IDs like we do with aliases. This accomplishes our goal of gaining whatever advantages we gain from identifiers while keeping the interface as useful as possible for end users, and the code to implement it is pretty trivial and not too costly in terms of performance. -myk -------------- next part -------------- An HTML attachment was scrubbed... URL: From etzwane at schwag.org Wed Apr 30 18:52:30 2003 From: etzwane at schwag.org (Sean McAfee) Date: Wed, 30 Apr 2003 14:52:30 -0400 Subject: More custom field revisions In-Reply-To: <3EAF80CA.1090701@mozilla.org> Message-ID: <20030430185230.A3F13BCD8@diggity.schwag.org> Gervase Markham wrote: >It seems to me that the most natural model for custom fields is this: >When you create a field, you select a number of products, between 1 and >N, to which it applies. If you select 1, it's the same as the current >concept of a custom field. If you select N, it's the same as the current >concept of a global custom field. If you select any number in between, >it's the subset. And when you later create product N+1, and want it to have the same "global" fields as the original N products, do you need to remember which fields you'd previously added to the first N and add them individually to N+1? >This way, you have one mechanism for managing the fields - in a lot of >code, they can all be treated the same rather than via this false >dichotomy of global vs. product-specific. >The key thing is that this doesn't remove any abilities from the >proposal - those who want only single-product and global fields can >still have them. It also, I strongly suspect, makes the implementation >simpler because 1-product and n-product fields have more in common >internally. What concerns me is the spectre of a set of N products on the one side, a set of M custom fields on the other (N and M both being large), and some arbitrarily complicated set of has-a relationships between them. I think that would be difficult for an administrator to keep straight, and difficult to cleanly represent in the admin interface. Better, I think, to impose some degree of order. >From another message: >The other thing is that people often read Bugzilla URLs. As spaces get >encoded as %20, using them in field names makes them much harder to read. > >query.cgi?Wibble%20Fish=Something&%3FFoo%20Field%41=Something%20Else >c.f.: >query.cgi?product=Something&component=Something%20Else OK, I can see the utility in this. I would ask, though, that the administrator not be required to compose from scratch, for every field, a name which isn't relevant to the user interface. The admin interface could, for example, propose a reasonable default by downcasing the display name and replacing all nonalphanumerics with underscores, and twiddling the result to avoid name collision. The administrator could then accept this suggestion, modify it, or nuke it and make up a new one. >From yet another message: >To summarise, then, there are a few things I really feel I need to >insist on :-): [snip] >- The separation of content from presentation by moving the definition >of how and where the fields are displayed to the templates. I think it should be possible to modify the presentation of custom fields in this way, but I'd rather provide reasonable default behavior that obviates the need to perform template-twiddling for each and every custom field. This is the kind of thing I have in mind: ------------------------------------------------------------

Here are some really important fields:

[% PROCESS custom_field name = 'important_field_one' %] [% PROCESS custom_field name = 'important_field_two' %]

Here are the run-of-the-mill fields:

[% PROCESS show_custom_fields skip = [ 'bottom_field_one', 'bottom_field_two' ] # important_field_one and important_field_two are implicitly skipped, # since they were already processed via the prior custom_field blocks; # bottom_field_one and bottom_field_two are explicitly skipped, # since we'll display them ourselves later # # Maybe there should also be "first", "last", and/or "order" # parameters to modify the administrator-defined default ordering? %]

And here are some fields you probably won't care about very often:

[% PROCESS custom_field name = 'bottom_field_one' %] [% PROCESS custom_field name = 'bottom_field_two' %] ------------------------------------------------------------ This example only deals with reordering the fields and interspersing other text, but the field elements themselves could also be provided by custom template code, as long as everyone agrees on how to record which fields have already been displayed. -- Sean McAfee -- etzwane at schwag.org From gerv at mozilla.org Wed Apr 30 21:23:10 2003 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 30 Apr 2003 22:23:10 +0100 Subject: More custom field revisions In-Reply-To: <20030430185230.A3F13BCD8@diggity.schwag.org> References: <20030430185230.A3F13BCD8@diggity.schwag.org> Message-ID: <3EB03EBE.6010905@mozilla.org> Sean McAfee wrote: > And when you later create product N+1, and want it to have the same > "global" fields as the original N products, do you need to remember which > fields you'd previously added to the first N and add them individually > to N+1? It's a reasonable point, but doesn't destroy the model. There's two ways you could play this: - Say that you have to allocate custom fields by hand for each new product, because there's no way Bugzilla can know which one you want - Have the product selection UI phrased as "Restrict to products:" and differentiate between the cases where the admin selects all N (which would restrict the field to just those N unless changed manually) and where the admin selects none at all (which would mean the field was auto-added to each new product.) This would require a "global" boolean in the database; but it would only be looked at when doing admin - the implementation would still be common. > What concerns me is the spectre of a set of N products on the one side, > a set of M custom fields on the other (N and M both being large), and > some arbitrarily complicated set of has-a relationships between them. You make it sound complex, but it's not. On every "edit custom field" screen, you have a "Restrict to products:" multiselect. And that's all you need. > OK, I can see the utility in this. I would ask, though, that the > administrator not be required to compose from scratch, for every field, > a name which isn't relevant to the user interface. Again, you make it sound complicated. I suppose it depends on whether we define the display names in the templates (which I think we should, but I'm open to persuasion) but the UI could be something like this short name (lower-case alphanumeric and underscore): [ ] display name: [ ] > The admin interface > could, for example, propose a reasonable default by downcasing the > display name and replacing all nonalphanumerics with underscores, and > twiddling the result to avoid name collision. The administrator could > then accept this suggestion, modify it, or nuke it and make up a new one. Hmm. We could do that. If it were me, I'd like to pick my own, but I can see the value in Bugzilla making a suggestion. >>- The separation of content from presentation by moving the definition >>of how and where the fields are displayed to the templates. > > I think it should be possible to modify the presentation of custom fields in > this way, but I'd rather provide reasonable default behavior that obviates > the need to perform template-twiddling for each and every custom field. Oh, I agree that we should display them without intervention - note that I said "how and where", not "if" :-) In other words, there should be a default location, and changing it requires hacking templates, plus a default UI widget, and changing that requires hacking templates. So your suggestion of how to do it sounds roughly right. :-) Gerv