From gerv at mozilla.org  Mon Nov  4 17:43:39 2002
From: gerv at mozilla.org (Gervase Markham)
Date: Mon, 04 Nov 2002 17:43:39 +0000
Subject: [Fwd: Online Help]
Message-ID: <3DC6B1CB.8080706@mozilla.org>

Anyone got any views on this? I heard nothing when I sent it originally...

Gerv

-------- Original Message --------
Subject: Online Help
Date: Mon, 30 Sep 2002 21:35:53 +0100
From: Gervase Markham <gerv at mozilla.org>
Reply-To: developers at bugzilla.org
Organization: mozilla.org
To: developers at bugzilla.org

There's a patch for context-sensitive help over in
http://bugzilla.mozilla.org/show_bug.cgi?id=114179 (needs review, if
anyone thinks it's worth having) , but this message is more about things
like the Bug Writing Guidelines.

I produced a patch to make these a page.cgi page (so they got a header,
footer etc.) but matty made the point that this stuff should perhaps be
in our end-user documentation, which is currently Section 3 of the
Bugzilla Guide.

So we need to have a discussion about our strategy. There seem to be a
couple of routes for page-based help:

- page.cgi-based pages.
    Pros: Bugzilla look and feel
    Cons: possible duplication of material with that in the Guide

- link directly to pages in the Guide
    Pros: One source for Bugzilla usage information
    Cons: Possible that manual and online help require different styles
          Harder to translate

Views?

Gerv

----
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gerv at mozilla.org>



From gerv at mozilla.org  Mon Nov  4 17:43:52 2002
From: gerv at mozilla.org (Gervase Markham)
Date: Mon, 04 Nov 2002 17:43:52 +0000
Subject: [Fwd: Non-specific templates]
Message-ID: <3DC6B1D8.2060303@mozilla.org>

Or this one?

Gerv

-------- Original Message --------
Subject: Non-specific templates
Date: Fri, 04 Oct 2002 08:07:53 +0100
From: Gervase Markham <gerv at mozilla.org>
Reply-To: developers at bugzilla.org
Organization: mozilla.org
To: developers at bugzilla.org

global/field-descs.html.tmpl contains no output. All it does it define a
mapping hash for you. Should it be an "html" template? If not, what
ctype should it be using? "xxx"? "none"?

Gerv

----
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gerv at mozilla.org>



From gerv at mozilla.org  Mon Nov  4 18:20:12 2002
From: gerv at mozilla.org (Gervase Markham)
Date: Mon, 04 Nov 2002 18:20:12 +0000
Subject: Performance measurements
In-Reply-To: <Pine.LNX.4.44.0210240906140.938-100000@tomato.home>
References: <Pine.LNX.4.44.0210240906140.938-100000@tomato.home>
Message-ID: <3DC6BA5C.5020603@mozilla.org>

Bradley Baetz wrote:
> When you run teh query from mysql it shows the time taken at the end :)
> 
> I have a script to generate n bugs; I'll tidy it up and attach it this 
> evening.

Ping? :-)

Gerv



From bbaetz at student.usyd.edu.au  Mon Nov  4 22:08:24 2002
From: bbaetz at student.usyd.edu.au (Bradley Baetz)
Date: Tue, 5 Nov 2002 09:08:24 +1100 (EST)
Subject: Performance measurements
In-Reply-To: <3DC6BA5C.5020603@mozilla.org>
Message-ID: <Pine.LNX.4.44.0211050906090.1008-200000@tomato.home>

On Mon, 4 Nov 2002, Gervase Markham wrote:

> Bradley Baetz wrote:
> > When you run teh query from mysql it shows the time taken at the end :)
> > 
> > I have a script to generate n bugs; I'll tidy it up and attach it this 
> > evening.
> 
> Ping? :-)


Umm, er... Attached.  Its not a full schema, but its reasonably easy to 
extend.

Note that I was using the same basic script for pg, too, so it does 
indiviual INSERTs, which may take quite a while if you make the numbers 
too big.

Thre are a few off-by-one errors in there, but thats not important for our 
purposes.

Bradley

-------------- next part --------------
#!/usr/bin/perl -w

use strict;

my $numUsers = 30000;
my $numProducts = 1;
my $numBugs = 10000;
my $numCcs = 100000;
my $numLongDescs = 100000;

print "BEGIN;\n";

print "CREATE TABLE profiles (
  userid integer NOT NULL auto_increment,
  login_name varchar(255),
  PRIMARY KEY (userid)
);
";

my %users;
foreach my $i (1..$numUsers) {
    my $username = '';
    foreach my $x (1..rand(9)+1) {
        $username .= chr(65+int(rand(26)));
    }
    redo if ($users{$username});
    $users{$username} = 1;
    print "INSERT INTO profiles(login_name) VALUES ('$username');\n";
}

print "
CREATE UNIQUE INDEX profiles_login_name_idx ON profiles(login_name);
";

print "CREATE TABLE products (
  id integer NOT NULL auto_increment,
  name varchar(64) NOT NULL,
  PRIMARY KEY (id)
);
";

my %products;
foreach my $i (1..$numProducts) {
    my $prod = '';
    foreach my $x (1..rand(9)+1) {
        $prod .= chr(65+int(rand(26)));
    }
    redo if ($products{$prod});
    $products{$prod} = 1;
    print "INSERT INTO products(name) VALUES ('$prod');\n";
}

print "
CREATE UNIQUE INDEX products_name_idx ON products(name);
";

print "CREATE TABLE bugs (
  bug_id integer NOT NULL auto_increment,
  product_id integer NOT NULL, -- XXX REFERENCES products(id),
  assigned_to integer NOT NULL, -- REFERENCES profiles(userid),
  reporter integer NOT NULL, -- REFERENCES profiles(userid),
  PRIMARY KEY (bug_id)
);
";

foreach my $i (1..$numBugs) {
    print "INSERT INTO bugs(product_id, assigned_to, reporter) VALUES (" .
      (int(rand($numProducts-1))+1) . "," .
      (int(rand($numUsers-1)) + 1) . "," .
      (int(rand($numUsers-1)) + 1) .
      ");\n";
}

print "
CREATE INDEX bugs_product_id_idx ON bugs(product_id);
CREATE INDEX bugs_assigned_to_idx ON bugs(assigned_to);
CREATE INDEX bugs_reporter_idx ON bugs(reporter);
";

print "CREATE TABLE cc (
  bug_id integer NOT NULL, -- REFERENCES bugs(bug_id),
  who integer NOT NULL -- REFERENCES profiles(userid)
);
";

my %bugs;
foreach my $i (1..$numCcs) {
    my $bug = int(rand($numBugs-1)) + 1;
    my $user = int(rand($numUsers-1)) + 1;
    if (defined($bugs{$bug}) && $bugs{$bug}{$user}) {
        redo;
    }
    $bugs{$bug}{$user} = 1;
    print "INSERT INTO cc(bug_id, who) VALUES ($bug,$user);\n";
}

print "
CREATE INDEX cc_who_idx ON cc(who);
CREATE UNIQUE INDEX cc_bug_id_who_idx ON cc(bug_id,who);
";

print "CREATE TABLE longdescs (
  bug_id integer NOT NULL, -- REFERENCES bugs(bug_id),
  who integer NOT NULL -- REFERENCES profiles(userid)
);
";

foreach my $i (1..$numLongDescs) {
    my $bug = int(rand($numBugs-1)) + 1;
    my $user = int(rand($numUsers-1)) + 1;
    print "INSERT INTO longdescs(bug_id, who) VALUES ($bug,$user);\n";
}

print "
CREATE INDEX longdescs_bug_id_idx ON longdescs(bug_id);
CREATE INDEX longdescs_who_idx ON longdescs(who);
";

print "COMMIT;\n";

From matthew at barnson.org  Tue Nov  5 01:59:51 2002
From: matthew at barnson.org (Matthew P. Barnson)
Date: 04 Nov 2002 18:59:51 -0700
Subject: [Fwd: Online Help]
In-Reply-To: <3DC6B1CB.8080706@mozilla.org>
References: <3DC6B1CB.8080706@mozilla.org>
Message-ID: <1036461591.2170.20.camel@chandler.int.barnson.org>

On Mon, 2002-11-04 at 10:43, Gervase Markham wrote:
> Anyone got any views on this? I heard nothing when I sent it originally...
> - page.cgi-based pages.
>     Pros: Bugzilla look and feel
>     Cons: possible duplication of material with that in the Guide

  I'd be against this sort of approach... duplication of effort is
needless.

> - link directly to pages in the Guide
>     Pros: One source for Bugzilla usage information
>     Cons: Possible that manual and online help require different styles
>           Harder to translate

  I'd be all for this kind of approach.  The important thing is to
figure out the context-sensitive portions that the Guide could have
links for.  Hmm, that didn't come out well.  I mean, KDE and Gnome both
use this type of help system, where in the well-written products,
clicking "help" at a particular part takes you to the help screen for
the menu/dropdown/what-have-you that you're at.  You can also read the
help end-to-end.  It would require a bit more of a screen-based approach
to the User's Guide portion of The Bugzilla Guide, but would be quite
do-able IMHO, and probably more readable than what we have now.

 
-- 
Matthew P. Barnson
Sr. UNIX Systems Administrator
DAM Computer Consulting, Inc.
"When you cuss, think of us!"

"...the general idea that [the Supreme Court ]will restrain
itself, despite believing a law is stupid, is a feature,
not a bug in our constitutional tradition."
-Lawrence Lessig
nd 100%". --Penn Jillette
 one and drive on without guilt!
-ccm




From gerv at mozilla.org  Tue Nov  5 09:37:50 2002
From: gerv at mozilla.org (Gervase Markham)
Date: Tue, 05 Nov 2002 09:37:50 +0000
Subject: [Fwd: Online Help]
In-Reply-To: <1036461591.2170.20.camel@chandler.int.barnson.org>
References: <3DC6B1CB.8080706@mozilla.org> <1036461591.2170.20.camel@chandler.int.barnson.org>
Message-ID: <3DC7916E.9010809@mozilla.org>

Matthew P. Barnson wrote:
> On Mon, 2002-11-04 at 10:43, Gervase Markham wrote:
>>- link directly to pages in the Guide
>>    Pros: One source for Bugzilla usage information
>>    Cons: Possible that manual and online help require different styles
>>          Harder to translate
> 
>   I'd be all for this kind of approach. 

So how would you solve the localisation problem?

Gerv




From bbaetz at student.usyd.edu.au  Tue Nov  5 23:19:03 2002
From: bbaetz at student.usyd.edu.au (Bradley Baetz)
Date: Wed, 6 Nov 2002 10:19:03 +1100 (EST)
Subject: You may want to upgrade TT...
Message-ID: <Pine.LNX.4.44.0211061013330.1352-100000@tomato.home>

Theres now a development v 2.08c of template toolkit. This works arround a 
perl bug exposed via the recent update to CGI.pm, where error messages 
would end up being reported as "Template::Exception" rather than anything 
useful. Gerv was finding this really annoying, in particular :)

It will also provide a speedup to people running v2.08, since File::Temp
will then become lazily loaded, and Bugzila doesn't usually use that part
of TT toolkit. This was first used in v2.08, so theres no difference from
earlier releases of TT.

Theres no need to do this in checksetup, and up the formal version
requirements, since it really only affects developers. We can reconsider
once a stable 2.09 release comes out (because of the speed thing).

Bradley



From myk at mozilla.org  Tue Nov  5 23:34:26 2002
From: myk at mozilla.org (Myk Melez)
Date: Tue, 05 Nov 2002 15:34:26 -0800
Subject: You may want to upgrade TT...
In-Reply-To: <Pine.LNX.4.44.0211061013330.1352-100000@tomato.home>
References: <Pine.LNX.4.44.0211061013330.1352-100000@tomato.home>
Message-ID: <3DC85582.5050401@mozilla.org>

Bradley Baetz wrote:

>Theres now a development v 2.08c of template toolkit. This works arround a 
>perl bug exposed via the recent update to CGI.pm, where error messages 
>would end up being reported as "Template::Exception" rather than anything 
>useful. Gerv was finding this really annoying, in particular :)
>
Any idea what the fix for that looks like?  I might prefer to patch my 
current 2.07 installation, since upgrading TT means porting my FLUSH 
patch, which may not be easy.




From bbaetz at student.usyd.edu.au  Tue Nov  5 23:45:01 2002
From: bbaetz at student.usyd.edu.au (Bradley Baetz)
Date: Wed, 6 Nov 2002 10:45:01 +1100 (EST)
Subject: You may want to upgrade TT...
In-Reply-To: <3DC85582.5050401@mozilla.org>
Message-ID: <Pine.LNX.4.44.0211061040350.1820-100000@tomato.home>

On Tue, 5 Nov 2002, Myk Melez wrote:

> Bradley Baetz wrote:
> 
> >Theres now a development v 2.08c of template toolkit. This works arround a 
> >perl bug exposed via the recent update to CGI.pm, where error messages 
> >would end up being reported as "Template::Exception" rather than anything 
> >useful. Gerv was finding this really annoying, in particular :)
> >
> Any idea what the fix for that looks like?  I might prefer to patch my 
> current 2.07 installation, since upgrading TT means porting my FLUSH 
> patch, which may not be easy.

Yeah, its in the archives at 
http://www.template-toolkit.org/pipermail/templates/2002-October/003779.html 
although its been base64 encoded by my mailer.

I generated it with a perl script + manual corrections. I can mail you a 
copy if you want.
 
You're going to have to update eventually, though, since 2.08 will become
a requirement fairly soon. I don't think that there are likly to be major 
changes which would have affected that patch, though.

Bradley



From matthew at barnson.org  Wed Nov  6 03:10:40 2002
From: matthew at barnson.org (Matthew P. Barnson)
Date: 05 Nov 2002 20:10:40 -0700
Subject: [Fwd: Online Help]
In-Reply-To: <3DC7916E.9010809@mozilla.org>
References: <3DC6B1CB.8080706@mozilla.org>
	<1036461591.2170.20.camel@chandler.int.barnson.org> 
	<3DC7916E.9010809@mozilla.org>
Message-ID: <1036552240.2801.297.camel@chandler.int.barnson.org>

Well, I hadn't really given that much thought, but it looks like the KDE
guys have already figured this out. 
http://i18n.kde.org/translation-howto/index.php .  It seems to be a
pretty comprehensive how-to, and I don't think we'd go wrong emulating
it, since the standards involved are fairly universal and becoming
better understood in the UNIX community these days.

Basically, if I understand correctly, we need to generate "empty" files
which contain the bare structure of the Guide for translations.  These
"empty" files are actually skeletal Docbook XML with no textual data
between the tags. Apparently, you can merge these "PO's" with the master
"POT" when the master (English) version of the Guide is updated, so that
translators end up with "fuzzy" areas on their translation, with English
words in there temporarily that need to be translated.

I'm not certain what to do about the section id links and other
xreflabels and such that give clues to locations of things in the
documentation.  I'm thinking we should probably stick to the English
definition of the link, but make sure that the entire text is UTF-8
encoded.  Although I'm really not even sure what that means at this
point, I'm sure I can figure it out :)

We probably want to put in a skeleton structure for translations we're
going to attempt first.  Although my German is quite rusty, after I
reorganize the doc, I'll be happy to begin translation efforts.  The
translation will be so bad that I am sure a native German speaker will
desparately want to correct it.  I suggest we use ISO3166-1 codes, like
this:

bugzilla/en/docs/sgml (or html, or txt, whatever)
bugzilla/de/docs/sgml
bugzilla/pt/docs/sgml (Portugal Portuguese translation)
bugzilla/br/docs/sgml (Brazilian Portuguese translation)
etc.

What would really be the cat's meow would be to have the country code be
*before* the Bugzilla path, so that we can indicate an entire localized
tree:

en/bugzilla/docs/sgml
de/bugzilla/docs/sgml
etc.

That would make it easier on the linking for the app, so we don't have
to have logic in the app with a param saying "please enter your
two-letter ISO3166 country code here".  Although, IMHO, that would be an
acceptable parameter if we don't want to have separate localized
versions of the app...


On Tue, 2002-11-05 at 02:37, Gervase Markham wrote:
> So how would you solve the localisation problem?
 
-- 
Matthew P. Barnson
Sr. UNIX Systems Administrator
DAM Computer Consulting, Inc.
"When you cuss, think of us!"

"...the general idea that [the Supreme Court ]will restrain
itself, despite believing a law is stupid, is a feature,
not a bug in our constitutional tradition."
-Lawrence Lessig
nd 100%". --Penn Jillette
 one and drive on without guilt!
-ccm




From gerv at mozilla.org  Tue Nov  5 08:31:48 2002
From: gerv at mozilla.org (Gervase Markham)
Date: Tue, 05 Nov 2002 08:31:48 +0000
Subject: For interest: Bugzilla performance
Message-ID: <3DC781F4.1000605@mozilla.org>

As you may recall, I made some changes to the default params on the 
Bugzilla Search UI two weeks ago. Specifically, I changed:

- The default for email addresses to "is" rather than "contains", and
- The default for comments search to "contains string" rather than
   "contains all words/strings"

