From bugreport at peshkin.net Tue Nov 1 05:15:17 2005 From: bugreport at peshkin.net (Joel Peshkin) Date: Mon, 31 Oct 2005 21:15:17 -0800 Subject: landfill now has mysql5.0.15 Message-ID: <4366F9E5.9050308@peshkin.net> When you want to use mysql 5.0.15, just specify db_port=3307 db_host=127.0.0.1 and you'll have it. From justdave at bugzilla.org Tue Nov 1 07:07:37 2005 From: justdave at bugzilla.org (David Miller) Date: Tue, 01 Nov 2005 02:07:37 -0500 Subject: What kind of support for PostgreSQL do we want in 2.22? In-Reply-To: <1130788078.3353.0.camel@localhost.localdomain> References: <4366011C.3040706@gmail.com> <1130788078.3353.0.camel@localhost.localdomain> Message-ID: <43671439.6000600@bugzilla.org> Max Kanat-Alexander wrote on 10/31/05 2:47 PM: > On Mon, 2005-10-31 at 12:33 +0100, Fr?d?ric Buclin wrote: >> In 2.20, we said the support for PostgreSQL was still experimental. What >> is the status for 2.22? Still experimental or do we want a real support? > > If we finish the bugs, it's not experimental. :-) If we don't finish > the bugs, it's experimental. :-) > > At least, that's my viewpoint on it. OK, so if we decide we want Postgres to be supported in 2.22 then those bugs should all be release blockers. Is that realistic? -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From mkanat at bugzilla.org Tue Nov 1 19:10:09 2005 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 01 Nov 2005 11:10:09 -0800 Subject: What kind of support for PostgreSQL do we want in 2.22? In-Reply-To: <43671439.6000600@bugzilla.org> References: <4366011C.3040706@gmail.com> <1130788078.3353.0.camel@localhost.localdomain> <43671439.6000600@bugzilla.org> Message-ID: <1130872210.3352.0.camel@localhost.localdomain> On Tue, 2005-11-01 at 02:07 -0500, David Miller wrote: > OK, so if we decide we want Postgres to be supported in 2.22 then those > bugs should all be release blockers. > > Is that realistic? I don't think so. I think it's too many bugs, and it would delay the release far too long. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From LpSolit at gmail.com Tue Nov 1 19:27:19 2005 From: LpSolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Tue, 01 Nov 2005 20:27:19 +0100 Subject: What kind of support for PostgreSQL do we want in 2.22? In-Reply-To: <1130872210.3352.0.camel@localhost.localdomain> References: <4366011C.3040706@gmail.com> <1130788078.3353.0.camel@localhost.localdomain> <43671439.6000600@bugzilla.org> <1130872210.3352.0.camel@localhost.localdomain> Message-ID: <4367C197.8070009@gmail.com> > I don't think so. I think it's too many bugs, and it would delay the > release far too long. OK, so we don't care about these bugs for the 2.22 release. For the record, note that we made no progress compared to 2.20. :( I suggest to really get them fixed for 2.24. LpSolit From jochen.wiedmann at gmail.com Wed Nov 2 20:47:44 2005 From: jochen.wiedmann at gmail.com (Jochen Wiedmann) Date: Wed, 02 Nov 2005 21:47:44 +0100 Subject: Developing Bugzilla patches is frustrating Message-ID: <436925F0.2000107@gmail.com> Hi, in the last months I have developed several patches for Bugzilla, which I personally believe to be useful. All patches are properly submitted to the relevant bugs. So far not one made it into the trunk. Reasons are varying. In one case, the patch's still waiting for review. In other cases review was denied, mostly for very formal reasons. Being a committer of several other open source projects, I know the typical problems of a committer very well. In particular, I accept the importance of educating the user. (Me, in that case.) However, even considering this, I cannot fight the feeling that the Bugzilla committers are particularly resistent. Sorry, but it seemed about time to drop that note. Jochen From mkanat at bugzilla.org Wed Nov 2 21:06:40 2005 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 02 Nov 2005 13:06:40 -0800 Subject: Developing Bugzilla patches is frustrating In-Reply-To: <436925F0.2000107@gmail.com> References: <436925F0.2000107@gmail.com> Message-ID: <1130965600.3329.22.camel@localhost.localdomain> On Wed, 2005-11-02 at 21:47 +0100, Jochen Wiedmann wrote: > in the last months I have developed several patches for Bugzilla, which > I personally believe to be useful. All patches are properly submitted to > the relevant bugs. So far not one made it into the trunk. Hey Jochen. Could you post links to all the bugs that you have patches on? -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From jochen.wiedmann at gmail.com Wed Nov 2 21:26:00 2005 From: jochen.wiedmann at gmail.com (Jochen Wiedmann) Date: Wed, 02 Nov 2005 22:26:00 +0100 Subject: Developing Bugzilla patches is frustrating In-Reply-To: <1130965600.3329.22.camel@localhost.localdomain> References: <436925F0.2000107@gmail.com> <1130965600.3329.22.camel@localhost.localdomain> Message-ID: <43692EE8.3070500@gmail.com> Max Kanat-Alexander wrote: > Hey Jochen. Could you post links to all the bugs that you have patches > on? For starters, how about 287326? Jochen From bugreport at peshkin.net Wed Nov 2 21:26:08 2005 From: bugreport at peshkin.net (Joel Peshkin) Date: Wed, 02 Nov 2005 13:26:08 -0800 Subject: Developing Bugzilla patches is frustrating In-Reply-To: <436925F0.2000107@gmail.com> References: <436925F0.2000107@gmail.com> Message-ID: <43692EF0.80400@peshkin.net> Jochen Wiedmann wrote: > Reasons are varying. In one case, the patch's still waiting for > review. In other cases review was denied, mostly for very formal reasons. > > Being a committer of several other open source projects, I know the > typical problems of a committer very well. In particular, I accept the > importance of educating the user. (Me, in that case.) However, even > considering this, I cannot fight the feeling that the Bugzilla > committers are particularly resistent. It probably helps to get a "live" review with a reviewer on IRC when you do your first few patches. From mkanat at bugzilla.org Wed Nov 2 21:38:41 2005 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 02 Nov 2005 13:38:41 -0800 Subject: Developing Bugzilla patches is frustrating In-Reply-To: <43692EE8.3070500@gmail.com> References: <436925F0.2000107@gmail.com> <1130965600.3329.22.camel@localhost.localdomain> <43692EE8.3070500@gmail.com> Message-ID: <1130967521.3329.31.camel@localhost.localdomain> On Wed, 2005-11-02 at 22:26 +0100, Jochen Wiedmann wrote: > For starters, how about 287326? OK. The reason that 287326 hasn't been reviewed is that it depends on other patches that aren't ready, yet. That is, we need to have the simple plain-text fields patch in before we have the single-select fields patch in. It's true that the patch has been waiting there for a while, and I've definitely had it on my mind, but I haven't had time to review it, and since it depends on other code existing first, I just haven't gotten to it yet. I'll add a few comments to the bug, now, though. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From LpSolit at gmail.com Thu Nov 3 00:17:54 2005 From: LpSolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Thu, 03 Nov 2005 01:17:54 +0100 Subject: Do we want Bugzilla to be case-sensitive or case-insensitive? Message-ID: <43695732.6030001@gmail.com> With the support of PostgreSQL, several bugs have been reported about the fact that PostgreSQL and MySQL behave differently when querying the DB, simply because PostgreSQL is case-sensitive by default and because MySQL is case-insensitive by default. This way, you can create the 'Bugzilla' and 'bugzilla' products on your installation running PostgreSQL, but MySQL will complain that this product already exists when trying to add the second one. This problem appears everywhere, from components to keywords. So we have to make a crucial decision now: Do we want Bugzilla to be case-sensitive or case-insensitive? This decision will have strong implications in the future development of the Bugzilla code. LpSolit From bugzilla at glob.com.au Thu Nov 3 00:53:54 2005 From: bugzilla at glob.com.au (byron) Date: Thu, 3 Nov 2005 08:53:54 +0800 (WST) Subject: Do we want Bugzilla to be case-sensitive or case-insensitive? Message-ID: <20051103005354.390594BC1D8@sweep.bur.st> > Do we want Bugzilla to be case-sensitive or case-insensitive? insensitive. -b begin-base64 644 signature.gif R0lGODlhbQAHAIAAAABPo////ywAAAAAbQAHAAACfAxuGAnch+Bibkn7FL1p XgVl4Ig1jjlZRoqybgun2Cur5uOunq7u/Ipq7WIyIc7XG9JquEgumPzdlhTf h0O83kDJaXEm8mRHwXKJy5sac7qYOpT+gtv0n+0ujQOfdqh16caWt0foBViH N1PRMXimiLUGt3ElVimlgbllWAAAOw== ==== From LpSolit at gmail.com Thu Nov 3 01:14:41 2005 From: LpSolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Thu, 03 Nov 2005 02:14:41 +0100 Subject: Do we want Bugzilla to be case-sensitive or case-insensitive? In-Reply-To: <20051103005354.390594BC1D8@sweep.bur.st> References: <20051103005354.390594BC1D8@sweep.bur.st> Message-ID: <43696481.8020908@gmail.com> >>Do we want Bugzilla to be case-sensitive or case-insensitive? > > > insensitive. On IRC, some of us came to the conclusion that choosing either PostgreSQL or MySQL is a strategical choice, depending of what companies want in terms of intrinsic properties. In the same way some users like *nix case-sensitiveness, some others prefer windows case-insensitiveness. Forcing all comparisons to be case-insensitive would require to rewrite 98% of all SQL queries!! .... or to find another way to force Pg to be case-insensitive. But it appears that is *not* possible to change this behavior in PostgreSQL, at all. I don't know how Oracle behaves, though. No matter what we choose, it won't be a simple problem to fix. :( LpSolit From bugzilla at glob.com.au Thu Nov 3 02:00:12 2005 From: bugzilla at glob.com.au (byron) Date: Thu, 3 Nov 2005 10:00:12 +0800 (WST) Subject: Do we want Bugzilla to be case-sensitive or case-insensitive? Message-ID: <20051103020012.2B2B84BC69C@sweep.bur.st> > > insensitive. > > On IRC, some of us came to the conclusion that choosing either > PostgreSQL or MySQL is a strategical choice, depending of what companies > want in terms of intrinsic properties. In the same way some users like > *nix case-sensitiveness, some others prefer windows case-insensitiveness. yeah, but database choice shouldn't affect how bugzilla works. > Forcing all comparisons to be case-insensitive would require to rewrite > 98% of all SQL queries!! eww. > case-insensitive. But it appears that is *not* possible to change this > behavior in PostgreSQL, at all. I don't know how Oracle behaves, though. for what it's worth, ms-sql is case-insensitive by default. the default behavour is chosen as install time, and with ms-sql 2000 it's set at database/table creation time. so you can't change it without recreating the database and/or table. to do case sensitivity against a table that has case-insensitive collation you need to cast the fields _and_ data as varbinary select * from users where cast(username as varbinary) = cast('byron.jones' as varbinary) of course this is ms-sql specific. > No matter what we choose, it won't be a simple problem to fix. :( roger that! -b begin-base64 644 signature.gif R0lGODlhbQAHAIAAAABPo////ywAAAAAbQAHAAACfAxuGAnch+Bibkn7FL1p XgVl4Ig1jjlZRoqybgun2Cur5uOunq7u/Ipq7WIyIc7XG9JquEgumPzdlhTf h0O83kDJaXEm8mRHwXKJy5sac7qYOpT+gtv0n+0ujQOfdqh16caWt0foBViH N1PRMXimiLUGt3ElVimlgbllWAAAOw== ==== From chicks at chicks.net Thu Nov 3 02:18:59 2005 From: chicks at chicks.net (Christopher Hicks) Date: Wed, 2 Nov 2005 21:18:59 -0500 (EST) Subject: Do we want Bugzilla to be case-sensitive or case-insensitive? In-Reply-To: <43696481.8020908@gmail.com> References: <20051103005354.390594BC1D8@sweep.bur.st> <43696481.8020908@gmail.com> Message-ID: On Thu, 3 Nov 2005, Fr?d?ric Buclin wrote: > On IRC, some of us came to the conclusion that choosing either PostgreSQL or > MySQL is a strategical choice, depending of what companies want in terms of > intrinsic properties. In the same way some users like *nix > case-sensitiveness, some others prefer windows case-insensitiveness. I understand that to some degree both have their place and that where that is depends on some degree to personal taste. But I think pretending its a taste issue and ignoring the actual benefits and difficulties in each case is unwise. When dealing with human names, book titles, and other thing where case is key, having case sensitivity is not an option. When dealing with product names, SKU's and other things that are much more relevant to bugzilla allowing two things to be named the same thing with only varying case it seems clear that whatever border cases might be assisted by case sensitivity the vast majority is server better by case insensitivity. By choosing to go the convenient way for most as the officially accepted bugzilla behavior it seems like we'll minimize confusion and support hassles down the road. As far as choosing between PostgreSQL and MySQL as a strategic decision its sort of funny to me. I've been using Class::DBI and its relatives for some time now to write code that's portable between Oracle, MySQL, and PostgreSQL because I tired of fighting the same old religious battles time and time again. Perl has a long history of supporting database portability to various degrees. The only real strategic choice here is whether to care about database portability or not. Beyond that its only determining which portion of humanity you're going to piss off by not choosing their ice cream flavor. > Forcing all comparisons to be case-insensitive would require to rewrite > 98% of all SQL queries!! .... or to find another way to force Pg to be > case-insensitive. But it appears that is *not* possible to change this > behavior in PostgreSQL, at all. I don't know how Oracle behaves, though. This is where having a useful abstraction layer makes life much better. The fact that there are so many arbitary queries lying around to be fixed in this case is a sign of a poor design decision. Why not re-examine the way that the database layer is done. DBIx::Class is being actively maintained by smart folks these days and is very compatible with Class::DBI if you want it to be. This won't solve every issue of this ilk and there will need to be occassional optimizations, but in practice we haven't had to make many exceptions. > No matter what we choose, it won't be a simple problem to fix. :( So lets choose a good futureproof solution so folks are motivated to get rid of the old and bring in the new and split up the work. :) -- John Lundin once shaped the electrons thusly: > Ah. Okay, on the "nice to do" list. (Which in practice translates to > "won't do unless it becomes inconvenient or is fixed upstream.") From bbaetz at acm.org Thu Nov 3 08:32:30 2005 From: bbaetz at acm.org (Bradley Baetz) Date: Thu, 3 Nov 2005 19:32:30 +1100 Subject: Do we want Bugzilla to be case-sensitive or case-insensitive? In-Reply-To: <43696481.8020908@gmail.com> References: <20051103005354.390594BC1D8@sweep.bur.st> <43696481.8020908@gmail.com> Message-ID: <20051103083230.GA3059@mango.home> On Thu, Nov 03, 2005 at 02:14:41AM +0100, Fr?d?ric Buclin wrote: > On IRC, some of us came to the conclusion that choosing either > PostgreSQL or MySQL is a strategical choice, depending of what companies > want in terms of intrinsic properties. In the same way some users like > *nix case-sensitiveness, some others prefer windows case-insensitiveness. This really isn't the way to make a decision. In practice, it dosn't really matter. Pg will let you have products called ABC and abc, and mysql won't. The user just chooses whatever they want from a list. As long as we have approriate functional indexes so that searching is fast, noone will care. (I think that tsearch2 is case insensitve, anyway. Not 100% sure, though) Things such as emails that are inherantly case insensitive should just be case folded before putting it into the DB (You can enforce that with a check constraint in pg if you really want) There are many reasons to choose a database to use. Case folding should be well down the list.. (unless, of course, you *need* to have something case sensitive for the purposes of unique keys. thats fairly rare, though...) Bradley From Nick.Barnes at pobox.com Thu Nov 3 11:42:15 2005 From: Nick.Barnes at pobox.com (Nick Barnes) Date: Thu, 03 Nov 2005 11:42:15 +0000 Subject: Do we want Bugzilla to be case-sensitive or case-insensitive? In-Reply-To: <43696481.8020908@gmail.com> from =?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?= of "Thu, 03 Nov 2005 02:14:41 +0100" Message-ID: <83837.1131018135@thrush.ravenbrook.com> At 2005-11-03 01:14:41+0000, =?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?= writes: > >>Do we want Bugzilla to be case-sensitive or case-insensitive? > > > > > > insensitive. > > Forcing all comparisons to be case-insensitive would require to > rewrite 98% of all SQL queries!! .... or to find another way to > force Pg to be case-insensitive. But it appears that is *not* > possible to change this behavior in PostgreSQL, at all. What comparisons? Most strings in Bugzilla are either: 1. free-form text (in shortdesc, longdesc, etc): to search this case-insensitively, use the case-insensitive operators (~*, ILIKE) or downcase before comparing: lower(mycol) = 'some value'. If you are going to do lower(mycol) and want an index to help, it needs to be an expression index on the lower(mycol) expression. 2. drop-down fields, entered once by an administrator (or manager) and then selected from drop-downs. Are these strings ever compared against anything else in subsequent operation? In any case, force case-insensitive uniqueness on creation, either by searching for a match or by having a UNIQUE expression index on lower(mycol). 3. email addresses. These should retain case (like 'LpSolit at gmail.com') but we should reject case-duplicates on creation (In other words, as for #2). Searching should use case-insensitive operators, as for #1. > I don't know how Oracle behaves, though. It's case-sensitive, with a variety of hacks (broadly similar to PostgreSQL's, although uglier) to force insensitivity. The brand new Oracle 10gR2 release has some changes in this area. Nick B From mkanat at bugzilla.org Thu Nov 3 19:54:01 2005 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 03 Nov 2005 11:54:01 -0800 Subject: Do we want Bugzilla to be case-sensitive or case-insensitive? In-Reply-To: <83837.1131018135@thrush.ravenbrook.com> References: <83837.1131018135@thrush.ravenbrook.com> Message-ID: <1131047642.3329.23.camel@localhost.localdomain> I think that perhaps the heart of the issue has been slightly missed, in some of the discussion here. When using the Search screen, Products, Components, Keywords, Summaries, *anything* that you type in the Boolean Charts -- all are *case sensitive* on PostgreSQL. In fact, any text that you type *anywhere* to match *anything* is case sensitive on PostgreSQL. The is NO database-wide way around that. The only way to fix it is to make EVERY SINGLE: product = ? into: $dbh->sql_istrcmp('product', '?') In ALL OF BUGZILLA. And not just for products, but for everything that we want to match, anywhere, ever. At which point, on some DBs, we'd lose the value of our indexes, or on some others we'd have to start keeping track of a bunch of indexes on LOWER(product). Since we're not going to do that, we made only the most critical thing (usernames) case-insensitive on PostgreSQL, and everything else is case sensitive. If anybody comes up with a way to make an entire PostgreSQL database do case-insensitive comparisons, then I'm certainly open to it. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From kevin.benton at amd.com Thu Nov 3 21:10:25 2005 From: kevin.benton at amd.com (Benton, Kevin) Date: Thu, 3 Nov 2005 13:10:25 -0800 Subject: Do we want Bugzilla to be case-sensitive or Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4202E627A9@ssvlexmb2.amd.com> > -----Original Message----- > From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] > On Behalf Of Max Kanat-Alexander > Sent: Thursday, November 03, 2005 12:54 PM > To: developers at bugzilla.org > Subject: Re: Do we want Bugzilla to be case-sensitive or case-insensitive? > > I think that perhaps the heart of the issue has been slightly > missed, > in some of the discussion here. > > When using the Search screen, Products, Components, Keywords, > Summaries, *anything* that you type in the Boolean Charts -- all are > *case sensitive* on PostgreSQL. In fact, any text that you type > *anywhere* to match *anything* is case sensitive on PostgreSQL. > > The is NO database-wide way around that. > > The only way to fix it is to make EVERY SINGLE: > > product = ? > > into: > > $dbh->sql_istrcmp('product', '?') > > In ALL OF BUGZILLA. And not just for products, but for everything > that > we want to match, anywhere, ever. > > At which point, on some DBs, we'd lose the value of our indexes, or > on > some others we'd have to start keeping track of a bunch of indexes on > LOWER(product). > > Since we're not going to do that, we made only the most critical > thing > (usernames) case-insensitive on PostgreSQL, and everything else is case > sensitive. > > If anybody comes up with a way to make an entire PostgreSQL database > do > case-insensitive comparisons, then I'm certainly open to it. First, my disclaimer - I'm not a PostgreSQL expert so if I'm off-base, please let me know (kindly) and then politely ignore the comments below. For things like product and component names, in PostgreSQL, you could decide to store it in two forms, one already converted to lower case, and another in mixed-case format. One other way to get around the problem entirely is to enforce or not enforce duplicate inserts for all records that differ only by case. So, if someone tries to insert Xyz, then someone else tries to insert xyz or XYZ, as a Product or Component for example, you could reject the search given the proper settings. That could probably be done fairly easily through a trigger. You could also do your comparisons against a function that converts field values and search strings to lower case. >From a more philosophical view... As we incorporate new databases as back-ends for Bugzilla, we're going to have to deal with the quirks of each database separately. Since I'm hearing you say that PostgreSQL doesn't support case-insensitive searches globally, we need to find a way to address that quirk. One possible solution is to ask the PostgreSQL developers for that ability. Since we haven't supported PostgreSQL until now, asking users to upgrade to a very recent version seems fair to me. The point of saying use DBI is appropriate, but it's not. Not every database does indexing the same way (as we know) and to try to deal with all databases using one standard method seems to me to be impractical. On the other hand, creating a class to deal with all the databases so that programmers developers who really don't care about the quirks of one over another can do it without caring seems very wise. Personally, I thought that getting rid of DB.pm wasn't such a hot idea. Why? It moves us away from abstracting interaction with the underlying back-end. If we utilize a module for DB interaction, it allows us to update just that portion of the code when it comes time to deal with how to ask the database for information and how to send it changes. As we add support for new back-ends like Oracle, MS-SQL, XML, or whatever else, it will be much easier if we use a DB interaction class because the interaction would be pre-defined. Implementation would be left only in the DB.pm module (or a module it imported). In this model, only that module would need to be updated in order to handle new databases (or new database versions). Do I think comparisons should be case insensitive? From a process management perspective, hands-down yes I think searches should be case insensitive except in very rare circumstances. If someone can type Xyz and someone else can type XYZ in a search not knowing that they mean something different, they're going to get confusing and different results. If Acme and acme are different, it seems to me that there's a bigger underlying problem - people don't usually know that Acme != acme != ACME != aCME. Having said that, I wouldn't want to take away the ability for users to search in a method that's case sensitive or insensitive. This brings up a point about usability - while it's really cool to have the ability to store things in case-sensitive formats, I think Microsoft did do something right by deciding that filenames should be stored in mixed case format, but will always match regardless of case. Unfortunately for us, this is the mentality we have to deal with in a large part of our user-bases. Users simply don't expect that Acme is different from acme. No matter how we choose to tackle this, it seems to me that we need the highest level of usability we can offer and in my mind, that means we must be able to provide case-insensitive searches in the Boolean search tables. It also seems to me that where a case-sensitive search is required over a case-insensitive search is very rare. Therefore, I think that we should be able to do all our searches without regard for case first, then deal with the exceptions, possibly by giving a user an option to do a case-sensitive search. From mkanat at bugzilla.org Thu Nov 3 21:25:36 2005 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 03 Nov 2005 13:25:36 -0800 Subject: Do we want Bugzilla to be case-sensitive or In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4202E627A9@ssvlexmb2.amd.com> References: <6F7DA19D05F3CF40B890C7CA2DB13A4202E627A9@ssvlexmb2.amd.com> Message-ID: <1131053137.3329.58.camel@localhost.localdomain> On Thu, 2005-11-03 at 13:10 -0800, Benton, Kevin wrote: > For things like product and component names, in PostgreSQL, you could > decide to store it in two forms, one already converted to lower case, > and another in mixed-case format. Yeah, we discussed this as an option. :-) Believe me, Tomas and I went over everything. I could show you our ICQ logs, this was the one "unsolvable" problem we ran into. That option doesn't work out really well, it creates a lot of complexity. > One other way to get around the > problem entirely is to enforce or not enforce duplicate inserts for all > records that differ only by case. Yes, that's the solution that I was going to adopt. See https://bugzilla.mozilla.org/show_bug.cgi?id=300417 > Since I'm > hearing you say that PostgreSQL doesn't support case-insensitive > searches globally, we need to find a way to address that quirk. Yes, I know. :-) And I'm saying that there *is* a way to address the quirk, and it's far too expensive in terms of code complexity, so it's going to remain a quirk. > One > possible solution is to ask the PostgreSQL developers for that ability. I would love that. We'd probably see it around PostgreSQL 8.3 or 8.4 or even PostgreSQL 9, some years down the road. Feel free to suggest it, though. > Since we haven't supported PostgreSQL until now, asking users to upgrade > to a very recent version seems fair to me. One of the reasons that people want to use PostgreSQL is that they have it installed already, so they could have an older version. That's why I decided to support 7.3 as the minimum. (Also, 8 was brand new when I first really got into the code side of this in Bugzilla.) > On the other hand, > creating a class to deal with all the databases so that programmers > developers who really don't care about the quirks of one over another > can do it without caring seems very wise. Yes. There are many classes like that, on CPAN. I investigated a lot of them, they didn't serve our particular needs, really. It's possible that one of them would work, with a lot of extra code from us. > Personally, I thought that getting rid of DB.pm wasn't such a hot idea. We didn't get rid of DB.pm. Oh, you mean that there was a proposal to do so? > In this model, only that module would > need to be updated in order to handle new databases (or new database > versions). Right, which is how it is. In fact, usually that module doesn't even need to be updated, just a new one needs to be added. > Do I think comparisons should be case insensitive? From a process > management perspective, hands-down yes I think searches should be case > insensitive except in very rare circumstances. I agree with you fully. If you can find a way to do that *without adding 100% to the complexity of Bugzilla code*, then I'm all for it. I really would like that. I'm just not going to force every contributor and every reviewer to ALWAYS put $dbh->sql_istrcmp('field', '?') where they really just mean "field = ?" in their SQL. I'm not saying that I *want* PostgreSQL Bugzilla to be case sensitive. I'm saying that PostgreSQL Bugzilla *is* case sensitive, and it's a WONTFIX until we have a decent way of fixing it. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From djm at mindrot.org Sun Nov 6 03:27:55 2005 From: djm at mindrot.org (Damien Miller) Date: Sun, 6 Nov 2005 14:27:55 +1100 Subject: Do we want Bugzilla to be case-sensitive or In-Reply-To: <1131053137.3329.58.camel@localhost.localdomain> References: <6F7DA19D05F3CF40B890C7CA2DB13A4202E627A9@ssvlexmb2.amd.com> <1131053137.3329.58.camel@localhost.localdomain> Message-ID: <20051106142755.688c0916.djm@mindrot.org> On Thu, 03 Nov 2005 13:25:36 -0800 Max Kanat-Alexander wrote: > On Thu, 2005-11-03 at 13:10 -0800, Benton, Kevin wrote: > > For things like product and component names, in PostgreSQL, you could > > decide to store it in two forms, one already converted to lower case, > > and another in mixed-case format. > > Yeah, we discussed this as an option. :-) Believe me, Tomas and I went > over everything. I could show you our ICQ logs, this was the one > "unsolvable" problem we ran into. Surely this is in the case of "don't do that"? Component and product names are rarely touched and should only really be touched by clueful people. Accidental duplicates are both obvious and fairly easily rectified. -d From Guillaume.Rousse at inria.fr Sun Nov 6 21:20:21 2005 From: Guillaume.Rousse at inria.fr (Guillaume Rousse) Date: Sun, 06 Nov 2005 22:20:21 +0100 Subject: Another way to map users to LDAP Message-ID: <436E7395.1070803@inria.fr> Current LDAP implementation use mail LDAP attribute from user login to compute its bugzilla ID. This is quite fine on single-datastore bugzilla system, but on multiple-datastore bugzilla, some users may have to use different ids on different bugzilla. For instance, user X involved in projects foo and bar would like to be X at foo.org in foo project's bugzilla, and X at bar.org on bar project's bugzilla. I have a personal patch that completly replaced original bugzilla LDAP mapping with this system. However, if there is any interest, I could rewrite it so as to offer either a choice between the two different mapping methods. -- The only thing more accurate than incoming enemy fire is incoming friendly fire -- Murphy's Military Laws n?15 From justdave at bugzilla.org Thu Nov 10 18:16:23 2005 From: justdave at bugzilla.org (David Miller) Date: Thu, 10 Nov 2005 13:16:23 -0500 Subject: Retargeting enhancements Message-ID: <43738E77.708@bugzilla.org> The last three or four releases, every time we're preparing to branch, a whole mess of bugs wind up getting retargeted to the next release because they don't make the cut to get into the current one. As it currently stands, we have around 300 bugs that fit this criteria to get pushed out of the 2.22 release. Quite a few of these bugs have been getting pushed along every release since the 2.14 days, and the comments on the bugs show it. This really isn't an idea solution, especially with enhancement requests. I'd like to come up with a way to deal with enhancement requests which avoids targeting them at a specific release until they have an owner actually working on them that can tell us they think it'll make it by then... in other words, if it still has the default assignee, it shouldn't be targeted to a release. The question, then, is what do we target them to? There's some value to having something other than --- as a target... to show that we've actually looked at it and decided it's not a dupe. On the other hand, I suppose that's what UNCONFIRMED is for. Future is the next best option that we currently have, but that sounds a lot like "we never plan on doing this" to most folks. I'm leaning at this point to just going with --- since we have the UNCONFIRMED distinction right now. Perhaps go to Future for things that need architectural changes before they can be implemented? Do we have someone willing to triage the "Future" stuff periodically and "defuture" things that required architectural changes that have been made since they were filed? -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From LpSolit at gmail.com Thu Nov 10 19:02:36 2005 From: LpSolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Thu, 10 Nov 2005 20:02:36 +0100 Subject: Retargeting enhancements In-Reply-To: <43738E77.708@bugzilla.org> References: <43738E77.708@bugzilla.org> Message-ID: <4373994C.2030205@gmail.com> > I'd like to come up with a way to deal with enhancement requests which > avoids targeting them at a specific release until they have an owner > actually working on them that can tell us they think it'll make it by > then... in other words, if it still has the default assignee, it > shouldn't be targeted to a release. Several bugs have assignees who are pretty inactive, or who are active but are not interested in these bugs anymore and forgot to reassign them to the default assignee. So looking for bugs who have the default assignee on them only is not a good idea IMO. My suggestion is to retarget all enhancement bugs targetted 2.22 to --- and let each assignee retarget them back to 2.24 if they are (still) working on them (and marking the bug as ASSIGNED to make it clear). In a month or so, all enhancement bugs targetted --- should be reassign to the default assignee (and QA contact for the older ones), showing clearly that anyone can take it (this way, these bugs will also fall back to UNCO or NEW, cleaning up old ASSIGNED bugs). This will give us a good idea of which bugs have real activity. > need architectural changes before they can be implemented? Do we have > someone willing to triage the "Future" stuff periodically and "defuture" > things that required architectural changes that have been made since > they were filed? Here are interesting results from charts for the Bugzilla product, including all bugs (enhancement + "real" bugs): Date\Series,"UNCONFIRMED","NEW","ASSIGNED","REOPENED","RESOLVED","VERIFIED","CLOSED" 2005-11-10,180,1743,191,27,5502,1314,164 Do you really want to triage more than 2000 open bugs?? Let's retarget them to --- and don't waste your time triaging bugs targetted Future or ---. More important (from my point of view) is to triage old open bugs and close those we don't want to fix and those who have been fixed already or are no longer applicable. LpSolit From justdave at bugzilla.org Thu Nov 10 20:18:37 2005 From: justdave at bugzilla.org (David Miller) Date: Thu, 10 Nov 2005 15:18:37 -0500 Subject: Retargeting enhancements In-Reply-To: <4373994C.2030205@gmail.com> References: <43738E77.708@bugzilla.org> <4373994C.2030205@gmail.com> Message-ID: <4373AB1D.50101@bugzilla.org> Fr?d?ric Buclin wrote on 11/10/05 2:02 PM: > My suggestion is to retarget all enhancement bugs targetted 2.22 to --- > and let each assignee retarget them back to 2.24 if they are (still) > working on them (and marking the bug as ASSIGNED to make it clear). In a > month or so, all enhancement bugs targetted --- should be reassign to > the default assignee (and QA contact for the older ones), showing > clearly that anyone can take it (this way, these bugs will also fall > back to UNCO or NEW, cleaning up old ASSIGNED bugs). This will give us a > good idea of which bugs have real activity. Ooh, I like that idea. >> need architectural changes before they can be implemented? Do we have >> someone willing to triage the "Future" stuff periodically and >> "defuture" things that required architectural changes that have been >> made since they were filed? > Do you really want to triage more than 2000 open bugs?? Let's retarget > them to --- and don't waste your time triaging bugs targetted Future or > ---. More important (from my point of view) is to triage old open bugs > and close those we don't want to fix and those who have been fixed > already or are no longer applicable. We'll have to eventually if we want our sanity back. But it can certainly be an ongoing project and not something someone has to waste a lot of time on right this minute. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From mkanat at bugzilla.org Thu Nov 10 20:30:44 2005 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 10 Nov 2005 12:30:44 -0800 Subject: Retargeting enhancements In-Reply-To: <4373994C.2030205@gmail.com> References: <43738E77.708@bugzilla.org> <4373994C.2030205@gmail.com> Message-ID: <1131654644.3328.13.camel@localhost.localdomain> On Thu, 2005-11-10 at 20:02 +0100, Fr?d?ric Buclin wrote: > Several bugs have assignees who are pretty inactive, or who are active > but are not interested in these bugs anymore and forgot to reassign them > to the default assignee. I have several bugs that I am not *currently* working on, but I haven't assigned them to the default assignee because I do plan to work on them. > My suggestion is to retarget all enhancement bugs targetted 2.22 to --- > and let each assignee retarget them back to 2.24 if they are (still) > working on them (and marking the bug as ASSIGNED to make it clear). I tend to mark the bug as ASSIGNED at the moment I actually start working on the bug. That's what ASSIGNED is for, in my understanding. I also tend to use the TM field to work out how I'd like to plan my work. However, it's true that at this point enhancements that are targeted at 2.22 should be fixed. > Do you really want to triage more than 2000 open bugs?? Let's retarget > them to --- and don't waste your time triaging bugs targetted Future or > ---. My concern is this: We already have 2000 open bugs. The ones where we've set a TM are ones that we actually want to and currently plan to fix. Setting their TM back to "---" puts them back into the same class as all the other 2000 bugs, making it much more difficult to differentiate them. But yeah, to address Dave's concern, I almost never target a bug at a release until it has an owner actually working on it. I think that's generally a good idea. And I never set a bug to ASSIGNED until I actually put a patch on it. The only exception to this that I can think of recently was the Custom Field bugs, where I really wanted to see somebody take them for 2.22, so I targeted them when they had no owner. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From olav at bkor.dhs.org Thu Nov 10 21:39:50 2005 From: olav at bkor.dhs.org (Olav Vitters) Date: Thu, 10 Nov 2005 22:39:50 +0100 Subject: Retargeting enhancements In-Reply-To: <1131654644.3328.13.camel@localhost.localdomain> References: <43738E77.708@bugzilla.org> <4373994C.2030205@gmail.com> <1131654644.3328.13.camel@localhost.localdomain> Message-ID: <20051110213950.GH22424@bkor.dhs.org> On Thu, Nov 10, 2005 at 12:30:44PM -0800, Max Kanat-Alexander wrote: > The only exception to this that I can think of recently was the Custom > Field bugs, where I really wanted to see somebody take them for 2.22, so > I targeted them when they had no owner. I appreciate such target setting. Knowing what bugs (even general/meta stuff) are really wanted for a Bugzilla release is very helpful. I'm not always sure if an enhancement is really wanted and if someone will (have time to) review it. After 2.20 was released I wanted to help fix some bugs. I looked at the enhancement bugs targeted for 2.22 in NEW state and assigned to the default owner for potential bugs. Such a list was very helpful. Above example (custom field stuff) is far greater than what I'd like to fix. I want to limit myself (currently) to the smaller (but nice to have) stuff and not have to figure out how a reviewer/maintainer might want something implemented. Complex stuff is ok, as long as I don't have to make designs. For 2.24 I hope to help simplify the UI, although I think a lot of people want to target that as well. -- Regards, Olav From rpello at balicamp.com Wed Nov 16 09:53:39 2005 From: rpello at balicamp.com (Ray Mike Troy Pello) Date: Wed, 16 Nov 2005 16:53:39 +0700 Subject: Report whining In-Reply-To: <435677E4.6070107@peshkin.net> References: <435677E4.6070107@peshkin.net> Message-ID: <437B01A3.5010709@balicamp.com> Dear all, I am setting bugzilla from 2.20 branch. There is a need for me to produce a daily report. I see that there is a event whining feature on it Can this be configured to sent reports instead? or Is it possible to save a report query so the whining will do the report query instead? Or does anyone have a report whine added already? Please direct me to the appropriate forum if this post is not on the right one. regards Ray Pello *BaliCamp SEPG* From LpSolit at gmail.com Wed Nov 16 13:44:29 2005 From: LpSolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Wed, 16 Nov 2005 14:44:29 +0100 Subject: Retargeting enhancements In-Reply-To: <20051110213950.GH22424@bkor.dhs.org> References: <43738E77.708@bugzilla.org> <4373994C.2030205@gmail.com> <1131654644.3328.13.camel@localhost.localdomain> <20051110213950.GH22424@bkor.dhs.org> Message-ID: <437B37BD.5080104@gmail.com> I did an interesting search on b.m.o about open bugs... - targetted to 2.22 - marked as enhancement - untouched for more than 6 months (last changed date is less than 2005-05-01) - and where the assignee didn't touch them for more than a year (time since assignee touched is greater than 1y) I get a list of 118 bugs from the inital list of 292 open enhancements targetted 2.22. I think it's *really* safe and appropriate to retarget these bugs to --- and reassign them to the default assignee and QA contact. For the remaining 174 bugs, we could do some triage manually. If nobody complains today, I plan to do it myself this evening or tomorrow morning. LpSolit From LpSolit at gmail.com Wed Nov 16 13:48:47 2005 From: LpSolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Wed, 16 Nov 2005 14:48:47 +0100 Subject: Retargeting enhancements In-Reply-To: <20051110213950.GH22424@bkor.dhs.org> References: <43738E77.708@bugzilla.org> <4373994C.2030205@gmail.com> <1131654644.3328.13.camel@localhost.localdomain> <20051110213950.GH22424@bkor.dhs.org> Message-ID: <437B38BF.8010307@gmail.com> Oh... and if I remove the constraint "bugs untouched for more than 6 months", the list increases to 181 bugs (some of them weren't in the previous list because retargetting them again and again alters the last change date). LpSolit From CDaniell at realm.com Wed Nov 16 18:05:46 2005 From: CDaniell at realm.com (Casey Daniell) Date: Wed, 16 Nov 2005 12:05:46 -0600 Subject: Modifying bugzilla emails auto sent Message-ID: <5B044FE1AD8C9A428559290A7479ED4B1A6B6E@dal0701.realpulse.com> All, I am having a bit of a problem untangling where the emails that bugzilla sends for issues created/modified are formatted. It looks like its in processmail, but I don't quite understand the logic behind it. Currently there is a summary list of the issue created, ... Summary: PMC Role Change Request - PMC Admin Role cannot delete an invoice or deactivate a vendor Product: Pay Version: 4.3.1.1 Platform: Other OS/Version: All Status: UNCONFIRMED Severity: critical Priority: P2-High ... I need to add another field to this summary email, and can't figure out where this info is gathered to modify it to include an additional field from the DB. Assistance please? (Oh we are using Bugzilla 2.18.X) Casey B. Daniell Realm Business Solutions, Inc. 13727 Noel Rd. Suite 800 Dallas, TX 75240 O:(469) 791-1065 H:(972) 980-4156 C:(512) 589-3667 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkanat at bugzilla.org Wed Nov 16 18:10:21 2005 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 16 Nov 2005 10:10:21 -0800 Subject: Retargeting enhancements In-Reply-To: <437B37BD.5080104@gmail.com> References: <43738E77.708@bugzilla.org> <4373994C.2030205@gmail.com> <1131654644.3328.13.camel@localhost.localdomain> <20051110213950.GH22424@bkor.dhs.org> <437B37BD.5080104@gmail.com> Message-ID: <1132164621.3350.7.camel@localhost.localdomain> On Wed, 2005-11-16 at 14:44 +0100, Fr?d?ric Buclin wrote: > I get a list of 118 bugs from the inital list of 292 open enhancements > targetted 2.22. I think it's *really* safe and appropriate to retarget > these bugs to --- and reassign them to the default assignee and QA contact. Yeah, that sounds like a good idea to me. Just make sure you add a comment explaining what you're doing and mentioning that it's OK for the assigned developer to re-target them back at a release. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From justdave at bugzilla.org Thu Nov 17 04:53:43 2005 From: justdave at bugzilla.org (David Miller) Date: Wed, 16 Nov 2005 23:53:43 -0500 Subject: Retargeting enhancements In-Reply-To: <437B37BD.5080104@gmail.com> References: <43738E77.708@bugzilla.org> <4373994C.2030205@gmail.com> <1131654644.3328.13.camel@localhost.localdomain> <20051110213950.GH22424@bkor.dhs.org> <437B37BD.5080104@gmail.com> Message-ID: <437C0CD7.1050107@bugzilla.org> Fr?d?ric Buclin wrote on 11/16/05 8:44 AM: > I get a list of 118 bugs from the inital list of 292 open enhancements > targetted 2.22. I think it's *really* safe and appropriate to retarget > these bugs to --- and reassign them to the default assignee and QA contact. > > For the remaining 174 bugs, we could do some triage manually. > > If nobody complains today, I plan to do it myself this evening or > tomorrow morning. Sounds good to me. Thanks! -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From CDaniell at realm.com Thu Nov 17 22:56:39 2005 From: CDaniell at realm.com (Casey Daniell) Date: Thu, 17 Nov 2005 16:56:39 -0600 Subject: Modifying bugzilla emails auto sent Message-ID: <5B044FE1AD8C9A428559290A7479ED4B1A6B79@dal0701.realpulse.com> I finally found the answer to this... http://groups.google.com/group/netscape.public.mozilla.webtools/browse_frm/t hread/139dbb3145ed2346/70c6badeca6a6c6e?lnk=st &q=bugzilla+fielddefs+email&rnum=3&hl=en#70c6badeca6a6c6e Is there anyway to add this to the docs? It looks like something that many organizations would change, and its currently fairly difficult to ferret out. Casey -----Original Message----- From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org]On Behalf Of Casey Daniell Sent: Wednesday, November 16, 2005 12:06 PM To: developers at bugzilla.org Subject: Modifying bugzilla emails auto sent All, I am having a bit of a problem untangling where the emails that bugzilla sends for issues created/modified are formatted. It looks like its in processmail, but I don't quite understand the logic behind it. Currently there is a summary list of the issue created, ... Summary: PMC Role Change Request - PMC Admin Role cannot delete an invoice or deactivate a vendor Product: Pay Version: 4.3.1.1 Platform: Other OS/Version: All Status: UNCONFIRMED Severity: critical Priority: P2-High ... I need to add another field to this summary email, and can't figure out where this info is gathered to modify it to include an additional field from the DB. Assistance please? (Oh we are using Bugzilla 2.18.X) Casey B. Daniell Realm Business Solutions, Inc. 13727 Noel Rd. Suite 800 Dallas, TX 75240 O:(469) 791-1065 H:(972) 980-4156 C:(512) 589-3667 NOTICE: This communication contains information which is confidential to Realm Business Solutions, Inc. or its subsidiary ("Realm"). If you are not the intended recipient of this communication, please delete and destroy all copies. If you are the intended recipient of this communication, you should not copy, disclose or distribute this communication without Realm's authority. Any views expressed in this communication are those of the individual sender, except where the sender specifically states them to be Realm's views. Except as required by law, Realm does not represent, warrant or guarantee that the integrity of this communication has been maintained nor that the communication is free of errors, harmful code, interception or interference. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugreport at peshkin.net Sat Nov 19 19:19:36 2005 From: bugreport at peshkin.net (Joel Peshkin) Date: Sat, 19 Nov 2005 11:19:36 -0800 Subject: Bugzilla Performance Tuning Message-ID: <437F7AC8.7020402@peshkin.net> I would like to start to accumulate useful advice in a documentation section for sites to optimize performance...... I'd like suggestions for what should be included.... My starting list.... 1) Shadow database (provide some hints) 2) Raid-0 or LVM 3) Compress the most easily compressible http traffic (don't compress everything... IE will break) AddOutputFilterByType DEFLATE text/html text/plain text/javascript 4) MySql's query cache is off by default. Has anyone experimented with this? I did some very rudimentary tests and found that the act of loading and displaying the next bug in a buglist results in about 10 successful query cache hits. I have not idea how much time that saves or doesn't save. From bbaetz at acm.org Sat Nov 19 23:55:07 2005 From: bbaetz at acm.org (Bradley Baetz) Date: Sun, 20 Nov 2005 10:55:07 +1100 Subject: Bugzilla Performance Tuning In-Reply-To: <437F7AC8.7020402@peshkin.net> References: <437F7AC8.7020402@peshkin.net> Message-ID: <20051119235507.GB2937@mango.home> On Sat, Nov 19, 2005 at 11:19:36AM -0800, Joel Peshkin wrote: > My starting list.... 0) modperl. I actually have this working for index.cgi, and mostly working for show_bug.cgi (mostly meaning its very very hacky) > 4) MySql's query cache is off by default. Has anyone experimented with > this? I did some very rudimentary tests and found that the act of > loading and displaying the next bug in a buglist results in about 10 > successful query cache hits. I have not idea how much time that saves or > doesn't save. Can you find out what queries? If we're running the same query multiple times in a row, we should fix that. Bradley From mkanat at bugzilla.org Wed Nov 23 03:02:49 2005 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 22 Nov 2005 19:02:49 -0800 Subject: Planning the Release of 2.20.1 Message-ID: <1132714969.6518.27.camel@localhost.localdomain> Hey hey. Well, 2.20 has been one of our most stable releases ever, with almost no major bugs being reported against it. However, it's getting near that time again... That's right! This is the time when I ask for everybody's help in getting a release out the door. Here are the 2.20.1 Blockers: http://tinyurl.com/b98ds Let's do everything we can do get those fixed! :-) -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too.