From mkanat at bugzilla.org Mon Aug 1 10:52:02 2005 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 01 Aug 2005 03:52:02 -0700 Subject: Bug Deletion Message-ID: <1122893522.17348.7.camel@eslappy> So, bug deletion is a bad idea. We keep telling people this. We tell them instead to move their bugs to a graveyard product that nobody can access but the admins. Why don't we just modify "bug deletion" to do that? We can get rid of bug deletion, and replace it with a param called something like "graveyard_product_name". -Max -- http://www.everythingsolved.com/ Friendly, Expert Bugzilla and Linux Services From LpSolit at gmail.com Mon Aug 1 11:07:21 2005 From: LpSolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Mon, 01 Aug 2005 13:07:21 +0200 Subject: Bug Deletion In-Reply-To: <1122893522.17348.7.camel@eslappy> References: <1122893522.17348.7.camel@eslappy> Message-ID: <42EE0269.9020701@gmail.com> Max Kanat-Alexander a ?crit : > So, bug deletion is a bad idea. We keep telling people this. > > We tell them instead to move their bugs to a graveyard product that > nobody can access but the admins. > > Why don't we just modify "bug deletion" to do that? We can get rid of > bug deletion, and replace it with a param called something like > "graveyard_product_name". > > -Max Bug deletion works perfectly well. I see no reason to remove this feature. I don't see why bug deletion would be a bad idea. Frederic From dberlin at dberlin.org Mon Aug 1 12:54:10 2005 From: dberlin at dberlin.org (Daniel Berlin) Date: Mon, 01 Aug 2005 08:54:10 -0400 Subject: Bug Deletion In-Reply-To: <42EE0269.9020701@gmail.com> References: <1122893522.17348.7.camel@eslappy> <42EE0269.9020701@gmail.com> Message-ID: <1122900851.32467.120.camel@linux.site> On Mon, 2005-08-01 at 13:07 +0200, Fr?d?ric Buclin wrote: > Max Kanat-Alexander a ?crit : > > So, bug deletion is a bad idea. We keep telling people this. > > > > We tell them instead to move their bugs to a graveyard product that > > nobody can access but the admins. > > > > Why don't we just modify "bug deletion" to do that? We can get rid of > > bug deletion, and replace it with a param called something like > > "graveyard_product_name". > > > > -Max > > > Bug deletion works perfectly well. I see no reason to remove this > feature. I don't see why bug deletion would be a bad idea. > Because some people confuse bug systems with version control, and think the bug system should not be allowed to truly delete information, even if it is only historical. From kevin.benton at amd.com Mon Aug 1 16:08:00 2005 From: kevin.benton at amd.com (Benton, Kevin) Date: Mon, 1 Aug 2005 09:08:00 -0700 Subject: Bug Deletion Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201AC3C14@ssvlexmb2.amd.com> Isn't that why it's an option in the Parameters screen? --- Kevin Benton Perl/Bugzilla Developer Advanced Micro Devices The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. -----Original Message----- From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] On Behalf Of Daniel Berlin Sent: Monday, August 01, 2005 6:54 AM To: developers at bugzilla.org Subject: Re: Bug Deletion On Mon, 2005-08-01 at 13:07 +0200, Fr?d?ric Buclin wrote: > Max Kanat-Alexander a ?crit : > > So, bug deletion is a bad idea. We keep telling people this. > > > > We tell them instead to move their bugs to a graveyard product that > > nobody can access but the admins. > > > > Why don't we just modify "bug deletion" to do that? We can get rid of > > bug deletion, and replace it with a param called something like > > "graveyard_product_name". > > > > -Max > > > Bug deletion works perfectly well. I see no reason to remove this > feature. I don't see why bug deletion would be a bad idea. > Because some people confuse bug systems with version control, and think the bug system should not be allowed to truly delete information, even if it is only historical. - To view or change your list settings, click here: From stethomas at ebay.com Mon Aug 1 16:09:51 2005 From: stethomas at ebay.com (Thomas, Steve) Date: Mon, 1 Aug 2005 10:09:51 -0600 Subject: Bug Deletion Message-ID: <8E1982313133E740ABCCF578C7060FEC0491FE43@DEN-EXM-02.corp.ebay.com> Bug deletion is sometimes a good idea, sometimes a bad idea, depending on why you are doing it. This can be said for file deletion on an OS, food deletion in your kitchen, and so on. Good/bad depends on the context. I have had *several* reasons over the years to need to delete bug entries, such as testing, starting a project in Bugz that never became a real project, and so on. Yes, you might be able to archive these things, but, in the opinion of this user / administrator of this system, the information is useless and cluttersome, and should be deleted. Its very arrogant of a software system to assume that it knows more than I do about my own situation. Speaking of that though, I personally have NOT used Bugzilla in a while (until very recently), so I don't know if deleting a bug is easy to do now or not. Steve Thomas ________________________________ From: developers-owner at bugzilla.org on behalf of Max Kanat-Alexander Sent: Mon 8/1/2005 3:52 AM To: developers at bugzilla.org Subject: Bug Deletion So, bug deletion is a bad idea. We keep telling people this. We tell them instead to move their bugs to a graveyard product that nobody can access but the admins. Why don't we just modify "bug deletion" to do that? We can get rid of bug deletion, and replace it with a param called something like "graveyard_product_name". -Max -- http://www.everythingsolved.com/ Friendly, Expert Bugzilla and Linux Services - To view or change your list settings, click here: -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 4933 bytes Desc: not available URL: From kevin.benton at amd.com Mon Aug 1 16:18:09 2005 From: kevin.benton at amd.com (Benton, Kevin) Date: Mon, 1 Aug 2005 09:18:09 -0700 Subject: REMIND and LATER considered harmful [was Re: RESOLVED] Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201AC3C1D@ssvlexmb2.amd.com> > Isn't that what comments are for? > > status: Pending > > comment: I need more info from... > > just my 2 cents, Yes and no. Part of process management involves knowing why a particular item is being held up. So, for example, if a status is Pending and the reason is Customer Information, the clock stops completely. If, on the other hand, a bug is put into Pending status, and it's something within our control, the clock may or may not stop - Pending Priority doesn't stop the clock, but Pending Bug Resolution would (assuming that the bug it depends on is being worked on). Can the system be fooled? Of course. Using it effectively depends on the people using it in a responsible manner. At least by providing a method for accountability, the opportunity is there and since we're all adults at the place I work at, we can generally be trusted to follow proper process. --- Kevin Benton Perl/Bugzilla Developer Advanced Micro Devices The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. Benton, Kevin wrote: >>From a process monitoring perspective, "NEEDINFO" by itself isn't enough >from my point of view. There are other reasons a bug may be in a >PENDING state besides a need for additional information. > >--- >Kevin Benton >Perl/Bugzilla Developer >Advanced Micro Devices > >The opinions stated in this communication do not necessarily reflect the >view of Advanced Micro Devices and have not been reviewed by management. >This communication may contain sensitive and/or confidential and/or >proprietary information. Distribution of such information is strictly >prohibited without prior consent of Advanced Micro Devices. This >communication is for the intended recipient(s) only. If you have >received this communication in error, please notify the sender, then >destroy any remaining copies of this communication. > > > >-----Original Message----- >From: developers-owner at bugzilla.org >[mailto:developers-owner at bugzilla.org] On Behalf Of timeless >Sent: Thursday, July 14, 2005 12:12 PM >To: developers at bugzilla.org >Subject: Re: REMIND and LATER considered harmful [was Re: RESOLVED] > >Gregary Hendricks wrote: > > >>For this we, as well as a number of bugzillae, have implemented a >>NEEDINFO status. Along with it we have an added field of who we >> >> > > need information from (reporter, last commentor, or someone else > > entirely) who is then CC'd on the bug for the duration that the bug > > is in the NEEDINFO state. This places the responsibility of the bug > > squarely on the shoulders of the info provider until they come back > > with the additional information. This really helps in the processing > > of a bug as it is obvious by the status that no work can be > > completed until someone (usually the reporter) comes back with > > something more than was initially provided. > >i much prefer this (both ideally and having seen it) over all the other >forms suggested in this thread. > >- >To view or change your list settings, click here: > > > > >- >To view or change your list settings, click here: > > > > > - To view or change your list settings, click here: From justdave at bugzilla.org Mon Aug 1 19:59:13 2005 From: justdave at bugzilla.org (David Miller) Date: Mon, 01 Aug 2005 15:59:13 -0400 Subject: Recommendations for Bugzilla hardware In-Reply-To: <20050731192707.GA7562@sunni.localdomain> References: <20050731192707.GA7562@sunni.localdomain> Message-ID: <42EE7F11.2070404@bugzilla.org> Eddie Xie wrote: > I maintain a customized version of Bugzilla for my organization. We > are upgrading some of our equipment, and one of the things being > considered for upgrade is our Bugzilla server. What sort of specs > would be good for our new server? Bugzilla is used a lot in our > organization. We have around 100 users and over 40,000 bugs in our > database. More bugs get added all the time. We also seem to like > generating graphs and reports. > > We don't want to invest too much in a Bugzilla server if we could put > that money and hardware elsewhere. On the other hand, we don't want > our users complaining that Bugzilla is slow, because it is used all > the time. I welcome any recommendations for this. All depends on what hardware you have it running on now. :) Our Bugzilla is on a 2 x 3.4 GHz HT Xeon box, with hardware SCSI RAID, and we use a replicated database for queries, the primary and replicated MySQL servers are on two separate boxes which are both 2 x 2.8 GHz with software RAID. We've got about 120,000 total users (about 10,000 active) and over 300,000 bugs. We survived for a long time with much less-capable hardware (these machines are fairly new). The database servers are both getting moved to new hardware soon (which will be equivalent hardware with the web server). Our current performance bottlenecks are software-related though (mostly sending mail). Changes to Bugzilla itself will be our next avenue for performance improvements. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Foundation http://www.mozilla.org/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From mkanat at bugzilla.org Tue Aug 2 00:08:17 2005 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 01 Aug 2005 17:08:17 -0700 Subject: Errors upgrading 2.16.3 to 2.18.3 In-Reply-To: References: Message-ID: <1122941298.3019.6.camel@eslappy> On Mon, 2005-08-01 at 06:21 -0700, Joel Peshkin wrote: >> Quantifier follows nothing in regex; marked by <-- HERE in m/* <-- >> HERE @ignitionpartners.com/ at Bugzilla/User.pm line 263. > > That sounds like something that should be caught as part of an eval() > and reported more gracefully. Please file a bug. We have a bug for it already; it's something about how we should validate regexes. It would be pretty easy to do in 2.20; we'd just modify sql_regexp. However, the problem is that the *database* is reporting that error, not perl. And we have no particular way in perl to validate that a regex will be valid for a DB. However, if anybody can think of some way to tackle it, it would be certainly a welcome enhancement. :-) -Max -- http://www.everythingsolved.com/ Friendly, Expert Bugzilla and Linux Services From mkanat at bugzilla.org Sat Aug 6 11:05:06 2005 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sat, 06 Aug 2005 04:05:06 -0700 Subject: No More Prototypes Message-ID: <1123326306.3340.5.camel@localhost.localdomain> Hey there. Please note the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=303669 Basically, we have been mis-using subroutine prototypes. I misunderstood their purpose. But I wrote the patch on that bug to remove them where we've put them. :-) -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From paulspencer at mindspring.com Mon Aug 8 19:57:40 2005 From: paulspencer at mindspring.com (Paul Spencer) Date: Mon, 08 Aug 2005 15:57:40 -0400 Subject: Just saw the announcement for 2.20-rc2 Message-ID: <42F7B934.4090506@mindspring.com> I just saw the announcement for 2.20-rc2! To the Bugzilla team, THANK YOU for all your hard work. Paul Spencer From mkanat at bugzilla.org Tue Aug 9 00:01:01 2005 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 08 Aug 2005 17:01:01 -0700 Subject: "Environmental Variable" Authentication Method question.. In-Reply-To: <1123534192_307@spool6-east.superfeed.net> References: <1123485954.889002.261760@g44g2000cwa.googlegroups.com> <1123534192_307@spool6-east.superfeed.net> Message-ID: <1123545661.3381.15.camel@localhost.localdomain> A lot of the below section would be good for the docs: On Mon, 2005-08-08 at 16:47 -0400, A. Karl Kornel wrote: > There is only one required parameter for this form of authentication: > auth_env_email. auth_env_email needs to be set to the name of an > environment variable that contains the logged-in user's email address. > Bugzilla identifies users by email address (also referred to as a login). > > auth_env_id and auth_env_realname are optional, but useful. > auth_env_realname can be set to an environment variable that contains the > logged-in user's real name, so when a user is logs in for the first time > their real name is set up properly. Again, this is optional. > > auth_env_id is a bit more complicated. It can be set to an > environment variable that contains some unique ID, something besides an email > address, which can be used to identify this user. This unique ID should never > change. It is used so that a person can change their e-mail address > without losing access to their account (since the account is identified > by e-mail address). > > Just to make sure I'm clear, those parameters don't contain the user's > email/name/ID, the parameters contain the names of environment variables > that contain the user's email/name/ID. > > Also, there are a couple of caveats with this. First, changes to a > user's email or password must take place outside of Bugzilla, since this > info is being managed outside of Bugzilla. Second, you can not log out > through Bugzilla (Bugzilla didn't log you in, so it can't log you out!). > Also, because of a bug that I don't really want to get into, it may be a > good idea to have users log in before granting access to any Bugzilla > pages. -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From exie at linkageposted.longmusic.com Tue Aug 9 07:40:29 2005 From: exie at linkageposted.longmusic.com (Eddie Xie) Date: 9 Aug 2005 00:40:29 -0700 Subject: Recommendations for Bugzilla hardware In-Reply-To: <42EE7F11.2070404@bugzilla.org> References: <20050731192707.GA7562@sunni.localdomain> <42EE7F11.2070404@bugzilla.org> Message-ID: <09677276026e6c7461195a52e847fb002318227f.exie@com.longmusic.linkageposted> On 2005 August 01 (Mon) 12:59:13pm PDT, David Miller wrote: > Eddie Xie wrote: > >I maintain a customized version of Bugzilla for my organization. We > >are upgrading some of our equipment, and one of the things being > >considered for upgrade is our Bugzilla server. What sort of specs > >would be good for our new server? Bugzilla is used a lot in our > >organization. We have around 100 users and over 40,000 bugs in our > >database. More bugs get added all the time. We also seem to like > >generating graphs and reports. > > > >We don't want to invest too much in a Bugzilla server if we could put > >that money and hardware elsewhere. On the other hand, we don't want > >our users complaining that Bugzilla is slow, because it is used all > >the time. I welcome any recommendations for this. > > All depends on what hardware you have it running on now. :) Currently, our system has a PIII 1Ghz CPU, 512MB RAM, 3x36Gig SCSI drives in RAID5 and a 40GB local hard drive. Everything runs on this one system. > Our Bugzilla is on a 2 x 3.4 GHz HT Xeon box, with hardware SCSI RAID, > and we use a replicated database for queries, the primary and replicated > MySQL servers are on two separate boxes which are both 2 x 2.8 GHz with > software RAID. We've got about 120,000 total users (about 10,000 > active) and over 300,000 bugs. We survived for a long time with much > less-capable hardware (these machines are fairly new). > > The database servers are both getting moved to new hardware soon (which > will be equivalent hardware with the web server). > > Our current performance bottlenecks are software-related though (mostly > sending mail). Changes to Bugzilla itself will be our next avenue for > performance improvements. I see that you have your Bugzilla using dual processor systems. How much of a benefit is it to have two processors? Do you have to do anything special to get this benefit (e.g., use a specially compiled version of MySQL, or use a specialized version of Linux or FreeBSD). What is the benefit of using a replicated database for queries? Is it only when multiple queries are going on at the same time? Thanks for your reply! -- Eddie Xie From justdave at bugzilla.org Tue Aug 9 08:49:23 2005 From: justdave at bugzilla.org (David Miller) Date: Tue, 09 Aug 2005 04:49:23 -0400 Subject: Recommendations for Bugzilla hardware In-Reply-To: <09677276026e6c7461195a52e847fb002318227f.exie@com.longmusic.linkageposted> References: <20050731192707.GA7562@sunni.localdomain> <42EE7F11.2070404@bugzilla.org> <09677276026e6c7461195a52e847fb002318227f.exie@com.longmusic.linkageposted> Message-ID: <42F86E13.70305@bugzilla.org> Eddie Xie wrote: > I see that you have your Bugzilla using dual processor systems. How > much of a benefit is it to have two processors? Do you have to do > anything special to get this benefit (e.g., use a specially compiled > version of MySQL, or use a specialized version of Linux or FreeBSD). You need a kernel that was compiled for "SMP" or "Symmetric Multi-Processing". Most linux distros these days have such a kernel already compiled for you in one of the kernel packages (I know Red Hat, Debian, Fedora, and Ubuntu all do, I haven't used many others). It's a great benefit to a machine with Apache and MySQL on the same box, because then essentially, MySQL gets one and Apache gets the other (not exactly, but that's the general idea). In the case of having just the webserver on that box, Apache can basically handle twice as many requests at once because it has both processors to split the load between. > What is the benefit of using a replicated database for queries? Is it > only when multiple queries are going on at the same time? When you send an update to a table, the table gets locked for a brief moment, preventing queries from accessing that table (MySQL doesn't have row-level locks unfortunately -- not in the current versions we support anyway). So every time someone updates a bug, anyone running a query is going to be put on hold momentarily. If lots of people are changing bugs at once, this leaves very little time for queries to run. The replicated database is set up with "low-priority writes," meaning that queries get priority, and updates are done whenever there aren't any queries running. If there's a LOT of people running queries, it's possible for the replicated database to get a little bit stale, but it keeps everyone running quickly, and it usually doesn't stay behind for very long. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Foundation http://www.mozilla.org/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From bugreport at peshkin.net Tue Aug 9 09:01:00 2005 From: bugreport at peshkin.net (Joel Peshkin) Date: Tue, 09 Aug 2005 02:01:00 -0700 Subject: Recommendations for Bugzilla hardware In-Reply-To: <09677276026e6c7461195a52e847fb002318227f.exie@com.longmusic.linkageposted> References: <20050731192707.GA7562@sunni.localdomain> <42EE7F11.2070404@bugzilla.org> <09677276026e6c7461195a52e847fb002318227f.exie@com.longmusic.linkageposted> Message-ID: <42F870CC.7080205@peshkin.net> Eddie Xie wrote: > >What is the benefit of using a replicated database for queries? Is it >only when multiple queries are going on at the same time? > > It helps there, of course. However, the major payoff is that operations that need to write to the database do not need to wait for a long query to end. Without the replication, a single user running an extremely long query can cause many other basic operations to need to wait for that query to end. In a large site, that could mean that logging in or posting a bug could be stalled for minutes. From timeless at myrealbox.com Tue Aug 9 09:37:51 2005 From: timeless at myrealbox.com (timeless) Date: Tue, 09 Aug 2005 02:37:51 -0700 Subject: REMIND and LATER considered harmful [was Re: RESOLVED] In-Reply-To: <42EB1E0E.2010200@gmx.net> References: <6F7DA19D05F3CF40B890C7CA2DB13A42018CE0B1@ssvlexmb2.amd.com> <42EB1E0E.2010200@gmx.net> Message-ID: <42F8796F.4080402@myrealbox.com> Mick Weiss wrote: > Isn't that what comments are for? > > status: Pending > >>> From a process monitoring perspective, "NEEDINFO" by itself isn't enough >> from my point of view. There are other reasons a bug may be in a >> PENDING state besides a need for additional information. the problem is that people run queries, and the only useful things to check on are summaries (which you really don't want to change a lot), status whiteboard (which many people ignore, and which others decorate randomly). it can't even show flags (it can show keywords, so you could use them for NEEDINFO/STACKWANTED/blah, but most people don't include keywords, some people are actively trying to kill bugzilla's support for keywords, and they don't clearly indicate that a bug is blocked until something else happens) From kevin.benton at amd.com Tue Aug 9 15:43:02 2005 From: kevin.benton at amd.com (Benton, Kevin) Date: Tue, 9 Aug 2005 08:43:02 -0700 Subject: REMIND and LATER considered harmful [was Re: RESOLVED] Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201CDFDFA@ssvlexmb2.amd.com> >Mick Weiss wrote: >> Isn't that what comments are for? >> >> status: Pending >> >>>> From a process monitoring perspective, "NEEDINFO" by itself isn't >enough >>> from my point of view. There are other reasons a bug may be in a >>> PENDING state besides a need for additional information. > >the problem is that people run queries, and the only useful things to >check on are summaries (which you really don't want to change a lot), >status whiteboard (which many people ignore, and which others decorate >randomly). > >it can't even show flags (it can show keywords, so you could use them >for NEEDINFO/STACKWANTED/blah, but most people don't include keywords, >some people are actively trying to kill bugzilla's support for keywords, >and they don't clearly indicate that a bug is blocked until something >else happens) I would agree with you except the type of queries I'm talking about are not usually done by people, but by computers for the purpose of generating management-level reports. Managers want to know where issues are. One way to find out is to look at why bugs are not getting resolved. To do that at a glance, the manager must enforce the proper use of a "pending" status. By proper use, I mean that you can't just set status to pending and walk away from the bug. There has to be a reason why the bug is set up in a pending status. When a bug is put into that pending status, if a pending reason is attached to the status, someone can verify that the reason makes sense later on. When that status is from a specific list of pending statuses, now the manager can monitor the process. If the status and reason are correct, the reporting data makes sense. If people are abusing it by setting a pending status willy-nilly just to delay working on something, managers will be able to look at the information and see the abuse. What I'm talking about boils down to making Bugzilla more useful to management as a process management tool. --- Kevin Benton Perl/Bugzilla Developer Advanced Micro Devices The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. From micklweiss at gmx.net Tue Aug 9 16:50:54 2005 From: micklweiss at gmx.net (Mick Weiss) Date: Tue, 09 Aug 2005 12:50:54 -0400 Subject: "Environmental Variable" Authentication Method question.. In-Reply-To: <1123545661.3381.15.camel@localhost.localdomain> References: <1123485954.889002.261760@g44g2000cwa.googlegroups.com> <1123534192_307@spool6-east.superfeed.net> <1123545661.3381.15.camel@localhost.localdomain> Message-ID: <42F8DEEE.5030403@gmx.net> I'd say fwd that to whoever is doing work on the Documentation ;-) - Mick Max Kanat-Alexander wrote: > A lot of the below section would be good for the docs: > >On Mon, 2005-08-08 at 16:47 -0400, A. Karl Kornel wrote: > > >> There is only one required parameter for this form of authentication: >>auth_env_email. auth_env_email needs to be set to the name of an >>environment variable that contains the logged-in user's email address. >>Bugzilla identifies users by email address (also referred to as a login). >> >> auth_env_id and auth_env_realname are optional, but useful. >>auth_env_realname can be set to an environment variable that contains the >>logged-in user's real name, so when a user is logs in for the first time >>their real name is set up properly. Again, this is optional. >> >> auth_env_id is a bit more complicated. It can be set to an >>environment variable that contains some unique ID, something besides an email >>address, which can be used to identify this user. This unique ID should never >>change. It is used so that a person can change their e-mail address >>without losing access to their account (since the account is identified >>by e-mail address). >> >> Just to make sure I'm clear, those parameters don't contain the user's >>email/name/ID, the parameters contain the names of environment variables >>that contain the user's email/name/ID. >> >> Also, there are a couple of caveats with this. First, changes to a >>user's email or password must take place outside of Bugzilla, since this >>info is being managed outside of Bugzilla. Second, you can not log out >>through Bugzilla (Bugzilla didn't log you in, so it can't log you out!). >>Also, because of a bug that I don't really want to get into, it may be a >>good idea to have users log in before granting access to any Bugzilla >>pages. >> >> > > > From myk at mozilla.org Thu Aug 11 08:53:59 2005 From: myk at mozilla.org (Myk Melez) Date: Thu, 11 Aug 2005 01:53:59 -0700 Subject: second UI hackathon next Friday, August 19 Message-ID: <42FB1227.7000408@mozilla.org> The next UI hackathon is happening next Friday, August 19. Once again, we'll focus on the attachment UI, since although we made good progress on it in the last hackathon, we should get a little further before moving on to other things. In a change of format, however, I'll discuss and review patches to other UI as time allows, so if you have a burning desire to improve some other UI before that UI's hackathon rolls around, pop in to the IRC channel and ping me about it. I welcome the participation of all Bugzilla hackers and users who want to contribute to improving Bugzilla usability! Code reviewers would be particularly useful, since while I can review other hackers' patches, I can't review my own. Join me in the #hackathon channel (ircs://irc.mozilla.org:6697/%23hackathon) on irc.mozilla.org next Friday, August 19, from 10am to 6pm PDT. In the meantime, feel free to add ideas to the wiki scratchpad at http://wiki.mozilla.org/Bugzilla:UI_Hackathon. -myk From micklweiss at gmx.net Thu Aug 11 15:27:18 2005 From: micklweiss at gmx.net (Mick Weiss) Date: Thu, 11 Aug 2005 11:27:18 -0400 Subject: QA irc channel Message-ID: <42FB6E56.2090802@gmx.net> I'm not sure if everyone knows this, but we now have a QA channel for bugzilla. Anyone interested should come on in and say hello :-) ircs://irc.mozilla.org:6697/%23qa-bugzilla - Mick From gerv at mozilla.org Sun Aug 14 14:25:23 2005 From: gerv at mozilla.org (Gervase Markham) Date: Sun, 14 Aug 2005 15:25:23 +0100 Subject: [Fwd: Bugzilla users] Message-ID: <42FF5453.9000705@mozilla.org> Passing on the kudos... Gerv -------- Original Message -------- Subject: Bugzilla users Date: Fri, 12 Aug 2005 15:26:05 +0100 From: Graham Jones To: gerv at mozilla.org Dear Bugzilla team, Just a quick email to express our thanks and grattitude for such an outstanding product. As users for over a year now, we have found Bugzilla to be an invaluable tracking tool, having improved communication on many levels within our company. Issues become so readily visible and maneageable, leading to better team focus and higher quality of output. Thank you very much indeed! Please kindly include us in the "bugzilla users" list. Kind regards, Graham Jones Embedded Systems Team Leader Wayfarer Transit Systems Ltd. 10 Willis Way Poole Dorset BH15 3SS United Kingdom T: +44 (0) 1202 339455 M: +44 (0) 7710 429233 www.wayfarer.co.uk From dcalvert at AllianceBankNA.com Mon Aug 15 16:52:44 2005 From: dcalvert at AllianceBankNA.com (Calvert, Douglas) Date: Mon, 15 Aug 2005 12:52:44 -0400 Subject: Are the bugzilla templates for b.m.o in CVS? Message-ID: Hello, Are the bugzilla templates for b.m.o in CVS? I looked a little bit but could not find them. I would be interested in seeing how the mozilla folks do the guided bug entry. Thanks... From justdave at bugzilla.org Mon Aug 15 19:06:16 2005 From: justdave at bugzilla.org (David Miller) Date: Mon, 15 Aug 2005 15:06:16 -0400 Subject: Are the bugzilla templates for b.m.o in CVS? In-Reply-To: References: Message-ID: <4300E7A8.3040006@bugzilla.org> Calvert, Douglas wrote: > Hello, > Are the bugzilla templates for b.m.o in CVS? I looked a little bit but > could not find them. I would be interested in seeing how the mozilla > folks do the guided bug entry. Thanks... Yeah, the page in question is in the tarballs even. See template/en/default/bug/create/create-guided.html.tmpl The one on b.m.o is slightly modified from that, but not much. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Foundation http://www.mozilla.org/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From stethomas at ebay.com Tue Aug 16 00:37:00 2005 From: stethomas at ebay.com (Thomas, Steve) Date: Mon, 15 Aug 2005 18:37:00 -0600 Subject: Is Bugzilla on Windows/IIS a Bad Idea? Message-ID: <8E1982313133E740ABCCF578C7060FEC0619CB7E@DEN-EXM-02.corp.ebay.com> Hey folks, After some hacking, I have managed to get Bugzilla completely working on a Windows/IIS instance (with ActivePerl, etc. etc.). Mail, of course, doesn't work, even though I have the new build that is supposed to make it so you don't have to do anything on Windows to make it work (like you did before, wherein you had to hack code to make it work). I spent some amount of time hacking through the Mail:Mailing stuff and so on, and discovered that, as near as I can tell, its not even close to working. My initial take is that it will require a LOT more hacking to make mail work on Windows, so the "fix" from before actually made the situation much worse. (Note that this is my *initial take* -- I hope that I'm completely wrong and there's an easy fix, but I didn't see one anywhere). My overall question is this: should I just give up trying to make Bugzilla work on Windows, and is it a lost cause? Is there any significant installed base that is on Windows? Thanks again for your help, Steve Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.benton at amd.com Tue Aug 16 00:46:33 2005 From: kevin.benton at amd.com (Benton, Kevin) Date: Mon, 15 Aug 2005 17:46:33 -0700 Subject: Is Bugzilla on Windows/IIS a Bad Idea? Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201CE0553@ssvlexmb2.amd.com> Steve - I'm glad to report that Bugzilla works fine on Windows. What version of Bugzilla are you working with? While I'm using Apache, I am pretty certain that getting it to run under IIS isn't that difficult as I've heard others make it through the "gauntlet." The trick in getting mail to work with Bugzilla on Windows is to make sure you're set up to use SMTP as your delivery method. Apart from that, there are others here who have done it and can explain the process better. --- Kevin Benton Perl/Bugzilla Developer Advanced Micro Devices The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. ________________________________ From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] On Behalf Of Thomas, Steve Sent: Monday, August 15, 2005 6:37 PM To: developers at bugzilla.org Subject: Is Bugzilla on Windows/IIS a Bad Idea? Hey folks, After some hacking, I have managed to get Bugzilla completely working on a Windows/IIS instance (with ActivePerl, etc. etc.). Mail, of course, doesn't work, even though I have the new build that is supposed to make it so you don't have to do anything on Windows to make it work (like you did before, wherein you had to hack code to make it work). I spent some amount of time hacking through the Mail:Mailing stuff and so on, and discovered that, as near as I can tell, its not even close to working. My initial take is that it will require a LOT more hacking to make mail work on Windows, so the "fix" from before actually made the situation much worse. (Note that this is my *initial take* -- I hope that I'm completely wrong and there's an easy fix, but I didn't see one anywhere). My overall question is this: should I just give up trying to make Bugzilla work on Windows, and is it a lost cause? Is there any significant installed base that is on Windows? Thanks again for your help, Steve Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruce.armstrong at teamsybase.com Tue Aug 16 01:13:27 2005 From: bruce.armstrong at teamsybase.com (Bruce Armstrong [TeamSybase]) Date: Mon, 15 Aug 2005 18:13:27 -0700 (PDT) Subject: Is Bugzilla on Windows/IIS a Bad Idea? In-Reply-To: <8E1982313133E740ABCCF578C7060FEC0619CB7E@DEN-EXM-02.corp.ebay.com> Message-ID: <20050816011327.96635.qmail@web30705.mail.mud.yahoo.com> What version of Bugzilla are you using? All the latest builds are pretty much Windows friendly, and the docs on the few modifications needed to get working are pretty clear: http://www.bugzilla.org/docs/2.18/html/os-specific.html#os-win32 http://www.bugzilla.org/docs/2.18/html/configuration.html#http-iis --- "Thomas, Steve" wrote: > Hey folks, > > > > After some hacking, I have managed to get Bugzilla > completely working on > a Windows/IIS instance (with ActivePerl, etc. etc.). > > > > Mail, of course, doesn't work, even though I have > the new build that is > supposed to make it so you don't have to do anything > on Windows to make > it work (like you did before, wherein you had to > hack code to make it > work). > > > > I spent some amount of time hacking through the > Mail:Mailing stuff and > so on, and discovered that, as near as I can tell, > its not even close to > working. My initial take is that it will require a > LOT more hacking to > make mail work on Windows, so the "fix" from before > actually made the > situation much worse. (Note that this is my *initial > take* -- I hope > that I'm completely wrong and there's an easy fix, > but I didn't see one > anywhere). > > > > My overall question is this: should I just give up > trying to make > Bugzilla work on Windows, and is it a lost cause? Is > there any > significant installed base that is on Windows? > > > > Thanks again for your help, > > > > > > Steve Thomas > > > > > > > > > > Bruce Armstrong [TeamSybase] --------------------------------- http://www.teamsybase.com Preach the gospel at all times. If necessary, use words. -- Francis of Assisi http://www.needhim.org From jpyeron at pdinc.us Tue Aug 16 02:43:58 2005 From: jpyeron at pdinc.us (Jason Pyeron) Date: Mon, 15 Aug 2005 22:43:58 -0400 (EDT) Subject: Is Bugzilla on Windows/IIS a Bad Idea? In-Reply-To: <20050816011327.96635.qmail@web30705.mail.mud.yahoo.com> References: <20050816011327.96635.qmail@web30705.mail.mud.yahoo.com> Message-ID: we use cygwin On Mon, 15 Aug 2005, Bruce Armstrong [TeamSybase] wrote: > What version of Bugzilla are you using? All the > latest builds are pretty much Windows friendly, and > the docs on the few modifications needed to get > working are pretty clear: > > http://www.bugzilla.org/docs/2.18/html/os-specific.html#os-win32 > > http://www.bugzilla.org/docs/2.18/html/configuration.html#http-iis > > > --- "Thomas, Steve" wrote: > >> Hey folks, >> >> >> >> After some hacking, I have managed to get Bugzilla >> completely working on >> a Windows/IIS instance (with ActivePerl, etc. etc.). >> >> >> >> Mail, of course, doesn't work, even though I have >> the new build that is >> supposed to make it so you don't have to do anything >> on Windows to make >> it work (like you did before, wherein you had to >> hack code to make it >> work). >> >> >> >> I spent some amount of time hacking through the >> Mail:Mailing stuff and >> so on, and discovered that, as near as I can tell, >> its not even close to >> working. My initial take is that it will require a >> LOT more hacking to >> make mail work on Windows, so the "fix" from before >> actually made the >> situation much worse. (Note that this is my *initial >> take* -- I hope >> that I'm completely wrong and there's an easy fix, >> but I didn't see one >> anywhere). >> >> >> >> My overall question is this: should I just give up >> trying to make >> Bugzilla work on Windows, and is it a lost cause? Is >> there any >> significant installed base that is on Windows? >> >> >> >> Thanks again for your help, >> >> >> >> >> >> Steve Thomas >> >> >> >> >> >> >> >> >> >> > > Bruce Armstrong [TeamSybase] > > --------------------------------- > http://www.teamsybase.com > > Preach the gospel at all times. > If necessary, use words. -- Francis of Assisi > http://www.needhim.org > > - > To view or change your list settings, click here: > > -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Partner & Sr. Manager 7 West 24th Street #100 - - +1 (443) 921-0381 Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 jpyeron at pdinc.us Tue Aug 16 02:48:12 2005 From: jpyeron at pdinc.us (Jason Pyeron) Date: Mon, 15 Aug 2005 22:48:12 -0400 (EDT) Subject: Is Bugzilla on Windows/IIS a Bad Idea? In-Reply-To: <20050816011327.96635.qmail@web30705.mail.mud.yahoo.com> References: <20050816011327.96635.qmail@web30705.mail.mud.yahoo.com> Message-ID: Sorry, for the last post. We have been able to use cygwin's perl and Bugzilla out of the box, for a few years now. I know alot of changes have been made for ActiveState perl, if you have trouble, take a look at http://cygwin.com/setup.exe. You will be able to do this on NT4, 2000, and XP. -jason On Mon, 15 Aug 2005, Bruce Armstrong [TeamSybase] wrote: > What version of Bugzilla are you using? All the > latest builds are pretty much Windows friendly, and > the docs on the few modifications needed to get > working are pretty clear: > > http://www.bugzilla.org/docs/2.18/html/os-specific.html#os-win32 > > http://www.bugzilla.org/docs/2.18/html/configuration.html#http-iis > > > --- "Thomas, Steve" wrote: > >> Hey folks, >> >> >> >> After some hacking, I have managed to get Bugzilla >> completely working on >> a Windows/IIS instance (with ActivePerl, etc. etc.). >> >> >> >> Mail, of course, doesn't work, even though I have >> the new build that is >> supposed to make it so you don't have to do anything >> on Windows to make >> it work (like you did before, wherein you had to >> hack code to make it >> work). >> >> >> >> I spent some amount of time hacking through the >> Mail:Mailing stuff and >> so on, and discovered that, as near as I can tell, >> its not even close to >> working. My initial take is that it will require a >> LOT more hacking to >> make mail work on Windows, so the "fix" from before >> actually made the >> situation much worse. (Note that this is my *initial >> take* -- I hope >> that I'm completely wrong and there's an easy fix, >> but I didn't see one >> anywhere). >> >> >> >> My overall question is this: should I just give up >> trying to make >> Bugzilla work on Windows, and is it a lost cause? Is >> there any >> significant installed base that is on Windows? >> >> >> >> Thanks again for your help, >> >> >> >> >> >> Steve Thomas >> >> >> >> >> >> >> >> >> >> > > Bruce Armstrong [TeamSybase] > > --------------------------------- > http://www.teamsybase.com > > Preach the gospel at all times. > If necessary, use words. -- Francis of Assisi > http://www.needhim.org > > - > To view or change your list settings, click here: > > -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Partner & Sr. Manager 7 West 24th Street #100 - - +1 (443) 921-0381 Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Tue Aug 16 08:45:13 2005 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 16 Aug 2005 09:45:13 +0100 Subject: Are the bugzilla templates for b.m.o in CVS? In-Reply-To: References: Message-ID: <4301A799.1050002@mozilla.org> Calvert, Douglas wrote: > Hello, > Are the bugzilla templates for b.m.o in CVS? I looked a little bit but > could not find them. I would be interested in seeing how the mozilla > folks do the guided bug entry. Thanks... They aren't all in CVS (for example, the custom front page) but that one is. create-guided.html.tmpl. Gerv From gerv at mozilla.org Tue Aug 16 10:23:14 2005 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 16 Aug 2005 11:23:14 +0100 Subject: [Fwd: Bugzilla users map] Message-ID: <4301BE92.4050804@mozilla.org> Guys, Does this sound like a good idea? (It appears to be powered by Google Maps.) Gerv -------- Original Message -------- Subject: Bugzilla users map Date: Mon, 15 Aug 2005 07:19:56 -0700 From: Claire McLister To: gerv at mozilla.org Hi, Would you be interested in creating a world map pin-pointing Bugzilla users? We have started a new service, called ZeeMaps, that easily allows group members to mark their locations on an interactive world map. (http://www.zeemaps.com) If you wish, you can create a ZeeMap for Bugzilla users and then email them the URL with the map password so they could add their own entries. Would be cool to see where all in the world Bugzilla is being used. Best wishes Claire -- Claire McLister mclister at zeesource.net 1684 Nightingale Avenue Suite 201 Sunnyvale, CA 94087 408-733-2737(fax) http://www.zeesource.net From luis.villa at gmail.com Tue Aug 16 12:11:42 2005 From: luis.villa at gmail.com (Luis Villa) Date: Tue, 16 Aug 2005 08:11:42 -0400 Subject: [Fwd: Bugzilla users map] In-Reply-To: <4301BE92.4050804@mozilla.org> References: <4301BE92.4050804@mozilla.org> Message-ID: <2cb10c44050816051157573b55@mail.gmail.com> We've at least had fun doing something similar for GNOME developers: http://live.gnome.org/GnomeWorldWide Luis On 8/16/05, Gervase Markham wrote: > Guys, > > Does this sound like a good idea? (It appears to be powered by Google Maps.) > > Gerv > > -------- Original Message -------- > Subject: Bugzilla users map > Date: Mon, 15 Aug 2005 07:19:56 -0700 > From: Claire McLister > To: gerv at mozilla.org > > Hi, > > Would you be interested in creating a world map pin-pointing Bugzilla > users? > > We have started a new service, called ZeeMaps, that easily allows > group members > to mark their locations on an interactive world map. > (http://www.zeemaps.com) > > If you wish, you can create a ZeeMap for Bugzilla users and then email > them the > URL with the map password so they could add their own entries. > > Would be cool to see where all in the world Bugzilla is being used. > > Best wishes > > Claire > > -- > Claire McLister mclister at zeesource.net > 1684 Nightingale Avenue Suite 201 > Sunnyvale, CA 94087 408-733-2737(fax) > > http://www.zeesource.net > > - > To view or change your list settings, click here: > > From Habers at pbworld.com Tue Aug 16 13:31:05 2005 From: Habers at pbworld.com (Habers, Mark) Date: Tue, 16 Aug 2005 09:31:05 -0400 Subject: Is Bugzilla on Windows/IIS a Bad Idea? Message-ID: <2BAAFCCCE018A447877157AFCED973440CAEF07D@nycmrmt2.corp.pbwan.net> Hi Steve, I finished upgrading our company BugZilla install to 2.20rc2 this past weekend and am running on IIS and have been running on Windows for 3 years now with various versions. I have to say, things are so much better now, but there are still some minor issues. Checksetup.pl did not run for me as is. The main reason in my case was that I was upgrading a pretty old BZ database and checksetup bombed on me repeatedly trying to convert some of my tables. I'd elaborate, but it doesn't sound like you had that issue. However, I was able to get past the issues by searching on google and in the mozilla.bugzilla.org site. For some reason I did have to modify the first line of all the CGI files to point to my Perl path, which probably means I screwed up because I didn't have to do this when I installed 2.18 on a clean environment. Anyway, to make a long story short, email worked right out of the box for me. On Version 2.20 you should be prompted to enter your smtp server during one of the checksetup runs. I didn't have to touch anything aside from that. I would recommend giving 2.20 a shot if that is not what you attempted to install and if it was what you installed, you probably have a problem on your smtp box. I have some horror stories about getting email to work on prior versions, but was overall very impressed with the progress the bugzilla team has made in providing substantial built in support for the OS I have no choice but to use and support in my job. Regards, Mark _____ From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] On Behalf Of Thomas, Steve Sent: Monday, August 15, 2005 6:37 PM To: developers at bugzilla.org Subject: Is Bugzilla on Windows/IIS a Bad Idea? Hey folks, After some hacking, I have managed to get Bugzilla completely working on a Windows/IIS instance (with ActivePerl, etc. etc.). Mail, of course, doesn't work, even though I have the new build that is supposed to make it so you don't have to do anything on Windows to make it work (like you did before, wherein you had to hack code to make it work). I spent some amount of time hacking through the Mail:Mailing stuff and so on, and discovered that, as near as I can tell, its not even close to working. My initial take is that it will require a LOT more hacking to make mail work on Windows, so the "fix" from before actually made the situation much worse. (Note that this is my *initial take* -- I hope that I'm completely wrong and there's an easy fix, but I didn't see one anywhere). My overall question is this: should I just give up trying to make Bugzilla work on Windows, and is it a lost cause? Is there any significant installed base that is on Windows? Thanks again for your help, Steve Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkanat at bugzilla.org Tue Aug 16 20:13:57 2005 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 16 Aug 2005 13:13:57 -0700 Subject: [Fwd: Bugzilla users map] In-Reply-To: <4301BE92.4050804@mozilla.org> References: <4301BE92.4050804@mozilla.org> Message-ID: <1124223238.3348.0.camel@localhost.localdomain> On Tue, 2005-08-16 at 11:23 +0100, Gervase Markham wrote: > Does this sound like a good idea? (It appears to be powered by Google Maps.) Sounds like fun. Don't see why not. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From mkanat at bugzilla.org Tue Aug 16 20:16:12 2005 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 16 Aug 2005 13:16:12 -0700 Subject: Is Bugzilla on Windows/IIS a Bad Idea? In-Reply-To: <2BAAFCCCE018A447877157AFCED973440CAEF07D@nycmrmt2.corp.pbwan.net> References: <2BAAFCCCE018A447877157AFCED973440CAEF07D@nycmrmt2.corp.pbwan.net> Message-ID: <1124223372.3348.3.camel@localhost.localdomain> On Tue, 2005-08-16 at 09:31 -0400, Habers, Mark wrote: > The main reason in my case was that I was upgrading a pretty old BZ > database and checksetup bombed on me repeatedly trying to convert some > of my tables. If you still have the exact error messages around that checksetup gave you (or a copy of your old database schema) I'd appreciate a bug report on that -- checksetup should ideally be able to upgrade from any version to any version. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From Habers at pbworld.com Tue Aug 16 21:37:50 2005 From: Habers at pbworld.com (Habers, Mark) Date: Tue, 16 Aug 2005 17:37:50 -0400 Subject: Is Bugzilla on Windows/IIS a Bad Idea? Message-ID: <2BAAFCCCE018A447877157AFCED973440CD1ABC4@nycmrmt2.corp.pbwan.net> Hi Max, I'm sorry, but I don't have the details in front of me. I was previously running BugZilla version 2.17.4 I do remember that an overly problematic area was the code block in checksetup at line 3573, specifically, $dbh->bz_drop_column("group_group_map", "isbless"); I was throwing a duplicate key error at that line...and checksetup stopped there. That's all I can say with confidence until I try and repeat the install on a local machine somewhere with my old db again. I'll do it again this week if I can. I seem to recall getting past the problem by doing that portion manually after issuing a repair table command... could be wrong though, I tried many things and there were a couple other errors, but nothing major, I'm running, and my users are happy. If I duplicate the issues I'll report them next time. I am more familiar with SQL Server than MySQL... sorry if this is a dumb question, but is it just a limitation of MySQL that prevents a huge script like checksetup from continuing on when it runs into a non-showstopper kind of problem? Would it be technically possible to port this over to something like SQL Server or Oracle? The frustration factor increases big time when 1 line out of several thousand has an issue of some sort and the script just dies instead of executing the rest... Realizing that sometimes executing the rest wouldn't be a good idea... but also sometimes it would be if at all possible. I do have to remind myself that this is a free DB and overall, it rocks. In fact, if you guys would like some Windows specific QA, I can probably smk test the install of 'almost ready for production' builds for you from time to time. I'm probably a good guinea pig after using BZ on Windows way before I probably should have attempted it. Thanks Mark -----Original Message----- From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] On Behalf Of Max Kanat-Alexander Sent: Tuesday, August 16, 2005 2:16 PM To: developers at bugzilla.org Subject: Re: Is Bugzilla on Windows/IIS a Bad Idea? On Tue, 2005-08-16 at 09:31 -0400, Habers, Mark wrote: > The main reason in my case was that I was upgrading a pretty old BZ > database and checksetup bombed on me repeatedly trying to convert some > of my tables. If you still have the exact error messages around that checksetup gave you (or a copy of your old database schema) I'd appreciate a bug report on that -- checksetup should ideally be able to upgrade from any version to any version. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. - To view or change your list settings, click here: From mkanat at bugzilla.org Tue Aug 16 22:24:00 2005 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 16 Aug 2005 15:24:00 -0700 Subject: Is Bugzilla on Windows/IIS a Bad Idea? In-Reply-To: <2BAAFCCCE018A447877157AFCED973440CD1ABC4@nycmrmt2.corp.pbwan.net> References: <2BAAFCCCE018A447877157AFCED973440CD1ABC4@nycmrmt2.corp.pbwan.net> Message-ID: <1124231040.3360.10.camel@localhost.localdomain> On Tue, 2005-08-16 at 17:37 -0400, Habers, Mark wrote: > I was throwing a duplicate key error at that line...and checksetup > stopped there. That's all I can say with confidence until I try and > repeat the install on a local machine somewhere with my old db again. > I'll do it again this week if I can. Yeah, I'd appreciate that, so that I could see the exact error. > I seem to recall getting past the > problem by doing that portion manually after issuing a repair table > command... [snip] If REPAIR TABLE was in fact the command you used to fix it, then the fault was not in checksetup but in the fact that your MySQL tables were corrupted. There is certainly nothing that checksetup could have done about that, really. :-) > I am more familiar with SQL Server than MySQL... sorry if this is a dumb > question, but is it just a limitation of MySQL that prevents a huge > script like checksetup from continuing on when it runs into a > non-showstopper kind of problem? If it was in fact a REPAIR TABLE that you had to issue to fix the problem, then the problem is definitely a showstopper. There is very little that any script or program can do with a corrupt table. > Would it be technically possible to port this over to something like > SQL Server or Oracle? Oracle: https://bugzilla.mozilla.org/show_bug.cgi?id=189947 MS-SQL: https://bugzilla.mozilla.org/show_bug.cgi?id=285122 If your perl skills are good, you're free to attempt to tackle or help tackle either one of those. Instructions exist in the comments. Otherwise, you're also free to hire me/somebody or otherwise induce me/somebody to get Bugzilla running on either of those database systems. MS-SQL will probably be particularly hard, as it is based on a very-non-ANSI-standard database. Oracle is one I'd like to do, but it's a bit difficult to get a testing installation working on a remote server that I have only SSH access to (since Oracle, strangely enough for an enterprise product, requires a GUI to install in a normal fashion). > The frustration > factor increases big time when 1 line out of several thousand has an > issue of some sort and the script just dies instead of executing the > rest... checksetup in general is dependent upon everything working in order. Nearly always it does. In fact, we have quite intense regression-testing of checksetup to make sure that it can upgrade any unmodified database from any version to our daily CVS version. > In fact, if you guys would like some Windows specific QA, I can probably > smk test the install of 'almost ready for production' builds for you > from time to time. I'm probably a good guinea pig after using BZ on > Windows way before I probably should have attempted it. That would be wonderful. We have QA efforts right before we release, and you can contact lpsolit -at- gmail or join the #qa-bugzilla channel on irc.mozilla.org to find out how you can help. :-) -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From myk at mozilla.org Wed Aug 17 21:17:02 2005 From: myk at mozilla.org (Myk Melez) Date: Wed, 17 Aug 2005 14:17:02 -0700 Subject: second UI hackathon next Friday, August 19 In-Reply-To: <42FB1227.7000408@mozilla.org> References: <42FB1227.7000408@mozilla.org> Message-ID: <4303A94E.4080402@mozilla.org> Myk Melez wrote: > Join me in the #hackathon channel > (ircs://irc.mozilla.org:6697/%23hackathon) on irc.mozilla.org next > Friday, August 19, from 10am to 6pm PDT. Due to scheduling conflicts, I'll be late to this hackathon, arriving by 11am. Sorry for the inconvenience and late notice. Get your patches ready! -myk From stethomas at ebay.com Thu Aug 18 02:14:09 2005 From: stethomas at ebay.com (Thomas, Steve) Date: Wed, 17 Aug 2005 20:14:09 -0600 Subject: Is Bugzilla on Windows/IIS a Bad Idea? Message-ID: <8E1982313133E740ABCCF578C7060FEC063512F1@DEN-EXM-02.corp.ebay.com> I upgraded to 2.20 and set my smtpserver param to our main internal mail server, along with trying out "localhost" (there is an smtpserver running on the local system). No luck. There are no errors, and otherwise no indication that there is anything wrong, except for the fact that nothing happens. I will try to track down the code again, but I suspect that Mail:Mailer is broken somehow. Steve. ________________________________ From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] On Behalf Of Habers, Mark Sent: Tuesday, August 16, 2005 6:31 AM To: developers at bugzilla.org Subject: Re: Is Bugzilla on Windows/IIS a Bad Idea? Hi Steve, I finished upgrading our company BugZilla install to 2.20rc2 this past weekend and am running on IIS and have been running on Windows for 3 years now with various versions. I have to say, things are so much better now, but there are still some minor issues. Checksetup.pl did not run for me as is. The main reason in my case was that I was upgrading a pretty old BZ database and checksetup bombed on me repeatedly trying to convert some of my tables. I'd elaborate, but it doesn't sound like you had that issue. However, I was able to get past the issues by searching on google and in the mozilla.bugzilla.org site. For some reason I did have to modify the first line of all the CGI files to point to my Perl path, which probably means I screwed up because I didn't have to do this when I installed 2.18 on a clean environment. Anyway, to make a long story short, email worked right out of the box for me. On Version 2.20 you should be prompted to enter your smtp server during one of the checksetup runs. I didn't have to touch anything aside from that. I would recommend giving 2.20 a shot if that is not what you attempted to install and if it was what you installed, you probably have a problem on your smtp box. I have some horror stories about getting email to work on prior versions, but was overall very impressed with the progress the bugzilla team has made in providing substantial built in support for the OS I have no choice but to use and support in my job. Regards, Mark ________________________________ From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] On Behalf Of Thomas, Steve Sent: Monday, August 15, 2005 6:37 PM To: developers at bugzilla.org Subject: Is Bugzilla on Windows/IIS a Bad Idea? Hey folks, After some hacking, I have managed to get Bugzilla completely working on a Windows/IIS instance (with ActivePerl, etc. etc.). Mail, of course, doesn't work, even though I have the new build that is supposed to make it so you don't have to do anything on Windows to make it work (like you did before, wherein you had to hack code to make it work). I spent some amount of time hacking through the Mail:Mailing stuff and so on, and discovered that, as near as I can tell, its not even close to working. My initial take is that it will require a LOT more hacking to make mail work on Windows, so the "fix" from before actually made the situation much worse. (Note that this is my *initial take* -- I hope that I'm completely wrong and there's an easy fix, but I didn't see one anywhere). My overall question is this: should I just give up trying to make Bugzilla work on Windows, and is it a lost cause? Is there any significant installed base that is on Windows? Thanks again for your help, Steve Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From kiffin at nl.demon.net Fri Aug 19 08:55:07 2005 From: kiffin at nl.demon.net (Kiffin Gish) Date: Fri, 19 Aug 2005 10:55:07 +0200 Subject: Planned release date for Bugzilla v2.20 ... Message-ID: <43059E6B.5030908@nl.demon.net> I've been playing around (testing) rc2 and it seems to work well. Just curious if there is a tentative deadline for the next version of Bugzilla. Thanks alot in advance. -- Kiffin Gish Development Team, Demon (THUS plc) Postbus 15829 1001 NH Amsterdam The Netherlands T: +31 (0)20-422 20 00 F: +31 (0)20-422 20 01 M: +31 (0)6-21 83 68 28 http://www.demon.nl From mkanat at bugzilla.org Fri Aug 19 09:32:58 2005 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 19 Aug 2005 02:32:58 -0700 Subject: Away For Four Days Message-ID: <1124443978.3573.1.camel@localhost.localdomain> I'll be gone from today (Friday) through Monday, and I probably won't have much access to a computer during that time. (I'll be at a music seminar in Los Angeles, CA.) -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From stethomas at ebay.com Fri Aug 19 19:45:30 2005 From: stethomas at ebay.com (Thomas, Steve) Date: Fri, 19 Aug 2005 13:45:30 -0600 Subject: SMTP on Windows/IIS update Message-ID: <8E1982313133E740ABCCF578C7060FEC0491FE5F@DEN-EXM-02.corp.ebay.com> Hey folks, I'm still trying to get this to work. Since I am a PHP programmer (actually my background includes almost everything *except* Perl), doing what seems to be required--rewriting the SMTP code--is not a good option for me. As such I wrote a PHP script to send an email (a one-liner) and my plan is to have BugMail simply call the script using HTTP. I still have no clue as to why the original code doesn't work. When I switch to using localhost directly and turn on the local SMTP server, I do in fact see the mail messages gather in the outbound queue, but they go nowhere from there. When I talk directly to the corporate SMTP server (which is Exchange, which is probably the problem overall), it just sucks up the mail message with no errors at all (or at least none that I get to see given the SMTP code). Thinking I could just drop in the open() call to the PHP script would be easy is turning out to be wrong as well. Given the sendmail roots (apparently) of the Bugzilla mail functionality deriving what you need for a normal mail interface (from, to, subject, message) is actually pretty hard for somebody with little Perl experience. Somebody that actually knows what they are doing could probably write me such a snippet in about 5 minutes, but oh well. If anybody has any other tricks I might pull to get the current SMTP code working with an MS exchange server, that would be splendid. Note that (as implied above) PHP's built-in mailer seems to have no problem sending mail to our servers. Thanks, Steve Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 3735 bytes Desc: not available URL: From stethomas at ebay.com Fri Aug 19 19:45:59 2005 From: stethomas at ebay.com (Thomas, Steve) Date: Fri, 19 Aug 2005 13:45:59 -0600 Subject: PS: I am using 2.20rc1 Message-ID: <8E1982313133E740ABCCF578C7060FEC0491FE60@DEN-EXM-02.corp.ebay.com> Just an addendum to my previous message, I *am* now using the latest build as of about 4 days ago... -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 2471 bytes Desc: not available URL: From Habers at pbworld.com Fri Aug 19 20:31:28 2005 From: Habers at pbworld.com (Habers, Mark) Date: Fri, 19 Aug 2005 16:31:28 -0400 Subject: SMTP on Windows/IIS update Message-ID: <2BAAFCCCE018A447877157AFCED973440CD1B495@nycmrmt2.corp.pbwan.net> Hi Steve, This is probably a support issue that eventually one of the developers here is going to request we take to that forum... I have a similar setup as you though and would offer the following suggestion. Talk to your exchange people and make sure that the SMTP server you are using is trusted to relay email to Exchange. In all but the most insecure environments, Exchange will not accept email from just any server on the WAN that happens to be running SMTP. I have 30 different SMTP boxes available here that I can use to relay my email from BugZilla. A fraction of those servers are actually trusted by Exchange to route said email to the corporate Exchange system. I also do not receive any errors on the BugZilla side when I point to an SMTP box that is not trusted. I believe you are having the same issue. I would start there before rewriting anything... To test this theory, identify another SMTP box on your network that is already able to send out email to your users, employees, etc.. and piggy back on that one instead. If your email starts working, the problem is at hand. If you don't have another SMTP box available that you know is sending email successfully, you will have to get your Exchange people to add your box as trusted and go from there... You'll probably want to do that anyway just to stay out of trouble and to keep from having to revisit this problem again down the road. Just my 2 cents.. Mark _____ From: Thomas, Steve [mailto:developers-owner at bugzilla.org] On Behalf Of Thomas, Steve Sent: Friday, August 19, 2005 1:46 PM To: developers at bugzilla.org Subject: SMTP on Windows/IIS update Hey folks, I'm still trying to get this to work. Since I am a PHP programmer (actually my background includes almost everything *except* Perl), doing what seems to be required--rewriting the SMTP code--is not a good option for me. As such I wrote a PHP script to send an email (a one-liner) and my plan is to have BugMail simply call the script using HTTP. I still have no clue as to why the original code doesn't work. When I switch to using localhost directly and turn on the local SMTP server, I do in fact see the mail messages gather in the outbound queue, but they go nowhere from there. When I talk directly to the corporate SMTP server (which is Exchange, which is probably the problem overall), it just sucks up the mail message with no errors at all (or at least none that I get to see given the SMTP code). Thinking I could just drop in the open() call to the PHP script would be easy is turning out to be wrong as well. Given the sendmail roots (apparently) of the Bugzilla mail functionality deriving what you need for a normal mail interface (from, to, subject, message) is actually pretty hard for somebody with little Perl experience. Somebody that actually knows what they are doing could probably write me such a snippet in about 5 minutes, but oh well. If anybody has any other tricks I might pull to get the current SMTP code working with an MS exchange server, that would be splendid. Note that (as implied above) PHP's built-in mailer seems to have no problem sending mail to our servers. Thanks, Steve Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From stethomas at ebay.com Fri Aug 19 23:11:38 2005 From: stethomas at ebay.com (Thomas, Steve) Date: Fri, 19 Aug 2005 17:11:38 -0600 Subject: SMTP on Windows/IIS update Message-ID: <8E1982313133E740ABCCF578C7060FEC0491FE62@DEN-EXM-02.corp.ebay.com> The PHP mailer works fine on the same exact box, so the issue is not a firewall/permissions problem. This is a highly, highly secure environment so Sendmail daemons are not allowed to exist here :-). I'll keep looking into it and let you know how it goes... Steve. ________________________________ From: developers-owner at bugzilla.org on behalf of Habers, Mark Sent: Fri 8/19/2005 1:31 PM To: developers at bugzilla.org Subject: Re: SMTP on Windows/IIS update Hi Steve, This is probably a support issue that eventually one of the developers here is going to request we take to that forum... I have a similar setup as you though and would offer the following suggestion. Talk to your exchange people and make sure that the SMTP server you are using is trusted to relay email to Exchange. In all but the most insecure environments, Exchange will not accept email from just any server on the WAN that happens to be running SMTP. I have 30 different SMTP boxes available here that I can use to relay my email from BugZilla. A fraction of those servers are actually trusted by Exchange to route said email to the corporate Exchange system. I also do not receive any errors on the BugZilla side when I point to an SMTP box that is not trusted. I believe you are having the same issue. I would start there before rewriting anything... To test this theory, identify another SMTP box on your network that is already able to send out email to your users, employees, etc.. and piggy back on that one instead. If your email starts working, the problem is at hand. If you don't have another SMTP box available that you know is sending email successfully, you will have to get your Exchange people to add your box as trusted and go from there... You'll probably want to do that anyway just to stay out of trouble and to keep from having to revisit this problem again down the road. Just my 2 cents.. Mark ________________________________ From: Thomas, Steve [mailto:developers-owner at bugzilla.org] On Behalf Of Thomas, Steve Sent: Friday, August 19, 2005 1:46 PM To: developers at bugzilla.org Subject: SMTP on Windows/IIS update Hey folks, I'm still trying to get this to work. Since I am a PHP programmer (actually my background includes almost everything *except* Perl), doing what seems to be required--rewriting the SMTP code--is not a good option for me. As such I wrote a PHP script to send an email (a one-liner) and my plan is to have BugMail simply call the script using HTTP. I still have no clue as to why the original code doesn't work. When I switch to using localhost directly and turn on the local SMTP server, I do in fact see the mail messages gather in the outbound queue, but they go nowhere from there. When I talk directly to the corporate SMTP server (which is Exchange, which is probably the problem overall), it just sucks up the mail message with no errors at all (or at least none that I get to see given the SMTP code). Thinking I could just drop in the open() call to the PHP script would be easy is turning out to be wrong as well. Given the sendmail roots (apparently) of the Bugzilla mail functionality deriving what you need for a normal mail interface (from, to, subject, message) is actually pretty hard for somebody with little Perl experience. Somebody that actually knows what they are doing could probably write me such a snippet in about 5 minutes, but oh well. If anybody has any other tricks I might pull to get the current SMTP code working with an MS exchange server, that would be splendid. Note that (as implied above) PHP's built-in mailer seems to have no problem sending mail to our servers. Thanks, Steve Thomas From justdave at bugzilla.org Fri Aug 19 23:47:56 2005 From: justdave at bugzilla.org (David Miller) Date: Fri, 19 Aug 2005 19:47:56 -0400 Subject: Planned release date for Bugzilla v2.20 ... In-Reply-To: <43059E6B.5030908@nl.demon.net> References: <43059E6B.5030908@nl.demon.net> Message-ID: <43066FAC.1000109@bugzilla.org> Kiffin Gish wrote: > I've been playing around (testing) rc2 and it seems to work well. > > Just curious if there is a tentative deadline for the next version of > Bugzilla. We're hoping to get it up on bugzilla.mozilla.org this coming weekend. We fully expect (based on past experience because it has such a large user base) to have a large number of regression bugs filed after doing that. The final 2.20 will get released as soon as those regressions are dealt with (which hopefully won't take more than a week or two). -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Foundation http://www.mozilla.org/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From micklweiss at gmx.net Sat Aug 20 01:32:25 2005 From: micklweiss at gmx.net (Mick Weiss) Date: Fri, 19 Aug 2005 21:32:25 -0400 Subject: SMTP on Windows/IIS update In-Reply-To: <8E1982313133E740ABCCF578C7060FEC0491FE62@DEN-EXM-02.corp.ebay.com> References: <8E1982313133E740ABCCF578C7060FEC0491FE62@DEN-EXM-02.corp.ebay.com> Message-ID: <43068829.90903@gmx.net> Thomas, Steve wrote: >The PHP mailer works fine on the same exact box, so the issue is not a firewall/permissions problem. > >This is a highly, highly secure environment so Sendmail daemons are not allowed to exist here :-). > > ROTFL. Thats why you use Windows / IIS. Which has a great history of security. ;-) good luck w/ that. - Mick > >I'll keep looking into it and let you know how it goes... > > >Steve. > > >________________________________ > >From: developers-owner at bugzilla.org on behalf of Habers, Mark >Sent: Fri 8/19/2005 1:31 PM >To: developers at bugzilla.org >Subject: Re: SMTP on Windows/IIS update > > > >Hi Steve, > >This is probably a support issue that eventually one of the developers here is going to request we take to that forum... I have a similar setup as you though and would offer the following suggestion. Talk to your exchange people and make sure that the SMTP server you are using is trusted to relay email to Exchange. In all but the most insecure environments, Exchange will not accept email from just any server on the WAN that happens to be running SMTP. I have 30 different SMTP boxes available here that I can use to relay my email from BugZilla. A fraction of those servers are actually trusted by Exchange to route said email to the corporate Exchange system. I also do not receive any errors on the BugZilla side when I point to an SMTP box that is not trusted. I believe you are having the same issue. I would start there before rewriting anything... To test this theory, identify another SMTP box on your network that is already able to send out email to your users, employees, etc! > .. and piggy back on that one instead. If your email starts working, the problem is at hand. If you don't have another SMTP box available that you know is sending email successfully, you will have to get your Exchange people to add your box as trusted and go from there... You'll probably want to do that anyway just to stay out of trouble and to keep from having to revisit this problem again down the road. Just my 2 cents.. > > > >Mark > > > >________________________________ > >From: Thomas, Steve [mailto:developers-owner at bugzilla.org] On Behalf Of Thomas, Steve >Sent: Friday, August 19, 2005 1:46 PM >To: developers at bugzilla.org >Subject: SMTP on Windows/IIS update > > > >Hey folks, > >I'm still trying to get this to work. Since I am a PHP programmer (actually my background includes almost everything *except* Perl), doing what seems to be required--rewriting the SMTP code--is not a good option for me. As such I wrote a PHP script to send an email (a one-liner) and my plan is to have BugMail simply call the script using HTTP. > >I still have no clue as to why the original code doesn't work. When I switch to using localhost directly and turn on the local SMTP server, I do in fact see the mail messages gather in the outbound queue, but they go nowhere from there. When I talk directly to the corporate SMTP server (which is Exchange, which is probably the problem overall), it just sucks up the mail message with no errors at all (or at least none that I get to see given the SMTP code). > >Thinking I could just drop in the open() call to the PHP script would be easy is turning out to be wrong as well. Given the sendmail roots (apparently) of the Bugzilla mail functionality deriving what you need for a normal mail interface (from, to, subject, message) is actually pretty hard for somebody with little Perl experience. Somebody that actually knows what they are doing could probably write me such a snippet in about 5 minutes, but oh well. > >If anybody has any other tricks I might pull to get the current SMTP code working with an MS exchange server, that would be splendid. Note that (as implied above) PHP's built-in mailer seems to have no problem sending mail to our servers. > >Thanks, > > > >Steve Thomas > > > > >- >To view or change your list settings, click here: > > > > > From micklweiss at gmx.net Sat Aug 20 01:52:00 2005 From: micklweiss at gmx.net (Mick Weiss) Date: Fri, 19 Aug 2005 21:52:00 -0400 Subject: Is Bugzilla on Windows/IIS a Bad Idea? In-Reply-To: <1124231040.3360.10.camel@localhost.localdomain> References: <2BAAFCCCE018A447877157AFCED973440CD1ABC4@nycmrmt2.corp.pbwan.net> <1124231040.3360.10.camel@localhost.localdomain> Message-ID: <43068CC0.2040609@gmx.net> There is a Windows QA effort already in place. I'm working with another person on this. Feel free to e-mail me if you'd like access to the current box that we are using. If you want to help with the QA stuff. This is not yet in bugzilla's landfill. (we have some issues finding a decent place to host, so it is on my DSL for now) - Mick Max Kanat-Alexander wrote: >On Tue, 2005-08-16 at 17:37 -0400, Habers, Mark wrote: > > >>I was throwing a duplicate key error at that line...and checksetup >>stopped there. That's all I can say with confidence until I try and >>repeat the install on a local machine somewhere with my old db again. >>I'll do it again this week if I can. >> >> > > Yeah, I'd appreciate that, so that I could see the exact error. > > > >>I seem to recall getting past the >>problem by doing that portion manually after issuing a repair table >>command... [snip] >> >> > > If REPAIR TABLE was in fact the command you used to fix it, then the >fault was not in checksetup but in the fact that your MySQL tables were >corrupted. There is certainly nothing that checksetup could have done >about that, really. :-) > > > >>I am more familiar with SQL Server than MySQL... sorry if this is a dumb >>question, but is it just a limitation of MySQL that prevents a huge >>script like checksetup from continuing on when it runs into a >>non-showstopper kind of problem? >> >> > > If it was in fact a REPAIR TABLE that you had to issue to fix the >problem, then the problem is definitely a showstopper. There is very >little that any script or program can do with a corrupt table. > > > >>Would it be technically possible to port this over to something like >>SQL Server or Oracle? >> >> > > Oracle: https://bugzilla.mozilla.org/show_bug.cgi?id=189947 > MS-SQL: https://bugzilla.mozilla.org/show_bug.cgi?id=285122 > > If your perl skills are good, you're free to attempt to tackle or help >tackle either one of those. Instructions exist in the comments. > > Otherwise, you're also free to hire me/somebody or otherwise induce >me/somebody to get Bugzilla running on either of those database systems. >MS-SQL will probably be particularly hard, as it is based on a >very-non-ANSI-standard database. Oracle is one I'd like to do, but it's >a bit difficult to get a testing installation working on a remote server >that I have only SSH access to (since Oracle, strangely enough for an >enterprise product, requires a GUI to install in a normal fashion). > > > >>The frustration >>factor increases big time when 1 line out of several thousand has an >>issue of some sort and the script just dies instead of executing the >>rest... >> >> > > checksetup in general is dependent upon everything working in order. >Nearly always it does. In fact, we have quite intense regression-testing >of checksetup to make sure that it can upgrade any unmodified database >from any version to our daily CVS version. > > > >>In fact, if you guys would like some Windows specific QA, I can probably >>smk test the install of 'almost ready for production' builds for you >>from time to time. I'm probably a good guinea pig after using BZ on >>Windows way before I probably should have attempted it. >> >> > > That would be wonderful. We have QA efforts right before we release, >and you can contact lpsolit -at- gmail or join the #qa-bugzilla channel >on irc.mozilla.org to find out how you can help. :-) > > -Max > > From justdave at bugzilla.org Sat Aug 20 11:23:57 2005 From: justdave at bugzilla.org (David Miller) Date: Sat, 20 Aug 2005 07:23:57 -0400 Subject: problems with mail interface In-Reply-To: <42E01601.40701@inria.fr> References: <42E01601.40701@inria.fr> Message-ID: <430712CD.3010106@bugzilla.org> Guillaume Rousse wrote: > I got some questions about the mail interface... > I've some ideas for solving those issues, such as merging those scripts, > using a parameters for the from header in the bugzilla configuration, > and completing features. Any interest ? Yes, see https://bugzilla.mozilla.org/show_bug.cgi?id=94850 -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Foundation http://www.mozilla.org/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From bugreport at peshkin.net Sat Aug 20 17:06:23 2005 From: bugreport at peshkin.net (Joel Peshkin) Date: Sat, 20 Aug 2005 10:06:23 -0700 Subject: Move attachments data to its own table? Message-ID: <4307630F.7010709@peshkin.net> As far as I know, I have the largest attachments table of any bugzilla installation. That means that I am your future. It seems that all accesses to the attachments table are very slow just because of the huge amount of data in the table. To date, we have been adding indexes to keep most operations from needing to actually access the row data. Rather than continuing this, I wonder if we should leave all the metadata (filename, mime-type, submitter, ceration timestamp, etc...) in the attachments table but migrate the actual attachment data (the "thedata" field) to its own table containing only attach_id and thedata. I don't see any disadvantage of doing this and it could save a lot of trouble. Anybody have any opinions about this? -Joel From jpyeron at pdinc.us Sat Aug 20 17:16:26 2005 From: jpyeron at pdinc.us (Jason Pyeron) Date: Sat, 20 Aug 2005 13:16:26 -0400 (EDT) Subject: Move attachments data to its own table? In-Reply-To: <4307630F.7010709@peshkin.net> References: <4307630F.7010709@peshkin.net> Message-ID: On Sat, 20 Aug 2005, Joel Peshkin wrote: > Rather than continuing this, I wonder if we should leave all the metadata > (filename, mime-type, submitter, ceration timestamp, etc...) in the > attachments table but migrate the actual attachment data (the "thedata" > field) to its own table containing only attach_id and thedata. I don't see > any disadvantage of doing this and it could save a lot of trouble. > > Anybody have any opinions about this? Very logical as far as I can see. That is how we store our video data. Why was it done this way the first time? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Partner & Sr. Manager 7 West 24th Street #100 - - +1 (443) 921-0381 Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Sat Aug 20 17:21:13 2005 From: myk at mozilla.org (Myk Melez) Date: Sat, 20 Aug 2005 10:21:13 -0700 Subject: Move attachments data to its own table? In-Reply-To: <4307630F.7010709@peshkin.net> References: <4307630F.7010709@peshkin.net> Message-ID: <43076689.8020900@mozilla.org> Joel Peshkin wrote: > I wonder if we should leave all the metadata (filename, mime-type, > submitter, ceration timestamp, etc...) in the attachments table but > migrate the actual attachment data (the "thedata" field) to its own > table containing only attach_id and thedata. I don't see any > disadvantage of doing this and it could save a lot of trouble. We've considered doing this in the past. The disadvantage is additional complexity, but that downside is minimal, especially with a good API to attachments like the Bugzilla::Attachment improvements in bug 302669 , attachment 193220 . I'm surprised that it's slow, frankly, since I'd expect MyISAM blob columns to be implemented in a way that doesn't slow down row access except when you actually access the blob fields. But if that's not the case, a separate table is the next best solution and works for me. -myk -------------- next part -------------- An HTML attachment was scrubbed... URL: From justdave at bugzilla.org Sat Aug 20 18:14:46 2005 From: justdave at bugzilla.org (David Miller) Date: Sat, 20 Aug 2005 14:14:46 -0400 Subject: Move attachments data to its own table? In-Reply-To: <43076689.8020900@mozilla.org> References: <4307630F.7010709@peshkin.net> <43076689.8020900@mozilla.org> Message-ID: <43077316.2000208@bugzilla.org> Myk Melez wrote: > Joel Peshkin wrote: >> I wonder if we should leave all the metadata (filename, mime-type, >> submitter, ceration timestamp, etc...) in the attachments table but >> migrate the actual attachment data (the "thedata" field) to its own >> table containing only attach_id and thedata. I don't see any >> disadvantage of doing this and it could save a lot of trouble. > We've considered doing this in the past. The disadvantage is additional > complexity, but that downside is minimal, especially with a good API to > attachments like the Bugzilla::Attachment improvements in bug 302669 > , attachment 193220 > . > > I'm surprised that it's slow, frankly, since I'd expect MyISAM blob > columns to be implemented in a way that doesn't slow down row access > except when you actually access the blob fields. But if that's not the > case, a separate table is the next best solution and works for me. Even if that's true, not every database engine is as smart about it as MySQL/MyISAM. It certainly won't hurt anything on MySQL (compared to the cost of transmitting that data over the wire, the extra processing for a table join is miniscule), and it will probably greatly help some of the other database engines. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Foundation http://www.mozilla.org/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From os at rsu.ru Sat Aug 20 09:41:56 2005 From: os at rsu.ru (Oleg Sharoiko) Date: Sat, 20 Aug 2005 13:41:56 +0400 (MSD) Subject: Bug in DBD::Pg that affects bugzilla with postgresql Message-ID: <20050820132748.T667@localhost> Hello! I was playing with 2.20rc2 and found that it's being hit by a bug in current version (1.43) of DBD driver for postgresql. The driver sends broken SQL statements when they contain data of BYTEA type. This breakes bugzilla installation process and probably prevents it from working at all. There is a fix for this bug (patch for quote.c) at the bottom of http://gborg.postgresql.org/pipermail/dbdpg-general/2005-August/001883.html I suppose it might be a good thing to mention this bug (and a fix?) in bugzilla docs, because 2.20 is the first version that supports postgresql and this bug may confuse those who will try bugzilla with postgresql. p.s. I'm not on the list, so pleas keep my email on Cc or To line in case you want to reply me. -- Oleg Sharoiko. Software and Network Engineer Computer Center of Rostov State University. From bbaetz at acm.org Sun Aug 21 00:15:45 2005 From: bbaetz at acm.org (Bradley Baetz) Date: Sun, 21 Aug 2005 10:15:45 +1000 Subject: Move attachments data to its own table? In-Reply-To: <4307630F.7010709@peshkin.net> References: <4307630F.7010709@peshkin.net> Message-ID: <20050821001545.GA2823@mango.home> On Sat, Aug 20, 2005 at 10:06:23AM -0700, Joel Peshkin wrote: > > As far as I know, I have the largest attachments table of any bugzilla > installation. That means that I am your future. > > It seems that all accesses to the attachments table are very slow just > because of the huge amount of data in the table. To date, we have been > adding indexes to keep most operations from needing to actually access > the row data. Hmm. Postgres moves 'large' bits of data into external TOAST tables, to avoid this. OTOH, adding extra indexes is a loss on postgres - it always has to look at the table data for queries, since the tuple may not be viewable to the current transaction. Bradley From jochen.wiedmann at gmail.com Mon Aug 22 06:20:34 2005 From: jochen.wiedmann at gmail.com (Jochen Wiedmann) Date: Mon, 22 Aug 2005 08:20:34 +0200 Subject: Seeking advice: Further development of custom fields patch Message-ID: <43096EB2.3030604@gmail.com> Hi, I have picked up the custom fields patch by Myk Melez and ported it to 2.20rc2. (See https://bugzilla.mozilla.org/attachment.cgi?id=192726 for my ported version.) So far it seems to work fine. I would now like to extend the patch with the abilities to search for a custom field and to choose the custom field as a result column in the search result. Before beginning, I would like to seek advice for my work. Obviously it could save me quite some hours of studying the sources, if someone with a detailed knowledge could drop me some hints. My first impression is as follows: 1.) I would consider it sufficient to change the "Advanced Search" page. Adding the "custom fields" there would mean changing the script query.cgi and the template search-advanced.html.tmpl. To provide the required data, I would copy Myk's changes from show_bug.cgi to query.cgi. In other words, I'd fill a variable $var->{'fields'} with the custom field definitions. Ideally, I'd also modify PrefillForm to handle default values. The changes in search-advanced.html.tmpl would match those for edit.html.tmpl. 2.) Looking into Search.pm, it seems that I could simplify the job by selecting suitable names for the form fields. Perhaps, that would allow to reuse some of the chart handling code. 3.) In buglist.cgi, I would have to invoke DefineColumn() for any custom field. A suitable column ID would be "custom.fieldname", with fieldname being the custom fields column name. A column name would be "bugs.fieldname", because the custom fields are part of the bugs table. Title would be the custom fields description. Currently I do have no idea, whether this would already be sufficient for generating the query. The result generation seems relatively straightforward: In the loop called "Results Retrieval, I would create an entry $bug->{'fields'}, again following Myk's patch for show_bug.cgi. Same for the template displaying the result. Any hint, suggestion, comment, or other help highly appreciated by Jochen From myk at mozilla.org Tue Aug 23 02:45:32 2005 From: myk at mozilla.org (Myk Melez) Date: Mon, 22 Aug 2005 19:45:32 -0700 Subject: Seeking advice: Further development of custom fields patch In-Reply-To: <43096EB2.3030604@gmail.com> References: <43096EB2.3030604@gmail.com> Message-ID: <430A8DCC.5050407@mozilla.org> Jochen Wiedmann wrote: > I would now like to extend the patch with the abilities to search for > a custom field and to choose the custom field as a result column in > the search result. My patch already has the ability to search on a custom field via the boolean charts, which includes custom fields in its field list. > 3.) In buglist.cgi, I would have to invoke DefineColumn() for any > custom field. A suitable column ID would be "custom.fieldname", > with fieldname being the custom fields column name. A column > name would be "bugs.fieldname", because the custom fields are > part of the bugs table. Title would be the custom fields > description. This seems reasonable at first glance. -myk From mkanat at bugzilla.org Wed Aug 24 19:06:24 2005 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 24 Aug 2005 12:06:24 -0700 Subject: Bug in DBD::Pg that affects bugzilla with postgresql In-Reply-To: <20050820132748.T667@localhost> References: <20050820132748.T667@localhost> Message-ID: <1124910385.4798.4.camel@localhost.localdomain> On Sat, 2005-08-20 at 13:41 +0400, Oleg Sharoiko wrote: > I was playing with 2.20rc2 and found that it's being hit by a bug in > current version (1.43) of DBD driver for postgresql. Hey Oleg, thanks for the information. Does that bug show up in all previous version of DBD::Pg, or just 1.43? That is, if I told somebody to use 1.41, would they be safe? Does it affect both Pg 7 and Pg 8? And also, do we know if a 1.44 will be coming out soon that has the fix in it? -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From mkanat at bugzilla.org Wed Aug 24 19:10:30 2005 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 24 Aug 2005 12:10:30 -0700 Subject: Seeking advice: Further development of custom fields patch In-Reply-To: <43096EB2.3030604@gmail.com> References: <43096EB2.3030604@gmail.com> Message-ID: <1124910631.4798.8.camel@localhost.localdomain> On Mon, 2005-08-22 at 08:20 +0200, Jochen Wiedmann wrote: > I would now like to extend the patch [snip] I think the absolute *best* way to go about extending custom fields in general would be to work on the bugs that are blockers of the Custom Fields meta-bug: > 3.) In buglist.cgi, I would have to invoke DefineColumn() Really, DefineColumn should go away entirely in favor of storing everything in the fielddefs table. If you have any other thoughts or questions, you can either ask here or you can come find us on the #mozwebtools channel on irc.mozilla.org. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From jochen.wiedmann at gmail.com Wed Aug 24 19:37:41 2005 From: jochen.wiedmann at gmail.com (Jochen Wiedmann) Date: Wed, 24 Aug 2005 21:37:41 +0200 Subject: Seeking advice: Further development of custom fields patch In-Reply-To: <1124910631.4798.8.camel@localhost.localdomain> References: <43096EB2.3030604@gmail.com> <1124910631.4798.8.camel@localhost.localdomain> Message-ID: <430CCC85.6080101@gmail.com> Max Kanat-Alexander wrote: > I think the absolute *best* way to go about extending custom fields in > general would be to work on the bugs that are blockers of the Custom > Fields meta-bug: > > I agree with you. The concept laid out in 91037 and its dependand bugs is well thought out. OTOH, it is so far away from the current Bugzilla, that I have no chance to realize it. My customer is ready to pay me some 5-10 days. Working on all the bugs, on which 91037 depends, would cost me months. Sorry, but that's as it is. > If you have any other thoughts or questions, you can either ask here or > you can come find us on the #mozwebtools channel on irc.mozilla.org. Thanks, I'll keep that in mind. Jochen From jochen.wiedmann at gmail.com Thu Aug 25 11:13:48 2005 From: jochen.wiedmann at gmail.com (Jochen Wiedmann) Date: Thu, 25 Aug 2005 13:13:48 +0200 Subject: PATCH: Bugzilla::Enum class Message-ID: <430DA7EC.1030703@gmail.com> Hi, as a preparation for Bug #287311 and as a result of my work on custom fields, I'd like to propose the attached patch. It is currently *very* conservative, changing almost no existing code. However, it should give a clear impression of a common framework for enumeration fields and hopefully be something, onto which anyone can agree. Please let me know, whether that part suits you. Regards, Jochen -------------- next part -------------- A non-text attachment was scrubbed... Name: BugzillaEnum.patch Type: text/x-patch Size: 2584 bytes Desc: not available URL: From jochen.wiedmann at gmail.com Thu Aug 25 11:40:40 2005 From: jochen.wiedmann at gmail.com (Jochen Wiedmann) Date: Thu, 25 Aug 2005 13:40:40 +0200 Subject: PATCH: Bugzilla::Enum class In-Reply-To: <430DA7EC.1030703@gmail.com> References: <430DA7EC.1030703@gmail.com> Message-ID: <430DAE38.4040002@gmail.com> Sorry, the class Bugzilla::Enum was missing ... -------------- next part -------------- A non-text attachment was scrubbed... Name: Enum.pm Type: application/x-perl Size: 11668 bytes Desc: not available URL: From sushilvj at gmail.com Thu Aug 25 14:17:57 2005 From: sushilvj at gmail.com (sushil jadhav) Date: Thu, 25 Aug 2005 07:17:57 -0700 Subject: Adding of new field on enter_bug screen and in DB Message-ID: <2fde3c3f0508250717736a5adf@mail.gmail.com> I have a requirement to add a text field on Enter bug screen, which needs to be stored in database also. Pls. advice step by step, since I am novice to Active perl and Bugzilla. Regards, Sushil -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkanat at bugzilla.org Thu Aug 25 19:00:25 2005 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 25 Aug 2005 12:00:25 -0700 Subject: PATCH: Bugzilla::Enum class In-Reply-To: <430DAE38.4040002@gmail.com> References: <430DA7EC.1030703@gmail.com> <430DAE38.4040002@gmail.com> Message-ID: <1124996425.3760.1.camel@localhost.localdomain> On Thu, 2005-08-25 at 13:40 +0200, Jochen Wiedmann wrote: > Sorry, the class Bugzilla::Enum was missing ... Hey Jochem. This code would be good to attach to the "custom select fields" bug. My first comment is that this should be a subclass of Bugzilla::Field. So, for example, Bugzilla::Field::Select or something like that. If you attach the code to a bug and ask me for review, I could give more detailed comments. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From mkanat at bugzilla.org Thu Aug 25 19:01:03 2005 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 25 Aug 2005 12:01:03 -0700 Subject: Adding of new field on enter_bug screen and in DB In-Reply-To: <2fde3c3f0508250717736a5adf@mail.gmail.com> References: <2fde3c3f0508250717736a5adf@mail.gmail.com> Message-ID: <1124996463.3760.3.camel@localhost.localdomain> On Thu, 2005-08-25 at 07:17 -0700, sushil jadhav wrote: > I have a requirement to add a text field on Enter bug screen, which > needs to be stored in database also. Hi Sushil -- this question would be more appropriate for the mozilla-webtools mailing list. You can see information on it at: http://www.bugzilla.org/support/ -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From os at rsu.ru Thu Aug 25 05:25:20 2005 From: os at rsu.ru (Oleg Sharoiko) Date: Thu, 25 Aug 2005 09:25:20 +0400 (MSD) Subject: Bug in DBD::Pg that affects bugzilla with postgresql In-Reply-To: <1124910385.4798.4.camel@localhost.localdomain> References: <20050820132748.T667@localhost> <1124910385.4798.4.camel@localhost.localdomain> Message-ID: <20050825091255.L4176@brain.cc.rsu.ru> Hi! On Wed, 24 Aug 2005, Max Kanat-Alexander wrote: MK>> I was playing with 2.20rc2 and found that it's being hit by a bug in MK>> current version (1.43) of DBD driver for postgresql. MK> Hey Oleg, thanks for the information. Does that bug show up in all MK>previous version of DBD::Pg, or just 1.43? That is, if I told somebody MK>to use 1.41, would they be safe? According to the webcvs branch Rel-1_42 includes revision 1.31 of qoute.c which should be ok. So I suppose that 1.42 and earlier version don't suffer from this bug. MK> Does it affect both Pg 7 and Pg 8? Well, I think yes it does. DBD::Pg just sends some garbage in SQL statement. MK> And also, do we know if a 1.44 will be coming out soon that has the fix MK>in it? I don't know. There seems to be no published roadmap on the site or in the mailing list. All I can tell is that the fix for this bug was commited on Aug, 9th (rev. 1.35 of qoute.c). You can ask on their list (http://gborg.postgresql.org/mailman/listinfo/dbdpg-general) for more information. -- Oleg Sharoiko. Software and Network Engineer Computer Center of Rostov State University. From LpSolit at gmail.com Thu Aug 25 20:59:29 2005 From: LpSolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Thu, 25 Aug 2005 22:59:29 +0200 Subject: Bug in DBD::Pg that affects bugzilla with postgresql In-Reply-To: <20050820132748.T667@localhost> References: <20050820132748.T667@localhost> Message-ID: <430E3131.7090800@gmail.com> My config is: Checking for DBD::Pg (v1.31) ok: found v1.43 Checking for PostgreSQL (v7.03.0000) ok: found v08.00.0100 and I have no problem. Frederic From sushilvj at gmail.com Fri Aug 26 01:38:19 2005 From: sushilvj at gmail.com (sushil jadhav) Date: Fri, 26 Aug 2005 10:38:19 +0900 Subject: Adding of new field on enter_bug screen and in DB In-Reply-To: <1124996463.3760.3.camel@localhost.localdomain> References: <2fde3c3f0508250717736a5adf@mail.gmail.com> <1124996463.3760.3.camel@localhost.localdomain> Message-ID: <2fde3c3f0508251838581b642d@mail.gmail.com> ok, thanx Regards, On 8/26/05, Max Kanat-Alexander wrote: > > On Thu, 2005-08-25 at 07:17 -0700, sushil jadhav wrote: > > I have a requirement to add a text field on Enter bug screen, which > > needs to be stored in database also. > > Hi Sushil -- this question would be more appropriate for the > mozilla-webtools mailing list. You can see information on it at: > > http://www.bugzilla.org/support/ > > -Max > -- > http://www.everythingsolved.com/ > Competent, Friendly Bugzilla Services. And Everything Else, too. > > - > To view or change your list settings, click here: > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From justdave at bugzilla.org Fri Aug 26 10:30:41 2005 From: justdave at bugzilla.org (David Miller) Date: Fri, 26 Aug 2005 06:30:41 -0400 Subject: rampant selectrow_array misuse Message-ID: <430EEF51.8050506@bugzilla.org> I noticed this happening in a couple patches up for approval tonight, and after discussion with LpSolit on IRC discovered that we've been rather careless with how we treat the results of selectrow_array and fetchrow_array. Both of these functions, as their names imply, return arrays. We have lots of places in the code where we run these functions and attempt to stick the results into a scalar. Sometimes that does what you want, and sometimes it doesn't, so it's a really bad habit to get into. Consider the poor newbies who are trying to learn perl by reading our code. :) You should play it safe, and always wrap the destination variable in parens, so that it explicitly pulls the first element out of the array. Consider the following: while (my $value = $dbh->selectrow_array("SELECT foo FROM table")) { do something; } Now consider that the "foo" column in "table" allows NULLS, and that some of the rows scattered in the middle of that column will have null values. The above code snippet will stop the first time you hit a null, because the while loop is looking at your $value variable and sees that you got an undef, which qualifies as false, so the loop exits. while (my ($value) = $dbh->selectrow_array("SELECT foo FROM table")) { do something; } The above snippet will process all of the data in the table, regardless of some of the values being null. Why? Because the while loop is looking at the array containing your $value, and not $value itself. An array containing an undef element is still a 1-element array, and an array with more than 0 elements counts as true, so the loop continues. When you hit the end of the data, $dbh->selectrow_array will return an empty array (zero elements in it), which now evaluates as false, so the loop exits. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Foundation http://www.mozilla.org/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From jochen.wiedmann at gmail.com Fri Aug 26 10:48:47 2005 From: jochen.wiedmann at gmail.com (Jochen Wiedmann) Date: Fri, 26 Aug 2005 12:48:47 +0200 Subject: rampant selectrow_array misuse In-Reply-To: <430EEF51.8050506@bugzilla.org> References: <430EEF51.8050506@bugzilla.org> Message-ID: On 8/26/05, David Miller wrote: > You should play it safe, and always wrap the destination variable in > parens, so that it explicitly pulls the first element out of the array. Or, may be simpler, use the proper *_arrayref methods from DBI? DBI clearly distinguishes between array and array reference. Jochen -- Having experienced 7 years of labour/green government, I now know the reason, why a conservative government is good for the economy: The economy's unable to imagine anything else ... From gerv at mozilla.org Fri Aug 26 11:02:46 2005 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 26 Aug 2005 12:02:46 +0100 Subject: rampant selectrow_array misuse In-Reply-To: <430EEF51.8050506@bugzilla.org> References: <430EEF51.8050506@bugzilla.org> Message-ID: <430EF6D6.4060702@mozilla.org> David Miller wrote: > Both of these functions, as their names imply, return arrays. That's not actually true, as far as I can tell. DBI docs are strangely hard to find on the net, but I tend to use http://www.he.net/info/mysql/dbi.html or a more up-to-date copy thereof. (I'm linking to that one because I've just found my bookmark to perldoc.com is broken.) "This utility method combines prepare, execute and fetchrow_array into a single call. If called in a list context it returns the first row of data from the statement. If called in a scalar context it returns the first field of the first row." Gerv From LpSolit at gmail.com Fri Aug 26 12:01:26 2005 From: LpSolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Fri, 26 Aug 2005 14:01:26 +0200 Subject: rampant selectrow_array misuse In-Reply-To: <430EF6D6.4060702@mozilla.org> References: <430EEF51.8050506@bugzilla.org> <430EF6D6.4060702@mozilla.org> Message-ID: <430F0496.6010104@gmail.com> Gervase Markham a ?crit : > "This utility method combines prepare, execute and fetchrow_array into a > single call. If called in a list context it returns the first row of > data from the statement. If called in a scalar context it returns the > first field of the first row." Yes, I confirm that, see /usr/lib/perl5/vendor_perl/5.8.6/i386-linux/DBI.pm, line 1545: sub selectrow_array { my $row = _do_selectrow('fetchrow_arrayref', @_) or return; return $row->[0] unless wantarray; return @$row; } Note the presence of 'wantarray'! :) So what we have done so far is correct as long as we are not in the "special" 'while ()' condition justdave talked about earlier. No reason to hold approval anymore, justdave. ;) From kevin.benton at amd.com Fri Aug 26 14:33:34 2005 From: kevin.benton at amd.com (Benton, Kevin) Date: Fri, 26 Aug 2005 07:33:34 -0700 Subject: rampant selectrow_array misuse Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201F13014@ssvlexmb2.amd.com> > > Both of these functions, as their names imply, return arrays. > > That's not actually true, as far as I can tell. DBI docs are strangely > hard to find on the net, but I tend to use > http://www.he.net/info/mysql/dbi.html > or a more up-to-date copy thereof. (I'm linking to that one because I've > just found my bookmark to perldoc.com is broken.) > > "This utility method combines prepare, execute and fetchrow_array into a > single call. If called in a list context it returns the first row of > data from the statement. If called in a scalar context it returns the > first field of the first row." Correct me if I'm wrong, but I think Dave's main point is still valid - if the function returns a null value, the while loop ends, correct? In any case, I believe Dave has another valid point - even if it is technically correct to use the scalar context, style-wise, it seems to me it would be more clear (better self-documenting) if we use array context instead by wrapping the variable with ()'s. This seems especially true to me if you "select foo, bar from baz"; In either case, to prevent inconsistent results, I think we should use one or the other, not both. On using arrayrefs, I think that as long as the selectrow_array and the variable assignment are very close together, the additional overhead required to deal with hashes isn't worth it. --- Kevin Benton Perl/Bugzilla Developer Advanced Micro Devices The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. From justdave at bugzilla.org Fri Aug 26 17:20:31 2005 From: justdave at bugzilla.org (David Miller) Date: Fri, 26 Aug 2005 13:20:31 -0400 Subject: rampant selectrow_array misuse In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4201F13014@ssvlexmb2.amd.com> References: <6F7DA19D05F3CF40B890C7CA2DB13A4201F13014@ssvlexmb2.amd.com> Message-ID: <430F4F5F.5030102@bugzilla.org> Benton, Kevin wrote: > In any case, I believe Dave has another valid point - even if it is > technically correct to use the scalar context, style-wise, it seems to > me it would be more clear (better self-documenting) if we use array > context instead by wrapping the variable with ()'s. This seems > especially true to me if you "select foo, bar from baz"; In either > case, to prevent inconsistent results, I think we should use one or the > other, not both. Yes, this was exactly my point. The way it's being done now works, but it's a bad habit. If we always use parens no matter when, then people who are trying to hack up Bugzilla and learning Perl will see that and follow suit, and will be less likely to make the mistakes with checking the results for nulls. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Foundation http://www.mozilla.org/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From mkanat at bugzilla.org Fri Aug 26 18:54:10 2005 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 26 Aug 2005 11:54:10 -0700 Subject: rampant selectrow_array misuse In-Reply-To: <430EEF51.8050506@bugzilla.org> References: <430EEF51.8050506@bugzilla.org> Message-ID: <1125082450.3406.12.camel@localhost.localdomain> On Fri, 2005-08-26 at 06:30 -0400, David Miller wrote: > An array containing an undef element is still a 1-element array, I thought an array containing an undef was a 0-element array... -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From justdave at bugzilla.org Fri Aug 26 19:11:21 2005 From: justdave at bugzilla.org (David Miller) Date: Fri, 26 Aug 2005 15:11:21 -0400 Subject: rampant selectrow_array misuse In-Reply-To: <1125082450.3406.12.camel@localhost.localdomain> References: <430EEF51.8050506@bugzilla.org> <1125082450.3406.12.camel@localhost.localdomain> Message-ID: <430F6959.8090107@bugzilla.org> Max Kanat-Alexander wrote: > On Fri, 2005-08-26 at 06:30 -0400, David Miller wrote: >> An array containing an undef element is still a 1-element array, > > I thought an array containing an undef was a 0-element array... nope. It's definitely a one-element array with the element being an undef. But a zero-element array is the same as an undef, maybe that's what you're thinking of. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Foundation http://www.mozilla.org/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From mkanat at bugzilla.org Fri Aug 26 19:26:18 2005 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 26 Aug 2005 12:26:18 -0700 Subject: rampant selectrow_array misuse In-Reply-To: <430F6959.8090107@bugzilla.org> References: <430EEF51.8050506@bugzilla.org> <1125082450.3406.12.camel@localhost.localdomain> <430F6959.8090107@bugzilla.org> Message-ID: <1125084378.3406.19.camel@localhost.localdomain> On Fri, 2005-08-26 at 15:11 -0400, David Miller wrote: > nope. It's definitely a one-element array with the element being an > undef. But a zero-element array is the same as an undef, maybe that's > what you're thinking of. Yeah, you're right: [mkanat at landfill mkanat]$ perl -e 'my @array = (undef); print @array . "\n"' 1 -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From bbaetz at acm.org Sun Aug 28 22:25:25 2005 From: bbaetz at acm.org (Bradley Baetz) Date: Mon, 29 Aug 2005 08:25:25 +1000 Subject: rampant selectrow_array misuse Message-ID: <200508282225.j7SMPPkh030375@mail10.syd.optusnet.com.au> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From jochen.wiedmann at gmail.com Mon Aug 29 00:38:44 2005 From: jochen.wiedmann at gmail.com (Jochen Wiedmann) Date: Mon, 29 Aug 2005 02:38:44 +0200 Subject: rampant selectrow_array misuse In-Reply-To: <200508282225.j7SMPPkh030375@mail10.syd.optusnet.com.au> References: <200508282225.j7SMPPkh030375@mail10.syd.optusnet.com.au> Message-ID: <43125914.3090701@gmail.com> Bradley Baetz wrote: > the perl driver has what you quoted, but the XS versions may do other things. This is not the case. DBI drivers implement only fetchrow_arrayref. All other fetch* and select* are defined and implement by DBI. It is *possible*, that a driver overwrites these implementations, but I see no reason for doing so and the drivers I know very well (MySQL, ODBC, Oracle) definitely don't. Jochen