I get email from Bugzilla whenever a search is killed for taking too 
long. The number of these mails, while fluctuating a lot, is therefore a 
crude measure of how overloaded Bugzilla is. Here are the averages, for 
the interest of staff@ and developers at .

Pre-changes:  45.9 mails per day over 7 days
Post-changes: 16.3 mails per day over 12 days

Further performance changes, which required changes to Bugzilla's code, 
will kick in at the upgrade on November 8th.

Gerv




From myk at mozilla.org  Wed Nov  6 09:32:19 2002
From: myk at mozilla.org (Myk Melez)
Date: Wed, 06 Nov 2002 01:32:19 -0800
Subject: For interest: Bugzilla performance
In-Reply-To: <3DC781F4.1000605@mozilla.org>
References: <3DC781F4.1000605@mozilla.org>
Message-ID: <3DC8E1A3.2020306@mozilla.org>

Gervase Markham wrote:

> Pre-changes:  45.9 mails per day over 7 days
> Post-changes: 16.3 mails per day over 12 days 

Note that the number of killed queries varies widely by day of week 
(f.e. there were 6 on Sunday, 17 on Monday, and 50 on Tuesday), so 
measuring two different time periods is likely to throw off the data.

Note also that emails sometimes mention multiple killed queries, 
especially when the queries are generated by a DOS attack.

We stopped a DOS attack last Wednesday evening, not the first we've 
dealt with in the last month, and that may have skewn results both 
before and afterwards.

Still I'm quite happy about these changes, which I think have improved 
performance.

> Further performance changes, which required changes to Bugzilla's 
> code, will kick in at the upgrade on November 8th.

Unfortunately we'll inherit some performance regressions as well from 
some recent code changes (the groups rewrite in particular) that the 
performance improvements will hopefully counteract.

-myk




From gerv at mozilla.org  Wed Nov  6 09:48:54 2002
From: gerv at mozilla.org (Gervase Markham)
Date: Wed, 06 Nov 2002 09:48:54 +0000
Subject: For interest: Bugzilla performance
In-Reply-To: <3DC8E1A3.2020306@mozilla.org>
References: <3DC781F4.1000605@mozilla.org> <3DC8E1A3.2020306@mozilla.org>
Message-ID: <3DC8E586.2030302@mozilla.org>

Myk Melez wrote:
> Gervase Markham wrote:
> 
>> Pre-changes:  45.9 mails per day over 7 days
>> Post-changes: 16.3 mails per day over 12 days 
> 
> Note that the number of killed queries varies widely by day of week 
> (f.e. there were 6 on Sunday, 17 on Monday, and 50 on Tuesday), so 
> measuring two different time periods is likely to throw off the data.

I hoped to counteract this problem by averaging. The second twelve days 
followed on from the first seven, so (roughly) we have a single week 
average, then a following two-week average.

> Note also that emails sometimes mention multiple killed queries, 
> especially when the queries are generated by a DOS attack.

This is also true, and I made no attempt to count this. I assumed, 
perhaps incorrectly, that this would not affect one set of results any 
more than another.

> We stopped a DOS attack last Wednesday evening, not the first we've 
> dealt with in the last month, and that may have skewn results both 
> before and afterwards.

If you exclude last Wednesday from the results (65 mails), then that 
16.3 figure goes down to 11.9, making the improvement greater.

>> Further performance changes, which required changes to Bugzilla's 
>> code, will kick in at the upgrade on November 8th.
> 
> Unfortunately we'll inherit some performance regressions as well from 
> some recent code changes (the groups rewrite in particular) that the 
> performance improvements will hopefully counteract.

Indeed. It's all swings and roundabouts.

Gerv



From myk at mozilla.org  Wed Nov  6 11:00:46 2002
From: myk at mozilla.org (Myk Melez)
Date: Wed, 06 Nov 2002 03:00:46 -0800
Subject: For interest: Bugzilla performance
In-Reply-To: <3DC781F4.1000605@mozilla.org>
References: <3DC781F4.1000605@mozilla.org> <3DC8E1A3.2020306@mozilla.org> <3DC8E586.2030302@mozilla.org>
Message-ID: <3DC8F65E.9010504@mozilla.org>

Gervase Markham wrote:

> If you exclude last Wednesday from the results (65 mails), then that 
> 16.3 figure goes down to 11.9, making the improvement greater.

I count 39 from last Wedneday (the difference is probably due to email 
client time localizations) and 98 mails in the last six days (Thursday, 
October 31 - Tuesday, November 5), which compares to:

40 emails from Thursday, October 3 - Tuesday, October 8
98 emails from Thursday, October 10 - Tuesday, October 15
312 emails from Thursday, October 17 - Tuesday, October 22
117 emails from Thursday, October 24 - Tuesday, October 29

Of these result sets, I believe only the latter two are influenced by 
your changes, and they do show a downward trend, but the overall results 
are too variable to be indicative.  This may be because of DOS attacks 
(intentional or otherwise), but it could also be natural volatility in 
Bugzilla usage.

-myk




From bbaetz at student.usyd.edu.au  Wed Nov  6 12:41:12 2002
From: bbaetz at student.usyd.edu.au (Bradley Baetz)
Date: Wed, 6 Nov 2002 23:41:12 +1100 (EST)
Subject: For interest: Bugzilla performance
In-Reply-To: <3DC8E1A3.2020306@mozilla.org>
Message-ID: <Pine.LNX.4.44.0211062252180.23023-100000@tomato.home>

On Wed, 6 Nov 2002, Myk Melez wrote:

> Note also that emails sometimes mention multiple killed queries, 
> especially when the queries are generated by a DOS attack.
> 
> We stopped a DOS attack last Wednesday evening, not the first we've 
> dealt with in the last month, and that may have skewn results both 
> before and afterwards.

Potential project for interested people - hack mod_throttle to allow
whitelisting ip blocks ;) (Does mod_throttle catch anyone anymore, since
the limit was raised to deal with NSCP's NATed connections?)

> Unfortunately we'll inherit some performance regressions as well from 
> some recent code changes (the groups rewrite in particular) that the 
> performance improvements will hopefully counteract.

Yeah. Unfortunately, there was no working arround that one - a bitwise AND
is always going to be quicker than an sql table join, no matter how you
write the query. It has given us some nice features, although Joel's stuff
isn't landing before bmo's upgrade, so most of the advantages are only
infrastructure related.

(The timing you did yesterday was on the whole script, mind you, not just
on the sql, so its possible, although unlikely, that something else slowed
down. We should test that at some point)

Bring on mod_perl! ;)

> -myk

Bradley



From myk at mozilla.org  Wed Nov  6 12:47:36 2002
From: myk at mozilla.org (Myk Melez)
Date: Wed, 06 Nov 2002 04:47:36 -0800
Subject: For interest: Bugzilla performance
In-Reply-To: <Pine.LNX.4.44.0211062252180.23023-100000@tomato.home>
References: <Pine.LNX.4.44.0211062252180.23023-100000@tomato.home>
Message-ID: <3DC90F68.2050101@mozilla.org>

Bradley Baetz wrote:

>On Wed, 6 Nov 2002, Myk Melez wrote:
>
>  
>
>>Note also that emails sometimes mention multiple killed queries, 
>>especially when the queries are generated by a DOS attack.
>>
>>We stopped a DOS attack last Wednesday evening, not the first we've 
>>dealt with in the last month, and that may have skewn results both 
>>before and afterwards.
>>    
>>
>
>Potential project for interested people - hack mod_throttle to allow
>whitelisting ip blocks ;) (Does mod_throttle catch anyone anymore, since
>the limit was raised to deal with NSCP's NATed connections?)
>
No, mod_throttle is now completely ineffective, since Netscape NATs 
everyone coming through the firewall to a single IP address.  I asked 
the author of mod_throttle about whitelisting, and he said it'll happen 
in versioni 4, due out sometime (this seemed to be later than sooner).

Fortunately, however, John Dee has agreed to work on a script that 
accomplishes what mod_throttle does except that it creates permanent 
bans and honors a whitelist, so we should have better defenses against 
these attacks soon.

-myk




From bbaetz at student.usyd.edu.au  Wed Nov  6 13:13:18 2002
From: bbaetz at student.usyd.edu.au (Bradley Baetz)
Date: Thu, 7 Nov 2002 00:13:18 +1100 (EST)
Subject: For interest: Bugzilla performance
In-Reply-To: <3DC90F68.2050101@mozilla.org>
Message-ID: <Pine.LNX.4.44.0211062352320.23434-100000@tomato.home>

On Wed, 6 Nov 2002, Myk Melez wrote:

> No, mod_throttle is now completely ineffective, since Netscape NATs 
> everyone coming through the firewall to a single IP address.  I asked 
> the author of mod_throttle about whitelisting, and he said it'll happen 
> in versioni 4, due out sometime (this seemed to be later than sooner).

Right, hence the 'potential project'...

Actually, all the NSCP stuff is in one subnet, right? Can't you manually
hack the mod_throttle source for your specific needs?

/me grabs source code:

in mod_throttle's access_handler, just before grabbing the critical
section, if r->connection->remote_addr.sin_addr is in an NSCP/AOL subnet,
then return DECLINED.

Totally and utterly untested, mind you - if it breaks you get to keep the 
pieces :)

Bradley




From gerv at mozilla.org  Wed Nov  6 14:23:58 2002
From: gerv at mozilla.org (Gervase Markham)
Date: Wed, 06 Nov 2002 14:23:58 +0000
Subject: For interest: Bugzilla performance
In-Reply-To: <3DC8F65E.9010504@mozilla.org>
References: <3DC781F4.1000605@mozilla.org> <3DC8E1A3.2020306@mozilla.org> <3DC8E586.2030302@mozilla.org> <3DC8F65E.9010504@mozilla.org>
Message-ID: <3DC925FE.80002@mozilla.org>

Myk Melez wrote:
> Of these result sets, I believe only the latter two are influenced by 
> your changes, and they do show a downward trend, but the overall results 
> are too variable to be indicative.  This may be because of DOS attacks 
> (intentional or otherwise), but it could also be natural volatility in 
> Bugzilla usage.

You have a larger archive than me :-) I didn't realise the volume was so 
low earlier in the month, nor that the week-on-week average was so 
volatile. The change was made on Wednesday, 23rd October.

Fair enough, then. We can't really tell if it made a difference. One 
thing that is true, though, is that reading the killed searches, there 
are less of the sort (lots of words in the comments, email substrings) 
that the changes were designed to prevent. But I suppose that's obvious.

Gerv



From gerv at mozilla.org  Wed Nov  6 15:59:38 2002
From: gerv at mozilla.org (Gervase Markham)
Date: Wed, 06 Nov 2002 15:59:38 +0000
Subject: Festa's CNET article on 200,000 bug sweepstake
Message-ID: <3DC93C6A.6060805@mozilla.org>

http://news.com.com/2100-1023-964663.html?tag=fd_top

We got off pretty lightly :-) I sent info to Catherine, and she provided 
Paul with the quote he used. CCing developers at bugzilla.org because 
Bugzilla gets a good plug at the end of this article.

Gerv




From douglas at SLAC.Stanford.EDU  Fri Nov  8 00:24:00 2002
From: douglas at SLAC.Stanford.EDU (Douglas Smith)
Date: Thu, 07 Nov 2002 16:24:00 -0800
Subject: Hello all-
Message-ID: <200211071624.00045.douglas@slac.stanford.edu>


I am new to development for bugzilla, and we are eval it
to be used for BaBar high energy experiment for bug tracking
with our software.

There are a few concerns I have - 

1. Is there standard way to produce/view debug messages in
developing/changing the code?
2. Can I get the user authentication to use the Apache server
authentication, instead of the interal bugzilla login?
And if I do get this to work, and people interested in my
changes for a later version (I might be a little rough on
this to get it working quickly).
3. We have ~1200 software packages to manage, I am assuming
that I can't (or shouldn't) create 1200 products in BugZilla,
any suggestions on how I should split these up, or is there
a limit (suggested or managable) on the number of components
in each product?
4. Support for Oracle in the works?  Perhaps I can help with
this?

Douglas

-- 
-----------------------------------------------------------
Douglas A. Smith                  douglas at slac.stanford.edu
Office: Bld 280, Rm 157                       (650)926-2369
-----------------------------------------------------------


From justdave at syndicomm.com  Fri Nov  8 01:06:14 2002
From: justdave at syndicomm.com (David Miller)
Date: Thu, 7 Nov 2002 20:06:14 -0500
Subject: Hello all-
In-Reply-To: <200211071624.00045.douglas@slac.stanford.edu>
References: <200211071624.00045.douglas@slac.stanford.edu>
Message-ID: <a05200f08b9f0b7da9466@[192.168.1.203]>

On 11/7/02 4:24 PM -0800, Douglas Smith wrote:

> 2. Can I get the user authentication to use the Apache server
> authentication, instead of the interal bugzilla login?
> And if I do get this to work, and people interested in my
> changes for a later version (I might be a little rough on
> this to get it working quickly).

This has been attempted once or twice...  there's advantages and drawbacks
to it.  See http://bugzilla.mozilla.org/show_bug.cgi?id=166794, which I'm
pretty sure is a dupe, because I know there's another bug with a ton more
discussion on it, but I can't find it right now.  The above bug will get
duped to it when I find it.

> 3. We have ~1200 software packages to manage, I am assuming
> that I can't (or shouldn't) create 1200 products in BugZilla,
> any suggestions on how I should split these up, or is there
> a limit (suggested or managable) on the number of components
> in each product?

You can have as many products as you want up to the limits of the
database's key size, and ditto for components.  I think you can have a
total of 32767 products, and the same number of components (total
components, not per product).

You may want a better way of breaking them up on the "choose a product"
page though when you go into Enter Bug.  I have one I'm working on right
now that has a list-box with the products instead of just listing them all
on the page, and the description on the right changes via javascript based
on which one you have selected.  (Look at the Bugzilla Helper on
bugzilla.mozilla.org for an example of this - their Choose-component
section within the guided bug form uses the same code)

> 4. Support for Oracle in the works?  Perhaps I can help with
> this?

It's been done in the past, a LONG time ago.  I wouldn't argue against it
happening again, and I'll likely help with it if it does.  I'm in the
process of making it work with Sybase right now, and Dave Lawrence is
working on support for Postgres.  Both of those will likely be done in the
next month or two.  (Postgres is almost done now, but Dave Lawrence is out
travelling the country in an RV promoting Red Hat right now :)
-- 
Dave Miller      Project Leader, Bugzilla Bug Tracking System
http://www.justdave.net/             http://www.bugzilla.org/


From myk at mozilla.org  Fri Nov  8 04:55:27 2002
From: myk at mozilla.org (Myk Melez)
Date: Thu, 07 Nov 2002 20:55:27 -0800
Subject: thanks for help on b.m.o upgrade and things still to do
Message-ID: <3DCB43BF.3020601@mozilla.org>

Hey everyone,

Thanks for all your help getting the Bugzilla trunk ready for the b.m.o 
upgrade (and developer's release)!  In the last few days a number of 
folks have pitched in with patches, reviews, testing, advice, and other 
help, and I appreciate it very much.  It has already contributed to 
making this upgrade smoother than previous ones.

There are still a few things to do and not much time to do them.  If you 
have some time, please pitch in.  The following bugs (in order of 
importance from most to least) need review:

178841 - confidential bug; email me if you want to help review and 
aren't in the security group
171505 - disabled flags should still show up in the UI

In addition, the following two bugs aren't on the blocker list, but they 
are low risk and small and ripe for adding (if the two bugs above get 
resolved quickly):

bug 170464 - OS/2 disappeared from operating system list (Bugzilla Helper)
bug 178984 - flag requestee field should be disabled unless flag is 
requested

If more bugs pop up in the next day I'll link to them from the b.m.o 
upgrade bug:

http://bugzilla.mozilla.org/show_bug.cgi?id=bmo-upgrade

If you see a bug that should be in the upgrade, tell me why in a comment 
on the upgrade bug, but note that only security vulnerabilities, serious 
bustage, significant performance improvements, and extremely low-risk UI 
enhancements will get into the upgrade at this late stage.

Also note that Dave has the final say on what goes into the developer's 
release (and thus, the b.m.o upgrade), but I think he's following my 
lead on things (at least until after the upgrade).  You need to get 
a=justdave on all bugs at this point before checking in a fix for them.

One more thing!  If you're responsible for a feature that landed since 
the last b.m.o upgrade on July 11, it would really help if you wrote up 
a small blurb about the feature, how it works, and how to use it.  I'll 
use your blurb in an email to the mozilla.org community about the 
upgrade on Monday, and I'll pass it along to Dave for use in the release 
notes and publicity for the developer's release.

-myk




From gerv at mozilla.org  Fri Nov  8 09:27:31 2002
From: gerv at mozilla.org (Gervase Markham)
Date: Fri, 08 Nov 2002 09:27:31 +0000
Subject: Hello all-
In-Reply-To: <200211071624.00045.douglas@slac.stanford.edu>
References: <200211071624.00045.douglas@slac.stanford.edu>
Message-ID: <3DCB8383.1070300@mozilla.org>

Douglas Smith wrote:
> I am new to development for bugzilla, and we are eval it
> to be used for BaBar high energy experiment for bug tracking
> with our software.
> 
> There are a few concerns I have - 

In the future, the newsgroup is probably a better place to ask such 
questions. :-)

> 1. Is there standard way to produce/view debug messages in
> developing/changing the code?

If it goes wrong, see the Apache error log. :-)

Gerv



From gerv at mozilla.org  Fri Nov  8 18:39:57 2002
From: gerv at mozilla.org (Gervase Markham)
Date: Fri, 08 Nov 2002 18:39:57 +0000
Subject: [Fwd: Online Help]
In-Reply-To: <1036552240.2801.297.camel@chandler.int.barnson.org>
References: <3DC6B1CB.8080706@mozilla.org>	<1036461591.2170.20.camel@chandler.int.barnson.org> 	<3DC7916E.9010809@mozilla.org> <1036552240.2801.297.camel@chandler.int.barnson.org>
Message-ID: <3DCC04FD.9010307@mozilla.org>

Matthew P. Barnson wrote:
> Well, I hadn't really given that much thought, but it looks like the KDE
> guys have already figured this out. 
> http://i18n.kde.org/translation-howto/index.php .  It seems to be a
> pretty comprehensive how-to, and I don't think we'd go wrong emulating
> it, since the standards involved are fairly universal and becoming
> better understood in the UNIX community these days.
> 
> Basically, if I understand correctly, we need to generate "empty" files
> which contain the bare structure of the Guide for translations.

The problem with this approach is that we then have two different 
translation mechanisms.

I think it's fair to say that translators will not want to bother with 
90% of content in the Bugzilla Guide - the admin either speaks English, 
or knows someone who does. More important is interface localisation (for 
which we already have a mechanism) and localisation of help.

Now, it's my assertion that the in-app help for Bugzilla is a different 
thing to the user section of the Bugzilla Guide, and that even if they 
share concepts, the text of one would not be suitable for direct use in 
the other.

I believe it would be easier all round if we use the normal Bugzilla 
localisation mechanism for all of Bugzilla, including its help. Then, if 
someone turns up with a completely translated Guide, we can cross that 
bridge at that point.

Gerv



From myk at mozilla.org  Sat Nov  9 14:13:47 2002
From: myk at mozilla.org (Myk Melez)
Date: Sat, 09 Nov 2002 06:13:47 -0800
Subject: b.m.o upgrade complete; regression fixing underway
Message-ID: <3DCD181B.7060106@mozilla.org>

The b.m.o upgrade took a little over seven hours.  I brought the system 
back up after 1am Friday night/Saturday morning.  The bad news is that 
we quickly found a bunch of regressions.  The good news is that so far 
all of them have been either minor or obvious (or in some cases both). 
 We have no known data loss/corruption bugs and only one (potential) 
security hole.

Thanks to everyone who stayed up or woke up around the world to help out 
with the regression fixing and reviewing!  Got a second?  Take a look at 
the list and pick off one or two to fix or review:

http://bugzilla.mozilla.org/show_bug.cgi?id=bmo-regressions

/me goes to get some sleep

-myk




From gerv at gerv.net  Fri Nov 15 09:33:40 2002
From: gerv at gerv.net (Gervase Markham)
Date: Fri, 15 Nov 2002 09:33:40 +0000
Subject: Bugzilla bug tracking database for 2.5 now available.
Message-ID: <3DD4BF74.7060808@gerv.net>

Martin,

I'm one of the core developers of Bugzilla, and just wanted to say how 
great it is that you've started using it for the Linux kernel 
(http://bugme.osdl.org/).

Might I suggest you set up a product (or component) for people to file 
bugs against your Bugzilla installation in? This allows you to triage 
them, separate out local tweak requests from more general enhancements, 
and forward the latter on to us in http://bugzilla.mozilla.org :-) You 
might even use Bugzilla's bug moving feature for this purpose.

Also, are you aware of the 
news://news.mozilla.org/netscape.public.mozilla.webtools newsgroup? It's 
the best place for Bugzilla advice. Particularly, I'd suggest you run 
ideas past it before implementing any sigificant changes or enhancements 
- not because you are incapable (perish the thought), but merely because 
we've found in the past that people who don't, normally do things the 
obvious and hard, rather than the less-obvious and easy way :-)

Good luck, and let us know if there's anything we can do to help. We 
love to get feedback on how we can make Bugzilla better.

Gerv



From bbaetz at student.usyd.edu.au  Fri Nov 15 10:56:57 2002
From: bbaetz at student.usyd.edu.au (Bradley Baetz)
Date: Fri, 15 Nov 2002 21:56:57 +1100
Subject: Why quicksearch sucks
Message-ID: <20021115105657.GA15966@tomato.home>

As you've probably noticed, quicksearch has been disabled on bmo due to
load issues. This is bug 179960.

The main problem is that quicksearch entries are inherently slow. We do
a substring search on the description OR status whiteboard for each
word. This means that the best we can get away with is a linear search
of all the bug in teh database.

However, we also do a substring match on the product/components. Before
the upgrade, this was just an extra string search. After the upgrade +
bug 43600, this is now a string search on the product/component table,
and an integer equality test on teh bugs table, via a JOIN/

Now, you'd think that that would be faster - comparing a number has to
beat a string subsearch on each bug entry. The problem is that QS uses
OR between items, so the database cannot use the product/component stuff
as a filter to start with. Instead, rather than the 'simple' traversal
of all the entries, because this is a join the db has to use a separate
table, to create the rows containt the bugs, product, _and_ component
entries. This table ends up having to be on disk for our 180000-odd
bugs, which is real slow.

This is basically the same problem as bug 127200, I think.

So, how do we fix it? The correct fix is to use a subselect for the
product id:

SELECT ... FROM bugs WHERE bugs.product_id IN (SELECT id FROM products
WHERE (instr(products.name, 'foo')))) OR ... OR instr(bugs.short_desc,
"foo"))

That then gets us back to the previous search, but probably slightly
faster because of the number checks.

Which is great, except that mysql doesn't support SUBSELECTs.

So the alternate solution is to do what was done in bug 21700, and
lookup stuff in joined tables first. I wasnt to do this via some sort of
warpper func which would use subselects for database servers, and a
separate select + IN for mysql. There are a couple of disadvantages with
this:

- the routine we use will be messy
- for small matches, (not using OR), this may be slower, because of the
extra perl<->db overhead
- for really large matches, this may be slower, not only because of the
overhead, but because matching most of the db will require the temp
table anyway.

Also:

- &debug=1 output won't show the full query. Tough. :)
- Bugzilla::Search won't really be abel to give you back the SQL per se;
it'd have to change to a ->runQuery method. Its probably going to have
to do that for other reasons, though, so thats not an issue.

I'm not sure how much the last two will affect things; the second isn't
the common case, and we really shouldn't be tuning to people seecting >
50000 bugs. The first is unlikly to be much - even if its (say) 20%
(which its not on localhost, but could be if your db server was a long
way away), 120% of 0.01 seconds isn't going to be noticable by anyone,
and it smore than balanced out by teh cases where it would matter.

There are issues with the max size for an IN; we can fix that by
breaking it up into subsections and then using OR on the bits.

Note that when we move to custfields, we'll have exactly the same
problem, so we do need a generic solution to this.

Thoughts?

Bradley


From kniht at us.ibm.com  Fri Nov 15 17:24:28 2002
From: kniht at us.ibm.com (Jon Tollefson)
Date: 15 Nov 2002 11:24:28 -0600
Subject: Bugzilla bug tracking database for 2.5 now available.
In-Reply-To: <443986008.1037346905@[10.10.2.3]>
References: <3DD4BF74.7060808@gerv.net>  <443986008.1037346905@[10.10.2.3]>
Message-ID: <1037381068.6872.158.camel@skynet.rchland.ibm.com>

On Fri, 2002-11-15 at 09:55, Martin J. Bligh wrote:
> > I'm one of the core developers of Bugzilla, and just wanted to 
> > say how great it is that you've started using it for the Linux 
> > kernel (http://bugme.osdl.org/).
> 
> Thanks - there's actually a small team of people here doing it,
> I'm just a rabble-rouser for interfacing with the Linux community, 
> Jon (cc'ed) is doing the hard work of configuring Bugzilla.
> 
> > Might I suggest you set up a product (or component) for people 
> > to file bugs against your Bugzilla installation in? This allows 
> > you to triage them, separate out local tweak requests from more 
> > general enhancements, and forward the latter on to us in 
> > http://bugzilla.mozilla.org :-) You might even use Bugzilla's 
> > bug moving feature for this purpose.
> 
> We did discuss creating such a category already, not sure where
> that was at ... we'll probably need one eventually. The config is
> still fairly embryonic at this stage - made more sense to just do 
> something basic, and push it out there to see what else it needed.
> 

I am thinking that would be a good idea.  It would probably just be a
single component for bugzilla; not wanting to distract too much from the
main purpose of the server (to track Linux bugs).


> > Also, are you aware of the news://news.mozilla.org/netscape.public.mozilla.webtools newsgroup? 
> > It's the best place for Bugzilla advice. Particularly, I'd suggest 
> > you run ideas past it before implementing any sigificant changes or
> > enhancements - not because you are incapable (perish the thought), 
> > but merely because we've found in the past that people who don't, 
> > normally do things the obvious and hard, rather than the 
> > less-obvious and asy way :-)
> 
> Nah, I actually am fairly incapable at this sort of thing ;-) 
> But Jon isn't ... he'll do all that stuff, so he'll probably contact 
> you directly. We want to do something wacky with versions for 
> instance, if we can't see an obvious way, that might be a good thing 
> to start with.
>  
> > Good luck, and let us know if there's anything we can do to help. 
> > We love to get feedback on how we can make Bugzilla better.
> 
> Thanks for the support,
> 
> M.

Thanks for the information and support.  I have been following that news group though I haven't post there much.
I am normally on the #mozwebtools irc channel too, but have been a
fairly quiet guy.  I will try to open up more :)

Jon




From mbligh at aracnet.com  Fri Nov 15 15:55:08 2002
From: mbligh at aracnet.com (Martin J. Bligh)
Date: Fri, 15 Nov 2002 07:55:08 -0800
Subject: Bugzilla bug tracking database for 2.5 now available.
In-Reply-To: <3DD4BF74.7060808@gerv.net>
References: <3DD4BF74.7060808@gerv.net>
Message-ID: <443986008.1037346905@[10.10.2.3]>

> I'm one of the core developers of Bugzilla, and just wanted to 
> say how great it is that you've started using it for the Linux 
> kernel (http://bugme.osdl.org/).

Thanks - there's actually a small team of people here doing it,
I'm just a rabble-rouser for interfacing with the Linux community, 
Jon (cc'ed) is doing the hard work of configuring Bugzilla.

> Might I suggest you set up a product (or component) for people 
> to file bugs against your Bugzilla installation in? This allows 
> you to triage them, separate out local tweak requests from more 
> general enhancements, and forward the latter on to us in 
> http://bugzilla.mozilla.org :-) You might even use Bugzilla's 
> bug moving feature for this purpose.

We did discuss creating such a category already, not sure where
that was at ... we'll probably need one eventually. The config is
still fairly embryonic at this stage - made more sense to just do 
something basic, and push it out there to see what else it needed.

> Also, are you aware of the news://news.mozilla.org/netscape.public.mozilla.webtools newsgroup? 
> It's the best place for Bugzilla advice. Particularly, I'd suggest 
> you run ideas past it before implementing any sigificant changes or
> enhancements - not because you are incapable (perish the thought), 
> but merely because we've found in the past that people who don't, 
> normally do things the obvious and hard, rather than the 
> less-obvious and asy way :-)

Nah, I actually am fairly incapable at this sort of thing ;-) 
But Jon isn't ... he'll do all that stuff, so he'll probably contact 
you directly. We want to do something wacky with versions for 
instance, if we can't see an obvious way, that might be a good thing 
to start with.
 
> Good luck, and let us know if there's anything we can do to help. 
> We love to get feedback on how we can make Bugzilla better.

Thanks for the support,

M.



From afranke at ags.uni-sb.de  Sat Nov 16 05:04:56 2002
From: afranke at ags.uni-sb.de (Andreas Franke)
Date: Sat, 16 Nov 2002 06:04:56 +0100
Subject: Why quicksearch sucks 
In-Reply-To: Your message of "Fri, 15 Nov 2002 21:56:57 +1100."
             <20021115105657.GA15966@tomato.home> 
Message-ID: <200211160503.GAA26115@ags.uni-sb.de>

Hi Bradley, hi all,

> The main problem is that quicksearch entries are inherently slow. We do
> a substring search on the description OR status whiteboard for each
> word. This means that the best we can get away with is a linear search
> of all the bug in teh database.

That's true. Note that quicksearch has been designed for an
existing bugzilla backend, with the goal of
(1) getting a good approximation of "what the b.m.o. user wants" 
(2) within a "reasonable" amount of time on b.m.o.
At the time of the design, and with respect to the typical load
of b.m.o at that time, typical requests with 1 - 3 words were
served within an acceptable time interval.

If this situation has changed (e.g. backend code changed,
number of users / queries / bugs has gone up, typical
server load has increased), then there are always two 
alternative approaches: 
(a) adopt quicksearch to the new situation, or
(b) change the situation so that quicksearch still works.

In our case, the bugzilla backend code seems to be the only 
parameter of the situation that we can change; and on the
quicksearch side I think changing the search semantics
is the only parameter we can tune. Let's keep these two
alternatives in mind.

> However, we also do a substring match on the product/components. Before
> the upgrade, this was just an extra string search. After the upgrade +
> bug 43600, this is now a string search on the product/component table,
> and an integer equality test on teh bugs table, via a JOIN/
> [...]
> So, how do we fix it? The correct fix is to use a subselect for the
> product id:
> [...]
> That then gets us back to the previous search, but probably slightly
> faster because of the number checks.
> 
> Which is great, except that mysql doesn't support SUBSELECTs.
> 
> So the alternate solution is to do what was done in bug 21700, and
> lookup stuff in joined tables first. I wasnt to do this via some sort of
> warpper func which would use subselects for database servers, and a
> separate select + IN for mysql. 

I think this is a good solution. In my experience with a (non-bugzilla)
mysql app, the app<->db communication overhead is hardly a problem.
Also, if it is too easy to submit queries with a 50000 bugs result
set by accident, then it may make sense to define a default limit 
for a result set (maybe somewhere in the range of 2000-5000, possibly
as a per-user pref), so that you need to explicitly ask for the 
_complete_ result set if you really want it, something like
&all_results=1 . I'm not sure whether this would obsolete the
need for temp tables on disk, but if it does it may be worth
considering.

So this would be a possible solution on the bugzilla backend side,
dealing with the performance difference for some kinds of queries
caused by the latest code changes. On the other side, maybe as a
short-term solution, we could adopt quicksearch by just changing
the semantics to _not_ include product / component by default,
so that you'd have to explicitly specify the "area prefix" (":")
if you want to do substring matches in product and component names,
and only there. This makes it a bit less intuitive for new users
who are not familiar with the actual product/component hierarchy
used by mozilla.org, but most of the queries would still find 
most of the relevant bugs, so having quicksearch available again
with that changed semantics may be an improvement over it being
disabled completely. And when the real solution is well tested
and checked in, the semantics can always be changed back if so
desired.

I compared the behavior of b.m.o. for a specific example query:
1) the original semantics: 
   http://www.ps.uni-sb.de/~afranke/moz0/quicksearch.html
2) the new semantics: 
   http://www.ps.uni-sb.de/~afranke/moz1/quicksearch.html

The patch for quicksearch.js (as a unified diff) is here: 
http://www.ps.uni-sb.de/~afranke/quicksearch.js.diff

1a) currently on b.m.o., the search for 
	bugzilla quicksearch 
  takes about 17-19 seconds and returns 14 bugs.

1b) the slightly more expert query 
	:bugzilla quicksearch
  takes about 14-19 seconds and returns 13 bugs. 
  This is the almost the same
  as the previous result set, missing only bug 159451 
  ("Bugzilla QuickSearch broken in default Chimera install") 
  which is in a non-bugzilla product because it is probably 
  caused by the browser, not the bugzilla code; so we may
  tolerate this inaccuracy.

2a) with the semantics changed to not search 
  the product and component names by default,
  the first query 
	bugzilla quicksearch
  takes only 4-5 seconds, but returns only a single
  bug (159451) as a result, since "bugzilla" does
  not occur in the summary (etc.) in the other bugs.

2b) the second query
	:bugzilla quicksearch
  takes 11-12 seconds and returns the same 13 bugs
  as 1b).

So with this change, all the non-expert quicksearch queries
where the user just enters some word fragments should be
as fast as before the backend code change, but with a slightly
different semantics. But I suspect only very few people will
notice the difference.
And even "expert" queries using the ":" prefix to trigger product
and component name matching will be faster because product and
component name matching is avoided for all the other search terms.
 
Is this sufficient improvement to make this change and enable 
quicksearch on b.m.o again? Or are we going for the backend
fix only?

Cheers,
Andreas

==============================================================
Here are the query urls for the above examples, taken from
http://www.ps.uni-sb.de/~afranke/moz0/quicksearchhack.html and
http://www.ps.uni-sb.de/~afranke/moz1/quicksearchhack.html
using the "preview query url as page" button:

[1a] original query for "bugzilla quicksearch":

http://bugzilla.mozilla.org/buglist.cgi
?bug_status=UNCONFIRMED
&bug_status=NEW
&bug_status=ASSIGNED
&bug_status=REOPENED
&field0-0-0=product
&type0-0-0=substring
&value0-0-0=bugzilla
&field0-0-1=component
&type0-0-1=substring
&value0-0-1=bugzilla
&field0-0-2=short_desc
&type0-0-2=substring
&value0-0-2=bugzilla
&field0-0-3=status_whiteboard
&type0-0-3=substring
&value0-0-3=bugzilla
&field1-0-0=product
&type1-0-0=substring
&value1-0-0=quicksearch
&field1-0-1=component
&type1-0-1=substring
&value1-0-1=quicksearch
&field1-0-2=short_desc
&type1-0-2=substring
&value1-0-2=quicksearch
&field1-0-3=status_whiteboard
&type1-0-3=substring
&value1-0-3=quicksearch

[1b] original query for ":bugzilla quicksearch"

http://bugzilla.mozilla.org/buglist.cgi
?bug_status=UNCONFIRMED
&bug_status=NEW
&bug_status=ASSIGNED
&bug_status=REOPENED
&field0-0-0=product
&type0-0-0=substring
&value0-0-0=bugzilla
&field0-0-1=component
&type0-0-1=substring
&value0-0-1=bugzilla
&field1-0-0=product
&type1-0-0=substring
&value1-0-0=quicksearch
&field1-0-1=component
&type1-0-1=substring
&value1-0-1=quicksearch
&field1-0-2=short_desc
&type1-0-2=substring
&value1-0-2=quicksearch
&field1-0-3=status_whiteboard
&type1-0-3=substring
&value1-0-3=quicksearch

[2a] new query for "bugzilla quicksearch":

http://bugzilla.mozilla.org/buglist.cgi
?bug_status=UNCONFIRMED
&bug_status=NEW
&bug_status=ASSIGNED
&bug_status=REOPENED
&field0-0-0=short_desc
&type0-0-0=substring
&value0-0-0=bugzilla
&field0-0-1=status_whiteboard
&type0-0-1=substring
&value0-0-1=bugzilla
&field1-0-0=short_desc
&type1-0-0=substring
&value1-0-0=quicksearch
&field1-0-1=status_whiteboard
&type1-0-1=substring
&value1-0-1=quicksearch

[2b] new query for ":bugzilla quicksearch":

http://bugzilla.mozilla.org/buglist.cgi
?bug_status=UNCONFIRMED
&bug_status=NEW
&bug_status=ASSIGNED
&bug_status=REOPENED
&field0-0-0=product
&type0-0-0=substring
&value0-0-0=bugzilla
&field0-0-1=component
&type0-0-1=substring
&value0-0-1=bugzilla
&field1-0-0=short_desc
&type1-0-0=substring
&value1-0-0=quicksearch
&field1-0-1=status_whiteboard
&type1-0-1=substring
&value1-0-1=quicksearch



From bbaetz at student.usyd.edu.au  Sat Nov 16 05:29:14 2002
From: bbaetz at student.usyd.edu.au (Bradley Baetz)
Date: Sat, 16 Nov 2002 16:29:14 +1100
Subject: Why quicksearch sucks
In-Reply-To: <200211160503.GAA26115@ags.uni-sb.de>
References: <20021115105657.GA15966@tomato.home> <200211160503.GAA26115@ags.uni-sb.de>
Message-ID: <20021116052914.GA4245@tomato.home>

On Sat, Nov 16, 2002 at 06:04:56AM +0100, Andreas Franke wrote:

> So this would be a possible solution on the bugzilla backend side,
> dealing with the performance difference for some kinds of queries
> caused by the latest code changes. On the other side, maybe as a
> short-term solution, we could adopt quicksearch by just changing
> the semantics to _not_ include product / component by default,
> so that you'd have to explicitly specify the "area prefix" (":")
> if you want to do substring matches in product and component names,
> and only there.

This doesn't work. The reason is that if I'm searching for 'ftp login
failure', then I want to find a bug with the summary 'login failure' in
the 'Networking: FTP' component, and not fail because 'ftp' wasn't in
the summary.

OTOH, I don't see much of a point for including the status whiteboard...

> This makes it a bit less intuitive for new users
> who are not familiar with the actual product/component hierarchy
> used by mozilla.org, but most of the queries would still find 
> most of the relevant bugs, so having quicksearch available again
> with that changed semantics may be an improvement over it being
> disabled completely. And when the real solution is well tested
> and checked in, the semantics can always be changed back if so
> desired.

Nope; see above.

> 

<snip>

Well, the fact that bmo is 40-50 times as slow as myk's test machine
points to anohter oppertunity for improvment :)

> Is this sufficient improvement to make this change and enable 
> quicksearch on b.m.o again? Or are we going for the backend
> fix only?

I thik we do want the backend fix, epscially since custom fields is
going to make this basically a requirement.

> 
> Cheers,
> Andreas
> 

Bradley


From afranke at ags.uni-sb.de  Sat Nov 16 08:43:04 2002
From: afranke at ags.uni-sb.de (Andreas Franke)
Date: Sat, 16 Nov 2002 09:43:04 +0100
Subject: Why quicksearch sucks 
In-Reply-To: Your message of "Sat, 16 Nov 2002 16:29:14 +1100."
             <20021116052914.GA4245@tomato.home> 
Message-ID: <200211160842.JAA00594@ags.uni-sb.de>

> This doesn't work. The reason is that if I'm searching for 'ftp login
> failure', then I want to find a bug with the summary 'login failure' in
> the 'Networking: FTP' component, and not fail because 'ftp' wasn't in
> the summary.

The point was that under the assumption that almost all bugs about 
ftp login failure are located in the ftp component, the query
	:ftp login failure
with the new semantics would give you almost the same results as
	ftp login failure
gives you now. Of course, this requires the user knowledge about the
product/component hierarchy, or else relies on redundancy (the majority
of bugs in the ftp component contain the substring "ftp" in the 
summary, too). Actually, your example gives exactly the same result
(one bug) in both cases, even without the colon.

But your point is taken. Fixing the backend now is certainly much 
better, unfortunately I can't help on that side. 

Thanks for your effort,

Andreas



From gerv at mozilla.org  Sat Nov 16 09:43:26 2002
From: gerv at mozilla.org (Gervase Markham)
Date: Sat, 16 Nov 2002 09:43:26 +0000
Subject: Why quicksearch sucks
In-Reply-To: <20021115105657.GA15966@tomato.home>
References: <20021115105657.GA15966@tomato.home> <200211160503.GAA26115@ags.uni-sb.de> <20021116052914.GA4245@tomato.home>
Message-ID: <3DD6133E.3010406@mozilla.org>

> Well, the fact that bmo is 40-50 times as slow as myk's test machine
> points to anohter oppertunity for improvment :)


mozilla.org staff are working on getting a new machine - and I think 
there's a realisation inside Netscape that it's an urgent requirement. 
But we can't commit to a timescale.

> I thik we do want the backend fix, epscially since custom fields is
> going to make this basically a requirement.

I completely agree that this is the right thing to do. Are you sticking 
your hand in the air? You are probably the best person to do it, if you 
have time.

Gerv




From bbaetz at student.usyd.edu.au  Sat Nov 16 11:43:19 2002
From: bbaetz at student.usyd.edu.au (Bradley Baetz)
Date: Sat, 16 Nov 2002 22:43:19 +1100
Subject: Why quicksearch sucks
In-Reply-To: <3DD6133E.3010406@mozilla.org>
References: <20021115105657.GA15966@tomato.home> <200211160503.GAA26115@ags.uni-sb.de> <20021116052914.GA4245@tomato.home> <3DD6133E.3010406@mozilla.org>
Message-ID: <20021116114319.GB7542@tomato.home>

On Sat, Nov 16, 2002 at 09:43:26AM +0000, Gervase Markham wrote:
> >Well, the fact that bmo is 40-50 times as slow as myk's test machine
> >points to anohter oppertunity for improvment :)
> 
> mozilla.org staff are working on getting a new machine - and I think 
> there's a realisation inside Netscape that it's an urgent requirement. 
> But we can't commit to a timescale.

mod_perl will help, too, since we won't be reparsing all these perl
files for every single request.

> 
> >I thik we do want the backend fix, epscially since custom fields is
> >going to make this basically a requirement.
> 
> I completely agree that this is the right thing to do. Are you sticking 
> your hand in the air? You are probably the best person to do it, if you 
> have time.
> 

I'll play with this. Probably won't have time tomorrow, though.

> Gerv

Bradley


From gerv at mozilla.org  Sun Nov 17 17:04:29 2002
From: gerv at mozilla.org (Gervase Markham)
Date: Sun, 17 Nov 2002 17:04:29 +0000
Subject: Chart selection UI
Message-ID: <3DD7CC1D.7070809@mozilla.org>

I'm currently working on generic charting. The design is here:
<http://www.mozilla.org.uk/temp/graph/>

If you look at
<http://www.mozilla.org.uk/temp/graph/select-mockup.html>, you'll see 
that charts have a three-level categorisation. The idea is to use JS to 
update the second and third level lists as selections are made in the 
first and second level lists, respectively.

The big question is: what do we do for people who have JS switched off?

This problem is not comparable to the query page with Products and 
Components, because selecting just a Component to search on is a 
perfectly valid search restriction, whereas in with reports you need to 
select a Category, Sub-category and Name which make a valid data set. 
So, having all the possibilities in each list is not a valid solution.

There are three solutions, none very appealing:

1) Have one big <select> for those without JS, and choose the UI with
    <script> and <noscript>.
   - Everyone downloads the data that makes up the list twice, once in JS
     and once in the big <select>
   - The large select would get really unwieldy.
   - You would have to write the entire JS UI using document.write().

2) Make people without JS submit the form every time they make a
    selection in any of the select boxes.
   - With the speed of b.m.o. at the moment, this would make it take ages
     for people without JS to assemble a report.

3) Require JS to assemble reports (viewing them would work fine
    without.)
   - Now we have things like popup control, I think more people
     are happy to have JS on.
   - This goes against our current policy of not requiring JS.

Thoughts? I'm leaning towards 2), on the basis that it doesn't penalise 
people with JS with an extra download as 1) does.

Gerv



From preed at sigkill.com  Sun Nov 17 20:16:32 2002
From: preed at sigkill.com (J. Paul Reed)
Date: Sun, 17 Nov 2002 12:16:32 -0800 (PST)
Subject: 2.17.1 status report - 1st draft
Message-ID: <Pine.LNX.4.43.0211171208030.28244-100000@underworld.sigkill.com>


The first draft of the 2.17.1 status report is here:

http://landfill.bugzilla.org/preed/bugzilla-org/status_updates/2002-11-17.html

I need comments/corrections/etc.

The plan is to post this tonight.

Things to note:

* We have some security-sensitive bugs that were fixed, and they're in the
  status report, but haven't been cleared in Bugzilla; how are we going to
  handle this, considering we usually don't clear those bugs until we have a
  stable release that fixes them?

* Joel: if you want a section on the improvements offered by bug 143826,
  could you give me a writeup? I've got a midterm tomorrow, and don't have
  time to do the research + writeup; if not, I'll just stick it in the list
  of improvements that's already in the report.

* Anything I need to add to the Upcoming Major Feature list?

Anything else, lemme know via email; I'll be on campus/studying for the
rest of the day, so I'll roll comments I get via email in, and hopefully
post this thing tonight (after justdave looks at it, of course :-)

Later,
Rip Van JP
  -----------------------------------------------------------------------
  J. Paul Reed                 preed at sigkill.com || web.sigkill.com/preed
  Wait, stop!  We can outsmart those dolphins.  Don't forget: we invented
  computers, leg warmers, bendy straws, peel-and-eat shrimp, the glory
  hole, *and* the pudding cup!  -- Homer Simpson, Tree House of Horror XI




From justdave at syndicomm.com  Sun Nov 17 20:42:23 2002
From: justdave at syndicomm.com (David Miller)
Date: Sun, 17 Nov 2002 15:42:23 -0500
Subject: 2.17.1 status report - 1st draft
In-Reply-To:  <Pine.LNX.4.43.0211171208030.28244-100000@underworld.sigkill.com>
References:  <Pine.LNX.4.43.0211171208030.28244-100000@underworld.sigkill.com>
Message-ID: <a05200f06b9fdab7f9433@[192.168.1.203]>

On 11/17/02 12:16 PM -0800, J. Paul Reed wrote:

> * We have some security-sensitive bugs that were fixed, and they're in the
>   status report, but haven't been cleared in Bugzilla; how are we going to
>   handle this, considering we usually don't clear those bugs until we have a
>   stable release that fixes them?

They were all new bugs introduced since 2.16.1, and never existed in a
stable release, and to my knowledge, none of them were in the tree any
longer than a few weeks.  Since they never existed in a stable release,
they should have been cleared as soon as they were checked in (with a
message posted to this list warning people to cvs update if they were using
cvs)
-- 
Dave Miller      Project Leader, Bugzilla Bug Tracking System
http://www.justdave.net/             http://www.bugzilla.org/


From preed at sigkill.com  Sun Nov 17 22:13:58 2002
From: preed at sigkill.com (J. Paul Reed)
Date: Sun, 17 Nov 2002 14:13:58 -0800 (PST)
Subject: 2.17.1 status report - 1st draft
In-Reply-To: <a05200f06b9fdab7f9433@[192.168.1.203]>
Message-ID: <Pine.LNX.4.43.0211171413130.28244-100000@underworld.sigkill.com>

On Sun, 17 Nov 2002, David Miller wrote:

> They were all new bugs introduced since 2.16.1, and never existed in a
> stable release, and to my knowledge, none of them were in the tree any
> longer than a few weeks.  Since they never existed in a stable release,
> they should have been cleared as soon as they were checked in (with a
> message posted to this list warning people to cvs update if they were
> using cvs)

K; I'll clear the security bit and post a message to the newsgroup + this
list regarding those bugs when the status report goes out.

Later,
Paul
  -----------------------------------------------------------------------
  J. Paul Reed                 preed at sigkill.com || web.sigkill.com/preed
  Wait, stop!  We can outsmart those dolphins.  Don't forget: we invented
  computers, leg warmers, bendy straws, peel-and-eat shrimp, the glory
  hole, *and* the pudding cup!  -- Homer Simpson, Tree House of Horror XI




From bbaetz at student.usyd.edu.au  Sun Nov 17 22:58:20 2002
From: bbaetz at student.usyd.edu.au (Bradley Baetz)
Date: Mon, 18 Nov 2002 09:58:20 +1100
Subject: 2.17.1 status report - 1st draft
In-Reply-To: <Pine.LNX.4.43.0211171208030.28244-100000@underworld.sigkill.com>
References: <Pine.LNX.4.43.0211171208030.28244-100000@underworld.sigkill.com>
Message-ID: <20021117225820.GA1034@tomato.home>

On Sun, Nov 17, 2002 at 12:16:32PM -0800, J. Paul Reed wrote:
> 
> Things to note:
> 
> * We have some security-sensitive bugs that were fixed, and they're in the
>   status report, but haven't been cleared in Bugzilla; how are we going to
>   handle this, considering we usually don't clear those bugs until we have a
>   stable release that fixes them?

All the security bugs only affect the development version, though.  
Besides, you posted the url to a public list, so.... :)

Bradley


From bbaetz at student.usyd.edu.au  Sun Nov 17 23:00:26 2002
From: bbaetz at student.usyd.edu.au (Bradley Baetz)
Date: Mon, 18 Nov 2002 10:00:26 +1100
Subject: 2.17.1 status report - 1st draft
In-Reply-To: <Pine.LNX.4.43.0211171413130.28244-100000@underworld.sigkill.com>
References: <a05200f06b9fdab7f9433@[192.168.1.203]> <Pine.LNX.4.43.0211171413130.28244-100000@underworld.sigkill.com>
Message-ID: <20021117230026.GB1034@tomato.home>

> K; I'll clear the security bit and post a message to the newsgroup + this
> list regarding those bugs when the status report goes out.

Well, wait til they're actually fixed ;)

If we don't fix them all by tonight, should we document some of the
information leaking ones as 'known issues' ? We don't have any privlege
escalation ones, or anything along those lines.

Bradley


From preed at sigkill.com  Sun Nov 17 23:01:13 2002
From: preed at sigkill.com (J. Paul Reed)
Date: Sun, 17 Nov 2002 15:01:13 -0800 (PST)
Subject: 2.17.1 status report - 1st draft
In-Reply-To: <20021117225820.GA1034@tomato.home>
Message-ID: <Pine.LNX.4.43.0211171500190.28244-100000@underworld.sigkill.com>

On Mon, 18 Nov 2002, Bradley Baetz wrote:

> Besides, you posted the url to a public list, so.... :)

Yeah, I know... which is why I kinda was wondering what we should do.

The bug summaries are pretty useful to people wanting to exploit stuff
too... (imagine that), and those are in the status report.

Later,
Paul
  -----------------------------------------------------------------------
  J. Paul Reed                 preed at sigkill.com || web.sigkill.com/preed
  Wait, stop!  We can outsmart those dolphins.  Don't forget: we invented
  computers, leg warmers, bendy straws, peel-and-eat shrimp, the glory
  hole, *and* the pudding cup!  -- Homer Simpson, Tree House of Horror XI




From justdave at syndicomm.com  Sun Nov 17 23:27:42 2002
From: justdave at syndicomm.com (David Miller)
Date: Sun, 17 Nov 2002 18:27:42 -0500
Subject: Chart selection UI
In-Reply-To: <3DD7CC1D.7070809@mozilla.org>
References: <3DD7CC1D.7070809@mozilla.org>
Message-ID: <a05200f07b9fdd56d6830@[192.168.1.203]>

On 11/17/02 5:04 PM +0000, Gervase Markham wrote:

> 2) Make people without JS submit the form every time they make a
>     selection in any of the select boxes.
>    - With the speed of b.m.o. at the moment, this would make it take ages
>      for people without JS to assemble a report.
>
> Thoughts? I'm leaning towards 2), on the basis that it doesn't penalise
> people with JS with an extra download as 1) does.

I'll go with that.  Javascript is pretty darn useful when used properly,
and it's a shame some sites have to abuse it to the point where people
don't trust it.

I don't think we have a requirement that it work as well without Javascript
as it does with.  The only requirement is that it has to work without
Javascript.  If that means it winds up being a huge amount of effort on the
user's part because they aren't getting the timesaving assistance from the
Javascript then so be it, as long as they still can do it if they spend
that effort.
-- 
Dave Miller      Project Leader, Bugzilla Bug Tracking System
http://www.justdave.net/             http://www.bugzilla.org/


From gerv at mozilla.org  Sun Nov 17 23:53:19 2002
From: gerv at mozilla.org (Gervase Markham)
Date: Sun, 17 Nov 2002 23:53:19 +0000
Subject: 2.17.1 status report - 1st draft
In-Reply-To: <Pine.LNX.4.43.0211171208030.28244-100000@underworld.sigkill.com>
References: <Pine.LNX.4.43.0211171208030.28244-100000@underworld.sigkill.com>
Message-ID: <3DD82BEF.3090800@mozilla.org>

J. Paul Reed wrote:

> The first draft of the 2.17.1 status report is here:
>
> http://landfill.bugzilla.org/preed/bugzilla-org/status_updates/2002-11-17.html
>
> I need comments/corrections/etc.

Sad how the list of upcoming major features hasn't changed all that much 
since the last report :-(

You can add bug 16009 - generic charting. Description: "Allow users to 
define arbitrary data sets for which historical data will be recorded, 
and then plot those data sets".

The blurb on bug reporting improvements has some b.m.o.-specific bits 
which are inappropriate for this status. Please remove the paragraph and 
bullets starting "This feature is in its first revision."

Similarly, please remove the Miscellaneous Improvement about the guided 
bug entry form. This is not true for the trunk - it's a b.m.o.-specific 
customisation.

Add to: "The performance of some queries and CGIs has been improved", 
the addendum "and some have got worse. Hey, that's life."

;-)

The buglist probably needs a polish by hand. Having all the bug numbers 
in the same format would be good.

Otherwise, excellent :-)

Gerv



From preed at sigkill.com  Sun Nov 17 23:57:39 2002
From: preed at sigkill.com (J. Paul Reed)
Date: Sun, 17 Nov 2002 15:57:39 -0800 (PST)
Subject: 2.17.1 status report - 1st draft
In-Reply-To: <3DD82BEF.3090800@mozilla.org>
Message-ID: <Pine.LNX.4.43.0211171556280.28244-100000@underworld.sigkill.com>

On Sun, 17 Nov 2002, Gervase Markham wrote:

> The buglist probably needs a polish by hand. Having all the bug numbers
> in the same format would be good.

You raising your hand on that?

Those are pulled/parsed directly from Bonsai comments; if everyone with
Buzilla checkin access (agreed to) use the same format, we'd be golden.

And I wouldn't be pointing the finger back at you to fix it. ;-)

Later,
Paul
  -----------------------------------------------------------------------
  J. Paul Reed                 preed at sigkill.com || web.sigkill.com/preed
  Wait, stop!  We can outsmart those dolphins.  Don't forget: we invented
  computers, leg warmers, bendy straws, peel-and-eat shrimp, the glory
  hole, *and* the pudding cup!  -- Homer Simpson, Tree House of Horror XI




From gerv at mozilla.org  Mon Nov 18 00:00:55 2002
From: gerv at mozilla.org (Gervase Markham)
Date: Mon, 18 Nov 2002 00:00:55 +0000
Subject: 2.17.1 status report - 1st draft
In-Reply-To: <Pine.LNX.4.43.0211171556280.28244-100000@underworld.sigkill.com>
References: <Pine.LNX.4.43.0211171556280.28244-100000@underworld.sigkill.com>
Message-ID: <3DD82DB7.8000802@mozilla.org>

J. Paul Reed wrote:

> You raising your hand on that?
>
> Those are pulled/parsed directly from Bonsai comments; if everyone with
> Buzilla checkin access (agreed to) use the same format, we'd be golden.
>
> And I wouldn't be pointing the finger back at you to fix it. ;-)

I would have thought it would take five minutes to go down the list and 
fix the ten or so which don't start "Bug XXXXX - " to start that way. 
Mostly, it just involves removing the text "Fix for"...

Gerv



From preed at sigkill.com  Mon Nov 18 00:13:01 2002
From: preed at sigkill.com (J. Paul Reed)
Date: Sun, 17 Nov 2002 16:13:01 -0800 (PST)
Subject: 2.17.1 status report - 1st draft
In-Reply-To: <3DD82DB7.8000802@mozilla.org>
Message-ID: <Pine.LNX.4.43.0211171609090.28244-100000@underworld.sigkill.com>

On Mon, 18 Nov 2002, Gervase Markham wrote:

> I would have thought it would take five minutes to go down the list and
> fix the ten or so which don't start "Bug XXXXX - " to start that way.
> Mostly, it just involves removing the text "Fix for"...

I suppose I can do that.

But a more standard checkin message format would be nice, too.

Which... really consists of Bug XXXXX - description, <patch by ...> r=

Note the capital B and the r=.

I'm looking in your general direction, Myk. ;-)

Later,
Paul
  -----------------------------------------------------------------------
  J. Paul Reed                 preed at sigkill.com || web.sigkill.com/preed
  Wait, stop!  We can outsmart those dolphins.  Don't forget: we invented
  computers, leg warmers, bendy straws, peel-and-eat shrimp, the glory
  hole, *and* the pudding cup!  -- Homer Simpson, Tree House of Horror XI




From preed at sigkill.com  Mon Nov 18 04:40:18 2002
From: preed at sigkill.com (J. Paul Reed)
Date: Sun, 17 Nov 2002 20:40:18 -0800 (PST)
Subject: Status update
In-Reply-To: <3DD83A0F.5070906@peshkin.net>
Message-ID: <Pine.LNX.4.43.0211172039330.9910-100000@underworld.sigkill.com>

On Sun, 17 Nov 2002, Joel Peshkin wrote:

>      For the status update, I'd suggest specifically mentioning the 3
> items below.

These and Gerv's changes made... take a look, and get back to me if there
are any problems.

Later,
Paul
  -----------------------------------------------------------------------
  J. Paul Reed                 preed at sigkill.com || web.sigkill.com/preed
  Wait, stop!  We can outsmart those dolphins.  Don't forget: we invented
  computers, leg warmers, bendy straws, peel-and-eat shrimp, the glory
  hole, *and* the pudding cup!  -- Homer Simpson, Tree House of Horror XI





From gerv at mozilla.org  Mon Nov 18 12:02:35 2002
From: gerv at mozilla.org (Gervase Markham)
Date: Mon, 18 Nov 2002 12:02:35 +0000
Subject: 2.17.1 status report - 1st draft
In-Reply-To: <Pine.LNX.4.43.0211171609090.28244-100000@underworld.sigkill.com>
References: <Pine.LNX.4.43.0211171609090.28244-100000@underworld.sigkill.com>
Message-ID: <3DD8D6DB.8080104@mozilla.org>

> But a more standard checkin message format would be nice, too.
> 
> Which... really consists of Bug XXXXX - description, <patch by ...> r=
> 
> Note the capital B and the r=.
> 
> I'm looking in your general direction, Myk. ;-)

I use:

Bug XXXXX - <summary>. [optional descriptive extra text, including any 
other bugs fixed by this checkin.] Patch by <nick>; <review details>

where <review details> can be something like:
r,a=justdave.
or
r=bbaetz, caillon, a=justdave.
or
2xr=myk.

So JP's script would cut it off at "Patch by". The description and 
optional text is full-stop-terminated, and the patch author is separated 
from the review details by a semicolon.

Obviously, a totally prescriptive format is wrong because there are some 
patches that just won't fit it. But I think a default standard would be 
sensible.

Gerv





From timeless at myrealbox.com  Mon Nov 18 14:03:39 2002
From: timeless at myrealbox.com (timeless)
Date: Mon, 18 Nov 2002 09:03:39 -0500
Subject: 2.17.1 status report - 1st draft
In-Reply-To: <3DD8D6DB.8080104@mozilla.org>
References: <Pine.LNX.4.43.0211171609090.28244-100000@underworld.sigkill.com> <3DD8D6DB.8080104@mozilla.org>
Message-ID: <3DD8F33B.4000408@myrealbox.com>

Gervase Markham wrote:
>> But a more standard checkin message format would be nice, too.
>>
>> Which... really consists of Bug XXXXX - description, <patch by ...> r=
>>
>> Note the capital B and the r=.

that capital B seems kinda annoying, i'm not sure how consistent i am 
about its case, i could ask bonsai.

my format doesn't have the - usually, the patchby/review line goes on 
its own line. I think i tend to use space as my delim instead of ;/, as 
gerv does. otherwise our formats are pretty similar.

>> I'm looking in your general direction, Myk. ;-)
> 
> 
> I use:
> 
> Bug XXXXX - <summary>. [optional descriptive extra text, including any 
> other bugs fixed by this checkin.] Patch by <nick>; <review details>
> 
> where <review details> can be something like:
> r,a=justdave.
> or
> r=bbaetz, caillon, a=justdave.
> or
> 2xr=myk.
> 
> So JP's script would cut it off at "Patch by". The description and 
> optional text is full-stop-terminated, and the patch author is separated 
> from the review details by a semicolon.
> 
> Obviously, a totally prescriptive format is wrong because there are some 
> patches that just won't fit it. But I think a default standard would be 
> sensible.
> 
> Gerv
> 
> 
> 
> ----
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=timeless at myrealbox.com>




From bbaetz at student.usyd.edu.au  Mon Nov 18 14:18:02 2002
From: bbaetz at student.usyd.edu.au (Bradley Baetz)
Date: Tue, 19 Nov 2002 01:18:02 +1100
Subject: 2.17.1 status report - 1st draft
In-Reply-To: <3DD8F33B.4000408@myrealbox.com>
References: <Pine.LNX.4.43.0211171609090.28244-100000@underworld.sigkill.com> <3DD8D6DB.8080104@mozilla.org> <3DD8F33B.4000408@myrealbox.com>
Message-ID: <20021118141802.GA15611@tomato.home>

On Mon, Nov 18, 2002 at 09:03:39AM -0500, timeless wrote:
> that capital B seems kinda annoying, i'm not sure how consistent i am 
> about its case, i could ask bonsai.
> 

Can't we just grep for 5 or 6 digit numbers in the checkin comments?
Maybe 4 digit ones too? That has no greater risk of typos than any
"bug=" scheme

Bradley


From gerv at mozilla.org  Mon Nov 18 15:32:16 2002
From: gerv at mozilla.org (Gervase Markham)
Date: Mon, 18 Nov 2002 15:32:16 +0000
Subject: 2.17.1 status report - 1st draft
In-Reply-To: <3DD8F33B.4000408@myrealbox.com>
References: <Pine.LNX.4.43.0211171609090.28244-100000@underworld.sigkill.com> <3DD8D6DB.8080104@mozilla.org> <3DD8F33B.4000408@myrealbox.com>
Message-ID: <3DD90800.2030301@mozilla.org>

>>> Which... really consists of Bug XXXXX - description, <patch by ...> r=
>>>
>>> Note the capital B and the r=.
> 
> that capital B seems kinda annoying, i'm not sure how consistent i am 
> about its case, i could ask bonsai.

It's a capital B because that's what you have at the beginning of 
sentences in English. :-) I know you generally consider yourself an 
exception to the usual rules of grammar, but I think it's reasonable for 
the standard, if we have one, to follow them :-)

 > Can't we just grep for 5 or 6 digit numbers in the checkin comments?
 > Maybe 4 digit ones too? That has no greater risk of typos than any
 > "bug=" scheme

This is not about finding numbers; it's about making JP's 
automatically-formatted lists of checked in bugs look nice with minimum 
intervention. These don't just contain the bug numbers, but other parts 
of the checkin comment. See his latest status report.

Gerv



From gerv at mozilla.org  Tue Nov 19 09:24:52 2002
From: gerv at mozilla.org (Gervase Markham)
Date: Tue, 19 Nov 2002 09:24:52 +0000
Subject: Zippy?
Message-ID: <3DDA0364.6000801@mozilla.org>

Amusingly enough, someone just launched a product called Zippy...
http://www.theregister.co.uk/content/4/28163.html

Gerv



From bbaetz at student.usyd.edu.au  Tue Nov 19 13:40:41 2002
From: bbaetz at student.usyd.edu.au (Bradley Baetz)
Date: Wed, 20 Nov 2002 00:40:41 +1100
Subject: mod_perl status
Message-ID: <20021119134041.GA6816@tomato.home>

Over the next couple of weeks, I want to get at least show_bug running
under mod_perl. This accounts for just 40% of bmo's hits, so it should
bring us a large perf win. I'll probably do the index page too as a
trial run (another 5%), and if I can manage it, buglist.cgi (16%). Since
over 15% of bmo's page requests are static (css/js), the combination of
those should give us a very large speed improvment.

Basically, I'm going to be doing this by fixing the dependancies to the
mod_perl bug, bug 87406. Some of these are large design changes, so you
should cc youself on any of the dependancies which you may be interested
in, esp bug 87411.

The first step is to move various 'stuff' into modules, with the
(eventual) goal of removing globals.pl and CGI.pl

I have patches for templates (bug 173622) and bug_form.pl (bug 171493).
I also have an unattached patch for the DB stuff (bug 163290), but that
really requires the shadowlog to be killed first (bug 180870)

Because these patches move large chunks of code arround, they will get
conflicts; these are easy to resolve by just applying the change in one
file to the new one. If i ask you to review one of these patches, please
take that into account.

There is an issue with currently globally-pushed template objects, such
as 'user', as well as stuff like the current cgi object (ie MFORM/FORM,
when pushed to templates) I'd like to have a Bugzilla::Current module,
which is made accessable to the templates via a plugin. A template which
wants the current Bugzilla::User object would then do something along
the lines of:

[% current = USE Bugzilla::Current %]
[% myUser = current.user %]

at the top of the template.

This would also allow scripts to have this global access, although its
probably a bad idea to encourage use of this object from scripts, since
the .cgi will have access to this via the return value from
quietly_check_login (and so won't need this extra accessor) and the
modules shouldn't care about the current user - they should, in general,
be generic enough to apply to any user. Exceptions would be stuff like a
logging module, perhaps, and this may be usable for backwards
compatability.

The Bugzilla::Current thing will be set to clear itself out at the
beginning of each request (to avoid mod_perl persistency issues).

Does that sound like a solution to people, or an overengineered hack?

Bradley


From bbaetz at student.usyd.edu.au  Thu Nov 21 04:44:59 2002
From: bbaetz at student.usyd.edu.au (Bradley Baetz)
Date: Thu, 21 Nov 2002 15:44:59 +1100
Subject: mod_perl status
In-Reply-To: <20021119134041.GA6816@tomato.home>
References: <20021119134041.GA6816@tomato.home>
Message-ID: <20021121044459.GA25942@tomato.home>

On Wed, Nov 20, 2002 at 12:40:41AM +1100, Bradley Baetz wrote:
> There is an issue with currently globally-pushed template objects, such
> as 'user', as well as stuff like the current cgi object (ie MFORM/FORM,
> when pushed to templates) I'd like to have a Bugzilla::Current module,
> which is made accessable to the templates via a plugin. A template which
> wants the current Bugzilla::User object would then do something along
> the lines of:
> 

<snip>

I've now done this as part of bug 173622. _Please_ comment on this. The
module (Bugzilla.pm) has more POD than code, so it should be really
clear what is going on.

I want to check this in ASAP so that I can work on the next stages, so
prompt comment would be appreciated.

Thanks,

Bradley


From gerv at mozilla.org  Thu Nov 21 23:32:13 2002
From: gerv at mozilla.org (Gervase Markham)
Date: Thu, 21 Nov 2002 23:32:13 +0000
Subject: Generic charting
Message-ID: <3DDD6CFD.9070009@mozilla.org>

Just a quick update; I've designed and planned this, and estimated it at 
about 20 hours of work, including testing. I know this is blocking 
custres and custstatus, so it's high on my priority list, but this is 
just a warning that it's fairly big and so it may be a month or so 
before you see anything.

Gerv



From Debashish.Ghosh at firstdatacorp.com  Fri Nov 22 22:25:39 2002
From: Debashish.Ghosh at firstdatacorp.com (Debashish.Ghosh at firstdatacorp.com)
Date: Fri, 22 Nov 2002 16:25:39 -0600
Subject: bugzilla help needed - drop down 'Assigned To' Box
Message-ID: <OFA987B0E8.CB912209-ON86256C79.0078B7C1@firstdatacorp.com>


Hi,
I work for a fairly large company (Fortune 100). We are primarily a
mainframe based company using a tool called Infoman for our bug reporting
and handling. However lately there has been  a push to incorporate a web
based bug reporting tool and what better (and free) than Bugzilla. It will
be initially used by the team  I work in and will be rolled out in a
phased manner to other teams. And I have been chosen the Bugzilla
administrator!!!!!!
We right now use Bugzilla 2.14.2 and I have some customising questions.
I have defined a generic group so that nobody other than the users in the
grp can access bugs defined to that grp. Now, the requirement is when one
creates  a new bug all the users named in that grp will show in a drop down
box in the 'Assigned to' box. I am not conversant with Perl so  a little
hand holding will be greatly appreciated.
Thanks and regards,
Debashish






From justdave at syndicomm.com  Sat Nov 23 01:18:23 2002
From: justdave at syndicomm.com (David Miller)
Date: Fri, 22 Nov 2002 20:18:23 -0500
Subject: bugzilla help needed - drop down 'Assigned To' Box
In-Reply-To: <OFA987B0E8.CB912209-ON86256C79.0078B7C1@firstdatacorp.com>
References: <OFA987B0E8.CB912209-ON86256C79.0078B7C1@firstdatacorp.com>
Message-ID: <a05200f05ba04817a67ed@[192.168.1.203]>

On 11/22/02 4:25 PM -0600, Debashish.Ghosh at firstdatacorp.com wrote:

> Hi,
> I work for a fairly large company (Fortune 100). We are primarily a
> mainframe based company using a tool called Infoman for our bug reporting
> and handling. However lately there has been  a push to incorporate a web
> based bug reporting tool and what better (and free) than Bugzilla. It will
> be initially used by the team  I work in and will be rolled out in a
> phased manner to other teams. And I have been chosen the Bugzilla
> administrator!!!!!!

Very cool. :-)

> We right now use Bugzilla 2.14.2 and I have some customising questions.

You should get 2.14.4 at a bare minimum (security fixes) and 2.16.1 if you
want supported code, as we won't be supporting the 2.14 series after
December this year.

> I have defined a generic group so that nobody other than the users in the
> grp can access bugs defined to that grp. Now, the requirement is when one
> creates  a new bug all the users named in that grp will show in a drop down
> box in the 'Assigned to' box. I am not conversant with Perl so  a little
> hand holding will be greatly appreciated.

There has been a lot of talk on this exact subject on the general mailing
list/newsgroup in the last week or two.  You should check out the archives
and join in the conversation.
news://news.mozilla.org/netscape.public.mozilla.webtools  I haven't done a
whole lot with that myself yet, but there is supposed to be a patch out
there that does this already.  You'll find references to it in that thread.
-- 
Dave Miller      Project Leader, Bugzilla Bug Tracking System
http://www.justdave.net/             http://www.bugzilla.org/


From gerv at mozilla.org  Sun Nov 24 09:49:01 2002
From: gerv at mozilla.org (Gervase Markham)
Date: Sun, 24 Nov 2002 09:49:01 +0000
Subject: Custom fields
Message-ID: <3DE0A08D.3020607@mozilla.org>

So, should we support custom fields?
http://joelonsoftware.com/news/20020912.html

Thoughts?

Gerv



From preed at sigkill.com  Sun Nov 24 09:59:18 2002
From: preed at sigkill.com (J. Paul Reed)
Date: Sun, 24 Nov 2002 01:59:18 -0800 (PST)
Subject: Custom fields
In-Reply-To: <3DE0A08D.3020607@mozilla.org>
Message-ID: <Pine.LNX.4.43.0211240154220.15079-100000@underworld.sigkill.com>

On Sun, 24 Nov 2002, Gervase Markham wrote:

> So, should we support custom fields?
> http://joelonsoftware.com/news/20020912.html
>
> Thoughts?

He makes a very good point. And while I don't always *agree* with Joel, I
really do respect him as a software engineer; the vast majority of his
writings (or is that rantings?) are right on the mark.

Who wanted custom fields? And why did they want them?

I can easily see his point about that turning into a mess, inciting people
to create possibly hundreds of useless fields and file problems with their
own custom field setup as Bugzilla bugs.

Having said that, I know a lot of people (seem to) want it; maybe we can
put out on RFC on the newgroup or website saying "We've thought about
custom fields, but there are very good reasons *not* to do custom fields,
and Bugzilla users/"customers" are trading a lot of other possibly
significantly more useful features to have the BZ team work on custom
fields. Now then: *if* BZ had custom fields, *what* things would *you* make
a custom field?" And then let's monitor the response; if they're things
that would be better handled in comments the way they are now, then maybe a
page is in order explaining *why* custom fields don't exist in BZ 2.x, and
why the issue has been pushed back to await discussion in BZ 3.0.

I'll even volunteer now to write it up. ;-)

Later,
Paul
  -----------------------------------------------------------------------
  J. Paul Reed                 preed at sigkill.com || web.sigkill.com/preed
  Wait, stop!  We can outsmart those dolphins.  Don't forget: we invented
  computers, leg warmers, bendy straws, peel-and-eat shrimp, the glory
  hole, *and* the pudding cup!  -- Homer Simpson, Tree House of Horror XI




From gerv at mozilla.org  Sun Nov 24 10:13:29 2002
From: gerv at mozilla.org (Gervase Markham)
Date: Sun, 24 Nov 2002 10:13:29 +0000
Subject: Custom fields
In-Reply-To: <Pine.LNX.4.43.0211240154220.15079-100000@underworld.sigkill.com>
References: <Pine.LNX.4.43.0211240154220.15079-100000@underworld.sigkill.com>
Message-ID: <3DE0A649.3040207@mozilla.org>

> Having said that, I know a lot of people (seem to) want it; 


He says that too; the point is that we need to tell them what's good for 
them. ;-)

He has paying customers, and he still does this. How much more freedom, 
then, do we have as an open source project, to give people the benefits 
of our wisdom and tell them how they should do things? If they walk 
away, we don't lose nearly as much as Joel does.

> maybe we can
> put out on RFC on the newgroup or website saying "We've thought about
> custom fields, but there are very good reasons *not* to do custom fields,

<snip>

Sounds like a reasonable idea to me.

>
> I'll even volunteer now to write it up. ;-)

Easy, tiger :-) Let's have some more discussion first. Put your energies 
into those mail patches which are blocking so much stuff ;-)

Gerv



From bbaetz at student.usyd.edu.au  Sun Nov 24 10:23:57 2002
From: bbaetz at student.usyd.edu.au (Bradley Baetz)
Date: Sun, 24 Nov 2002 21:23:57 +1100
Subject: Custom fields
In-Reply-To: <3DE0A08D.3020607@mozilla.org>
References: <3DE0A08D.3020607@mozilla.org>
Message-ID: <20021124102357.GA8399@mango.home>

On Sun, Nov 24, 2002 at 09:49:01AM +0000, Gervase Markham wrote:
> So, should we support custom fields?
> http://joelonsoftware.com/news/20020912.html
> 
> Thoughts?

Well, admins can definately abuse them. But people keep wanting
'version fixed in' fields, and so on. And a company which only make
swindow ssoftware doesn't need a platform field.

There are downsides, wrt searching, though (which is why the patches
attached to the relevent bug need lots of reworking before they go in).
And we can also simplify most of our code, combining
whiteboard/os/platform/etc into one generic bit of code.

That said, I'm unlily to be working on it, although I understand Zippy
wants it.

Bradley


From preed at sigkill.com  Sun Nov 24 10:25:14 2002
From: preed at sigkill.com (J. Paul Reed)
Date: Sun, 24 Nov 2002 02:25:14 -0800 (PST)
Subject: Custom fields
In-Reply-To: <3DE0A649.3040207@mozilla.org>
Message-ID: <Pine.LNX.4.43.0211240220160.17389-100000@underworld.sigkill.com>

On Sun, 24 Nov 2002, Gervase Markham wrote:

> He has paying customers, and he still does this. How much more freedom,
> then, do we have as an open source project, to give people the benefits
> of our wisdom and tell them how they should do things? If they walk away,
> we don't lose nearly as much as Joel does.

Not necessarily.

One thing we have to think about that he doesn't is the cost and
probability of forking; it could be that some customer (Zippy, or ZippyII,
whomever that may be) *wants* custom fields, and are willing to fork the
project over that.

Are we willing to allow that to happen over this feature?

It's a rhetorical question to which I don't have the answer, but I ask it
to illustrate the point that our analysis isn't that simple
(unfortunately) just because we're not a commercial project.

In some ways, Joel has it easier, because he can say "We're not supporting
that," deal with the loss in sales, but keep the product clean and unified.

> > I'll even volunteer now to write it up. ;-)
>
> Easy, tiger :-)

"Tiger?"

Need I remind you that you're a mere 2 years older than I am?

Now Dave and Tara... *they* can call me 'tiger' (or Wesley, as the case
was... ;-)

Later,
Paul
  -----------------------------------------------------------------------
  J. Paul Reed                 preed at sigkill.com || web.sigkill.com/preed
  Wait, stop!  We can outsmart those dolphins.  Don't forget: we invented
  computers, leg warmers, bendy straws, peel-and-eat shrimp, the glory
  hole, *and* the pudding cup!  -- Homer Simpson, Tree House of Horror XI




From preed at sigkill.com  Sun Nov 24 10:35:40 2002
From: preed at sigkill.com (J. Paul Reed)
Date: Sun, 24 Nov 2002 02:35:40 -0800 (PST)
Subject: Email patches?! Where the *&$#& is Paul?!!! was Re: Custom fields
In-Reply-To: <3DE0A649.3040207@mozilla.org>
Message-ID: <Pine.LNX.4.43.0211240225161.17389-100000@underworld.sigkill.com>

On Sun, 24 Nov 2002, Gervase Markham wrote:

> Put your energies into those mail patches which are blocking so much
> stuff ;-)

Yeah, yeah... they'll both be done by the end of the year (that's what I'm
shooting for, anyway)... which, when you consider that's less than 40 days,
is not long at all.

This is my last 16 unit (full load) quarter at Poly, and to be sure, it's
really kicking my ass. Winter quarter will bring a comfortable 8 units +
senior project and spring quarter will bring a laughable 4 units + senior
project.

So I will definitely get back into BZ hacking in a big way next year. And
I'm aware of the issues involved with holding 84876 and 124174 up.  And I'm
very thankful/greatful that the team has been very accomodating about
allowing me to hold/fix these bugs, despite my academic schedule.

I'd like to work more on 124174 over the Thankgiving break, but we'll see
how that goes. It's understandably more difficult to get reviews and stuff
when people are all full of turkey and passed out. ;-)

Later,
Paul
  -----------------------------------------------------------------------
  J. Paul Reed                 preed at sigkill.com || web.sigkill.com/preed
  Wait, stop!  We can outsmart those dolphins.  Don't forget: we invented
  computers, leg warmers, bendy straws, peel-and-eat shrimp, the glory
  hole, *and* the pudding cup!  -- Homer Simpson, Tree House of Horror XI








From gerv at mozilla.org  Sun Nov 24 10:40:19 2002
From: gerv at mozilla.org (Gervase Markham)
Date: Sun, 24 Nov 2002 10:40:19 +0000
Subject: Custom fields
In-Reply-To: <Pine.LNX.4.43.0211240220160.17389-100000@underworld.sigkill.com>
References: <Pine.LNX.4.43.0211240220160.17389-100000@underworld.sigkill.com>
Message-ID: <3DE0AC93.9080100@mozilla.org>

J. Paul Reed wrote:

> One thing we have to think about that he doesn't is the cost and
> probability of forking; it could be that some customer (Zippy, or ZippyII,
> whomever that may be) *wants* custom fields, and are willing to fork the
> project over that.

The only cost here is the possibility of lost development effort. For 
Joel, that's not an issue, because his customers don't do development 
for him. For us, it's usually just failing to gain some extra resource, 
rather than actively losing anything.

People like Dave, who work full time on the Bugzilla trunk, are an 
exception to this. If his employer forks, we do actively lose resource. 
So Dave will almost certainly find himself presented with conflicts 
where it would be easier for him to check in some feature that his 
employer wants (and "better for Bugzilla" because his employer stays on 
the trunk), but probably better for Bugzilla's design and cleanness if 
he doesn't.

I am very pleased that he has begun to address this issue in the latest 
status report.

> Are we willing to allow that to happen over this feature?

It's happened before - Bugzilla used to be in a whole load of pieces (RH 
Bugzilla (Oracle), IssueZilla (the word 'issue'), Fenris...). And if we 
say that we are unwilling to let it happen, we are saying that therefore 
we will definitely include any feature that anyone produces.

> In some ways, Joel has it easier, because he can say "We're not supporting
> that," deal with the loss in sales, but keep the product clean and 
> unified.

Why is Bugzilla less clean and unified if we say "We're not supporting 
that" and someone forks?

Open Source software is about having the power to adapt software to your 
own needs. There is certainly no requirement for any "core distribution" 
of a piece of software to roll in every feature or enhancement that 
someone produces. And we should certainly not try and prevent people 
needing to do personal customisations by incorporating all sorts of 
cruft into the main distribution under the banner of "unity".

> >>I'll even volunteer now to write it up. ;-)
> >
> >Easy, tiger :-)
>
> "Tiger?"
>
> Need I remind you that you're a mere 2 years older than I am?

It's an expression :-) No need to read too much into it.

Gerv



From gerv at mozilla.org  Sun Nov 24 10:50:00 2002
From: gerv at mozilla.org (Gervase Markham)
Date: Sun, 24 Nov 2002 10:50:00 +0000
Subject: Email patches?! Where the *&$#& is Paul?!!! was Re: Custom fields
In-Reply-To: <Pine.LNX.4.43.0211240225161.17389-100000@underworld.sigkill.com>
References: <Pine.LNX.4.43.0211240225161.17389-100000@underworld.sigkill.com>
Message-ID: <3DE0AED8.1020204@mozilla.org>

> I'd like to work more on 124174 over the Thankgiving break, but we'll see
> how that goes. It's understandably more difficult to get reviews and stuff
> when people are all full of turkey and passed out. ;-)

84876 is not only easier to finish, but also blocks more stuff (it 
blocks mail templatisation, for a start, which is a really big job. 
124174 is larger, and blocks Win32, which has a whole load of other 
blockers too.

If anyone disagrees, let's hear it, but I for one would prefer that you 
made 84876 your number 1 priority, or handed it off to another developer.

In addition, I don't have Thanksgiving, so would be very happy to give 
you reviews on 84876 even on Thursday night ;-)

Gerv



From preed at sigkill.com  Sun Nov 24 10:59:12 2002
From: preed at sigkill.com (J. Paul Reed)
Date: Sun, 24 Nov 2002 02:59:12 -0800 (PST)
Subject: Email patches?! Where the *&$#& is Paul?!!! was Re: Custom fields
In-Reply-To: <3DE0AED8.1020204@mozilla.org>
Message-ID: <Pine.LNX.4.43.0211240256260.17389-100000@underworld.sigkill.com>

On Sun, 24 Nov 2002, Gervase Markham wrote:

> 84876 is not only easier to finish, but also blocks more stuff (it blocks
> mail templatisation, for a start, which is a really big job.  124174 is
> larger, and blocks Win32, which has a whole load of other blockers too.
>
> If anyone disagrees, let's hear it, but I for one would prefer that you
> made 84876 your number 1 priority, or handed it off to another developer.

Which do you want?

http://bugzilla.org/cgi-bin/mj_wwwusr/domain=bugzilla.org?list=developers&func=archive-get-part&extra=200210/97

I'm inclined to agree with bbaetz
(http://bugzilla.org/cgi-bin/mj_wwwusr/domain=bugzilla.org?list=developers&func=archive-get-part&extra=200210/95)
on this one, mainly because 127174 is mostly done, is a (big) perf one, has
no controversy, and at least gives the illusion that we care about and are
working on Win32 ;-)

Later,
Paul
  -----------------------------------------------------------------------
  J. Paul Reed                 preed at sigkill.com || web.sigkill.com/preed
  Wait, stop!  We can outsmart those dolphins.  Don't forget: we invented
  computers, leg warmers, bendy straws, peel-and-eat shrimp, the glory
  hole, *and* the pudding cup!  -- Homer Simpson, Tree House of Horror XI




From gerv at mozilla.org  Sun Nov 24 13:11:37 2002
From: gerv at mozilla.org (Gervase Markham)
Date: Sun, 24 Nov 2002 13:11:37 +0000
Subject: Email patches?! Where the *&$#& is Paul?!!! was Re: Custom fields
In-Reply-To: <Pine.LNX.4.43.0211240256260.17389-100000@underworld.sigkill.com>
References: <Pine.LNX.4.43.0211240256260.17389-100000@underworld.sigkill.com>
Message-ID: <3DE0D009.4060806@mozilla.org>

J. Paul Reed wrote:

> >If anyone disagrees, let's hear it, but I for one would prefer that you
> >made 84876 your number 1 priority, or handed it off to another developer.
>
> Which do you want?
>
> http://bugzilla.org/cgi-bin/mj_wwwusr/domain=bugzilla.org?list=developers&func=archive-get-part&extra=200210/97

Er... both of these requests ask for 84876 :-) In the one you reference, 
bbaetz says "the second one" (i.e. processmail as package, 124174), and 
I say  "actually the first one, because it blocks templatisation", which 
is basically what I just said in this thread also.

> I'm inclined to agree with bbaetz
> (http://bugzilla.org/cgi-bin/mj_wwwusr/domain=bugzilla.org?list=developers&func=archive-get-part&extra=200210/95)
> on this one, mainly because 127174 is mostly done, is a (big) perf 
> one, has
> no controversy, and at least gives the illusion that we care about and are
> working on Win32 ;-)

In other words, it gives our customers a false sense of when they are 
going to get what they want. I thought that sort of thing was reserved 
for commercial projects :-)

But, at the risk of engendering controversy, if you won't have time for 
the other bug, I'm happy to produce a patch and drive it through. I 
conceded after our technical disagreement on that bug, partly on the 
basis that some fix was better than no fix (as several people said.) But 
having done that, we still have no fix...

Gerv



From preed at sigkill.com  Sun Nov 24 13:32:20 2002
From: preed at sigkill.com (J. Paul Reed)
Date: Sun, 24 Nov 2002 05:32:20 -0800 (PST)
Subject: Email patches?! Where the *&$#& is Paul?!!! was Re: Custom fields
In-Reply-To: <3DE0D009.4060806@mozilla.org>
Message-ID: <Pine.LNX.4.43.0211240511320.17389-100000@underworld.sigkill.com>

On Sun, 24 Nov 2002, Gervase Markham wrote:

> J. Paul Reed wrote:
>
> > >If anyone disagrees, let's hear it, but I for one would prefer that you
> > >made 84876 your number 1 priority, or handed it off to another developer.
> >
> > Which do you want?
> >
> > http://bugzilla.org/cgi-bin/mj_wwwusr/domain=bugzilla.org?list=developers&func=archive-get-part&extra=200210/97
>
> Er... both of these requests ask for 84876 :-)

No they don't.

Which leads me to believe you're not seeing the same thing I'm seeing when
I load that URL (which is why I wish we were using Mailman instead of
Majordomo, but that's an ancillary issue).

The first URL says:

---
Bradley Baetz wrote:
> Well, my rock is called 'honors thesis' :)
>
> Seriously, though, the second of your bugs (moving processmail to a
> package) would save us about 1 second per call, and its relatively free
> of
> contraversy, so that may be the better one to start with.

Ah. I was about to suggest the first one, because it blocks a load of
other mail work, particularly templatisation :-) But I guess perf is
more important right now.
---

You did suggest "the first one" (84876), as you did this time, but then
concede "I guess perf is more important right now," leading me to believe
you think 124174 should be fixed first.

So, I reiterate: which is it?

> In other words, it gives our customers a false sense of when they are
> going to get what they want. I thought that sort of thing was reserved
> for commercial projects :-)

Actually, that's not true.

If you look at bugs nominated under the [needed for Win32bz] whiteboard,
124174 is there, along with 84876 and a number of bugs related to both of
those.

So fixing *either* of them will help Win32ers. But 124174 is "more" helpful
to Win32ers.

> But, at the risk of engendering controversy, if you won't have time for
> the other bug, I'm happy to produce a patch and drive it through. I
> conceded after our technical disagreement on that bug, partly on the
> basis that some fix was better than no fix (as several people said.) But
> having done that, we still have no fix...

We have no fix because every time you get involved on 84876, it turns into a
pissing match. That's not assigning blame to you (if anything, I'm as
responsible as you are), but it *is* a statement of fact.

If you remember, I wanted to get 84876 fixed in August, *before* school
started, when I had a bunch of time. I made this very clear at the time.
That didn't happen because the time was basically spent arguing between
ourselves, then arguing in front of justdave, and then it was September.

At that time, bbaetz contributed some other code to help with 84876, and I
said I'd merge everyone's patches together and submit something. I still
plan on doing so, and I told you the timetable in which I plan on doing it.

Considering that the holidays are coming up and 84876 is a big bug
involving not only fixing the bug itself, but the associated email
templatization and this isn't affecting anyone in a superbad way (i.e.
we're not in the 2.18--or 2.17.2--push right now), I think it can wait for
a month.

But what the hell do I know?

Later,
Paul
  -----------------------------------------------------------------------
  J. Paul Reed                 preed at sigkill.com || web.sigkill.com/preed
  Wait, stop!  We can outsmart those dolphins.  Don't forget: we invented
  computers, leg warmers, bendy straws, peel-and-eat shrimp, the glory
  hole, *and* the pudding cup!  -- Homer Simpson, Tree House of Horror XI



From gerv at mozilla.org  Sun Nov 24 14:22:22 2002
From: gerv at mozilla.org (Gervase Markham)
Date: Sun, 24 Nov 2002 14:22:22 +0000
Subject: Email patches?! Where the *&$#& is Paul?!!! was Re: Custom fields
In-Reply-To: <Pine.LNX.4.43.0211240511320.17389-100000@underworld.sigkill.com>
References: <Pine.LNX.4.43.0211240511320.17389-100000@underworld.sigkill.com>
Message-ID: <3DE0E09E.1040907@mozilla.org>

J. Paul Reed wrote:

> Which leads me to believe you're not seeing the same thing I'm seeing when
> I load that URL (which is why I wish we were using Mailman instead of
> Majordomo, but that's an ancillary issue).

Don't blame Majordomo, blame me (see below.)

> You did suggest "the first one" (84876), as you did this time, but then
> concede "I guess perf is more important right now," leading me to believe
> you think 124174 should be fixed first.
>
> So, I reiterate: which is it?

Oops, sorry. I let me recollection of that email thread overrule the 
evidence of my own eyes. I remember wanting 84876 to be fixed first; I 
failed to notice that I'd conceded (at the time) that the other was more 
important.

However, the situation is now different - the big need for perf was for 
the b.m.o. upgrade, which has now happened. So perf has got less 
important. And I was willing to let 84876 go for a bit because I thought 
you would be tackling both of them in a reasonably short timeframe. But 
that hasn't happened.

So, my view has changed in the past month, as circumstances have 
changed. I apologise if this change has caused you inconvenience, and 
(relating to the above discussion) I apologise for not reading carefully 
enough first time.

> >In other words, it gives our customers a false sense of when they are
> >going to get what they want. I thought that sort of thing was reserved
> >for commercial projects :-)
>
> Actually, that's not true.

Well, you were the one who used the words "give the illusion that".

> >But, at the risk of engendering controversy, if you won't have time for
> >the other bug, I'm happy to produce a patch and drive it through. I
> >conceded after our technical disagreement on that bug, partly on the
> >basis that some fix was better than no fix (as several people said.) But
> >having done that, we still have no fix...
>
> We have no fix because every time you get involved on 84876, it turns 
> into a
> pissing match. That's not assigning blame to you (if anything, I'm as
> responsible as you are), but it *is* a statement of fact.

As you imply above, it takes two to have an argument.

> If you remember, I wanted to get 84876 fixed in August, *before* school
> started, when I had a bunch of time. I made this very clear at the time.
> That didn't happen because the time was basically spent arguing between
> ourselves, then arguing in front of justdave, and then it was September.

I think that it's important that Bugzilla developers should feel free to 
challenge the implementation of a feature if they don't think it's right 
technically. That's what review (and design, which we don't do enough 
of) is all about.

I think that the blame for the 84876 debacle can be shared approximately 
equally between you, me and Dave - you and I for a complete inability to 
see the other side of the argument, and Dave for sitting on the problem 
and not making a decision for a long time when asked to do so. But I 
think we should leave that behind and try and work out the best way to 
move forward.

> At that time, bbaetz contributed some other code to help with 84876, and I
> said I'd merge everyone's patches together and submit something. I still
> plan on doing so, and I told you the timetable in which I plan on 
> doing it.
>
> Considering that the holidays are coming up and 84876 is a big bug
> involving not only fixing the bug itself, but the associated email
> templatization and this isn't affecting anyone in a superbad way (i.e.
> we're not in the 2.18--or 2.17.2--push right now), I think it can wait 
> for a month.

I would hope to get the templatisation project finished well before the 
next release push, because the localised version translators need a good 
bit of lead time to get their versions sorted out. l10n patches are not 
like others, which can be checked in five minutes before a freeze. And 
we have been waiting nearly two months already.

I understand that you have other commitments; that's why I am suggesting 
you let someone else with more time take on one or more of these patches.

Gerv




From bugreport at peshkin.net  Sun Nov 24 14:18:22 2002
From: bugreport at peshkin.net (Joel Peshkin)
Date: Sun, 24 Nov 2002 06:18:22 -0800
Subject: Custom fields
References: <Pine.LNX.4.43.0211240220160.17389-100000@underworld.sigkill.com> <3DE0AC93.9080100@mozilla.org>
Message-ID: <3DE0DFAE.4080508@peshkin.net>


Not  all Joels agree....

1) Sites will frequently need to add some special field to make THEIR 
customer happy.  It is likely that they will need to do this and then 
tweak templates to make this vary on a per-product basis.  Just because 
any site specific thing that is needed by contributors with sufficient 
clout DOES become a standard field should not imply that the others are 
irrelevent.

2) About once a week, I see an RFE response that says.... "This should 
not be a feature, you should wait for customfields and do it that way"
    Do we plan to dust off all of those and re-evaluate that position? 
 Won't the resulting heap of fields really clutter Bugzilla?

I think customfields is a highly valuable feature.  It may not be 
necessary to make it all controlled by a pretty GUI, but we should put a 
good set of hooks in for sites to add their own fields without setting 
themselves up for merge problems down the road.  Basically, we should 
use a similar approach to what Gerv did in CheckCanChangeField() where 
we assume that someone at the site can program, but not that they are 
staying up-to-date on everything happening in the tree.

-Joel




From gerv at mozilla.org  Sun Nov 24 14:30:59 2002
From: gerv at mozilla.org (Gervase Markham)
Date: Sun, 24 Nov 2002 14:30:59 +0000
Subject: Custom fields
In-Reply-To: <Pine.LNX.4.43.0211240220160.17389-100000@underworld.sigkill.com>
References: <Pine.LNX.4.43.0211240220160.17389-100000@underworld.sigkill.com> <3DE0AC93.9080100@mozilla.org> <3DE0DFAE.4080508@peshkin.net>
Message-ID: <3DE0E2A3.7060206@mozilla.org>

Joel Peshkin wrote:

> 1) Sites will frequently need to add some special field to make THEIR
> customer happy.  It is likely that they will need to do this and then
> tweak templates to make this vary on a per-product basis.  Just because
> any site specific thing that is needed by contributors with sufficient
> clout DOES become a standard field should not imply that the others 
> are irrelevent.

No-one would argue that our current set of fields is a particularly 
sensible default set for a bug tracking system (URL, for example). But 
that doesn't mean we should implement customfields as a way of avoiding 
hard decisions about what the available set should be.

> 2) About once a week, I see an RFE response that says.... "This should
> not be a feature, you should wait for customfields and do it that way"
>    Do we plan to dust off all of those and re-evaluate that position?
> Won't the resulting heap of fields really clutter Bugzilla?

One reasonable answer would be: "We don't support doing this." As I said 
earlier, this is a valid response to some feature requests.

Another point is that there are a number of things we could do as an 
alternative to custom fields, which would help with these people's 
problems. Things like bug cloning, making the version field a 
multi-select, and so on.

Gerv




From kiko at async.com.br  Sun Nov 24 14:38:27 2002
From: kiko at async.com.br (Christian Reis)
Date: Sun, 24 Nov 2002 12:38:27 -0200
Subject: Custom fields
In-Reply-To: <3DE0DFAE.4080508@peshkin.net>; from bugreport@peshkin.net on Sun, Nov 24, 2002 at 06:18:22AM -0800
References: <Pine.LNX.4.43.0211240220160.17389-100000@underworld.sigkill.com> <3DE0AC93.9080100@mozilla.org> <3DE0DFAE.4080508@peshkin.net>
Message-ID: <20021124123827.H1071@blackjesus.async.com.br>

On Sun, Nov 24, 2002 at 06:18:22AM -0800, Joel Peshkin wrote:
> 1) Sites will frequently need to add some special field to make THEIR 
> customer happy.  It is likely that they will need to do this and then 
> tweak templates to make this vary on a per-product basis.  Just because 
> any site specific thing that is needed by contributors with sufficient 
> clout DOES become a standard field should not imply that the others are 
> irrelevent.

Hey, I've admined Bugzilla for Async for a couple of years now, for
everything from Sales requests to Hardware trouble, and I have *never*
wanted more fields - actually, the only thing that I *ever* wanted was
*to remove fields*. Just my 2c. I guess other admins should chip in.
Myk, what's the situation for beloved BMO?

Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL


From bbaetz at student.usyd.edu.au  Sun Nov 24 14:45:58 2002
From: bbaetz at student.usyd.edu.au (Bradley Baetz)
Date: Mon, 25 Nov 2002 01:45:58 +1100
Subject: Custom fields
In-Reply-To: <20021124123827.H1071@blackjesus.async.com.br>
References: <Pine.LNX.4.43.0211240220160.17389-100000@underworld.sigkill.com> <3DE0AC93.9080100@mozilla.org> <3DE0DFAE.4080508@peshkin.net> <20021124123827.H1071@blackjesus.async.com.br>
Message-ID: <20021124144558.GA12621@mango.home>

On Sun, Nov 24, 2002 at 12:38:27PM -0200, Christian Reis wrote:
> 
> Hey, I've admined Bugzilla for Async for a couple of years now, for
> everything from Sales requests to Hardware trouble, and I have *never*
> wanted more fields - actually, the only thing that I *ever* wanted was
> *to remove fields*. Just my 2c. I guess other admins should chip in.
> Myk, what's the situation for beloved BMO?

Well, thats sort of the point. We'd have our default set of custom
fields, and you can remove the ones you don't want. Since they would be
handled generically, you wouldn't have to go through code/templates/etc
removing referenes to these non-existent field.

People who want version to be multiselect could change the type of the
custfield from 'select' to 'multiselect', and thats it. Suff can be
per poduct, too.

Again, this does require quite a bit of bugzilla hacking to work - it is
a fairly large job.

Bradley


From gerv at mozilla.org  Sun Nov 24 14:54:50 2002
From: gerv at mozilla.org (Gervase Markham)
Date: Sun, 24 Nov 2002 14:54:50 +0000
Subject: Custom fields
In-Reply-To: <Pine.LNX.4.43.0211240220160.17389-100000@underworld.sigkill.com>
References: <Pine.LNX.4.43.0211240220160.17389-100000@underworld.sigkill.com> <3DE0AC93.9080100@mozilla.org> <3DE0DFAE.4080508@peshkin.net> <20021124123827.H1071@blackjesus.async.com.br>
Message-ID: <3DE0E83A.3090107@mozilla.org>

Christian Reis wrote:

> Hey, I've admined Bugzilla for Async for a couple of years now, for
> everything from Sales requests to Hardware trouble, and I have *never*
> wanted more fields - actually, the only thing that I *ever* wanted was
> *to remove fields*. Just my 2c. I guess other admins should chip in.
> Myk, what's the situation for beloved BMO?

Asking b.m.o. is a bit dodgy, because historically, b.m.o.'s 
requirements have controlled what fields there are. However, the only 
field which I think is not really generic is URL. So, here's an 
alternative question: how would b.m.o. cope without the URL field?

Gerv



From bbaetz at student.usyd.edu.au  Sun Nov 24 15:23:16 2002
From: bbaetz at student.usyd.edu.au (Bradley Baetz)
Date: Mon, 25 Nov 2002 02:23:16 +1100
Subject: Custom fields
In-Reply-To: <3DE0E83A.3090107@mozilla.org>
References: <Pine.LNX.4.43.0211240220160.17389-100000@underworld.sigkill.com> <3DE0AC93.9080100@mozilla.org> <3DE0DFAE.4080508@peshkin.net> <20021124123827.H1071@blackjesus.async.com.br> <3DE0E83A.3090107@mozilla.org>
Message-ID: <20021124152316.GA14874@mango.home>

On Sun, Nov 24, 2002 at 02:54:50PM +0000, Gervase Markham wrote:
> Asking b.m.o. is a bit dodgy, because historically, b.m.o.'s 
> requirements have controlled what fields there are. However, the only 
> field which I think is not really generic is URL. So, here's an 
> alternative question: how would b.m.o. cope without the URL field?

'Really badly'. Its a bug tracking system for a webbrowser; providing
url links are sort of important...

Linkifying urls comments doesn't work because:

a) they're not searchable
b) sometimes people want to test invalid urls which the url linkify code
won't pick up
c) they're not searchable
d) Its a central place, rather than having to read thorugh lots of
comments

Bradley


From bugreport at peshkin.net  Sun Nov 24 20:12:47 2002
From: bugreport at peshkin.net (Joel Peshkin)
Date: Sun, 24 Nov 2002 12:12:47 -0800
Subject: CVS tip - major checkin - Rearchitected Product Groups
Message-ID: <3DE132BF.8030208@peshkin.net>


All:

   Bug 147275 has finally landed.  In the CVS tip, the entire mechanism 
for handling groups has been revised.

   First, it is intended to be backwards-compatible so that you should 
be able to completely ignore the new capabilties and Bugzilla will 
default to setting group controls just the way that were always done 
before.

    However, it is now possible to exert much more control over how 
groups and products are related.  In editproducts.cgi, there is now a 
mechnaism to permit you to edit the "Group Controls" for a product and 
determine which groups are applicable, default, and mandatory for each 
product as well as controlling entry for each product and being able to 
set bugs in a product to be totally read-only unless some group 
restrictions are met.

    Example: When several products need to be associated with the same 
default group (formerly a product group), instead of defining several 
groups with the same names as the products and managing memberships in 
each group, a single group can be defined to control access and that 
group can be set as a "Default" group for all of the products.

   Example:  If certain products are never supposed to have a publically 
accessible bug, define a group of all authorized users and set the 
groups control for those products to indicate that the group is 
Mandatory/Mandatory.  This will place bugs in that group without giving 
the user any option at all.

  Example: Anyonce can enter a security bug.  Create a product for 
security bugs. Do not restrict entry to the product at all. However, set 
the Member/Nonmember permissions to Default/Mandatory.  This will permit 
anyone to enter and members of the security group will be able to 
override the default group restriction while nonmembers will be forced 
to restrict the bug to the security group.

    The list of possible scenarios goes on.  I am rather certain that 
some scenarios have not been anticipated.  If you file any bugs on this 
for either further enhancment or for regressions, please copy me on the bug.

Thanks,

Joel Peshkin




From kiko at async.com.br  Sun Nov 24 21:26:00 2002
From: kiko at async.com.br (Christian Reis)
Date: Sun, 24 Nov 2002 19:26:00 -0200
Subject: Custom fields
In-Reply-To: <20021124152316.GA14874@mango.home>; from bbaetz@student.usyd.edu.au on Mon, Nov 25, 2002 at 02:23:16AM +1100
References: <Pine.LNX.4.43.0211240220160.17389-100000@underworld.sigkill.com> <3DE0AC93.9080100@mozilla.org> <3DE0DFAE.4080508@peshkin.net> <20021124123827.H1071@blackjesus.async.com.br> <3DE0E83A.3090107@mozilla.org> <20021124152316.GA14874@mango.home>
Message-ID: <20021124192600.J1071@blackjesus.async.com.br>

On Mon, Nov 25, 2002 at 02:23:16AM +1100, Bradley Baetz wrote:
> On Sun, Nov 24, 2002 at 02:54:50PM +0000, Gervase Markham wrote:
> > Asking b.m.o. is a bit dodgy, because historically, b.m.o.'s 
> > requirements have controlled what fields there are. However, the only 
> > field which I think is not really generic is URL. So, here's an 
> > alternative question: how would b.m.o. cope without the URL field?
> 
> 'Really badly'. Its a bug tracking system for a webbrowser; providing
> url links are sort of important...

Sorta evil, but you see this really shows how the application domain can
influence directly the need for specific fields. Is a webbrowser special
in this respect? I don't know.

Can we get other examples?

Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL


From justdave at syndicomm.com  Sun Nov 24 22:41:24 2002
From: justdave at syndicomm.com (David Miller)
Date: Sun, 24 Nov 2002 17:41:24 -0500
Subject: Custom fields
In-Reply-To: <20021124192600.J1071@blackjesus.async.com.br>
References:  <Pine.LNX.4.43.0211240220160.17389-100000@underworld.sigkill.com>
 <3DE0AC93.9080100@mozilla.org> <3DE0DFAE.4080508@peshkin.net>
 <20021124123827.H1071@blackjesus.async.com.br>
 <3DE0E83A.3090107@mozilla.org> <20021124152316.GA14874@mango.home>
 <20021124192600.J1071@blackjesus.async.com.br>
Message-ID: <a05200f0aba0702a3c982@[192.168.1.203]>

There's a number of RFEs dealing with making things product-specific.

What Zippy really wants is a way to control what fields are available in
which products.

This would probably work equally well if we added a few commonly-requested
field types, and made them enableable/disableable per product.

Adding specific fields probably does less damage to query/buglist since you
don't have to be too generic about how you're searching for it...
-- 
Dave Miller      Project Leader, Bugzilla Bug Tracking System
http://www.justdave.net/             http://www.bugzilla.org/


From justdave at syndicomm.com  Sun Nov 24 22:54:41 2002
From: justdave at syndicomm.com (David Miller)
Date: Sun, 24 Nov 2002 17:54:41 -0500
Subject: The tree is open
Message-ID: <a05200f0dba0708bc3748@[192.168.1.203]>

The 2.17.1 tarball has been rolled and the tree is open again (this was
done before Joel's groups patch was checked in).

Approval will still be required for all checkins, but we'll be much more
liberal about what gets approved now.

2.17.1 will be getting posted on the ftp/web site as soon as mozilla.org's
ftp staging server is up again (it's been down yesterday and today)
-- 
Dave Miller      Project Leader, Bugzilla Bug Tracking System
http://www.justdave.net/             http://www.bugzilla.org/


From jake at bugzilla.org  Sun Nov 24 22:55:41 2002
From: jake at bugzilla.org (Jake)
Date: Sun, 24 Nov 2002 17:55:41 -0500
Subject: Custom fields
In-Reply-To: <a05200f0aba0702a3c982@[192.168.1.203]>
References: <Pine.LNX.4.43.0211240220160.17389-100000@underworld.sigkill.com> <3DE0AC93.9080100@mozilla.org> <3DE0DFAE.4080508@peshkin.net> <20021124123827.H1071@blackjesus.async.com.br> <3DE0E83A.3090107@mozilla.org> <20021124152316.GA14874@mango.home> <20021124192600.J1071@blackjesus.async.com.br> <a05200f0aba0702a3c982@[192.168.1.203]>
Message-ID: <3DE158ED.8080106@bugzilla.org>

I agree with this approach.  We could even add a few "empty" field types 
that can be configured/named/turned on via templates.  That is the way 
the help-desk software we use at work works and is fairly common among 
other networking apps I've worked with (such as Microsoft's Active 
Directory, although configured is very limited).

That would allow us to allow admins to create custom fields while still 
keeping things under control because we would only provide a limited 
number of these empty fields.

It would also be applicable to bmo... I mean are the OpSys and Platform 
fields really useful to the Bugzilla product?  And they're even less 
useful to the mozilla.org product!

David Miller wrote:

>There's a number of RFEs dealing with making things product-specific.
>
>What Zippy really wants is a way to control what fields are available in
>which products.
>
>This would probably work equally well if we added a few commonly-requested
>field types, and made them enableable/disableable per product.
>
>Adding specific fields probably does less damage to query/buglist since you
>don't have to be too generic about how you're searching for it...
>  
>



From bbaetz at student.usyd.edu.au  Mon Nov 25 00:02:47 2002
From: bbaetz at student.usyd.edu.au (Bradley Baetz)
Date: Mon, 25 Nov 2002 11:02:47 +1100
Subject: Custom fields
In-Reply-To: <20021124192600.J1071@blackjesus.async.com.br>
References: <Pine.LNX.4.43.0211240220160.17389-100000@underworld.sigkill.com> <3DE0AC93.9080100@mozilla.org> <3DE0DFAE.4080508@peshkin.net> <20021124123827.H1071@blackjesus.async.com.br> <3DE0E83A.3090107@mozilla.org> <20021124152316.GA14874@mango.home> <20021124192600.J1071@blackjesus.async.com.br>
Message-ID: <20021125000247.GA1153@mango.home>

On Sun, Nov 24, 2002 at 07:26:00PM -0200, Christian Reis wrote:
> 
> Sorta evil, but you see this really shows how the application domain can
> influence directly the need for specific fields. Is a webbrowser special
> in this respect? I don't know.

thats exactly my point. We have custom fields, and provide a 'type' of
url. As gerv and I discussed on npm.webtools a few weeks back, that type
is teh same as a text field type except that we linkify the contents.
About 10-20 lines of code at most extra, rather than teh current support
code for a field lots of people won't want.

Bradley


From myk at mozilla.org  Mon Nov 25 20:54:36 2002
From: myk at mozilla.org (Myk Melez)
Date: Mon, 25 Nov 2002 12:54:36 -0800
Subject: Custom fields
In-Reply-To: <20021124123827.H1071@blackjesus.async.com.br>
References: <Pine.LNX.4.43.0211240220160.17389-100000@underworld.sigkill.com> <3DE0AC93.9080100@mozilla.org> <3DE0DFAE.4080508@peshkin.net> <20021124123827.H1071@blackjesus.async.com.br>
Message-ID: <3DE28E0C.5010907@mozilla.org>

Christian Reis wrote:

>Hey, I've admined Bugzilla for Async for a couple of years now, for
>everything from Sales requests to Hardware trouble, and I have *never*
>wanted more fields - actually, the only thing that I *ever* wanted was
>*to remove fields*. Just my 2c. I guess other admins should chip in.
>Myk, what's the situation for beloved BMO?
>
As Gerv says, b.m.o has influenced Bugzilla too significantly to be able 
to say for sure, but I'm more interested in removing existing fields for 
products they don't apply to or users who don't care about them.

If I had my way, a patch that did that for all fields (or the ones that 
needed it most) would be more important than one implementing custom fields.

Since this is an open-source project, however, anyone is free to 
implement custom fields no matter what we say, in which case the 
question becomes what we're willing to do to make their lives easier, 
and I'm not sure the answer to that question is nothing.  Even if we 
decided not to take the patch, there are probably things we could do to 
make its co-existence with our codebase easier, and we should consider 
doing those things instead of washing our hands of the whole affair on 
the grounds that custom fields are a bad idea (which, for the record, I 
think they probably are).

-myk




From arvind at pixim.com  Tue Nov 26 06:55:56 2002
From: arvind at pixim.com (Arvind Singh)
Date: Mon, 25 Nov 2002 22:55:56 -0800
Subject: Custom fields
Message-ID: <16020FEDDBAF5440A59EB485AC75B2BB0611CC@exchange.pixim.com>

I believe we could add a limited no of empty fields and let the bugzilla adminsitrator have the privilege to define those empty fields for their. Each company ahs a different set of requirement. I believe instead of being rigid we should provide flexibilty in the usage and administration of bugzilla.On the bugzilla newsgroups everyday we get requests for custom fields. As mentioned earlier some time adding custom fields may become confusing but we should give the flexibility and let the bugzilla users decide whether he wants to use that or not. 
This will allow admins to create custom fields while still keeping things under control as only
fixed numbe of empty fields are provided.

Arvind.

> -----Original Message-----
> From: Myk Melez [mailto:myk at mozilla.org]
> Sent: Monday, November 25, 2002 12:55 PM
> To: developers at bugzilla.org
> Subject: Re: Custom fields
> 
> 
> Christian Reis wrote:
> 
> >Hey, I've admined Bugzilla for Async for a couple of years now, for
> >everything from Sales requests to Hardware trouble, and I 
> have *never*
> >wanted more fields - actually, the only thing that I *ever* 
> wanted was
> >*to remove fields*. Just my 2c. I guess other admins should chip in.
> >Myk, what's the situation for beloved BMO?
> >
> As Gerv says, b.m.o has influenced Bugzilla too significantly 
> to be able 
> to say for sure, but I'm more interested in removing existing 
> fields for 
> products they don't apply to or users who don't care about them.
> 
> If I had my way, a patch that did that for all fields (or the 
> ones that 
> needed it most) would be more important than one implementing 
> custom fields.
> 
> Since this is an open-source project, however, anyone is free to 
> implement custom fields no matter what we say, in which case the 
> question becomes what we're willing to do to make their lives easier, 
> and I'm not sure the answer to that question is nothing.  Even if we 
> decided not to take the patch, there are probably things we 
> could do to 
> make its co-existence with our codebase easier, and we should 
> consider 
> doing those things instead of washing our hands of the whole 
> affair on 
> the grounds that custom fields are a bad idea (which, for the 
> record, I 
> think they probably are).
> 
> -myk
> 
> 
> ----
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=arvind at pixim.com>
> 


From vladimir at cs.yorku.ca  Thu Nov 28 00:42:38 2002
From: vladimir at cs.yorku.ca (Vladimir Blagojevic)
Date: Wed, 27 Nov 2002 19:42:38 -0500 (EST)
Subject: Importing to mozilla
Message-ID: <Pine.GSO.4.44.0211271924550.24164-100000@blue.cs.yorku.ca>

Hi,

Does anyone know of any tools for importing bug database from other open
source formats to bugzilla. For example, are there any tools for
importing gnats database into bugzilla? How hard would it be to write
these tools from scratch - any estimate would be helpful.

I found a mention (http://gcc.gnu.org/ml/gcc/2001-11/msg00870.html) of
some XML DTD schema which I would be interested to look into. Is there
more information available about this project?

"Dawn Endico made Bugzilla's XML DTD the industry-standard bug-tracking
DTD (no standardization committee, but most open bug-trackers support the
format now).  So you can do a mysql dump of data, export it via XML for
importation elsewhere, or export your existing data to an
easily-understood XML format for importation."


Thanks,
Vladimir



From justdave at syndicomm.com  Thu Nov 28 00:49:46 2002
From: justdave at syndicomm.com (David Miller)
Date: Wed, 27 Nov 2002 19:49:46 -0500
Subject: Importing to mozilla
In-Reply-To: <Pine.GSO.4.44.0211271924550.24164-100000@blue.cs.yorku.ca>
References: <Pine.GSO.4.44.0211271924550.24164-100000@blue.cs.yorku.ca>
Message-ID: <a05200f00ba0b18847ceb@[192.168.1.203]>

On 11/27/02 7:42 PM -0500, Vladimir Blagojevic wrote:

> Does anyone know of any tools for importing bug database from other open
> source formats to bugzilla. For example, are there any tools for
> importing gnats database into bugzilla? How hard would it be to write
> these tools from scratch - any estimate would be helpful.

Look in the contrib directory in your local Bugzilla tarball for a script
called gnats2bz.

No guarantees that it works, it may need updating for the current schema.
-- 
Dave Miller      Project Leader, Bugzilla Bug Tracking System
http://www.justdave.net/             http://www.bugzilla.org/


From vladimir at cs.yorku.ca  Thu Nov 28 01:00:44 2002
From: vladimir at cs.yorku.ca (Vladimir Blagojevic)
Date: Wed, 27 Nov 2002 20:00:44 -0500 (EST)
Subject: Importing to mozilla
In-Reply-To: <a05200f00ba0b18847ceb@[192.168.1.203]>
Message-ID: <Pine.GSO.4.44.0211271957560.24965-100000@blue.cs.yorku.ca>

David,

Thanks.I look into it. I'll have to install bugzilla first. BTW do you
know what happened http://www.bugzilla.org/docs/html/dbschema.html ? I would
like to compare it to scarab's schema?

Vladimir

On Wed, 27 Nov 2002, David Miller wrote:
> Look in the contrib directory in your local Bugzilla tarball for a script
> called gnats2bz.
>
> No guarantees that it works, it may need updating for the current schema.
> --
> Dave Miller      Project Leader, Bugzilla Bug Tracking System
> http://www.justdave.net/             http://www.bugzilla.org/
> ----
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=vladimir at cs.yorku.ca>
>



From justdave at syndicomm.com  Thu Nov 28 01:17:09 2002
From: justdave at syndicomm.com (David Miller)
Date: Wed, 27 Nov 2002 20:17:09 -0500
Subject: Bugzilla Schema [was: Importing to mozilla]
In-Reply-To: <Pine.GSO.4.44.0211271957560.24965-100000@blue.cs.yorku.ca>
References: <Pine.GSO.4.44.0211271957560.24965-100000@blue.cs.yorku.ca>
Message-ID: <a05200f01ba0b1c796a3e@[192.168.1.203]>

On 11/27/02 8:00 PM -0500, Vladimir Blagojevic wrote:

> Thanks.I look into it. I'll have to install bugzilla first. BTW do you
> know what happened http://www.bugzilla.org/docs/html/dbschema.html ? I would
> like to compare it to scarab's schema?

I believe Barnboy removed it because it was horribly out of date.  Though I
notice it's still listed in the index.... hmmm.  The text description on
the page following it is definitely out of date as well.

I was planning to redo the schema chart myself at some point when I get a
little money to get a licensed copy of OmniGraffle :-)  but that's a few
weeks off yet.  If anyone wants to beat me to it, feel free.

You may be able to figure out some of it from the --MYSQL-- sections in
checksetup.pl, but some of the newer stuff that's been added recently will
probably take a little more documentation...
-- 
Dave Miller      Project Leader, Bugzilla Bug Tracking System
http://www.justdave.net/             http://www.bugzilla.org/