From etzwane at schwag.org  Thu May  1 22:06:23 2003
From: etzwane at schwag.org (Sean McAfee)
Date: Thu, 01 May 2003 18:06:23 -0400
Subject: More custom field revisions
In-Reply-To: <3EB03EBE.6010905@mozilla.org>
Message-ID: <20030501220623.1B128BCDB@diggity.schwag.org>

Gervase Markham <gerv at mozilla.org> wrote:
>Sean McAfee wrote:
>> What concerns me is the spectre of a set of N products on the one side,
>> a set of M custom fields on the other (N and M both being large), and
>> some arbitrarily complicated set of has-a relationships between them.

>You make it sound complex, but it's not. On every "edit custom field" 
>screen, you have a "Restrict to products:" multiselect. And that's all 
>you need.

OK, that approach addresses the issue, but it doesn't scale well.
Adding a new global field to an N-product installation would involve:

1.  Shift-click all products visible in the multiselect (seven, say).
2.  Scroll down.
3.  Repeat steps 1 and 2 (ceil(N/7)-1) times.

If a new field were to be shared by only half the products, the admin
would have to scroll down the entire box, carefully shift-clicking the
correct half.  I see significant room for input errors.

If named field groups were employed instead, the previous two situations
are more straightforward to handle.  I think it's worth shouldering some
additional complexity to provide a cleaner, more intuitive interface.

>> OK, I can see the utility in this.  I would ask, though, that the
>> administrator not be required to compose from scratch, for every field,
>> a name which isn't relevant to the user interface. 

>> The admin interface
>> could, for example, propose a reasonable default by downcasing the
>> display name and replacing all nonalphanumerics with underscores, and
>> twiddling the result to avoid name collision.  The administrator could
>> then accept this suggestion, modify it, or nuke it and make up a new one.

>Hmm. We could do that. If it were me, I'd like to pick my own, but I can 
>see the value in Bugzilla making a suggestion.

I'm not really comfortable publicly exposing what is essentially an
implementation detail, of relevance only to those who sling around
query URLs.  This may be my own divergent experience again, but that's
not really common practice here.

>> I think it should be possible to modify the presentation of custom fields in
>> this way, but I'd rather provide reasonable default behavior that obviates
>> the need to perform template-twiddling for each and every custom field.

>Oh, I agree that we should display them without intervention - note that 
>I said "how and where", not "if" :-) In other words, there should be a 
>default location, and changing it requires hacking templates, plus a 
>default UI widget, and changing that requires hacking templates.

But you've also said that display names should reside in templates,
so the simple act of defining a new custom field would require hacking
templates (for small values of "hack").

-- 
Sean McAfee -- etzwane at schwag.org


From bugreport at peshkin.net  Thu May  1 22:51:49 2003
From: bugreport at peshkin.net (Joel Peshkin)
Date: Thu, 01 May 2003 15:51:49 -0700
Subject: More custom field revisions
In-Reply-To: <20030501220623.1B128BCDB@diggity.schwag.org>
References: <20030501220623.1B128BCDB@diggity.schwag.org>
Message-ID: <3EB1A505.1070505@peshkin.net>

Sean McAfee wrote:

> <snip>
>
>If a new field were to be shared by only half the products, the admin
>would have to scroll down the entire box, carefully shift-clicking the
>correct half.  I see significant room for input errors.
>
><snip>
>
Just don't lose the contents of custom fields when bugs are moved 
between products.

-Joel




From gerv at mozilla.org  Fri May  2 07:46:35 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Fri, 02 May 2003 08:46:35 +0100
Subject: Gerv away until Tuesday
Message-ID: <3EB2225B.20805@mozilla.org>

Just a note (given that I'm in several discussions with people on these 
lists, and I hate auto-reply out-of-office messages, as I'm sure you all 
do):

I'm away until Tuesday on a church weekend away. Plenty of time relaxing 
without the Internet and with the focus on God. :-)

See you all in four days.

Gerv



From caseyg at chsamerica.com  Fri May  2 17:42:01 2003
From: caseyg at chsamerica.com (Casey Gregoire)
Date: Fri, 2 May 2003 13:42:01 -0400 
Subject: Using I frame to contain the additional Comments section
Message-ID: <C3EB95A31BDAD511827C00B0D0F95AF574E3FA@BUCKWHEAT>

My boss wanted to see a scrollable frame that contained the additional
comments section of the edit bug screen. What I did was use a template for
the show_bug.cgi that only showed the comments section and put that as the
src value for the Iframe that I replaced the comments section in the
edit.html.tmpl. Of course that this does is every time you view a bug it
queries the database twice as much for the exact same data. I was looking
for a simple change that did not involve changing the cgi scripts for
Bugzilla. (All of my changes are in the templates) 

Can anyone tell me if there was a better way to go about doing this that
would query the database only once? (I don't want to have to change the
actual source code of Bugzilla if I can avoid it.) I included the templates
so you can see exactly what I did.

 <<show-onlycom.html.tmpl>>  <<edit.html.tmpl>> Thank you,
	Casey Gregoire
	Programmer
	CHS of America
	100 1st Ave S. Suite 601
	St. Petersburg, FL 33701
	Phone - (727) 824-0800 ext 1236

Every great achievement was once impossible. -- Anonymous
I'd like to get started on time, if we can, inasmuch as we're late already.
-- Larry Gelbart
Nothing is accomplished without passion. -- My Fortune Cookie

-------------- next part --------------
A non-text attachment was scrubbed...
Name: show-onlycom.html.tmpl
Type: application/octet-stream
Size: 1772 bytes
Desc: not available
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20030502/c5aea8c7/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: edit.html.tmpl
Type: application/octet-stream
Size: 19077 bytes
Desc: not available
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20030502/c5aea8c7/attachment-0001.obj>

From myk at mozilla.org  Fri May  2 18:37:54 2003
From: myk at mozilla.org (Myk Melez)
Date: Fri, 02 May 2003 11:37:54 -0700
Subject: Using I frame to contain the additional Comments section
In-Reply-To: <C3EB95A31BDAD511827C00B0D0F95AF574E3FA@BUCKWHEAT>
References: <C3EB95A31BDAD511827C00B0D0F95AF574E3FA@BUCKWHEAT>
Message-ID: <3EB2BB02.30606@mozilla.org>

Casey Gregoire wrote:

>Can anyone tell me if there was a better way to go about doing this that
>would query the database only once? (I don't want to have to change the
>actual source code of Bugzilla if I can avoid it.)
>
Currently Bugzilla generally assumes that every template wants to 
display everything it can, since templates were originally ported from 
inline HTML in the Perl script, where only one format was ever 
possible.  Bugzilla thus pushes all the data at the template, which 
decides what data to display.

Now that we have templates and multiple formats, we need to change that 
model so that Bugzilla merely hands the template a reference to a bug 
object, the template requests data from the bug object, and the bug 
object gets data from the database on demand.  The template then pulls 
the data it wants when it wants it, and it doesn't pull any data it 
doesn't want.  You still incur the cost of instantiating the script a 
second time in this model, but that cost will be effectively eliminated 
when mod_perl/SpeedyCGI support gets implemented (work on this is ongoing).

Unfortunately not much work is happening on switching from push to pull 
models, but fortunately some work has already been done, and one of the 
pieces that was done was comments on the "show bug" page, so when you go 
to the "show bug" page for a specific bug, show_bug.cgi hands the 
template a bug object, and that bug object doesn't pull comments from 
the database until the template calls its "longdesc" method.

Just make sure you aren't calling that method in the main template, and 
you should be able to save the cost of pulling that data twice.  You'll 
still pull other data twice, because the bug object assumes you want a 
base set of data that you probably don't need in the comments iframe.  
Perhaps you'd be interested in taking on the task of fixing that by 
converting it over to a pull model?

-myk




From caseyg at chsamerica.com  Fri May  2 19:31:41 2003
From: caseyg at chsamerica.com (Casey Gregoire)
Date: Fri, 2 May 2003 15:31:41 -0400 
Subject: Using I frame to contain the additional Comments section
Message-ID: <C3EB95A31BDAD511827C00B0D0F95AF574E47B@BUCKWHEAT>

I don't have the time allotted to me here to take on such an endeavor. As it
is we want a bunch of custom fields implemented before I think the custom
fields option in Bugzilla is usable so I am going to have to devote time to
doing that. That's why when I make a change like today it has to be short
and simple. I am not to savvy with perl yet either. Implementing Bugzilla
was a small side project for me in the grand scheme of things.

Thanks,
	Casey Gregoire

 -----Original Message-----
From: 	Myk Melez [mailto:myk at mozilla.org] 
Sent:	Friday, May 02, 2003 2:38 PM
To:	developers at bugzilla.org
Subject:	Re: Using I frame to contain the additional Comments section

Casey Gregoire wrote:

>Can anyone tell me if there was a better way to go about doing this that
>would query the database only once? (I don't want to have to change the
>actual source code of Bugzilla if I can avoid it.)
>
Currently Bugzilla generally assumes that every template wants to 
display everything it can, since templates were originally ported from 
inline HTML in the Perl script, where only one format was ever 
possible.  Bugzilla thus pushes all the data at the template, which 
decides what data to display.

Now that we have templates and multiple formats, we need to change that 
model so that Bugzilla merely hands the template a reference to a bug 
object, the template requests data from the bug object, and the bug 
object gets data from the database on demand.  The template then pulls 
the data it wants when it wants it, and it doesn't pull any data it 
doesn't want.  You still incur the cost of instantiating the script a 
second time in this model, but that cost will be effectively eliminated 
when mod_perl/SpeedyCGI support gets implemented (work on this is ongoing).

Unfortunately not much work is happening on switching from push to pull 
models, but fortunately some work has already been done, and one of the 
pieces that was done was comments on the "show bug" page, so when you go 
to the "show bug" page for a specific bug, show_bug.cgi hands the 
template a bug object, and that bug object doesn't pull comments from 
the database until the template calls its "longdesc" method.

Just make sure you aren't calling that method in the main template, and 
you should be able to save the cost of pulling that data twice.  You'll 
still pull other data twice, because the bug object assumes you want a 
base set of data that you probably don't need in the comments iframe.  
Perhaps you'd be interested in taking on the task of fixing that by 
converting it over to a pull model?

-myk


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


From jake at bugzilla.org  Fri May  2 20:06:00 2003
From: jake at bugzilla.org (Jake)
Date: Fri, 2 May 2003 16:06:00 -0400 (EDT)
Subject: Using I frame to contain the additional Comments section
In-Reply-To: <C3EB95A31BDAD511827C00B0D0F95AF574E47B@BUCKWHEAT>
References: <C3EB95A31BDAD511827C00B0D0F95AF574E47B@BUCKWHEAT>
Message-ID: <57853.208.20.196.122.1051905960.squirrel@mail.steenhagen.us>

> I don't have the time allotted to me here to take on such an endeavor. As
> it is we want a bunch of custom fields implemented before I think the
custom
> fields option in Bugzilla is usable so I am going to have to devote time
> to doing that. That's why when I make a change like today it has to be
short
> and simple. I am not to savvy with perl yet either. Implementing Bugzilla
> was a small side project for me in the grand scheme of things.
>

You may also wish to look at doing something like:

<div style="height: 200px; width: 90em; overflow: scroll;">
  [%# Do whatever retrieves the comments %]
</div>

Which will, assumming I've remembered the CSS stuff correctly, work
incredibly similar to an <iframe/>.  You can, of course, adjust the
height/width stuff as needed.  According to
http://www.w3schools.com/css/css_positioning.asp the overflow property of
CSS is supported by IE 4+ and NS 6+ which according to my memory is the
same set of browsers that support <iframe/> (I don't know where Opera,
etc. fits in for either).


From caseyg at chsamerica.com  Fri May  2 20:16:21 2003
From: caseyg at chsamerica.com (Casey Gregoire)
Date: Fri, 2 May 2003 16:16:21 -0400 
Subject: Using I frame to contain the additional Comments section
Message-ID: <C3EB95A31BDAD511827C00B0D0F95AF574E4AC@BUCKWHEAT>

Wow. That is what I have been looking for. Its been years since I have done
html. That is what I wanted exactly. Thanks.

Thanks,
	Casey Gregoire

 -----Original Message-----
From: 	Jake [mailto:jake at bugzilla.org] 
Sent:	Friday, May 02, 2003 4:06 PM
To:	developers at bugzilla.org
Subject:	Re: Using I frame to contain the additional Comments section

> I don't have the time allotted to me here to take on such an endeavor. As
> it is we want a bunch of custom fields implemented before I think the
custom
> fields option in Bugzilla is usable so I am going to have to devote time
> to doing that. That's why when I make a change like today it has to be
short
> and simple. I am not to savvy with perl yet either. Implementing Bugzilla
> was a small side project for me in the grand scheme of things.
>

You may also wish to look at doing something like:

<div style="height: 200px; width: 90em; overflow: scroll;">
  [%# Do whatever retrieves the comments %]
</div>

Which will, assumming I've remembered the CSS stuff correctly, work
incredibly similar to an <iframe/>.  You can, of course, adjust the
height/width stuff as needed.  According to
http://www.w3schools.com/css/css_positioning.asp the overflow property of
CSS is supported by IE 4+ and NS 6+ which according to my memory is the
same set of browsers that support <iframe/> (I don't know where Opera,
etc. fits in for either).
----
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=caseyg at chsamerica.com>


From caseyg at chsamerica.com  Fri May  2 21:22:30 2003
From: caseyg at chsamerica.com (Casey Gregoire)
Date: Fri, 2 May 2003 17:22:30 -0400 
Subject: Using I frame to contain the additional Comments section
Message-ID: <C3EB95A31BDAD511827C00B0D0F95AF574E4C4@BUCKWHEAT>

Before in the Iframe I was using a height of 60% and it worked fine, with
the div it does not. Has anyone used <div> extensively? May you might know
why this happens? (what did happened when I used a percentage is that the
area was the full size of the comment block no matter what. The <div> tag is
SUPPOSED to be able to do this.

Thanks,
	Casey Gregoire

 -----Original Message-----
From: 	Casey Gregoire [mailto:caseyg at chsamerica.com] 
Sent:	Friday, May 02, 2003 4:16 PM
To:	developers at bugzilla.org
Subject:	Re: Using I frame to contain the additional Comments section

Wow. That is what I have been looking for. Its been years since I have done
html. That is what I wanted exactly. Thanks.

Thanks,
	Casey Gregoire

 -----Original Message-----
From: 	Jake [mailto:jake at bugzilla.org] 
Sent:	Friday, May 02, 2003 4:06 PM
To:	developers at bugzilla.org
Subject:	Re: Using I frame to contain the additional Comments section

> I don't have the time allotted to me here to take on such an endeavor. As
> it is we want a bunch of custom fields implemented before I think the
custom
> fields option in Bugzilla is usable so I am going to have to devote time
> to doing that. That's why when I make a change like today it has to be
short
> and simple. I am not to savvy with perl yet either. Implementing Bugzilla
> was a small side project for me in the grand scheme of things.
>

You may also wish to look at doing something like:

<div style="height: 200px; width: 90em; overflow: scroll;">
  [%# Do whatever retrieves the comments %]
</div>

Which will, assumming I've remembered the CSS stuff correctly, work
incredibly similar to an <iframe/>.  You can, of course, adjust the
height/width stuff as needed.  According to
http://www.w3schools.com/css/css_positioning.asp the overflow property of
CSS is supported by IE 4+ and NS 6+ which according to my memory is the
same set of browsers that support <iframe/> (I don't know where Opera,
etc. fits in for either).
----
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=caseyg at chsamerica.com>
----
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=caseyg at chsamerica.com>


From bbaetz at acm.org  Sat May  3 13:37:05 2003
From: bbaetz at acm.org (Bradley Baetz)
Date: Sat, 3 May 2003 23:37:05 +1000
Subject: CGI.pm note
Message-ID: <20030503133705.GA15024@mango.home>

I discovered this evening stuff like that:

GetFormat("XXX", $cgi->param('format'), $cgi->param('ctype'));

is buggy. Thats because if |ctype| is present (and, say, set to 'Foo'),
but |format| isn't, GetFormat gets _two_ arguments ("XXX", "Foo"). this
is because $cgi->param('format') uses |return| (not |return undef|), and
that returns an empty array in array context, and so ('XXX', (), 'Foo')
becomes ('XXX', 'Foo').

This is not a CGI.pm bug (although I thought it was at first), because
of

foreach $x ($cgi->param('foo')) {
  ...
}

where an empty array is wanted.

IOW, passing $cgi->param('foo') directly into a function is only valid
if:

a) Its the last argument (and noone is checking the size of the passed
in args); or

b) The function has a prototype (For GetFormat, $;$$ would be used)
_and_ its not being called like &GetFormat which bypasses prototypes
(and its a function, not a method, because methods don't care about
prototypes); or

c) You've already checked that the param exists (in this case, though,
it should usually be stored in a scalar for speed/ease of access/etc
anyway); or

d) Its ||'d (or similar) with a default, like

GetFormat("XXX", $cgi->param('format') || 'default', $cgi->param('ctype'));

As I mentioned in (c), this is generally only important for stuff which
is accessed once, such as GetFormat (and I'll add a prototype onto that
locally, as part of my mod_perl stuff)

Bradley


From caseyg at chsamerica.com  Mon May  5 14:38:29 2003
From: caseyg at chsamerica.com (Casey Gregoire)
Date: Mon, 5 May 2003 10:38:29 -0400 
Subject: Accept Bug
Message-ID: <C3EB95A31BDAD511827C00B0D0F95AF574E73D@BUCKWHEAT>

I was looking at a peculiar thing on the bug database. When you look at a
bug that is marked NEW but assigned to someone else and you select the radio
button for accept bug, (Change status to assigned) it does not change the
owner to the person who selected accept. Does this sound right? if you open
some else's bug and click the link that says accept the bug, should it not
assign to the user who made the selection?

Thank you,
	Casey Gregoire
	Programmer
	CHS of America
	100 1st Ave S. Suite 601
	St. Petersburg, FL 33701
	Phone - (727) 824-0800 ext 1236

Every great achievement was once impossible. -- Anonymous
I'd like to get started on time, if we can, inasmuch as we're late already.
-- Larry Gelbart
Nothing is accomplished without passion. -- My Fortune Cookie



From kiko at async.com.br  Mon May  5 18:18:00 2003
From: kiko at async.com.br (Christian Reis)
Date: Mon, 5 May 2003 15:18:00 -0300
Subject: Accept Bug
In-Reply-To: <C3EB95A31BDAD511827C00B0D0F95AF574E73D@BUCKWHEAT>; from caseyg@chsamerica.com on Mon, May 05, 2003 at 10:38:29AM -0400
References: <C3EB95A31BDAD511827C00B0D0F95AF574E73D@BUCKWHEAT>
Message-ID: <20030505151800.P21824@blackjesus.async.com.br>

On Mon, May 05, 2003 at 10:38:29AM -0400, Casey Gregoire wrote:
> I was looking at a peculiar thing on the bug database. When you look at a
> bug that is marked NEW but assigned to someone else and you select the radio
> button for accept bug, (Change status to assigned) it does not change the
> owner to the person who selected accept. Does this sound right? if you open

This is by design, though you could argue it (or at least the labelling)
is broken. IIRC the reason is that certain organizations have these
things called "managers" that assign bugs to engineers, and not the
other way around. In that case, the engineers receive a notification
through email that bug X was assigned to them, and then they proceed to
spend the weekend coding a fix.

> some else's bug and click the link that says accept the bug, should it not
> assign to the user who made the selection?

I thought so too, but once someone on IRC pointed out this fact to me. I
think at least the label is wrong, and a bug to change it might even
exist.

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


From caseyg at chsamerica.com  Mon May  5 18:22:02 2003
From: caseyg at chsamerica.com (Casey Gregoire)
Date: Mon, 5 May 2003 14:22:02 -0400 
Subject: Accept Bug
Message-ID: <C3EB95A31BDAD511827C00B0D0F95AF574E89C@BUCKWHEAT>

But if you reassigned an 'assigned' bug to someone it comes up as new.
Should it not stay assigned there?

Thanks,
	Casey Gregoire

 -----Original Message-----
From: 	Christian Reis [mailto:kiko at async.com.br] 
Sent:	Monday, May 05, 2003 2:18 PM
To:	developers at bugzilla.org
Subject:	Re: Accept Bug

On Mon, May 05, 2003 at 10:38:29AM -0400, Casey Gregoire wrote:
> I was looking at a peculiar thing on the bug database. When you look at a
> bug that is marked NEW but assigned to someone else and you select the
radio
> button for accept bug, (Change status to assigned) it does not change the
> owner to the person who selected accept. Does this sound right? if you
open

This is by design, though you could argue it (or at least the labelling)
is broken. IIRC the reason is that certain organizations have these
things called "managers" that assign bugs to engineers, and not the
other way around. In that case, the engineers receive a notification
through email that bug X was assigned to them, and then they proceed to
spend the weekend coding a fix.

> some else's bug and click the link that says accept the bug, should it not
> assign to the user who made the selection?

I thought so too, but once someone on IRC pointed out this fact to me. I
think at least the label is wrong, and a bug to change it might even
exist.

Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL
----
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=caseyg at chsamerica.com>


From gerv at mozilla.org  Mon May  5 19:33:25 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Mon, 05 May 2003 20:33:25 +0100
Subject: Accept Bug
In-Reply-To: <C3EB95A31BDAD511827C00B0D0F95AF574E89C@BUCKWHEAT>
References: <C3EB95A31BDAD511827C00B0D0F95AF574E89C@BUCKWHEAT>
Message-ID: <3EB6BC85.4060500@mozilla.org>

Casey Gregoire wrote:
> But if you reassigned an 'assigned' bug to someone it comes up as new.
> Should it not stay assigned there?

One could argue, certainly, that this is inconsistent with your initial 
observation. :-)

Gerv



From caseyg at chsamerica.com  Mon May  5 19:38:33 2003
From: caseyg at chsamerica.com (Casey Gregoire)
Date: Mon, 5 May 2003 15:38:33 -0400 
Subject: Accept Bug
Message-ID: <C3EB95A31BDAD511827C00B0D0F95AF574E923@BUCKWHEAT>

After I sent it seemed to make sense since if it shows up as new the user
will get all the bugs that have been assigned to them that they have not
looked up in a list of 'new' bugs. Of course that goes into does new mean
new to the system, or new the assigned user?

Thanks,
	Casey Gregoire

 -----Original Message-----
From: 	Gervase Markham [mailto:gerv at mozilla.org] 
Sent:	Monday, May 05, 2003 3:33 PM
To:	developers at bugzilla.org
Subject:	Re: Accept Bug

Casey Gregoire wrote:
> But if you reassigned an 'assigned' bug to someone it comes up as new.
> Should it not stay assigned there?

One could argue, certainly, that this is inconsistent with your initial 
observation. :-)

Gerv

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


From arthur.barrett at march-hare.com  Tue May  6 01:04:31 2003
From: arthur.barrett at march-hare.com (Arthur Barrett)
Date: Tue, 6 May 2003 11:04:31 +1000 
Subject: Sybase help ? (or MSSQL help)
Message-ID: <EA4F8DA70D52D51193660080C8D5886BC882@NTSRVR01>

Dave,

We spoke a few weeks back about the Sybase patches.

I saw your comments "What lies ahead" - any chance of you posting the Sybase
mod patches to me some time soon?

Thanks!


Arthur

-----Original Message-----
From: David Miller [mailto:justdave at netscape.com] 
Sent: Wednesday, 9 April 2003 3:38 AM
To: developers at bugzilla.org
Subject: Re: Sybase help ? (or MSSQL help)


On 4/8/03 5:17 PM +1000, Arthur Barrett wrote:

> I noticed some limited references to using Sybase with Bugzilla.
>
> Can someone please point me at the patches or whatever I need to try 
> this ?

There's nothing posted yet.  I'll try really hard to get something up in the
next few weeks.  We have it mostly working now, I just haven't had time to
pull all of our local customizations out of it so I can post it.



From etzwane at schwag.org  Tue May  6 07:29:29 2003
From: etzwane at schwag.org (Sean McAfee)
Date: Tue, 06 May 2003 03:29:29 -0400
Subject: Latest custom field revisions
Message-ID: <20030506072929.474A1BCDB@diggity.schwag.org>

Hi folks--

Attached is a fresh edition of a custom fields requirements document.  I've
incorporated most or all of the recent list discussion on the topic.  Also
attached is an updated version of my suggested editcustomfields.cgi
interface.

Let me know what you think.  Thanks.

-- 
Sean McAfee -- etzwane at schwag.org
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: bz-cf-requirements.txt
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20030506/553de789/attachment.txt>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20030506/553de789/attachment.html>

From bbaetz at acm.org  Tue May  6 11:51:49 2003
From: bbaetz at acm.org (Bradley Baetz)
Date: Tue, 6 May 2003 21:51:49 +1000
Subject: CGI.pm note
In-Reply-To: <20030503133705.GA15024@mango.home>
References: <20030503133705.GA15024@mango.home>
Message-ID: <20030506115149.GA2872@mango.home>

On Sat, May 03, 2003 at 11:37:05PM +1000, Bradley Baetz wrote:
> 
> b) The function has a prototype (For GetFormat, $;$$ would be used)
> _and_ its not being called like &GetFormat which bypasses prototypes
> (and its a function, not a method, because methods don't care about
> prototypes); or

So, as a followup to this, I'd like to recommend that we prototype stuff
where possible. This isn't possible from any required file (because
thats a runtime thing, not a compile time thing), and most of our
modules are OO things which also don't work with prototypes, but there
is stuff which can be handled that way.

Thoughts?

Bradley


From bugreport at peshkin.net  Tue May  6 14:43:39 2003
From: bugreport at peshkin.net (Joel Peshkin)
Date: Tue, 06 May 2003 07:43:39 -0700
Subject: Latest custom field revisions
In-Reply-To: <20030506072929.474A1BCDB@diggity.schwag.org>
References: <20030506072929.474A1BCDB@diggity.schwag.org>
Message-ID: <3EB7CA1B.6030704@peshkin.net>


In general, this looks very good.  There are a few details not yet 
addressed which I think should be ....

1) What happens when a bug is moved to a product on which the custom 
field is not relevent and then is subsequently moved to a product where 
it is?  (I suggest that the field be made invisible while in the product 
where it is not irrelevent but not lost)

2) Which name is used for the activity log?

3) What happens to the activity log on field rename?  (It should stay 
consistent)

4) In the standard templates, there will no doubt be a routine that 
handles the custom fields.  If a site customizes the templates, can they 
indicate that a field is "already done" so the routine skips a specific 
field and leaves it to template customizations?





From slamm at yahoo-inc.com  Tue May  6 16:22:13 2003
From: slamm at yahoo-inc.com (Stephen Lamm)
Date: Tue, 6 May 2003 09:22:13 -0700
Subject: CGI.pm note
In-Reply-To: <20030506115149.GA2872@mango.home>; from bbaetz@acm.org on Tue, May 06, 2003 at 09:51:49PM +1000
References: <20030503133705.GA15024@mango.home> <20030506115149.GA2872@mango.home>
Message-ID: <20030506092213.T56214@yahoo-inc.com>

On 06/05/03 21:51 +1000, Bradley Baetz <bbaetz at acm.org> wrote:
> On Sat, May 03, 2003 at 11:37:05PM +1000, Bradley Baetz wrote:
> > 
> > b) The function has a prototype (For GetFormat, $;$$ would be used)
> > _and_ its not being called like &GetFormat which bypasses prototypes
> > (and its a function, not a method, because methods don't care about
> > prototypes); or
> 
> So, as a followup to this, I'd like to recommend that we prototype stuff
> where possible. This isn't possible from any required file (because
> thats a runtime thing, not a compile time thing), and most of our
> modules are OO things which also don't work with prototypes, but there
> is stuff which can be handled that way.
> 
> Thoughts?
> 
> Bradley

Prototypes are good when you want a function to behave like a built-in.
They are not meant for type checking. They should probably only be
used where needed.

Here is a good explanation of "Prototypes in Perl" by Tom Christiansen:

http://www.perl.com/pub/a/language/misc/fmproto.html

-slamm


From caseyg at chsamerica.com  Tue May  6 19:14:03 2003
From: caseyg at chsamerica.com (Casey Gregoire)
Date: Tue, 6 May 2003 15:14:03 -0400 
Subject: Submitted a new bug, ten people got an e-mail
Message-ID: <C3EB95A31BDAD511827C00B0D0F95AF57685F1@BUCKWHEAT>

I was on the Bugzilla.mozilla.org site today and enter in a bug (#204646)
and ten people got and mail. How is that? I did not put any cc's is watching
someone the only way for this to happen? As far as I know only the reporter,
owner, and QA contact would get these e-mails.

Thank you,
	Casey Gregoire
	Programmer
	CHS of America
	100 1st Ave S. Suite 601
	St. Petersburg, FL 33701
	Phone - (727) 824-0800 ext 1236

Every great achievement was once impossible. -- Anonymous
I'd like to get started on time, if we can, inasmuch as we're late already.
-- Larry Gelbart
Nothing is accomplished without passion. -- My Fortune Cookie



From justdave at syndicomm.com  Tue May  6 19:28:42 2003
From: justdave at syndicomm.com (David Miller)
Date: Tue, 6 May 2003 15:28:42 -0400
Subject: Submitted a new bug, ten people got an e-mail
In-Reply-To: <C3EB95A31BDAD511827C00B0D0F95AF57685F1@BUCKWHEAT>
References: <C3EB95A31BDAD511827C00B0D0F95AF57685F1@BUCKWHEAT>
Message-ID: <a05210506baddbd32b55d@[192.168.1.203]>

On 5/6/2003 3:14 PM -0400, Casey Gregoire wrote:

> I was on the Bugzilla.mozilla.org site today and enter in a bug (#204646)
> and ten people got and mail. How is that? I did not put any cc's is watching
> someone the only way for this to happen? As far as I know only the reporter,
> owner, and QA contact would get these e-mails.

b.m.o has "usewatchers" enabled, and lots of people watch each other.  I
know I watch most of the component owners for the Bugzilla product,
personally, and there's a number of people that watch me.  It's an easy way
to stay informed if you like bugmail :)
-- 
Dave Miller      Project Leader, Bugzilla Bug Tracking System
http://www.justdave.net/             http://www.bugzilla.org/


From etzwane at schwag.org  Tue May  6 21:38:24 2003
From: etzwane at schwag.org (Sean McAfee)
Date: Tue, 06 May 2003 17:38:24 -0400
Subject: Latest custom field revisions
In-Reply-To: <3EB7CA1B.6030704@peshkin.net>
Message-ID: <20030506213824.87F17BCDB@diggity.schwag.org>

Joel Peshkin <bugreport at peshkin.net> wrote:
>In general, this looks very good.  There are a few details not yet 
>addressed which I think should be ....

>1) What happens when a bug is moved to a product on which the custom 
>field is not relevent and then is subsequently moved to a product where 
>it is?  (I suggest that the field be made invisible while in the product 
>where it is not irrelevent but not lost)

I'd rather keep it simple and say that a field which is not shared by
both the old product and the new one is lost.  In a straightforward
implementation, custom fields are contained by products or field groups,
not by individual bugs.  Also, consider the extreme case:  If a bug is moved
among each product, it ends up carrying around a copy of every custom field
in the installaion.

An alternative approach might be to provide a "Store custom fields
in comment" checkbox when a bug is moved from one product to another.
If it's checked, fields which are not shared between the old and new
products are stored in a human-readable form in a comment.

>2) Which name is used for the activity log?

I dunno..."Custom Field Activity Log", I suppose.

>3) What happens to the activity log on field rename?  (It should stay 
>consistent)

Yeah, that's what one would reasonably expect.  DB references to fields will
be by ID number, so this shouldn't require any special handling.

>4) In the standard templates, there will no doubt be a routine that 
>handles the custom fields.  If a site customizes the templates, can they 
>indicate that a field is "already done" so the routine skips a specific 
>field and leaves it to template customizations?

Yeah, that could be done via a reserved variable, or implicitly, as I
proposed earlier:

------------------------------------------------------------
<p>
  Here are some really important fields:
</p>

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

<!-- other text -->

<p>
  Here are the run-of-the-mill fields:
</p>

[% PROCESS show_custom_fields
   #  important_field_one and important_field_two are implicitly skipped,
   #  since they were already processed via the prior custom_field blocks
%]
------------------------------------------------------------

-- 
Sean McAfee -- etzwane at schwag.org


From jon at vmware.com  Tue May  6 22:07:12 2003
From: jon at vmware.com (Jonathan Schatz)
Date: 06 May 2003 15:07:12 -0700
Subject: searching on 'CC' or 'Added Comment' fields
Message-ID: <1052258832.19468.19.camel@jonschatz-lx.vmware.com>

in our installation of bugzilla (forked between 2.17.3 and 2.17.4) i've
noticed strange things when i search for email addresses and select 'CC'
or 'Commenter" along with some other field ("Submitter", for instance).

when i try this on b.m.o, i get a nice error message:

"You are searching on a combination of email fields that will not return
a result due to a bug in Bugzilla's database software. When searching on
the CC or Added comment fields, do not search on other email fields at
the same time."

great. this error doesn't occur on my installation, but the values it
returns are wrong. can anyone point me to this bug in b.m.o? does anyone
know where the bug lies? even better, anyone know when the bug was
fixed?

thanks.

-jon
-- 
Jonathan Schatz
Engineering System Administrator
VMware, Inc
"Te occidere possunt sed te edere non possunt nefas est."





From myk at mozilla.org  Tue May  6 22:06:50 2003
From: myk at mozilla.org (Myk Melez)
Date: Tue, 06 May 2003 15:06:50 -0700
Subject: searching on 'CC' or 'Added Comment' fields
In-Reply-To: <1052258832.19468.19.camel@jonschatz-lx.vmware.com>
References: <1052258832.19468.19.camel@jonschatz-lx.vmware.com>
Message-ID: <3EB831FA.80401@mozilla.org>

That's a custom b.m.o hack.  It's not wrong values that led me to 
implement that, actually, it's that those searches take so long to run 
they bog down the server.  There should be a bug on query performance 
that takes that into account; I'm not sure what the bug number is.

-myk


Jonathan Schatz wrote:

>in our installation of bugzilla (forked between 2.17.3 and 2.17.4) i've
>noticed strange things when i search for email addresses and select 'CC'
>or 'Commenter" along with some other field ("Submitter", for instance).
>
>when i try this on b.m.o, i get a nice error message:
>
>"You are searching on a combination of email fields that will not return
>a result due to a bug in Bugzilla's database software. When searching on
>the CC or Added comment fields, do not search on other email fields at
>the same time."
>
>great. this error doesn't occur on my installation, but the values it
>returns are wrong. can anyone point me to this bug in b.m.o? does anyone
>know where the bug lies? even better, anyone know when the bug was
>fixed?
>
>thanks.
>
>-jon
>  
>



From kiko at async.com.br  Tue May  6 22:10:30 2003
From: kiko at async.com.br (Christian Reis)
Date: Tue, 6 May 2003 19:10:30 -0300
Subject: Using I frame to contain the additional Comments section
In-Reply-To: <C3EB95A31BDAD511827C00B0D0F95AF574E4C4@BUCKWHEAT>; from caseyg@chsamerica.com on Fri, May 02, 2003 at 05:22:30PM -0400
References: <C3EB95A31BDAD511827C00B0D0F95AF574E4C4@BUCKWHEAT>
Message-ID: <20030506191030.H26873@blackjesus.async.com.br>

On Fri, May 02, 2003 at 05:22:30PM -0400, Casey Gregoire wrote:
> Before in the Iframe I was using a height of 60% and it worked fine, with
> the div it does not. Has anyone used <div> extensively? May you might know
> why this happens? (what did happened when I used a percentage is that the
> area was the full size of the comment block no matter what. The <div> tag is
> SUPPOSED to be able to do this.

Try playing with the position CSS property. 

Hey Justdave -- reply-to is a pain in this sort of answer. Can't we fix
the list not to provide it? You know, Reply-To munging considered
harmful? ;)

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  Tue May  6 22:19:32 2003
From: justdave at syndicomm.com (David Miller)
Date: Tue, 6 May 2003 18:19:32 -0400
Subject: Using I frame to contain the additional Comments section
In-Reply-To: <20030506191030.H26873@blackjesus.async.com.br>
References: <C3EB95A31BDAD511827C00B0D0F95AF574E4C4@BUCKWHEAT>
 <20030506191030.H26873@blackjesus.async.com.br>
Message-ID: <a05210507badde4f60782@[192.168.1.203]>

On 5/6/2003 7:10 PM -0300, Christian Reis wrote:

> Hey Justdave -- reply-to is a pain in this sort of answer. Can't we fix
> the list not to provide it? You know, Reply-To munging considered
> harmful? ;)

No, because this is a community discussion list and replies are supposed to
go to the list.  We have so much trouble with that on mozilla-webtools I
don't even want to think about trying it here.  I *hate* lists that don't
reply to the list because you have to either a) change the address back to
the list when you reply or b) reply-to-all.  I hate being the recipient of
a reply-to-all because that means I have to read it twice (once in the copy
sent to me, and once in the copy sent to the list).  I get enough mail
already, I don't need that.
-- 
Dave Miller      Project Leader, Bugzilla Bug Tracking System
http://www.justdave.net/             http://www.bugzilla.org/


From gerv at mozilla.org  Tue May  6 22:43:36 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Tue, 06 May 2003 23:43:36 +0100
Subject: Latest custom field revisions
In-Reply-To: <3EB7CA1B.6030704@peshkin.net>
References: <20030506072929.474A1BCDB@diggity.schwag.org> <3EB7CA1B.6030704@peshkin.net>
Message-ID: <3EB83A98.2030304@mozilla.org>

Joel Peshkin wrote:
> 1) What happens when a bug is moved to a product on which the custom 
> field is not relevent and then is subsequently moved to a product where 
> it is?  (I suggest that the field be made invisible while in the product 
> where it is not irrelevent but not lost)

We already have an intermediate screen for moving between products; this 
should provide a warning that, if the operation is completed, the values 
of custom fields X, Y and Z will be lost.

> 2) Which name is used for the activity log?

Er... it's the same activity log as the normal one. Or, if you mean, 
what is the label in the "What" column, it should be the display name 
for the custom field.

> 3) What happens to the activity log on field rename?  (It should stay 
> consistent)

I would suppose that the name used would be the current display name 
corresponding to that field. So if you change a field to do something 
totally different, the activity log will look weird. So don't do 
anything that dumb.

> 4) In the standard templates, there will no doubt be a routine that 
> handles the custom fields.  If a site customizes the templates, can they 
> indicate that a field is "already done" so the routine skips a specific 
> field and leaves it to template customizations?

I think several people have already solved this one on the list :-)

Gerv



From gerv at mozilla.org  Tue May  6 22:49:12 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Tue, 06 May 2003 23:49:12 +0100
Subject: Using I frame to contain the additional Comments section
In-Reply-To: <20030506191030.H26873@blackjesus.async.com.br>
References: <C3EB95A31BDAD511827C00B0D0F95AF574E4C4@BUCKWHEAT> <20030506191030.H26873@blackjesus.async.com.br>
Message-ID: <3EB83BE8.6010909@mozilla.org>

Christian Reis wrote:
> On Fri, May 02, 2003 at 05:22:30PM -0400, Casey Gregoire wrote:
> 
>>Before in the Iframe I was using a height of 60% and it worked fine, with
>>the div it does not. Has anyone used <div> extensively? May you might know
>>why this happens? (what did happened when I used a percentage is that the
>>area was the full size of the comment block no matter what. The <div> tag is
>>SUPPOSED to be able to do this.
> 
> Try playing with the position CSS property. 
> 
> Hey Justdave -- reply-to is a pain in this sort of answer.

Why? I found that interesting and informative (although you could have 
given him, and us, a bit more of a clue :-)

Gerv




From bbaetz at acm.org  Tue May  6 23:53:38 2003
From: bbaetz at acm.org (Bradley Baetz)
Date: Wed, 7 May 2003 09:53:38 +1000
Subject: CGI.pm note
In-Reply-To: <20030506092213.T56214@yahoo-inc.com>
References: <20030503133705.GA15024@mango.home> <20030506115149.GA2872@mango.home> <20030506092213.T56214@yahoo-inc.com>
Message-ID: <20030506235338.GA1328@mango.home>

On Tue, May 06, 2003 at 09:22:13AM -0700, Stephen Lamm wrote:
> 
> Prototypes are good when you want a function to behave like a built-in.
> They are not meant for type checking. They should probably only be
> used where needed.

I don't want it for type checking, so much as for type coersion. If the
param is a scalar, then wantarray is false, and so CGI.pm's param
routine returns undef rather than ().

Bradley


From usmlekaplan at yahoo.com  Wed May  7 15:38:45 2003
From: usmlekaplan at yahoo.com (usmle Prep)
Date: Wed, 7 May 2003 08:38:45 -0700 (PDT)
Subject: Ability to edit Custom Fields while doing Multiple bug edits
Message-ID: <20030507153845.63240.qmail@web20204.mail.yahoo.com>

Multiple bug edits in bugzilla allow to edit just the
fields that are stored in bugs tables. But we would
like to update the custom fields as well while doing
multiple bug edits.Has anyone implemented it. I know
it is very tough to accomplish it.
Thanks a lot,
Sri

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com


From etzwane at schwag.org  Wed May  7 23:41:36 2003
From: etzwane at schwag.org (Sean McAfee)
Date: Wed, 07 May 2003 19:41:36 -0400
Subject: New custom fields schema
Message-ID: <20030507234136.BDDB2BCDD@diggity.schwag.org>

Hi folks--

I've updated my custom fields schema, incorporating several changes
based on recent discussions.  I've also fixed a few unrelated errors in the
original document.  Oh, and I've added some foreign key constraints, which
are purely for documentation purposes, since MySQL doesn't enforce them
AFAIK.

Let me know what you think.  Thanks.


-- 
Sean McAfee -- etzwane at schwag.org
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: bz-cf-design.txt
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20030507/59bb32cf/attachment.txt>

From jason at pyeron.com  Wed May  7 23:52:14 2003
From: jason at pyeron.com (Jason Pyeron)
Date: Wed, 7 May 2003 19:52:14 -0400 (EDT)
Subject: New custom fields schema
In-Reply-To: <20030507234136.BDDB2BCDD@diggity.schwag.org>
Message-ID: <Pine.LNX.4.44.0305071950320.3089-100000@ns.pyerotechnics.com>

Looks good, what was the resolution on the defaults issue?

On Wed, 7 May 2003, Sean McAfee wrote:

Hi folks--

I've updated my custom fields schema, incorporating several changes
based on recent discussions.  I've also fixed a few unrelated errors in the
original document.  Oh, and I've added some foreign key constraints, which
are purely for documentation purposes, since MySQL doesn't enforce them
AFAIK.

Let me know what you think.  Thanks.




-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-                                                               -
- Jason Pyeron                   http://www.pyerotechnics.com   -
- Owner & Lead                  Pyerotechnics Development, Inc. -
- +1 410 808 6646 (c)           500 West University Parkway #1S -
- +1 410 467 2266 (f)           Baltimore, Maryland  21210-3253 -
-                                                               -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

This message is for the designated recipient only and may contain 
privileged, proprietary, or otherwise private information. If you
have received it in error, purge the message from your system and 
notify the sender immediately.  Any other use of the email by you 
is prohibited.





From etzwane at schwag.org  Thu May  8 06:43:23 2003
From: etzwane at schwag.org (Sean McAfee)
Date: Thu, 08 May 2003 02:43:23 -0400
Subject: New custom fields schema
In-Reply-To: <Pine.LNX.4.44.0305071950320.3089-100000@ns.pyerotechnics.com>
Message-ID: <20030508064323.F08E3BCDD@diggity.schwag.org>

Jason Pyeron <jason at pyeron.com> wrote:
>Looks good, what was the resolution on the defaults issue?

Defaults will be stored in the tables with bug data, with a bug_id of NULL.
I'll note it explicitly in the design doc.


-- 
Sean McAfee -- etzwane at schwag.org


From usmlekaplan at yahoo.com  Thu May  8 14:33:20 2003
From: usmlekaplan at yahoo.com (usmle Prep)
Date: Thu, 8 May 2003 07:33:20 -0700 (PDT)
Subject: How to clone an existing bugzilla database
Message-ID: <20030508143320.49988.qmail@web20207.mail.yahoo.com>

Dear developers,
I just want to retain the same data structure as
existing bugzilla database. The newly created database
should have all the products,customfields similar to
the existing database, but should n't contain any
bugs.Is it possible to achieve this.
Please let me know.
Thanks,
Srikant

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com


From bugreport at peshkin.net  Thu May  8 15:00:26 2003
From: bugreport at peshkin.net (Joel Peshkin)
Date: Thu, 08 May 2003 08:00:26 -0700
Subject: How to clone an existing bugzilla database
In-Reply-To: <20030508143320.49988.qmail@web20207.mail.yahoo.com>
References: <20030508143320.49988.qmail@web20207.mail.yahoo.com>
Message-ID: <3EBA710A.5050709@peshkin.net>

usmle Prep wrote:

>Dear developers,
>I just want to retain the same data structure as
>existing bugzilla database. The newly created database
>should have all the products,customfields similar to
>the existing database, but should n't contain any
>bugs.Is it possible to achieve this.
>Please let me know.
>Thanks,
>Srikant
>
>_
>
Sure...

Just copy the database and use SQL commands to delete all the records in 
bugs, bug_group_map, attachments, etc....

If we knew the Bugzilla version you were using, we might even be able to 
tell you the commands to use.

-Joel





From usmlekaplan at yahoo.com  Thu May  8 15:07:38 2003
From: usmlekaplan at yahoo.com (usmle Prep)
Date: Thu, 8 May 2003 08:07:38 -0700 (PDT)
Subject: How to clone an existing bugzilla database
In-Reply-To: <3EBA710A.5050709@peshkin.net>
Message-ID: <20030508150738.94309.qmail@web20210.mail.yahoo.com>


Hi Joel,
Thanks a lot for your help. We are using 2.16.1
version.
Can you please point me to the commands if you can.
Thanks,
Srikant
--- Joel Peshkin <bugreport at peshkin.net> wrote:
> usmle Prep wrote:
> 
> >Dear developers,
> >I just want to retain the same data structure as
> >existing bugzilla database. The newly created
> database
> >should have all the products,customfields similar
> to
> >the existing database, but should n't contain any
> >bugs.Is it possible to achieve this.
> >Please let me know.
> >Thanks,
> >Srikant
> >
> >_
> >
> Sure...
> 
> Just copy the database and use SQL commands to
> delete all the records in 
> bugs, bug_group_map, attachments, etc....
> 
> If we knew the Bugzilla version you were using, we
> might even be able to 
> tell you the commands to use.
> 
> -Joel
> 
> 
> 
> ----
> To view or change your list settings, click here:
>
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=usmlekaplan at yahoo.com>


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com


From caseyg at chsamerica.com  Thu May  8 15:25:09 2003
From: caseyg at chsamerica.com (Casey Gregoire)
Date: Thu, 8 May 2003 11:25:09 -0400 
Subject: CVS and Bugzilla
Message-ID: <C3EB95A31BDAD511827C00B0D0F95AF5768EA1@BUCKWHEAT>

We have our own server with CVS on it here and would like to put our changes
to Bugzilla in there. But of course there are CVS directories from the
Bugzilla CVS server. What you suggest as the best way to go about putting my
version of Bugzilla on our cvs server with out losing the CVS updating
capabilities from the Bugzilla server? Or is there just now way to do it?


Thank you,
	Casey Gregoire
	Programmer
	CHS of America
	100 1st Ave S. Suite 601
	St. Petersburg, FL 33701
	Phone - (727) 824-0800 ext 1236

Every great achievement was once impossible. -- Anonymous
I'd like to get started on time, if we can, inasmuch as we're late already.
-- Larry Gelbart
Nothing is accomplished without passion. -- My Fortune Cookie



From jon at vmware.com  Thu May  8 16:26:20 2003
From: jon at vmware.com (Jonathan Schatz)
Date: 08 May 2003 09:26:20 -0700
Subject: CVS and Bugzilla
In-Reply-To: <C3EB95A31BDAD511827C00B0D0F95AF5768EA1@BUCKWHEAT>
References: <C3EB95A31BDAD511827C00B0D0F95AF5768EA1@BUCKWHEAT>
Message-ID: <1052411180.30895.5.camel@jonschatz-lx.vmware.com>

On Thu, 2003-05-08 at 08:25, Casey Gregoire wrote:
> We have our own server with CVS on it here and would like to put our changes
> to Bugzilla in there. But of course there are CVS directories from the
> Bugzilla CVS server. What you suggest as the best way to go about putting my
> version of Bugzilla on our cvs server with out losing the CVS updating
> capabilities from the Bugzilla server? Or is there just now way to do it?

i dealt with that here (actually, i kept a bz tree and synced it with a
cvs server _and_ a p4 server).

the easiest way to do it is to maintain your code as a patch against the
cvs version. then you can do a cvs update, followed by a patch -p0 and
everything should be happy.

this is a pita though (especially when someone checks in a change that's
whitespace only), but is the only way i found to be manageable.

-jon

-- 
Jonathan Schatz
Engineering System Administrator
VMware, Inc
"Te occidere possunt sed te edere non possunt nefas est."





From gerv at mozilla.org  Thu May  8 16:47:39 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Thu, 08 May 2003 17:47:39 +0100
Subject: CVS and Bugzilla
In-Reply-To: <C3EB95A31BDAD511827C00B0D0F95AF5768EA1@BUCKWHEAT>
References: <C3EB95A31BDAD511827C00B0D0F95AF5768EA1@BUCKWHEAT>
Message-ID: <3EBA8A2B.6010201@mozilla.org>

Casey Gregoire wrote:

> We have our own server with CVS on it here and would like to put our changes
> to Bugzilla in there. But of course there are CVS directories from the
> Bugzilla CVS server. What you suggest as the best way to go about putting my
> version of Bugzilla on our cvs server with out losing the CVS updating
> capabilities from the Bugzilla server? Or is there just now way to do it?

CVS has a concept called "vendor branches" and an import command for 
just this situation.
http://www.cvshome.org/docs/manual/cvs_13.html#SEC104

Gerv



From caseyg at chsamerica.com  Thu May  8 17:59:48 2003
From: caseyg at chsamerica.com (Casey Gregoire)
Date: Thu, 8 May 2003 13:59:48 -0400 
Subject: Charts on Bugzilla
Message-ID: <C3EB95A31BDAD511827C00B0D0F95AF5768FCB@BUCKWHEAT>

I am having a problem with the reports.cgi where the chart does not get
made. Most of the time the program seems to make a gif that is zero in size.
Now the bar charts work, but the change over time charts do not. Can anyone
help me with this? To get the data collection to work I made it so the
checkduplicates.cgi does not check the login. The mining directory does
actually have the right data in it but the charts does not get made. Can
anyone help me with this? I could not find a bug that covers my problem.

Thanks,  
Casey Gregoire


From usmlekaplan at yahoo.com  Thu May  8 18:15:31 2003
From: usmlekaplan at yahoo.com (usmle Prep)
Date: Thu, 8 May 2003 11:15:31 -0700 (PDT)
Subject: Is there a test install of Bugzilla which has all the features
Message-ID: <20030508181531.95156.qmail@web20207.mail.yahoo.com>

I would like to see a test install which has on new
bug entry a cc list show up and be able to select
multiple users from cc list.
The bugzilla.org one doesn't have a cc drop down list
showing up.
We are using 2.16.1 version which does show cc drop
down list but allows to select only one user .I would
want to make it select multiple users just like the
one in edit bug form.
Thanks,
Srikant

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com


From jon at vmware.com  Thu May  8 18:32:18 2003
From: jon at vmware.com (Jonathan Schatz)
Date: 08 May 2003 11:32:18 -0700
Subject: Charts on Bugzilla
In-Reply-To: <C3EB95A31BDAD511827C00B0D0F95AF5768FCB@BUCKWHEAT>
References: <C3EB95A31BDAD511827C00B0D0F95AF5768FCB@BUCKWHEAT>
Message-ID: <1052418738.30895.24.camel@jonschatz-lx.vmware.com>

On Thu, 2003-05-08 at 10:59, Casey Gregoire wrote:
> I am having a problem with the reports.cgi where the chart does not get
> made. Most of the time the program seems to make a gif that is zero in size.
> Now the bar charts work, but the change over time charts do not. Can anyone
> help me with this? To get the data collection to work I made it so the
> checkduplicates.cgi does not check the login. The mining directory does
> actually have the right data in it but the charts does not get made. Can
> anyone help me with this? I could not find a bug that covers my problem.

http://bugzilla.mozilla.org/show_bug.cgi?id=196247

i've had the same problem on 3 different machines. i've yet to see
charting work.

-jon
-- 
Jonathan Schatz
Engineering System Administrator
VMware, Inc
"Te occidere possunt sed te edere non possunt nefas est."





From JWilmoth at starbucks.com  Thu May  8 18:31:22 2003
From: JWilmoth at starbucks.com (Jon Wilmoth)
Date: Thu, 8 May 2003 11:31:22 -0700
Subject: How to clone an existing bugzilla database
Message-ID: <E2291D136BD35647A074B1053785B05B01494880@seams042.starbucks.net>

Assuming your using mysql as a backend:

MySQL stores its data in files (.frm, .MYD, and .MYI). Each database
instance has its own directory under which the files are stored.  Note
the location of where all instances differs between versions of MySQL
(i.e. verion 3.23.52 data files are under the 'var' directory while
version 4.0.12 are under the 'data' directory). The database does it's
own in-memory caching to improve performance. In order to ensure the
files contain all the data you want them to, you need to flush the
internal cache. The Database Backups section of the MySQL manual
(http://www.mysql.com/doc/en/Backup.html) describes this in detail.

Also, the latest release of the MySQL gui client (MySQL Control Center
0.9.1 available from http://www.mysql.com/products/mysqlcc/index.html)
lets you create new db's, flush tables and manage user
permissions...very useful for BZ work.

-----Original Message-----
From: usmle Prep [mailto:usmlekaplan at yahoo.com] 
Sent: Thursday, May 08, 2003 8:08 AM
To: developers at bugzilla.org
Subject: Re: How to clone an existing bugzilla database


Hi Joel,
Thanks a lot for your help. We are using 2.16.1
version.
Can you please point me to the commands if you can.
Thanks,
Srikant
--- Joel Peshkin <bugreport at peshkin.net> wrote:
> usmle Prep wrote:
> 
> >Dear developers,
> >I just want to retain the same data structure as
> >existing bugzilla database. The newly created
> database
> >should have all the products,customfields similar
> to
> >the existing database, but should n't contain any
> >bugs.Is it possible to achieve this.
> >Please let me know.
> >Thanks,
> >Srikant
> >
> >_
> >
> Sure...
> 
> Just copy the database and use SQL commands to
> delete all the records in 
> bugs, bug_group_map, attachments, etc....
> 
> If we knew the Bugzilla version you were using, we
> might even be able to 
> tell you the commands to use.
> 
> -Joel
> 
> 
> 
> ----
> To view or change your list settings, click here:
>
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=usmlekaplan at yahoo.com>


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
----
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=jwilmoth at starbucks.com>



From dberlin at dberlin.org  Thu May  8 18:39:19 2003
From: dberlin at dberlin.org (Daniel Berlin)
Date: Thu, 8 May 2003 14:39:19 -0400
Subject: Charts on Bugzilla
In-Reply-To: <C3EB95A31BDAD511827C00B0D0F95AF5768FCB@BUCKWHEAT>
Message-ID: <60DCFA32-8184-11D7-950C-000A95A34564@dberlin.org>


On Thursday, May 8, 2003, at 01:59  PM, Casey Gregoire wrote:

> I am having a problem with the reports.cgi where the chart does not get
> made. Most of the time the program seems to make a gif that is zero in 
> size.
> Now the bar charts work, but the change over time charts do not. Can 
> anyone
> help me with this? To get the data collection to work I made it so the
> checkduplicates.cgi does not check the login. The mining directory does
> actually have the right data in it but the charts does not get made. 
> Can
> anyone help me with this? I could not find a bug that covers my 
> problem.
>

You probably have a version of libgd that supports png but not gif, and 
Chart 0.99 supports gif but not png.
I installed Chart 2.2 and forced the image type to png, and it works 
okay for me.
I used to see exactly the same problem you describe.

--Dan



From bunsterj at convergentdev.com  Thu May  8 14:44:15 2003
From: bunsterj at convergentdev.com (Jordi S. Bunster)
Date: 08 May 2003 10:44:15 -0400
Subject: Levels of specialization
Message-ID: <1052405058.3073.6.camel@devpc2>

Greetings folks.

I'm new to the list. I've recently been hired to do some small (and some
not so small) local changes to Bugzilla. Hopefully they'll let me ship
them back, if there's any use for them outside the company.

Anyway, one of their biggest gripes with it, is the fact that we need
more that just Programs-->components. What they've requested me is
infinite levels of "sub-components".

My question: Does that break Bugzilla's internal logic completely? If
yes, can anyone enlighten me as to how to minimize the damage?

Thanks in advance ...

 -- Jordi


 



From caseyg at chsamerica.com  Thu May  8 18:55:50 2003
From: caseyg at chsamerica.com (Casey Gregoire)
Date: Thu, 8 May 2003 14:55:50 -0400 
Subject: Charts on Bugzilla
Message-ID: <C3EB95A31BDAD511827C00B0D0F95AF576904D@BUCKWHEAT>

What might help me is if I could get an output of the ./checksetup.pl for
the current version of Bugzilla at Bugzilla.org since theirs is working
maybe I have a perl module that is the wrong version.

Thanks,
	Casey Gregoire

 -----Original Message-----
From: 	Jonathan Schatz [mailto:jon at vmware.com] 
Sent:	Thursday, May 08, 2003 2:32 PM
To:	developers at bugzilla.org
Subject:	Re: Charts on Bugzilla

On Thu, 2003-05-08 at 10:59, Casey Gregoire wrote:
> I am having a problem with the reports.cgi where the chart does not get
> made. Most of the time the program seems to make a gif that is zero in
size.
> Now the bar charts work, but the change over time charts do not. Can
anyone
> help me with this? To get the data collection to work I made it so the
> checkduplicates.cgi does not check the login. The mining directory does
> actually have the right data in it but the charts does not get made. Can
> anyone help me with this? I could not find a bug that covers my problem.

http://bugzilla.mozilla.org/show_bug.cgi?id=196247

i've had the same problem on 3 different machines. i've yet to see
charting work.

-jon
-- 
Jonathan Schatz
Engineering System Administrator
VMware, Inc
"Te occidere possunt sed te edere non possunt nefas est."



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


From caseyg at chsamerica.com  Thu May  8 19:09:46 2003
From: caseyg at chsamerica.com (Casey Gregoire)
Date: Thu, 8 May 2003 15:09:46 -0400 
Subject: Charts on Bugzilla
Message-ID: <C3EB95A31BDAD511827C00B0D0F95AF5769065@BUCKWHEAT>

I tried forcing it to png and gif to no avail

Thanks,
	Casey Gregoire

 -----Original Message-----
From: 	Daniel Berlin [mailto:dberlin at dberlin.org] 
Sent:	Thursday, May 08, 2003 2:39 PM
To:	developers at bugzilla.org
Subject:	Re: Charts on Bugzilla


On Thursday, May 8, 2003, at 01:59  PM, Casey Gregoire wrote:

> I am having a problem with the reports.cgi where the chart does not get
> made. Most of the time the program seems to make a gif that is zero in 
> size.
> Now the bar charts work, but the change over time charts do not. Can 
> anyone
> help me with this? To get the data collection to work I made it so the
> checkduplicates.cgi does not check the login. The mining directory does
> actually have the right data in it but the charts does not get made. 
> Can
> anyone help me with this? I could not find a bug that covers my 
> problem.
>

You probably have a version of libgd that supports png but not gif, and 
Chart 0.99 supports gif but not png.
I installed Chart 2.2 and forced the image type to png, and it works 
okay for me.
I used to see exactly the same problem you describe.

--Dan

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


From dberlin at dberlin.org  Thu May  8 19:51:39 2003
From: dberlin at dberlin.org (Daniel Berlin)
Date: Thu, 8 May 2003 15:51:39 -0400
Subject: Charts on Bugzilla
In-Reply-To: <C3EB95A31BDAD511827C00B0D0F95AF5769065@BUCKWHEAT>
Message-ID: <7BF552B0-818E-11D7-A1F2-000A95A34564@dberlin.org>

With what version of chart?

On Thursday, May 8, 2003, at 03:09  PM, Casey Gregoire wrote:

> I tried forcing it to png and gif to no avail
>
> Thanks,
> 	Casey Gregoire
>
>  -----Original Message-----
> From: 	Daniel Berlin [mailto:dberlin at dberlin.org]
> Sent:	Thursday, May 08, 2003 2:39 PM
> To:	developers at bugzilla.org
> Subject:	Re: Charts on Bugzilla
>
>
> On Thursday, May 8, 2003, at 01:59  PM, Casey Gregoire wrote:
>
>> I am having a problem with the reports.cgi where the chart does not 
>> get
>> made. Most of the time the program seems to make a gif that is zero in
>> size.
>> Now the bar charts work, but the change over time charts do not. Can
>> anyone
>> help me with this? To get the data collection to work I made it so the
>> checkduplicates.cgi does not check the login. The mining directory 
>> does
>> actually have the right data in it but the charts does not get made.
>> Can
>> anyone help me with this? I could not find a bug that covers my
>> problem.
>>
>
> You probably have a version of libgd that supports png but not gif, and
> Chart 0.99 supports gif but not png.
> I installed Chart 2.2 and forced the image type to png, and it works
> okay for me.
> I used to see exactly the same problem you describe.
>
> --Dan
>
> ----
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=caseyg at chsamerica.com>
> ----
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=dberlin at dberlin.org>



From caseyg at chsamerica.com  Thu May  8 19:50:53 2003
From: caseyg at chsamerica.com (Casey Gregoire)
Date: Thu, 8 May 2003 15:50:53 -0400 
Subject: Charts on Bugzilla
Message-ID: <C3EB95A31BDAD511827C00B0D0F95AF576909A@BUCKWHEAT>

AH HA! I changed to chart 2.2, I forgot that I had still been using the old
version, WORKS GREAT NOW THANKS!

Thanks,
	Casey Gregoire

 -----Original Message-----
From: 	Casey Gregoire [mailto:caseyg at chsamerica.com] 
Sent:	Thursday, May 08, 2003 3:10 PM
To:	developers at bugzilla.org
Subject:	Re: Charts on Bugzilla

I tried forcing it to png and gif to no avail

Thanks,
	Casey Gregoire

 -----Original Message-----
From: 	Daniel Berlin [mailto:dberlin at dberlin.org] 
Sent:	Thursday, May 08, 2003 2:39 PM
To:	developers at bugzilla.org
Subject:	Re: Charts on Bugzilla


On Thursday, May 8, 2003, at 01:59  PM, Casey Gregoire wrote:

> I am having a problem with the reports.cgi where the chart does not get
> made. Most of the time the program seems to make a gif that is zero in 
> size.
> Now the bar charts work, but the change over time charts do not. Can 
> anyone
> help me with this? To get the data collection to work I made it so the
> checkduplicates.cgi does not check the login. The mining directory does
> actually have the right data in it but the charts does not get made. 
> Can
> anyone help me with this? I could not find a bug that covers my 
> problem.
>

You probably have a version of libgd that supports png but not gif, and 
Chart 0.99 supports gif but not png.
I installed Chart 2.2 and forced the image type to png, and it works 
okay for me.
I used to see exactly the same problem you describe.

--Dan

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


From usmlekaplan at yahoo.com  Thu May  8 20:10:21 2003
From: usmlekaplan at yahoo.com (usmle Prep)
Date: Thu, 8 May 2003 13:10:21 -0700 (PDT)
Subject: How to clone an existing bugzilla database
In-Reply-To: <E2291D136BD35647A074B1053785B05B01494880@seams042.starbucks.net>
Message-ID: <20030508201021.66343.qmail@web20206.mail.yahoo.com>

Thanks  a  lot!!!
--- Jon Wilmoth <JWilmoth at starbucks.com> wrote:
> Assuming your using mysql as a backend:
> 
> MySQL stores its data in files (.frm, .MYD, and
> .MYI). Each database
> instance has its own directory under which the files
> are stored.  Note
> the location of where all instances differs between
> versions of MySQL
> (i.e. verion 3.23.52 data files are under the 'var'
> directory while
> version 4.0.12 are under the 'data' directory). The
> database does it's
> own in-memory caching to improve performance. In
> order to ensure the
> files contain all the data you want them to, you
> need to flush the
> internal cache. The Database Backups section of the
> MySQL manual
> (http://www.mysql.com/doc/en/Backup.html) describes
> this in detail.
> 
> Also, the latest release of the MySQL gui client
> (MySQL Control Center
> 0.9.1 available from
> http://www.mysql.com/products/mysqlcc/index.html)
> lets you create new db's, flush tables and manage
> user
> permissions...very useful for BZ work.
> 
> -----Original Message-----
> From: usmle Prep [mailto:usmlekaplan at yahoo.com] 
> Sent: Thursday, May 08, 2003 8:08 AM
> To: developers at bugzilla.org
> Subject: Re: How to clone an existing bugzilla
> database
> 
> 
> Hi Joel,
> Thanks a lot for your help. We are using 2.16.1
> version.
> Can you please point me to the commands if you can.
> Thanks,
> Srikant
> --- Joel Peshkin <bugreport at peshkin.net> wrote:
> > usmle Prep wrote:
> > 
> > >Dear developers,
> > >I just want to retain the same data structure as
> > >existing bugzilla database. The newly created
> > database
> > >should have all the products,customfields similar
> > to
> > >the existing database, but should n't contain any
> > >bugs.Is it possible to achieve this.
> > >Please let me know.
> > >Thanks,
> > >Srikant
> > >
> > >_
> > >
> > Sure...
> > 
> > Just copy the database and use SQL commands to
> > delete all the records in 
> > bugs, bug_group_map, attachments, etc....
> > 
> > If we knew the Bugzilla version you were using, we
> > might even be able to 
> > tell you the commands to use.
> > 
> > -Joel
> > 
> > 
> > 
> > ----
> > To view or change your list settings, click here:
> >
>
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=usmlekaplan at yahoo.com>
> 
> 
> __________________________________
> Do you Yahoo!?
> The New Yahoo! Search - Faster. Easier. Bingo.
> http://search.yahoo.com
> ----
> To view or change your list settings, click here:
>
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=jwilmoth at starbucks.com>
> 
> ----
> To view or change your list settings, click here:
>
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=usmlekaplan at yahoo.com>


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com


From caseyg at chsamerica.com  Thu May  8 20:05:36 2003
From: caseyg at chsamerica.com (Casey Gregoire)
Date: Thu, 8 May 2003 16:05:36 -0400 
Subject: Charts on Bugzilla
Message-ID: <C3EB95A31BDAD511827C00B0D0F95AF57690AE@BUCKWHEAT>

When the chart graphs the bugs I get Bug Counts 10.000 - 80.000, how would I
get rid of the 3 decimal precision? 

Thanks,
	Casey Gregoire

 -----Original Message-----
From: 	Casey Gregoire [mailto:caseyg at chsamerica.com] 
Sent:	Thursday, May 08, 2003 3:51 PM
To:	developers at bugzilla.org
Subject:	Re: Charts on Bugzilla

AH HA! I changed to chart 2.2, I forgot that I had still been using the old
version, WORKS GREAT NOW THANKS!

Thanks,
	Casey Gregoire

 -----Original Message-----
From: 	Casey Gregoire [mailto:caseyg at chsamerica.com] 
Sent:	Thursday, May 08, 2003 3:10 PM
To:	developers at bugzilla.org
Subject:	Re: Charts on Bugzilla

I tried forcing it to png and gif to no avail

Thanks,
	Casey Gregoire

 -----Original Message-----
From: 	Daniel Berlin [mailto:dberlin at dberlin.org] 
Sent:	Thursday, May 08, 2003 2:39 PM
To:	developers at bugzilla.org
Subject:	Re: Charts on Bugzilla


On Thursday, May 8, 2003, at 01:59  PM, Casey Gregoire wrote:

> I am having a problem with the reports.cgi where the chart does not get
> made. Most of the time the program seems to make a gif that is zero in 
> size.
> Now the bar charts work, but the change over time charts do not. Can 
> anyone
> help me with this? To get the data collection to work I made it so the
> checkduplicates.cgi does not check the login. The mining directory does
> actually have the right data in it but the charts does not get made. 
> Can
> anyone help me with this? I could not find a bug that covers my 
> problem.
>

You probably have a version of libgd that supports png but not gif, and 
Chart 0.99 supports gif but not png.
I installed Chart 2.2 and forced the image type to png, and it works 
okay for me.
I used to see exactly the same problem you describe.

--Dan

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


From caseyg at chsamerica.com  Thu May  8 20:15:58 2003
From: caseyg at chsamerica.com (Casey Gregoire)
Date: Thu, 8 May 2003 16:15:58 -0400 
Subject: Charts on Bugzilla
Message-ID: <C3EB95A31BDAD511827C00B0D0F95AF57690BD@BUCKWHEAT>

Yet another stupid question, I apologize, right in front of me again.

Thanks,
	Casey Gregoire

 -----Original Message-----
From: 	Casey Gregoire [mailto:caseyg at chsamerica.com] 
Sent:	Thursday, May 08, 2003 4:06 PM
To:	developers at bugzilla.org
Subject:	Re: Charts on Bugzilla

When the chart graphs the bugs I get Bug Counts 10.000 - 80.000, how would I
get rid of the 3 decimal precision? 

Thanks,
	Casey Gregoire

 -----Original Message-----
From: 	Casey Gregoire [mailto:caseyg at chsamerica.com] 
Sent:	Thursday, May 08, 2003 3:51 PM
To:	developers at bugzilla.org
Subject:	Re: Charts on Bugzilla

AH HA! I changed to chart 2.2, I forgot that I had still been using the old
version, WORKS GREAT NOW THANKS!

Thanks,
	Casey Gregoire

 -----Original Message-----
From: 	Casey Gregoire [mailto:caseyg at chsamerica.com] 
Sent:	Thursday, May 08, 2003 3:10 PM
To:	developers at bugzilla.org
Subject:	Re: Charts on Bugzilla

I tried forcing it to png and gif to no avail

Thanks,
	Casey Gregoire

 -----Original Message-----
From: 	Daniel Berlin [mailto:dberlin at dberlin.org] 
Sent:	Thursday, May 08, 2003 2:39 PM
To:	developers at bugzilla.org
Subject:	Re: Charts on Bugzilla


On Thursday, May 8, 2003, at 01:59  PM, Casey Gregoire wrote:

> I am having a problem with the reports.cgi where the chart does not get
> made. Most of the time the program seems to make a gif that is zero in 
> size.
> Now the bar charts work, but the change over time charts do not. Can 
> anyone
> help me with this? To get the data collection to work I made it so the
> checkduplicates.cgi does not check the login. The mining directory does
> actually have the right data in it but the charts does not get made. 
> Can
> anyone help me with this? I could not find a bug that covers my 
> problem.
>

You probably have a version of libgd that supports png but not gif, and 
Chart 0.99 supports gif but not png.
I installed Chart 2.2 and forced the image type to png, and it works 
okay for me.
I used to see exactly the same problem you describe.

--Dan

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


From jon at vmware.com  Thu May  8 20:28:55 2003
From: jon at vmware.com (Jonathan Schatz)
Date: 08 May 2003 13:28:55 -0700
Subject: Charts on Bugzilla
In-Reply-To: <C3EB95A31BDAD511827C00B0D0F95AF576909A@BUCKWHEAT>
References: <C3EB95A31BDAD511827C00B0D0F95AF576909A@BUCKWHEAT>
Message-ID: <1052425735.30895.26.camel@jonschatz-lx.vmware.com>

On Thu, 2003-05-08 at 12:50, Casey Gregoire wrote:
> AH HA! I changed to chart 2.2, I forgot that I had still been using the old
> version, WORKS GREAT NOW THANKS!

ok, now reports.cgi works for me too.

can we bump up the required version of Chart to 2.2 in checksetup.pl?

-jon
-- 
Jonathan Schatz
Engineering System Administrator
VMware, Inc
"Te occidere possunt sed te edere non possunt nefas est."





From caseyg at chsamerica.com  Thu May  8 20:34:30 2003
From: caseyg at chsamerica.com (Casey Gregoire)
Date: Thu, 8 May 2003 16:34:30 -0400 
Subject: CVS and Bugzilla
Message-ID: <C3EB95A31BDAD511827C00B0D0F95AF57690CD@BUCKWHEAT>

If I do this import do I have to remove the CVS directories from the
Bugzilla tree or not?

Thanks,
	Casey Gregoire

 -----Original Message-----
From: 	Gervase Markham [mailto:gerv at mozilla.org] 
Sent:	Thursday, May 08, 2003 12:48 PM
To:	developers at bugzilla.org
Subject:	Re: CVS and Bugzilla

Casey Gregoire wrote:

> We have our own server with CVS on it here and would like to put our
changes
> to Bugzilla in there. But of course there are CVS directories from the
> Bugzilla CVS server. What you suggest as the best way to go about putting
my
> version of Bugzilla on our cvs server with out losing the CVS updating
> capabilities from the Bugzilla server? Or is there just now way to do it?

CVS has a concept called "vendor branches" and an import command for 
just this situation.
http://www.cvshome.org/docs/manual/cvs_13.html#SEC104

Gerv

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


From dberlin at dberlin.org  Thu May  8 20:55:20 2003
From: dberlin at dberlin.org (Daniel Berlin)
Date: Thu, 8 May 2003 16:55:20 -0400
Subject: Charts on Bugzilla
In-Reply-To: <C3EB95A31BDAD511827C00B0D0F95AF576909A@BUCKWHEAT>
Message-ID: <613C1305-8197-11D7-A58C-000A95A34564@dberlin.org>

NP.
It took me a while to guess the real problem here, because even if you 
turn on all the debug info, you still don't see the real error, because 
it gets output into the image source data (causing the image to appear 
broken, since it's not really a valid GIF file).
Cute, no?

On Thursday, May 8, 2003, at 03:50  PM, Casey Gregoire wrote:

> AH HA! I changed to chart 2.2, I forgot that I had still been using 
> the old
> version, WORKS GREAT NOW THANKS!
>
> Thanks,
> 	Casey Gregoire
>
>  -----Original Message-----
> From: 	Casey Gregoire [mailto:caseyg at chsamerica.com]
> Sent:	Thursday, May 08, 2003 3:10 PM
> To:	developers at bugzilla.org
> Subject:	Re: Charts on Bugzilla
>
> I tried forcing it to png and gif to no avail
>
> Thanks,
> 	Casey Gregoire
>
>  -----Original Message-----
> From: 	Daniel Berlin [mailto:dberlin at dberlin.org]
> Sent:	Thursday, May 08, 2003 2:39 PM
> To:	developers at bugzilla.org
> Subject:	Re: Charts on Bugzilla
>
>
> On Thursday, May 8, 2003, at 01:59  PM, Casey Gregoire wrote:
>
>> I am having a problem with the reports.cgi where the chart does not 
>> get
>> made. Most of the time the program seems to make a gif that is zero in
>> size.
>> Now the bar charts work, but the change over time charts do not. Can
>> anyone
>> help me with this? To get the data collection to work I made it so the
>> checkduplicates.cgi does not check the login. The mining directory 
>> does
>> actually have the right data in it but the charts does not get made.
>> Can
>> anyone help me with this? I could not find a bug that covers my
>> problem.
>>
>
> You probably have a version of libgd that supports png but not gif, and
> Chart 0.99 supports gif but not png.
> I installed Chart 2.2 and forced the image type to png, and it works
> okay for me.
> I used to see exactly the same problem you describe.
>
> --Dan
>
> ----
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=caseyg at chsamerica.com>
> ----
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=caseyg at chsamerica.com>
> ----
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=dberlin at dberlin.org>



From caseyg at chsamerica.com  Thu May  8 20:53:25 2003
From: caseyg at chsamerica.com (Casey Gregoire)
Date: Thu, 8 May 2003 16:53:25 -0400 
Subject: Charts on Bugzilla
Message-ID: <C3EB95A31BDAD511827C00B0D0F95AF57690E2@BUCKWHEAT>

Programming would be easy if every error was easy to find no?

Thanks,
	Casey Gregoire

 -----Original Message-----
From: 	Daniel Berlin [mailto:dberlin at dberlin.org] 
Sent:	Thursday, May 08, 2003 4:55 PM
To:	developers at bugzilla.org
Subject:	Re: Charts on Bugzilla

NP.
It took me a while to guess the real problem here, because even if you 
turn on all the debug info, you still don't see the real error, because 
it gets output into the image source data (causing the image to appear 
broken, since it's not really a valid GIF file).
Cute, no?

On Thursday, May 8, 2003, at 03:50  PM, Casey Gregoire wrote:

> AH HA! I changed to chart 2.2, I forgot that I had still been using 
> the old
> version, WORKS GREAT NOW THANKS!
>
> Thanks,
> 	Casey Gregoire
>
>  -----Original Message-----
> From: 	Casey Gregoire [mailto:caseyg at chsamerica.com]
> Sent:	Thursday, May 08, 2003 3:10 PM
> To:	developers at bugzilla.org
> Subject:	Re: Charts on Bugzilla
>
> I tried forcing it to png and gif to no avail
>
> Thanks,
> 	Casey Gregoire
>
>  -----Original Message-----
> From: 	Daniel Berlin [mailto:dberlin at dberlin.org]
> Sent:	Thursday, May 08, 2003 2:39 PM
> To:	developers at bugzilla.org
> Subject:	Re: Charts on Bugzilla
>
>
> On Thursday, May 8, 2003, at 01:59  PM, Casey Gregoire wrote:
>
>> I am having a problem with the reports.cgi where the chart does not 
>> get
>> made. Most of the time the program seems to make a gif that is zero in
>> size.
>> Now the bar charts work, but the change over time charts do not. Can
>> anyone
>> help me with this? To get the data collection to work I made it so the
>> checkduplicates.cgi does not check the login. The mining directory 
>> does
>> actually have the right data in it but the charts does not get made.
>> Can
>> anyone help me with this? I could not find a bug that covers my
>> problem.
>>
>
> You probably have a version of libgd that supports png but not gif, and
> Chart 0.99 supports gif but not png.
> I installed Chart 2.2 and forced the image type to png, and it works
> okay for me.
> I used to see exactly the same problem you describe.
>
> --Dan
>
> ----
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=caseyg at chsamerica.com>
> ----
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=caseyg at chsamerica.com>
> ----
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=dberlin at dberlin.org>

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


From gerv at mozilla.org  Thu May  8 21:50:37 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Thu, 08 May 2003 22:50:37 +0100
Subject: Levels of specialization
In-Reply-To: <1052405058.3073.6.camel@devpc2>
References: <1052405058.3073.6.camel@devpc2>
Message-ID: <3EBAD12D.4060002@mozilla.org>

Jordi S. Bunster wrote:
> Greetings folks.
> 
> I'm new to the list. I've recently been hired to do some small (and some
> not so small) local changes to Bugzilla. Hopefully they'll let me ship
> them back, if there's any use for them outside the company.
> 
> Anyway, one of their biggest gripes with it, is the fact that we need
> more that just Programs-->components. What they've requested me is
> infinite levels of "sub-components".

There is a bug on this; have a look in bugzilla.mozilla.org. No-one's 
implemented it; but I seem to remember from last time that this was 
discussed that the consensus was:

- infinite levels may be ultra-flexible, but are a nightmare to 
administer and provide sane UI for within an HTML form environment. 
Adding a third level would give you 95% of what infinite levels would.

- Said third level should probably be added above Products rather than 
below Components, for various data-integrity reasons. It would have an 
intermediate screen, like you get when you change products, if there 
were field value mismatches.

Gerv



From gerv at mozilla.org  Thu May  8 22:04:45 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Thu, 08 May 2003 23:04:45 +0100
Subject: CVS and Bugzilla
In-Reply-To: <C3EB95A31BDAD511827C00B0D0F95AF57690CD@BUCKWHEAT>
References: <C3EB95A31BDAD511827C00B0D0F95AF57690CD@BUCKWHEAT>
Message-ID: <3EBAD47D.7010204@mozilla.org>

Casey Gregoire wrote:
> If I do this import do I have to remove the CVS directories from the
> Bugzilla tree or not?

[Could you please bottom-post and trim? It makes threads of conversation 
much easier to follow. Thanks.]

I don't know how CVS import works; I'm afraid you are going to have to 
RTFlippingM :-)

Gerv



From jmcwill at crystalball.com  Thu May  8 22:04:41 2003
From: jmcwill at crystalball.com (Jason McWilliams)
Date: Thu, 8 May 2003 16:04:41 -0600
Subject: Levels of specialization
In-Reply-To: <3EBAD12D.4060002@mozilla.org>
Message-ID: <004501c315ad$d42b7850$4301a8c0@JMCWILL2K>

I have implemented "sub-components" to a certain degree.
It involved adding a new table and a foriegn key.  Then
hacking up a bunch of code.  Its in a test environment,
and not sure if it will actually ever be used.

The problem is, it takes a lot of hacking and some major
UI changes.  I did not add it to the admin add product
or to the multiple edit screens.

Everywhere you something happens to component or product,
its likely you have to do the same.  I would not recommend
trying to do this.  Maybe someday it will be added.

I would think that Products -> Components -> Subs
would take care of most people.

Jason



> -----Original Message-----
> From: developers-owner at bugzilla.org
> [mailto:developers-owner at bugzilla.org]On Behalf Of Gervase Markham
> Sent: Thursday, May 08, 2003 3:51 PM
> To: developers at bugzilla.org
> Subject: Re: Levels of specialization
> 
> 
> Jordi S. Bunster wrote:
> > Greetings folks.
> > 
> > I'm new to the list. I've recently been hired to do some 
> small (and some
> > not so small) local changes to Bugzilla. Hopefully they'll 
> let me ship
> > them back, if there's any use for them outside the company.
> > 
> > Anyway, one of their biggest gripes with it, is the fact 
> that we need
> > more that just Programs-->components. What they've requested me is
> > infinite levels of "sub-components".
> 
> There is a bug on this; have a look in bugzilla.mozilla.org. No-one's 
> implemented it; but I seem to remember from last time that this was 
> discussed that the consensus was:
> 
> - infinite levels may be ultra-flexible, but are a nightmare to 
> administer and provide sane UI for within an HTML form environment. 
> Adding a third level would give you 95% of what infinite levels would.
> 
> - Said third level should probably be added above Products 
> rather than 
> below Components, for various data-integrity reasons. It 
> would have an 
> intermediate screen, like you get when you change products, if there 
> were field value mismatches.
> 
> Gerv
> 
> ----
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=jmcwill at crystalball.com>


From gerv at mozilla.org  Thu May  8 22:17:39 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Thu, 08 May 2003 23:17:39 +0100
Subject: Charts on Bugzilla
In-Reply-To: <60DCFA32-8184-11D7-950C-000A95A34564@dberlin.org>
References: <60DCFA32-8184-11D7-950C-000A95A34564@dberlin.org>
Message-ID: <3EBAD783.9010203@mozilla.org>

Daniel Berlin wrote:
> You probably have a version of libgd that supports png but not gif, and 
> Chart 0.99 supports gif but not png.

That's not true; I get excellent PNGs on reports.cgi with 0.99.

Could all those people for whom reports.cgi is working please run 
checksetup.pl and post the correct snippet of their checksetup.pl output 
to the following bug:
http://bugzilla.mozilla.org/show_bug.cgi?id=204939

That way, we should be able to narrow down exactly which versions work.

Gerv



From gerv at mozilla.org  Thu May  8 22:17:43 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Thu, 08 May 2003 23:17:43 +0100
Subject: Charts on Bugzilla
In-Reply-To: <613C1305-8197-11D7-A58C-000A95A34564@dberlin.org>
References: <613C1305-8197-11D7-A58C-000A95A34564@dberlin.org>
Message-ID: <3EBAD787.8050805@mozilla.org>

Daniel Berlin wrote:
> NP.
> It took me a while to guess the real problem here, because even if you 
> turn on all the debug info, you still don't see the real error, because 
> it gets output into the image source data (causing the image to appear 
> broken, since it's not really a valid GIF file).

If you are looking at the new reports, you can add "&debug=1" to the URL 
to get a text/html content type and avoid this problem. :-) For the old 
charts, you're stuck.

Gerv



From dberlin at dberlin.org  Fri May  9 04:03:15 2003
From: dberlin at dberlin.org (Daniel Berlin)
Date: Fri, 9 May 2003 00:03:15 -0400
Subject: Charts on Bugzilla
In-Reply-To: <3EBAD783.9010203@mozilla.org>
Message-ID: <2907D44A-81D3-11D7-8BEB-000A95A34564@dberlin.org>


On Thursday, May 8, 2003, at 06:17  PM, Gervase Markham wrote:

> Daniel Berlin wrote:
>> You probably have a version of libgd that supports png but not gif, 
>> and Chart 0.99 supports gif but not png.
>
> That's not true; I get excellent PNGs on reports.cgi with 0.99.
>
That's simply impossible, sorry.

Please look at the readme to Chart past 1.0, and you'll see:
0.99c-pre3 - 1.0:
         Fixed _draw_data in Lines.pm: lines are limited to the frame
         Added f_x_tick, f_y_tick
         Added jpeg(), cgi_jpeg() to produce the format jpeg
         Delete GIF support, added PNG and JPEG instead


Prior to somewhere in between these versions, there was no PNG support.
Try grepping for png in 0.99, 0.99a, 0.99b, and you'll see it's nowhere 
in the sources.
0.99 (and 0.99a and 0.99b) can't output PNG.

You don't really have 0.99 if you are getting PNG's, or you aren't 
getting PNGs.



From etzwane at schwag.org  Fri May  9 06:50:01 2003
From: etzwane at schwag.org (Sean McAfee)
Date: Fri, 09 May 2003 02:50:01 -0400
Subject: Custom fields design doc
Message-ID: <20030509065001.B47ABBCDC@diggity.schwag.org>

Hi folks--

Attached is my custom fields design document, or at least what I've
completed of it so far.  It cuts off abruptly in the middle of describing
editcustomfields.cgi, but I think enough of the basic groundwork has been
laid to make it worth posting for comments.  If you have any, I'd appreciate
hearing 'em.  Thanks.


-- 
Sean McAfee -- etzwane at schwag.org
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: bz-cf-design.txt
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20030509/9a50731a/attachment.txt>

From gerv at mozilla.org  Fri May  9 07:56:55 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Fri, 09 May 2003 08:56:55 +0100
Subject: Charts on Bugzilla
In-Reply-To: <2907D44A-81D3-11D7-8BEB-000A95A34564@dberlin.org>
References: <2907D44A-81D3-11D7-8BEB-000A95A34564@dberlin.org>
Message-ID: <3EBB5F47.7010904@mozilla.org>

Daniel Berlin wrote:
> On Thursday, May 8, 2003, at 06:17  PM, Gervase Markham wrote:
>> That's not true; I get excellent PNGs on reports.cgi with 0.99.
>>
> That's simply impossible, sorry.

Well, Mozilla says they are PNGs, and my checksetup.pl says:

The following Perl modules are optional:
Checking for              GD (v1.20)   ok: found v1.40
Checking for     Chart::Base (v0.99)   ok: found v0.99
Checking for     XML::Parser (any)      not found
Checking for       GD::Graph (any)     ok: found v1.35
Checking for GD::Text::Align (any)     ok: found v1

> Please look at the readme to Chart past 1.0, and you'll see:
> 0.99c-pre3 - 1.0:
>         Fixed _draw_data in Lines.pm: lines are limited to the frame
>         Added f_x_tick, f_y_tick
>         Added jpeg(), cgi_jpeg() to produce the format jpeg
>         Delete GIF support, added PNG and JPEG instead

This doesn't imply that the two halves of the sentence happened in the 
same release in the quoted range.

> Prior to somewhere in between these versions, there was no PNG support.
> Try grepping for png in 0.99, 0.99a, 0.99b, and you'll see it's nowhere 
> in the sources.
> 0.99 (and 0.99a and 0.99b) can't output PNG.

0.99c can, though.

My copy of Chart/Base.pm has $Chart::Base::VERSION = 0.99, and 
references to PNG all over the code, and none to GIF.

Gerv



From jth at mikrobitti.fi  Fri May  9 08:06:32 2003
From: jth at mikrobitti.fi (Jouni Heikniemi)
Date: Fri, 09 May 2003 11:06:32 +0300
Subject: CVS and Bugzilla
In-Reply-To: <C3EB95A31BDAD511827C00B0D0F95AF57690CD@BUCKWHEAT>
Message-ID: <5.1.0.14.2.20030509105949.033c9608@mikrobitti.fi>

At 16:34 8.5.2003 -0400, you wrote:
>If I do this import do I have to remove the CVS directories from the
>Bugzilla tree or not?

They will be ignored on import, so you don't have to remove them. Just use

cvs -d [your cvsroot here] import bugzilla whatever tag

I've been using the setup you've been talking about for quite some time. It 
works fine, but do take my word for this: You will want to be well 
proficient with the interesting "features" of vendor branches before 
getting involved with your first upgrade and merge.

There is the alternative of using a normal branch instead of a vendor one. 
You lose something but you also gain something. Picking the correct 
solution depends on how much you're going to customize, how long can you 
stay in a state of freeze when upgrading your BZ and how good a conflict 
solver you are ;-) Read 
<http://mail.gnu.org/archive/html/info-cvs/2002-05/msg00374.html> for some 
ideas.


Jouni




From dberlin at dberlin.org  Fri May  9 11:30:32 2003
From: dberlin at dberlin.org (Daniel Berlin)
Date: Fri, 9 May 2003 07:30:32 -0400
Subject: Charts on Bugzilla
In-Reply-To: <3EBB5F47.7010904@mozilla.org>
Message-ID: <A506B20E-8211-11D7-AC32-000A95A34564@dberlin.org>


On Friday, May 9, 2003, at 03:56  AM, Gervase Markham wrote:

> Daniel Berlin wrote:
>> On Thursday, May 8, 2003, at 06:17  PM, Gervase Markham wrote:
>>> That's not true; I get excellent PNGs on reports.cgi with 0.99.
>>>
>> That's simply impossible, sorry.
>
> Well, Mozilla says they are PNGs, and my checksetup.pl says:
>
> The following Perl modules are optional:
> Checking for              GD (v1.20)   ok: found v1.40
> Checking for     Chart::Base (v0.99)   ok: found v0.99
> Checking for     XML::Parser (any)      not found
> Checking for       GD::Graph (any)     ok: found v1.35
> Checking for GD::Text::Align (any)     ok: found v1
>
>> Please look at the readme to Chart past 1.0, and you'll see:
>> 0.99c-pre3 - 1.0:
>>         Fixed _draw_data in Lines.pm: lines are limited to the frame
>>         Added f_x_tick, f_y_tick
>>         Added jpeg(), cgi_jpeg() to produce the format jpeg
>>         Delete GIF support, added PNG and JPEG instead
>
> This doesn't imply that the two halves of the sentence happened in the 
> same release in the quoted range.
>
Granted.

>> Prior to somewhere in between these versions, there was no PNG 
>> support.
>> Try grepping for png in 0.99, 0.99a, 0.99b, and you'll see it's 
>> nowhere in the sources.
>> 0.99 (and 0.99a and 0.99b) can't output PNG.
>
> 0.99c can, though.
>
> My copy of Chart/Base.pm has $Chart::Base::VERSION = 0.99, and 
> references to PNG all over the code, and none to GIF.

Then you have 99c.
I grepped 99b, and no references to png.
The real problem here then, I guess, is that they are all identified as 
0.99.
Seems a bit braindead to make such a change without bumping the base 
version.

--Dan



From caseyg at chsamerica.com  Fri May  9 12:32:12 2003
From: caseyg at chsamerica.com (Casey Gregoire)
Date: Fri, 9 May 2003 08:32:12 -0400 
Subject: Charts on Bugzilla
Message-ID: <C3EB95A31BDAD511827C00B0D0F95AF57691C0@BUCKWHEAT>



-----Original Message-----
From: Gervase Markham [mailto:gerv at mozilla.org]
Sent: Friday, May 09, 2003 3:57 AM
To: developers at bugzilla.org
Subject: Re: Charts on Bugzilla

Daniel Berlin wrote:
> On Thursday, May 8, 2003, at 06:17  PM, Gervase Markham wrote:
>> That's not true; I get excellent PNGs on reports.cgi with 0.99.
>>
> That's simply impossible, sorry.

Well, Mozilla says they are PNGs, and my checksetup.pl says:

The following Perl modules are optional:
Checking for              GD (v1.20)   ok: found v1.40
Checking for     Chart::Base (v0.99)   ok: found v0.99
Checking for     XML::Parser (any)      not found
Checking for       GD::Graph (any)     ok: found v1.35
Checking for GD::Text::Align (any)     ok: found v1

> Please look at the readme to Chart past 1.0, and you'll see:
> 0.99c-pre3 - 1.0:
>         Fixed _draw_data in Lines.pm: lines are limited to the frame
>         Added f_x_tick, f_y_tick
>         Added jpeg(), cgi_jpeg() to produce the format jpeg
>         Delete GIF support, added PNG and JPEG instead

This doesn't imply that the two halves of the sentence happened in the
same release in the quoted range.

> Prior to somewhere in between these versions, there was no PNG support.
> Try grepping for png in 0.99, 0.99a, 0.99b, and you'll see it's nowhere
> in the sources.
> 0.99 (and 0.99a and 0.99b) can't output PNG.

0.99c can, though.

My copy of Chart/Base.pm has $Chart::Base::VERSION = 0.99, and
references to PNG all over the code, and none to GIF.

Gerv

----

Well I was using 0.99b originally, so that must have been it. But I am
happier to have the newest version anyhow, and it works which all I am
concerned with.



Thanks,
	Casey Gregoire



From usmlekaplan at yahoo.com  Fri May  9 15:12:50 2003
From: usmlekaplan at yahoo.com (usmle Prep)
Date: Fri, 9 May 2003 08:12:50 -0700 (PDT)
Subject: What can be cause of slow perfomance on 2.16.1 version
Message-ID: <20030509151250.94778.qmail@web20208.mail.yahoo.com>

When I submit a bug, I am receiving an e-mail
notification that the bug is submitted, but the
post_bug.cgi shows up only after some time in the
browser.
The same thing happens even when I modify the bug, I
recive the e-mail even before the proces_bug.cgi shows
up  inthe browser.
What could be wrong.Any guessed would be very helpful.
Thanks a lot,
Sri

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com


From jacqui at groxis.com  Fri May  9 15:36:10 2003
From: jacqui at groxis.com (Jacqui Guerrero)
Date: Fri, 09 May 2003 08:36:10 -0700
Subject: buglist.cgi
Message-ID: <GAEGLHGNMKMDDJAHAHGOAEECCEAA.jacqui@groxis.com>

Hi,

I am trying to modify buglist.cgi such that certain users can only view and
submit bugs for a specific product.  If I have usebuggroups and
usebuggroupsentry on, is the product considered a group?  If so, how do I
use UserInGroup to check for the product that the user has access to?

Thanks,
Jacqueline Guerrero

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20030509/00653974/attachment.html>

From bugreport at peshkin.net  Fri May  9 18:04:24 2003
From: bugreport at peshkin.net (Joel Peshkin)
Date: Fri, 09 May 2003 11:04:24 -0700
Subject: What can be cause of slow perfomance on 2.16.1 version
In-Reply-To: <20030509151250.94778.qmail@web20208.mail.yahoo.com>
References: <20030509151250.94778.qmail@web20208.mail.yahoo.com>
Message-ID: <3EBBEDA8.7010600@peshkin.net>

usmle Prep wrote:

>When I submit a bug, I am receiving an e-mail
>notification that the bug is submitted, but the
>post_bug.cgi shows up only after some time in the
>browser.
><SNIP>
>
Try invoking sendmail -v <addresses> manually from the command line and 
sending a message to the same list of users Bugzilla is trying to notify.
If sendmail takes a long time to complete its work and come back that 
would be the culprit.  If that is the case, my best guess on a root 
cause would be if your sendmail is waiting for DNS to timeout before 
trying anohter way to resolve an address.

-Joel






From bugreport at peshkin.net  Fri May  9 18:23:12 2003
From: bugreport at peshkin.net (Joel Peshkin)
Date: Fri, 09 May 2003 11:23:12 -0700
Subject: buglist.cgi
In-Reply-To: <GAEGLHGNMKMDDJAHAHGOAEECCEAA.jacqui@groxis.com>
References: <GAEGLHGNMKMDDJAHAHGOAEECCEAA.jacqui@groxis.com>
Message-ID: <3EBBF210.5010601@peshkin.net>

Jacqui Guerrero wrote:

> I am trying to modify buglist.cgi such that certain users can only 
> view and submit bugs for a specific product.  If I have usebuggroups 
> and usebuggroupsentry on, is the product considered a group?  If so, 
> how do I  use UserInGroup to check for the product that the user has 
> access to?

What you are trying to do happens automatically if you use usebuggroups 
and usebuggroupsentry on and you make sure that you either create the 
products after those 2 features are enabled or else make sure there is a 
group named EXACTLY the same as each product.

If you need more protection than that (more control),  you need to use 
2.17.4

You really should not have to do customizations yourself using 
UserInGroup().  If you need to do that, you need to have a very deep 
understanding of how these seurity mechanisms work.  Even when the most 
involved developers make changes in those areas, we inspect each others' 
work very carefully.

-Joel




From jacqui at groxis.com  Fri May  9 18:45:25 2003
From: jacqui at groxis.com (Jacqui Guerrero)
Date: Fri, 09 May 2003 11:45:25 -0700
Subject: buglist.cgi
In-Reply-To: <3EBBF210.5010601@peshkin.net>
Message-ID: <GAEGLHGNMKMDDJAHAHGOKEEECEAA.jacqui@groxis.com>

Okay.  I actually created the product prior to turning the usebuggroups and
usebuggroupentry bits on.  What I did now is I deleted this product and
created a new one, with a regexp for the bug group.  However, it seems that
all users in this bug group are still able to view bugs in other bug groups.
Help!

Thanks,
Jacqui

-----Original Message-----
From: developers-owner at bugzilla.org
[mailto:developers-owner at bugzilla.org]On Behalf Of Joel Peshkin
Sent: Friday, May 09, 2003 11:23 AM
To: developers at bugzilla.org
Subject: Re: buglist.cgi


Jacqui Guerrero wrote:

> I am trying to modify buglist.cgi such that certain users can only
> view and submit bugs for a specific product.  If I have usebuggroups
> and usebuggroupsentry on, is the product considered a group?  If so,
> how do I  use UserInGroup to check for the product that the user has
> access to?

What you are trying to do happens automatically if you use usebuggroups
and usebuggroupsentry on and you make sure that you either create the
products after those 2 features are enabled or else make sure there is a
group named EXACTLY the same as each product.

If you need more protection than that (more control),  you need to use
2.17.4

You really should not have to do customizations yourself using
UserInGroup().  If you need to do that, you need to have a very deep
understanding of how these seurity mechanisms work.  Even when the most
involved developers make changes in those areas, we inspect each others'
work very carefully.

-Joel


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



From bugreport at peshkin.net  Fri May  9 19:20:26 2003
From: bugreport at peshkin.net (Joel Peshkin)
Date: Fri, 09 May 2003 12:20:26 -0700
Subject: buglist.cgi
In-Reply-To: <GAEGLHGNMKMDDJAHAHGOKEEECEAA.jacqui@groxis.com>
References: <GAEGLHGNMKMDDJAHAHGOKEEECEAA.jacqui@groxis.com>
Message-ID: <3EBBFF7A.2000206@peshkin.net>

Jacqui Guerrero wrote:

>Okay.  I actually created the product prior to turning the usebuggroups and
>usebuggroupentry bits on.  What I did now is I deleted this product and
>created a new one, with a regexp for the bug group.  However, it seems that
>all users in this bug group are still able to view bugs in other bug groups.
>Help!
>  
>
You are getting there....

If a bug is in one or more groups, then the user must be in ALL of the 
groups in order to see it.  So, you need to put bugs in groups in which 
a user is not a member in order to keep the user from seeing those bugs.

-Joel




From caseyg at chsamerica.com  Fri May  9 19:37:01 2003
From: caseyg at chsamerica.com (Casey Gregoire)
Date: Fri, 9 May 2003 15:37:01 -0400 
Subject: buglist.cgi
Message-ID: <C3EB95A31BDAD511827C00B0D0F95AF577AAD6@BUCKWHEAT>

How do I make so a user can ONLY look at the bug?

Thanks,
	Casey Gregoire

-----Original Message-----
From: Joel Peshkin [mailto:bugreport at peshkin.net]
Sent: Friday, May 09, 2003 3:20 PM
To: developers at bugzilla.org
Subject: Re: buglist.cgi

Jacqui Guerrero wrote:

>Okay.  I actually created the product prior to turning the usebuggroups and
>usebuggroupentry bits on.  What I did now is I deleted this product and
>created a new one, with a regexp for the bug group.  However, it seems that
>all users in this bug group are still able to view bugs in other bug
groups.
>Help!
> 
>
You are getting there....

If a bug is in one or more groups, then the user must be in ALL of the
groups in order to see it.  So, you need to put bugs in groups in which
a user is not a member in order to keep the user from seeing those bugs.

-Joel


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


From jacqui at groxis.com  Fri May  9 19:56:39 2003
From: jacqui at groxis.com (Jacqui Guerrero)
Date: Fri, 09 May 2003 12:56:39 -0700
Subject: buglist.cgi
In-Reply-To: <3EBBFF7A.2000206@peshkin.net>
Message-ID: <GAEGLHGNMKMDDJAHAHGOIEEGCEAA.jacqui@groxis.com>

There has to be an easier way to do this.  I will have to go through our
entire list of existing bugs - 700+ and assign them to their specific
Product to be in a bug group.  Is there a way to set it such that a user in
a group can only view and submit bugs for a product?

Thanks for your help!
Jacqui

-----Original Message-----
From: developers-owner at bugzilla.org
[mailto:developers-owner at bugzilla.org]On Behalf Of Joel Peshkin
Sent: Friday, May 09, 2003 12:20 PM
To: developers at bugzilla.org
Subject: Re: buglist.cgi


Jacqui Guerrero wrote:

>Okay.  I actually created the product prior to turning the usebuggroups and
>usebuggroupentry bits on.  What I did now is I deleted this product and
>created a new one, with a regexp for the bug group.  However, it seems that
>all users in this bug group are still able to view bugs in other bug
groups.
>Help!
>
>
You are getting there....

If a bug is in one or more groups, then the user must be in ALL of the
groups in order to see it.  So, you need to put bugs in groups in which
a user is not a member in order to keep the user from seeing those bugs.

-Joel


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



From bugreport at peshkin.net  Fri May  9 20:37:33 2003
From: bugreport at peshkin.net (Joel Peshkin)
Date: Fri, 09 May 2003 13:37:33 -0700
Subject: buglist.cgi
In-Reply-To: <C3EB95A31BDAD511827C00B0D0F95AF577AAD6@BUCKWHEAT>
References: <C3EB95A31BDAD511827C00B0D0F95AF577AAD6@BUCKWHEAT>
Message-ID: <3EBC118D.2040707@peshkin.net>

Casey Gregoire wrote:

>How do I make so a user can ONLY look at the bug?
>
>Thanks,
>	Casey Gregoire
>
>  
>
Put ALL of the other bugs in groups of which that user is not a member.,

-Joel




From jacqui at groxis.com  Fri May  9 22:17:04 2003
From: jacqui at groxis.com (Jacqui Guerrero)
Date: Fri, 09 May 2003 15:17:04 -0700
Subject: buglist.cgi
In-Reply-To: <GAEGLHGNMKMDDJAHAHGOIEEGCEAA.jacqui@groxis.com>
Message-ID: <GAEGLHGNMKMDDJAHAHGOCEEICEAA.jacqui@groxis.com>

How do you add a group in the list of checkboxes under the "Only users in
the selected groups can view this bug:" heading in a bug (the one right
under Additional Comments)?  I think this might be an easier way than
reassigning all previously logged bugs to their associated products.

Thanks,
Jacqui

-----Original Message-----
From: developers-owner at bugzilla.org
[mailto:developers-owner at bugzilla.org]On Behalf Of Jacqui Guerrero
Sent: Friday, May 09, 2003 12:57 PM
To: developers at bugzilla.org
Subject: Re: buglist.cgi


There has to be an easier way to do this.  I will have to go through our
entire list of existing bugs - 700+ and assign them to their specific
Product to be in a bug group.  Is there a way to set it such that a user in
a group can only view and submit bugs for a product?

Thanks for your help!
Jacqui

-----Original Message-----
From: developers-owner at bugzilla.org
[mailto:developers-owner at bugzilla.org]On Behalf Of Joel Peshkin
Sent: Friday, May 09, 2003 12:20 PM
To: developers at bugzilla.org
Subject: Re: buglist.cgi


Jacqui Guerrero wrote:

>Okay.  I actually created the product prior to turning the usebuggroups and
>usebuggroupentry bits on.  What I did now is I deleted this product and
>created a new one, with a regexp for the bug group.  However, it seems that
>all users in this bug group are still able to view bugs in other bug
groups.
>Help!
>
>
You are getting there....

If a bug is in one or more groups, then the user must be in ALL of the
groups in order to see it.  So, you need to put bugs in groups in which
a user is not a member in order to keep the user from seeing those bugs.

-Joel


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

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



From cjcollier at colliertech.org  Fri May  9 22:41:47 2003
From: cjcollier at colliertech.org (C.J. Collier)
Date: 09 May 2003 15:41:47 -0700
Subject: decentralization
Message-ID: <1052520106.23441.220.camel@larry.localnet>

bugzilla would do well to decentralize.  Each bugzilla server should
communicate with others.  Bug reports should be shared between projects.

For example, on bugs.debian.org bug #189211 depends on the resolution of
bug #97177 on bugzilla.gnome.org.  There is no way to have one depend on
the other, so it is not easy to tell when the bug is resolved.  Taking a
look at #189211 (bugs.debian.org) will show you a bit about the unhappy
mess this causes.

My suggestion would be to use URIs to reference bugs.  Perhaps something
like the following:

bugzilla://bugs.debian.org/?project=gnome-theme-manager&bugnumber=N

"bugnumber" would be gnome-theme-manager (on bugs.debian.org) specific. 
Global variables are bad.  I suggest some type of scoping, even if it
doesn't follow my suggestion exactly.

This would allow projects that use bugzilla to co-ordinate with the
projects that they depend on without being on the same server.

Thoughts?

C.J.




From cjcollier at colliertech.org  Fri May  9 23:02:25 2003
From: cjcollier at colliertech.org (C.J. Collier)
Date: 09 May 2003 16:02:25 -0700
Subject: Incentive
Message-ID: <1052521344.23310.237.camel@larry.localnet>

While I'm making suggestions, I suggest that bug bounties be
implemented.

I'm working on building a decentralized global karma system, and I'd
love to get it into Bugzilla.  It's still in early development, but I
think it will be a useful tool for exchange of appreciation or demarking
work that would be appreciated.

http://www.gnubucks.com/

I suggest allowing bug reporters to tack an appreciation on to the bugs
they report.  When developers mark a bug as resolved, those who attached
potential karma points to the bug in question will be contacted and
asked to verify that the bug fix works for them.  When this step is
completed, the karma points are assigned to the developer(s?) who fixed
the bug.

If the bug depends on other bugs, the assigned karma points could be
distributed down the chain.  Say bug D depends on bug C & B, where B
depends on A.  A user assigns 1000 karma points to bug D.  500 stick to
D and 250 flow to C & B each.  Since B depends on A, B keeps 125 and A
gets 125.  Thus the final application of karma points looks like this:

D: 500
C: 250
B: 125
A: 125

Of course the distribution can be tweaked.

Thoughts?

Since this is a dev mailing list, could someone tell me where to start
if I were interested in implementing this myself (which I am ;)?

Cheers,

C.J.




From gerv at mozilla.org  Fri May  9 23:11:55 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Sat, 10 May 2003 00:11:55 +0100
Subject: decentralization
In-Reply-To: <1052520106.23441.220.camel@larry.localnet>
References: <1052520106.23441.220.camel@larry.localnet>
Message-ID: <3EBC35BB.5080508@mozilla.org>

C.J. Collier wrote:
> bugzilla would do well to decentralize.  Each bugzilla server should
> communicate with others.  Bug reports should be shared between projects.
> 
> For example, on bugs.debian.org bug #189211 depends on the resolution of
> bug #97177 on bugzilla.gnome.org.

Er... bugs.debian.org is not a Bugzilla installation.

> There is no way to have one depend on
> the other, so it is not easy to tell when the bug is resolved.  Taking a
> look at #189211 (bugs.debian.org) will show you a bit about the unhappy
> mess this causes.

It would be possible, perhaps, to have a system where a bug in one 
Bugzilla could depend on one in another Bugzilla. But it would be a fair 
amount of work, if you wanted each one to notify the other of state 
changes. Is this situation really that common?

> My suggestion would be to use URIs to reference bugs.  Perhaps something
> like the following:
> 
> bugzilla://bugs.debian.org/?project=gnome-theme-manager&bugnumber=N

Or http://bugzilla.mozilla.org?show_bug.cgi?id=12345 ? :-)

> "bugnumber" would be gnome-theme-manager (on bugs.debian.org) specific. 
> Global variables are bad.  I suggest some type of scoping, even if it
> doesn't follow my suggestion exactly.

What advantage does having multiple bugs with the same number in an 
individual installation give you?

Gerv



From myk at mozilla.org  Fri May  9 23:09:02 2003
From: myk at mozilla.org (Myk Melez)
Date: Fri, 09 May 2003 16:09:02 -0700
Subject: decentralization
In-Reply-To: <1052520106.23441.220.camel@larry.localnet>
References: <1052520106.23441.220.camel@larry.localnet>
Message-ID: <3EBC350E.6020809@mozilla.org>

C.J. Collier wrote:

>bugzilla would do well to decentralize.  Each bugzilla server should
>communicate with others.  Bug reports should be shared between projects.
>  
>
Agreed.  This is bug 123130.

http://bugzilla.mozilla.org/show_bug.cgi?id=123130

>For example, on bugs.debian.org bug #189211 depends on the resolution of
>bug #97177 on bugzilla.gnome.org.  There is no way to have one depend on
>the other, so it is not easy to tell when the bug is resolved.  Taking a
>look at #189211 (bugs.debian.org) will show you a bit about the unhappy
>mess this causes.
>  
>
You are not the only one feeling this pain.  This is bug 134294.

http://bugzilla.mozilla.org/show_bug.cgi?id=134294

>My suggestion would be to use URIs to reference bugs.  Perhaps something
>like the following:
>
>bugzilla://bugs.debian.org/?project=gnome-theme-manager&bugnumber=N
>  
>
We already have URIs for bugs, so why not use the existing ones?

>"bugnumber" would be gnome-theme-manager (on bugs.debian.org) specific. 
>Global variables are bad.
>
This seems like a separate issue, and we're talking about unique 
identifiers in a database here, not variables.  What are the benefits of 
product/project-specific identifiers?

-myk




From bugreport at peshkin.net  Fri May  9 23:12:05 2003
From: bugreport at peshkin.net (Joel Peshkin)
Date: Fri, 09 May 2003 16:12:05 -0700
Subject: decentralization
In-Reply-To: <1052520106.23441.220.camel@larry.localnet>
References: <1052520106.23441.220.camel@larry.localnet>
Message-ID: <3EBC35C5.702@peshkin.net>

C.J. Collier wrote:

>bugzilla would do well to decentralize.  Each bugzilla server should
>communicate with others.  Bug reports should be shared between projects.
>
>For example, on bugs.debian.org bug #189211 depends on the resolution of
>bug #97177 on bugzilla.gnome.org.  There is no way to have one depend on
>the other, so it is not easy to tell when the bug is resolved.  Taking a
>look at #189211 (bugs.debian.org) will show you a bit about the unhappy
>mess this causes.
>
><snip>
>
This is actually a bit more complicated if we want it to work between 
public and non-public Bugzillas.  I could really use this-  but, for me 
to take advantage of this, I would have to be able to have a bug in my 
(non-public) Bugzilla depend on BMO's bug number xxxxx.   I often want 
to do this because I get site customization requests that rely on a 
Bugzilla enhancment.  Currently, I have no way to express this.  
Ideally, I could say....

Depends on (http:bugzilla.mozilla.org:80/bugzilla/)12345
Perhaps this could be generalized as a depends on [URL] where the URL 
would point directy at something like 
http://bugzilla.mozilla.org/show_bug.cgi?id=12345 ??

This "half of a dependency," by itself, would take care of about 80% of 
the need for this feature.

Doing the other "half" and having the blocking bug on a public system be 
aware that it is blocking a bug on a non-public system as well as 
handling notifications on changes opens a whole can of worms.

If I ignore the open/closed system question and just look for a 
mechanism, the interaction could look like this.
[[Joel dons fireproof suit...]]

User on bugzilla.gnome.org makes BGO bug 12345 depende on BMO bug 54321  
(by pasting a URL into BGO??)
BGO makes BGO#12345 depend on BMO#54321
BGO contacts BMO's external_dependency.cgi and passes it the BGO URL and 
bug number and the BMO bug number (and some credentials??)
BMO contacts BGO's external_dependency.cgi and queries to ensure that 
the BGO URL is legit and BGO shows the dependency
BMO and BGO now show dependencies on each other

On status change...
BMO has a status change on 54321, contacts BGO's 
external_dependency.cgi, and posts status change information
BGO handles its resulting notifications.

Questions:  
1) Should these inter-system contacts be done by HTTP or by SMTP?? (note 
that using SMTP would make this require more than a URL)
2) Should a "trust" be needed between the 2 systems to enable this?  
(i.e.  no trust means - My users are allowed to place dependencies on 
BMO bugs and my system will track them, but BMO does not permit my 
system to make it think its bugs block mine)





From gerv at mozilla.org  Fri May  9 23:14:36 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Sat, 10 May 2003 00:14:36 +0100
Subject: Incentive
In-Reply-To: <1052521344.23310.237.camel@larry.localnet>
References: <1052521344.23310.237.camel@larry.localnet>
Message-ID: <3EBC365C.9090302@mozilla.org>

C.J. Collier wrote:
> I'm working on building a decentralized global karma system, and I'd
> love to get it into Bugzilla.  It's still in early development, but I
> think it will be a useful tool for exchange of appreciation or demarking
> work that would be appreciated.

Apart from allowing someone to feel good or bad about themselves, what 
would a global karma system be _for_?

> http://www.gnubucks.com/

Did you check with the GNU Project before calling your idea GNUBucks?

Gerv



From jason at pyeron.com  Fri May  9 23:14:59 2003
From: jason at pyeron.com (Jason Pyeron)
Date: Fri, 9 May 2003 19:14:59 -0400 (EDT)
Subject: decentralization
In-Reply-To: <1052520106.23441.220.camel@larry.localnet>
Message-ID: <Pine.LNX.4.44.0305091859120.3089-100000@ns.pyerotechnics.com>

I really think that this is a good point.

as to the project issue:

 bug 42 at bugzilla.mozilla.org

this way a domain name can serve as a authoritative project identifier. 
This should prevent collisions. this is kinda link sun's java package naming 
rules.

On 9 May 2003, C.J. Collier wrote:

>bugzilla would do well to decentralize.  Each bugzilla server should
>communicate with others.  Bug reports should be shared between projects.
>
>For example, on bugs.debian.org bug #189211 depends on the resolution of
>bug #97177 on bugzilla.gnome.org.  There is no way to have one depend on
>the other, so it is not easy to tell when the bug is resolved.  Taking a
>look at #189211 (bugs.debian.org) will show you a bit about the unhappy
>mess this causes.
>
>My suggestion would be to use URIs to reference bugs.  Perhaps something
>like the following:
>
>bugzilla://bugs.debian.org/?project=gnome-theme-manager&bugnumber=N
>
>"bugnumber" would be gnome-theme-manager (on bugs.debian.org) specific. 
>Global variables are bad.  I suggest some type of scoping, even if it
>doesn't follow my suggestion exactly.
>
>This would allow projects that use bugzilla to co-ordinate with the
>projects that they depend on without being on the same server.
>
>Thoughts?
>
>C.J.
>
>
>----
>To view or change your list settings, click here:
><http://bugzilla.org/cgi-bin/mj_wwwusr?user=jpyeron at pyerotechnics.com>
>

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-                                                               -
- Jason Pyeron                   http://www.pyerotechnics.com   -
- Owner & Lead                  Pyerotechnics Development, Inc. -
- +1 410 808 6646 (c)           500 West University Parkway #1S -
- +1 410 467 2266 (f)           Baltimore, Maryland  21210-3253 -
-                                                               -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

This message is for the designated recipient only and may contain 
privileged, proprietary, or otherwise private information. If you
have received it in error, purge the message from your system and 
notify the sender immediately.  Any other use of the email by you 
is prohibited.





From jimw at bugopolis.com  Fri May  9 23:55:52 2003
From: jimw at bugopolis.com (Jim Walters)
Date: 09 May 2003 16:55:52 -0700
Subject: decentralization
In-Reply-To: <1052520106.23441.220.camel@larry.localnet>
References: <1052520106.23441.220.camel@larry.localnet>
Message-ID: <1052524552.1497.1935.camel@localhost.localdomain>

On Fri, 2003-05-09 at 15:41, C.J. Collier wrote:

> bugzilla would do well to decentralize.  Each bugzilla server should
> communicate with others.  Bug reports should be shared between projects.

This is the some of the motivating push behind web services. Maybe the
thing to do is to take some some time and polish the XML schema,
implement XML-RPC and then publish/register the WSDL in a UDDI as
described here:

http://www-106.ibm.com/developerworks/webservices/library/ws-wsdl3/?dwzone=webservices

Though Bugzilla would have to change a bit to enable a flexible
authorization system the storage requirements (in at least one design)
shouldn't cause an issue since you would just need to store a GUID which
would be used for subsequent display of details. And you obviously would
not want queries to be across referenced reports.

There are a couple of other advantage to doing this...

Last I looked there wasn't a WSDL for quality assurance defect reports.
Bugzilla define and promulgate this standard. By advancing the adoption
of a standard you probably would enhance the adoption of Bugzilla itself
since this level of interoperability doesn't much excist in the
commercial world. And I know from my experience that most complex
commercial undertakings usually require of multiple corporate
development groups. And there is the positive attribute of providing
external components interfaces to the Bugzilla system which are
decoupled from MySQL and perl modules. 

But I guess all that takes time and resources, doesn't it? :-)

__________________________
Jim Walters   Director of Technology
Bugopolis, Inc.

phone: +1 206 447 8315 
email: jimw at bugopolis.com
web: http://www.bugopolis.com
_________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20030509/e1d4de60/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smiley-3.png
Type: image/png
Size: 819 bytes
Desc: not available
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20030509/e1d4de60/attachment.png>

From myk at mozilla.org  Sat May 10 00:25:43 2003
From: myk at mozilla.org (Myk Melez)
Date: Fri, 09 May 2003 17:25:43 -0700
Subject: decentralization
In-Reply-To: <1052524552.1497.1935.camel@localhost.localdomain>
References: <1052520106.23441.220.camel@larry.localnet> <1052524552.1497.1935.camel@localhost.localdomain>
Message-ID: <3EBC4707.1000204@mozilla.org>

Jim Walters wrote:

> This is the some of the motivating push behind web services. Maybe the 
> thing to do is to take some some time and polish the XML schema, 
> implement XML-RPC and then publish/register the WSDL in a UDDI as 
> described here:

If it's WSDL it has to be SOAP rather than XML-RPC, doesn't it?  
Otherwise, I agree, except that I think we shouldn't wait until things 
are polished to push them out, we should just advertise them as bleeding 
edge and subject to change until we have enough actual use to know we 
got the interfaces right.  Polishing the schema, by the way, is bug 200837:

http://bugzilla.mozilla.org/show_bug.cgi?id=200837

> Though Bugzilla would have to change a bit to enable a flexible 
> authorization system

Now that bbaetz' authorization modularization patch has gone in, I think 
this is fixed.

> But I guess all that takes time and resources, doesn't it?

Yup.  Got some?

-myk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20030509/48fb0784/attachment.html>

From dberlin at dberlin.org  Sat May 10 00:51:29 2003
From: dberlin at dberlin.org (Daniel Berlin)
Date: Fri, 9 May 2003 20:51:29 -0400
Subject: decentralization
In-Reply-To: <1052524552.1497.1935.camel@localhost.localdomain>
Message-ID: <895B4F4F-8281-11D7-9E86-000A95A34564@dberlin.org>


On Friday, May 9, 2003, at 07:55  PM, Jim Walters wrote:

> On Fri, 2003-05-09 at 15:41, C.J. Collier wrote:
>
> bugzilla would do well to decentralize.  Each bugzilla server should
> communicate with others.  Bug reports should be shared between  
> projects.
>
> This is the some of the motivating push behind web services. Maybe the  
> thing to do is to take some some time and polish the XML schema,  
> implement XML-RPC and then publish/register the WSDL in a UDDI as  
> described here:

Redhat has actually already done this.

Grab the latest rh-bugzilla, and look at xmlrpc.cgi and Bugzilla/RPC.pm

I tried a few XMLRPC queries from a python XMLRPC client against their  
production server, and it worked fine.
Python 2.2.2 (#1, 04/01/03, 23:00:56)
[GCC Apple cpp-precomp 6.14] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> import xmlrpclib
 >>>  
connection=xmlrpclib.Server("http://bugzilla.redhat.com/bugzilla/ 
xmlrpc.cgi")
 >>> testconnect.bugzilla.getBug("13", "guest", "guest")

{'status_whiteboard': '', 'product': 'Red Hat Linux', 'qa_contact': '',  
'reporter': 'stone at hkust.se', 'estimated_time': 0.0, 'rep_platform':  
'i386', 'bug_file_loc': '', 'bug_severity': 'normal', 'remaining_time':  
0.0, 'bug_id': 13, 'internal_whiteboard': '', 'delta_ts': '2001-06-06  
17:42:48', 'creation_ts': '1998-11-09 13:28:12', 'target_milestone':  
'', 'cc': ['carl.corey at usa.net'], 'votes': '', 'longdescs':  
[{'isprivate': 0, 'bug_when': '1998-11-09 13:28:12', 'thetext': "Got  
this from the mc list:\nchange\n    rpm -qlvp $1 | sed -e  
's/^\\(..........\\)[-t] /\\1 1 /'\nto\n    rpm -qlvp $1 | sed -e  
's/^\\(..........\\)/\\1 1 /'\n\nin /usr/lib/mc/extfs/rpm\n\nsolves the  
problem.", 'work_time': '', 'who': 'stone at hkust.se'}, {'isprivate': 0,  
'bug_when': '1998-11-16 10:15:59', 'thetext': '*** Bug 71 has been  
marked as a duplicate of this bug. ***', 'work_time': '', 'who':  
'notting at redhat.com'}, {'isprivate': 0, 'bug_when': '1998-11-16  
10:20:59', 'thetext': 'Will be fixed in next release. As a workaround,  
you can update\nto mc 4.1.36, which includes this fix.', 'work_time':  
'', 'who': 'notting at redhat.com'}, {'isprivate': 0, 'bug_when':  
'1998-11-20 06:33:59', 'thetext': '*** Bug 138 has been marked as a  
duplicate of this bug. ***', 'work_time': '', 'who':  
'notting at redhat.com'}, {'isprivate': 0, 'bug_when': '1998-11-24  
10:49:59', 'thetext': '*** Bug 183 has been marked as a duplicate of  
this bug. ***', 'work_time': '', 'who': 'notting at redhat.com'},  
{'isprivate': 0, 'bug_when': '1998-11-30 10:54:59', 'thetext': '*** Bug  
207 has been marked as a duplicate of this bug. ***', 'work_time': '',  
'who': 'notting at redhat.com'}, {'isprivate': 0, 'bug_when': '1998-12-15  
16:38:59', 'thetext': '*** Bug 13 has been marked as a duplicate of  
this bug. ***\nmc                      Make rpmfs working for rpm  
2.5+.', 'work_time': '', 'who': 'notting at redhat.com'}, {'isprivate': 0,  
'bug_when': '1998-12-30 13:34:59', 'thetext': "*** Bug 13 has been  
marked as a duplicate of this bug. ***\n\nSomething broke mc's coolest  
feature (according to the\npackage description) i.e. the ability to  
peek into rpm\nfiles. When you cd into an rpm file on RedHat Linux 5.2  
you\ncannot see the files in it only HEADER, INSTALL, UPGRADE  
and\nINFO. It used to work on older versions of RedHat Linux\n(5.1,  
5.0) with the same mc version (4.1.35).\n\nThe line that doesn't work  
any more in /usr/lib/mc/extfs/rpm\nlooks like:\n\nrpm -qlvp $1 | sed -e  
's/^\\(..........\\)[-t] /\\1 1 /'\n\nRemoving [-t] from the above line  
corrects the problem, but\nthe same line used to work in earlier  
versions so the bug is\nsomwhere else. Maybe the output of rpm has  
changed (seems\nnot to be the case), or maybe sed has changed (this can  
be\nthe real reason, but I'm not sure).", 'work_time': '', 'who':  
'dkl at redhat.com'}, {'isprivate': 0, 'bug_when': '1999-01-01 16:22:59',  
'thetext': "*** Bug 13 has been marked as a duplicate of this bug.  
***\n\nOn the mc that ships with RH 5.2 for i386 when one  
presses\nenter on an rpm the contents of the RPM are not  
properly\nshown. Only the ../, /INFO, HEADER, INSTALL and  
UPGRADE\nfiles show up. None of the actual files installed by the  
rpm\nshow up.\n\n\tI have actually fixed this bug by editing the  
file\n/usr/lib/mc/extfs/rpm as folows\n\n# diff /usr/lib/mc/extfs/rpm  
/usr/lib/mc/extfs/rpm~\n100c100\n<     rpm -qlvp $1 | sed -e  
's/^\\(..........\\)/\\1 1 /'\n---\n>     rpm -qlvp $1 | sed -e  
's/^\\(..........\\)[-t] /\\1 1 /'\n#\n\nIt now works properly.  I do  
not know whether I should send\nthis fix as a patch to bugzilla.  Would  
appreciate any\nadvice.\n\nprabhu", 'work_time': '', 'who':  
'jbj at redhat.com'}, {'isprivate': 0, 'bug_when': '1999-01-05 10:52:59',  
'thetext': '*** Bug 13 has been marked as a duplicate of this bug.  
***\n\nall you get when you enter an rpm package with mc\'s vfs is\nthe  
header list.\napply this patch to fix:\n-cut-cut-\n--- rpm.orig\tWed  
Dec 30 23:58:00 1998\n+++ rpm\tFri\nJan  1 12:46:34 1999\n@@ -5,6 +5,7  
@@\n #            Tomasz\nK&oczko (kloczek at rudy.mif.pg.gda.pl) 1997\n #  
minor changes\nby Wojtek Pilorz (wpilorz at bdk.lublin.pl) 1997\n #  
minor\nchanges by Michele Marziani (marziani at fe.infn.it) 1997\n+#\nfix  
to handle new rpm output by Andrea  
Borgia\n<borgia at students.cs.unibo.it> (1999)\n # (C) 1996 The  
Free\nSoftware Foundation.\n #\n #\n@@ -97,7 +98,7 @@\n          
echo\n"$FILEPREF 0 $DATE INFO/CHANGELOG"\n     fi\n\n-    rpm -qlvp\n$1  
| sed -e \'s/^\\(..........\\)[-t] /\\1 1 /\'\n+    rpm -qlvp\n$1 | sed  
-e \'s/^\\(..........\\) /\\1 1 /\'\n }\n\n\nmcrpmfs_copyout  
()\n-cut-cut-', 'work_time': '', 'who': 'jbj at redhat.com'},  
{'isprivate': 0, 'bug_when': '1999-06-03 10:38:59', 'thetext': "*** Bug  
2997 has been marked as a duplicate of this bug. ***\n\nmc doesnot show  
contents of rpm exept /INFO, INSTALL and UPGRADE\nfile:  
/usr/lib/mc/extfs/rpm, line 100:\nrpm -qlvp $1 | sed -e  
's/^\\(..........\\)[-t] /\\1 1 /'\nreplace with:\nrpm -qlvp $1 | sed  
-e 's/^\\(..........\\) /\\1 1 /'\n\n------- Additional Comments From  
johnsonm at redhat.com  05/25/99 14:46 -------\nWhat version of rpm do you  
have installed?", 'work_time': '', 'who': 'jbj at redhat.com'}],  
'bug_status': 'CLOSED', 'short_desc': 'mc vfs does not work with RPMs   
[solution included]', 'priority': 'normal', 'alias': '', 'whoid': 0,  
'version': 5.2000000000000002, 'component': 'mc', 'assigned_to':  
'dkl at redhat.com', 'fixed_in': '', 'resolution': 'FIXED', 'op_sys':  
'Linux'}
 >>>


>
> http://www-106.ibm.com/developerworks/webservices/library/ws-wsdl3/ 
> ?dwzone=webservices
>
> Though Bugzilla would have to change a bit to enable a flexible  
> authorization system the storage requirements (in at least one design)  
> shouldn't cause an issue since you would just need to store a GUID  
> which would be used for subsequent display of details. And you  
> obviously would not want queries to be across referenced reports.
>
> There are a couple of other advantage to doing this...
>
> Last I looked there wasn't a WSDL for quality assurance defect  
> reports. Bugzilla define and promulgate this standard. By advancing  
> the adoption of a standard you probably would enhance the adoption of  
> Bugzilla itself since this level of interoperability doesn't much  
> excist in the commercial world. And I know from my experience that  
> most complex commercial undertakings usually require of multiple  
> corporate development groups. And there is the positive attribute of  
> providing external components interfaces to the Bugzilla system which  
> are decoupled from MySQL and perl modules.
>
> But I guess all that takes time and resources, doesn't it? <image.tiff>
>
>
>
<image.tiff>
>



From jimw at bugopolis.com  Sat May 10 00:56:16 2003
From: jimw at bugopolis.com (Jim Walters)
Date: 09 May 2003 17:56:16 -0700
Subject: decentralization
In-Reply-To: <3EBC4707.1000204@mozilla.org>
References: <1052520106.23441.220.camel@larry.localnet>
	 <1052524552.1497.1935.camel@localhost.localdomain>
	 <3EBC4707.1000204@mozilla.org>
Message-ID: <1052528176.1501.1942.camel@localhost.localdomain>

On Fri, 2003-05-09 at 17:25, Myk Melez wrote:

> Jim Walters wrote:
> 
> > This is the some of the motivating push behind web services. Maybe
> > the thing to do is to take some some time and polish the XML schema,
> > implement XML-RPC and then publish/register the WSDL in a UDDI as
> > described here:
> 
> If it's WSDL it has to be SOAP rather than XML-RPC, doesn't it? 

I'm no expert in this stuff, but I think SOAP is analogous to COM
whereas XML-RPC is analogous to, well, RPC. (Using this reference
http://archive.devx.com/javaSR/articles/glossary/glossary-2.asp )

I did mistake UDDI for being a global registry of WSDL specifications.
Don't remember who is hosting those anymore.

__________________________
Jim Walters   Director of Technology
Bugopolis, Inc.

phone: +1 206 447 8315 
email: jimw at bugopolis.com
web: http://www.bugopolis.com
_________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20030509/e507b1cf/attachment.html>

From myk at mozilla.org  Sat May 10 01:01:24 2003
From: myk at mozilla.org (Myk Melez)
Date: Fri, 09 May 2003 18:01:24 -0700
Subject: decentralization
In-Reply-To: <1052528176.1501.1942.camel@localhost.localdomain>
References: <1052520106.23441.220.camel@larry.localnet>	 <1052524552.1497.1935.camel@localhost.localdomain>	 <3EBC4707.1000204@mozilla.org> <1052528176.1501.1942.camel@localhost.localdomain>
Message-ID: <3EBC4F64.6090502@mozilla.org>

Jim Walters wrote:

> I'm no expert in this stuff, but I think SOAP is analogous to COM 
> whereas XML-RPC is analogous to, well, RPC. (Using this reference 
> http://archive.devx.com/javaSR/articles/glossary/glossary-2.asp )

SOAP is more like RPC on steroids, and WSDL seems to have been invented 
for describing SOAP services:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwebsrv/html/wsdlexplained.asp

But at least some people think it could be used for XML-RPC as well:

http://www.cookcomputing.com/blog/archives/000216.html

> I did mistake UDDI for being a global registry of WSDL specifications. 
> Don't remember who is hosting those anymore.

http://xmethods.net/ is the one I've heard about the most.

-myk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20030509/fe11dc31/attachment.html>

From gerv at mozilla.org  Sat May 10 06:55:09 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Sat, 10 May 2003 07:55:09 +0100
Subject: buglist.cgi
In-Reply-To: <GAEGLHGNMKMDDJAHAHGOCEEICEAA.jacqui@groxis.com>
References: <GAEGLHGNMKMDDJAHAHGOCEEICEAA.jacqui@groxis.com>
Message-ID: <3EBCA24D.4090907@mozilla.org>

Jacqui Guerrero wrote:
> How do you add a group in the list of checkboxes under the "Only users in
> the selected groups can view this bug:" heading in a bug (the one right
> under Additional Comments)?  I think this might be an easier way than
> reassigning all previously logged bugs to their associated products.

You can reassign all previously-logged bugs to their associated products 
using Bugzilla's "Change Multiple Bugs At Once" feature.

Gerv



From gerv at mozilla.org  Sat May 10 23:04:49 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Sun, 11 May 2003 00:04:49 +0100
Subject: Oops...
Message-ID: <3EBD8591.5010503@mozilla.org>

I just tried installing a new Bugzilla on landfill, and left the DB name 
as the default ("bugs"). When I ran checksetup, the following happened, 
which suggests that this database was rather old:

Have a messed something big up?

Gerv

<snip>

Checking for    MySQL Server (v3.23.41) ok: found v3.23.56

One or more of the tables in your existing MySQL database are of type ISAM.
ISAM tables are deprecated in MySQL 3.23 and don't support more than 16 
indexes
per table, which Bugzilla needs.  Converting your ISAM tables to type 
MyISAM:

Converting table attachments... done.
Converting table attachstatusdefs... done.
Converting table attachstatuses... done.
Converting table bugs... done.
Converting table bugs_activity... done.
Converting table cc... done.
Converting table components... done.
Converting table dependencies... done.
Converting table duplicates... done.
Converting table fielddefs... done.
Converting table groups... done.
Converting table keyworddefs... done.
Converting table keywords... done.
Converting table logincookies... done.
Converting table longdescs... done.
Converting table milestones... done.
Converting table namedqueries... done.
Converting table products... done.
Converting table profiles... done.
Converting table profiles_activity... done.
Converting table shadowlog... done.
Converting table tokens... done.
Converting table versions... done.
Converting table votes... done.
Converting table watch... done.

ISAM->MyISAM table conversion done.

Creating table group_control_map ...
Creating table user_group_map ...
Creating table group_group_map ...
Creating table flagexclusions ...
Creating table flagtypes ...
Creating table bug_group_map ...
Creating table flags ...
Creating table flaginclusions ...
Creating table quips ...
Updating field op_sys in table bugs ...
Creating duplicates directory...
Adding new field work_time to table longdescs ...
Adding new field estimated_time to table bugs ...
Adding new field remaining_time to table bugs ...
Adding new field isprivate to table longdescs ...
Adding new field isprivate to table attachments ...
Adding new field alias to table bugs ...
Deleting unused field watchfordiffs from table namedqueries ...
Updating database to use product IDs.
Adding new field id to table products ...
Adding new field product_id to table components ...
Adding new field product_id to table versions ...
Adding new field product_id to table milestones ...
Adding new field product_id to table bugs ...
Adding new field product_id to table attachstatusdefs ...
Updating the database to use component IDs.
Adding new field id to table components ...
Adding new field component_id to table bugs ...
Fixing Indexes and Uniqueness.
Removing, renaming, and retyping old product and component fields.
Deleting unused field program from table components ...
Deleting unused field program from table versions ...
Deleting unused field product from table milestones ...
Deleting unused field product from table bugs ...
Deleting unused field component from table bugs ...
Deleting unused field product from table attachstatusdefs ...
Updating field product in table products ...
Updating field type name in table products ...
old: varchar(64)
new: varchar(64) not null
Updating field value in table components ...
Updating field type name in table components ...
old: tinytext
new: varchar(64) not null
Adding indexes for products and components tables.
Fixing creation time on attachments...
Done - converted 58 attachments
Updating field type creation_ts in table attachments ...
old: timestamp(14)
new: datetime NOT NULL
Adding new field last_changed to table groups ...
Adding new field id to table groups ...
Adding new field refreshed_when to table profiles ...

WARNING - GROUPSET ACTIVITY ON BUG 388 CONTAINS DELETED GROUPS
Deleting unused field groupset from table profiles ...
Deleting unused field blessgroupset from table profiles ...
Deleting unused field groupset from table bugs ...
Deleting unused field bit from table groups ...
Converting attachment statuses to flags...
done.
Adding group admin ...
Removing paths from filenames in attachments table...
Done.
Resizing attachments.filename from mediumtext to varchar(100).
Updating field type filename in table attachments ...
old: mediumtext not null
new: varchar(100) not null
Removing shadowlog table
Updating field count in table votes ...
Reminder: Bugzilla now requires version 8.7 or later of sendmail.
[gerv at landfill bz16009]$



From justdave at syndicomm.com  Sat May 10 23:31:58 2003
From: justdave at syndicomm.com (David Miller)
Date: Sat, 10 May 2003 19:31:58 -0400
Subject: Oops...
In-Reply-To: <3EBD8591.5010503@mozilla.org>
References: <3EBD8591.5010503@mozilla.org>
Message-ID: <a05210500bae33bf028c4@[192.168.1.203]>

On 5/11/2003 12:04 AM +0100, Gervase Markham wrote:

> I just tried installing a new Bugzilla on landfill, and left the DB name
> as the default ("bugs"). When I ran checksetup, the following happened,
> which suggests that this database was rather old:
>
> Have a messed something big up?

Nope.  I'm not aware of any installations actually using that database
anymore, unless they also, are old.  The "tip" install uses a database
called "bugs_tip" and the 2.16.3 install uses one called "bugs_216".  Most
of the test installs use "bugs_12345" where 12345 is the bug number of the
bug they're testing.

The tip install was on bugs at one time, but it got moved to bugs_tip,
mostly for that reason :-)  (people have done things to the tip database
before on accident trying to test schema changes)
-- 
Dave Miller      Project Leader, Bugzilla Bug Tracking System
http://www.justdave.net/             http://www.bugzilla.org/


From cjcollier at colliertech.org  Sun May 11 07:46:31 2003
From: cjcollier at colliertech.org (C.J. Collier)
Date: 11 May 2003 00:46:31 -0700
Subject: Incentive
In-Reply-To: <3EBC365C.9090302@mozilla.org>
References: <1052521344.23310.237.camel@larry.localnet>
	 <3EBC365C.9090302@mozilla.org>
Message-ID: <1052639190.9989.161.camel@larry.localnet>

On Fri, 2003-05-09 at 16:14, Gervase Markham wrote:
> C.J. Collier wrote:
> > I'm working on building a decentralized global karma system, and I'd
> > love to get it into Bugzilla.  It's still in early development, but I
> > think it will be a useful tool for exchange of appreciation or demarking
> > work that would be appreciated.
> 
> Apart from allowing someone to feel good or bad about themselves, what 
> would a global karma system be _for_?

That's not enough?

> > http://www.gnubucks.com/
> 
> Did you check with the GNU Project before calling your idea GNUBucks?

Yep, Richard asked me to have him look at it and approve it as part of
the GNU project before it goes live.

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



From cjcollier at colliertech.org  Sun May 11 08:07:46 2003
From: cjcollier at colliertech.org (C.J. Collier)
Date: 11 May 2003 01:07:46 -0700
Subject: decentralization
In-Reply-To: <3EBC35BB.5080508@mozilla.org>
References: <1052520106.23441.220.camel@larry.localnet>
	 <3EBC35BB.5080508@mozilla.org>
Message-ID: <1052640466.9989.185.camel@larry.localnet>

On Fri, 2003-05-09 at 16:11, Gervase Markham wrote:

> What advantage does having multiple bugs with the same number in an 
> individual installation give you?

On Fri, 2003-05-09 at 16:09, Myk Melez wrote:

> This seems like a separate issue, and we're talking about unique 
> identifiers in a database here, not variables.  What are the benefits of 
> product/project-specific identifiers?

Perhaps the database ID shouldn't be used.  Why does the user know
anything about the data source?  Isn't that a bad thing (tm)?  Doesn't
it somewhat limit the flexibility of the installation platform?

Scoping the bug numbers to the individual project/products makes each
project/product seem a bit more homey.  It's not quite so dauntng if you
think of your particular project having only 40 bugs rather than the
hundreds of millions for all of the projects all over the internet that
use bugzilla.

Here's the question right back at you:  What's the benefit of having a
global counter for the number of bugs for all projects hosted at BMO? 
If there's a benefit, wouldn't that benefit increase if it were expanded
globally, and not just at BMO?  Shouldn't BMO and BGO share bug numbers
in this case?

What a nightmare. :)

namaste,

C.J., who is going to bed, and who will answer more fan mail tomorrow
after hugging his mother, step-mother and grandmothers as well as
spending time with his girlfriend.

Happy Mothers' day!




From willy at lukoil.uu.ru  Sun May 11 17:48:27 2003
From: willy at lukoil.uu.ru (Vitaly Fedrushkov)
Date: Sun, 11 May 2003 23:48:27 +0600 (YEKST)
Subject: decentralization
In-Reply-To: <3EBC35BB.5080508@mozilla.org>
Message-ID: <Pine.LNX.4.44.0305112320510.1471-100000@snowyowl.lukoil.uu.ru>

Good $daytime,

> Date: Sat, 10 May 2003 00:11:55 +0100
> From: Gervase Markham <gerv at mozilla.org>
> To: developers at bugzilla.org
> Subject: Re: decentralization

> > bugzilla://bugs.debian.org/?project=gnome-theme-manager&bugnumber=N

> Or http://bugzilla.mozilla.org?show_bug.cgi?id=12345 ? :-)

> > "bugnumber" would be gnome-theme-manager (on bugs.debian.org) specific. 
> > Global variables are bad.  I suggest some type of scoping, even if it
> > doesn't follow my suggestion exactly.

There's little in identifying anything but a bug ID, as all other
attributes, including product, may change.

> Date: Fri, 9 May 2003 19:14:59 -0400 (EDT)
> From: Jason Pyeron <jason at pyeron.com>

>  bug 42 at bugzilla.mozilla.org

> this way a domain name can serve as a authoritative project
> identifier.  This should prevent collisions. this is kinda link
> sun's java package naming rules.

Hostname + bug ID simply not enough.  There should be a way to
distinguish separate Bugzilla instances on the same host.  It looks
natural to make bug URIs resemble their respective user-visible URIs
like

  http://bugzilla.example.org/path/to/bugzilla?show_bug.cgi?id=12345

This specific syntax is not the best because it puts method
(e.g. show_bug) before object, and perfect URI would name the object
instead and then would allow different entry points to be modelled
like:

  http://bugzilla.example.org/path/to/bugzilla/ID/12344/
  http://bugzilla.example.org/path/to/bugzilla/ID/12344/show
  http://bugzilla.example.org/path/to/bugzilla/ID/12344/xml-show
  http://bugzilla.example.org/path/to/bugzilla/ID/12344/update-deps?...

Here "bug URI" is a plain HTTP URI , and various methods are "just"
verbs appended.

As a side effect, this approach makes bugs cache-friendly and may
reduce server load, as not all methods use parameters.

On the implementanion side, Apache can help with its URL-rewriting
capabilities, etc.  Not sure about other servers.

  Regards,
  Willy.

--
No easy hope or lies        | Vitaly "Willy the Pooh" Fedrushkov
Shall bring us to our goal, | Control Systems and Processes Division
But iron sacrifice          | LUKOIL Company, Chelyabinsk Branch
Of Body, Will and Soul.     | willy at lukoil.uu.ru  +7 3512 620367
                  R.Kipling | VVF1-RIPE




From cjcollier at colliertech.org  Sun May 11 14:28:49 2003
From: cjcollier at colliertech.org (C.J. Collier)
Date: 11 May 2003 07:28:49 -0700
Subject: Incentive
In-Reply-To: <3EBC365C.9090302@mozilla.org>
References: <1052521344.23310.237.camel@larry.localnet>
	 <3EBC365C.9090302@mozilla.org>
Message-ID: <1052663328.23091.8.camel@larry.localnet>

On Fri, 2003-05-09 at 16:14, Gervase Markham wrote:
> C.J. Collier wrote:
> > I'm working on building a decentralized global karma system, and I'd
> > love to get it into Bugzilla.  It's still in early development, but I
> > think it will be a useful tool for exchange of appreciation or demarking
> > work that would be appreciated.
> 
> Apart from allowing someone to feel good or bad about themselves, what 
> would a global karma system be _for_?

I'm sorry I wasn't more clear about this.  These questions have already
been asked and discussed at length.  I just don't have the time/energy
to do it again.  For more details, check the GnuBucks mailing list
archive:

http://lists.colliertech.org/pipermail/gnubucks/

> > http://www.gnubucks.com/
> 
> Did you check with the GNU Project before calling your idea GNUBucks?

And I've been pondering changing the name despite Richard's
semi-approval, assuming I can provide a clear mission statement and get
a team together.  For some more information about a recent brainstorming
session and some different ideas for naming check here:

http://www.livejournal.com/users/cjcollier/25610.html

Please feel free to comment.

> Gerv

namaste,

C.J.



From cjcollier at colliertech.org  Mon May 12 04:08:24 2003
From: cjcollier at colliertech.org (C.J. Collier)
Date: 11 May 2003 21:08:24 -0700
Subject: GnuBucks Follow-up
Message-ID: <1052712503.23240.149.camel@larry.localnet>

Heya Richard and lists,

I've spoken with all of the recipients of this email recently about some
of my suggestions for personal information exchange and/or theories
about distribution of load and information.

If you feel like this email is rambling and doesn't apply to the lists
I've posted it to, you're probably right.  But have faith.  Finish the
email.  It all comes together in the end.

First of all, in terms of Karma Points (Heretofore, GnuBucks), I
apologize for using the GNU moniker without asking the GNU project first
for permission.  I was not aware this was a faux pas.  I guess that's
what I get for being young, idealistic and na?ve.  Knowing it now, I
will avoid making such a step in the future.

The Karma Points project was intended as a global karma transfer and
notation system; but I also want it to evolve eventually to a spendable
currency, hence the 'bucks' portion of the previous name.  After
speaking with others about the project, I stepped back a bit and looked
at my goal from a different angle:

Two years ago, I started planning the development of a community
database project. Recently, I've been seeing other projects that have
similar goals, but don't quite hit the mark.  I've taken a bit of
inspiration from the things these projects have so far gotten right and
the mistakes they have made.  Some examples are LiveJournal,
friendster.com, Karma Points, the GNU project, and bugzilla.  They all
involve making the global community a smaller entity by providing easy
ways to network with other members in your community.

Since frendster.com is not a Free Software project, I've decided that
the idea should be re-implemented (as Free Software, without those
frickin' adds, and DISTRIBUTED, damnit ;).  My working name for this
potential project is 'acquaint.'  The purpose of 'acquaint' is the
replacement of friendster.com as the most visible representation of this
online community.

Here's a basic idea for implementation:

ISPs provide an interface to their local acquaint database through a URI
similar to this:

http://foo.com/acquaint

When an acquaint client is asked for information about a user at
foo.com, it issues an HTTP request for a URI similar to this:

http://foo.com/acquaint?foreign_user=bar at baz.com&local_user=cjcollier&command=get_friends

If http://foo.com/ responds with a 400 error, the client that issued the
request contacts a WHOIS database and asks for the technical contact for
the domain foo.com.  The client sends this technical contact an email
explaining what the acquaint project is and that there is demand for a
acquaint service to be installed on the domain.  It explains a bit about
the aims of the project, and also tells the administrator where to get a
few implementations of the acquaint protocol.  The goal here is that if
the admin gets enough of these requests, they will decide that they
should either not issue 400 responses for /acquaint or they should
actually install the software and add one more valuable service to their
ISP.

(on a side note, the same approach could be applied to /livejournal,
/ecalendar, /karmapoints, /bugzilla, and others.)

acquaint itself would provide services to store, list and link to
'friends,' 'mentors,' 'teachers,' 'lovers,' 'family members,' 'sworn
enemies,' 'neighbors,' etc.  These acquaintences would be indexed by
email addresses.  The database could potentially store information about
each user's person including photographs, testimonials, biographies,
autobiographies, interests, pets' names, etc. It would of course be good
to design flexibility into the protocol to allow for additional features
in the future. But I'm not a protocol engineer.  Anyone want to field
this?  If I do it, I'll probably get it wrong ;)

Compare LiveJournal's user info page:
http://www.livejournal.com/userinfo.bml?user=cjcollier

and friendster.com's user info page:
http://www.friendster.com/user.jsp?id=69291

I intend to build a UI to wrap around the LiveJournal, acquaint and
Karma Points protocols.  There should also be support for a distributed
calendaring system, web-based email, project management, and other
Personal Information.  All of these can be indexed by an email address. 

Which brings us to Evolution.

Evolution is a Personal Information Management tool.  All of these are
personal information.  If Evolution were made modular, I would write
modules (or help to write modules :) to access each of these services. 
How many more bug reports would be filed if it were as easy to file bug
reports (and attach incentive) as it was to write email?  How fast would
e-money (or e-karma) catch on if you could use the same tool you used to
keep track of your calendar and email to transfer funds?

Some food for thought.  Thanks for bearing with me!

C.J.






From deb at techna.co.in  Mon May 12 03:55:51 2003
From: deb at techna.co.in (DEBAJYOTI LAHIRI)
Date: Mon, 12 May 2003 09:25:51 +0530
Subject: interface change...
In-Reply-To: <3EBA710A.5050709@peshkin.net>
Message-ID: <NHBBIKJJEMEKMDMGOLKMAEMKCAAA.deb@techna.co.in>

Dear All,

Hi. We want to customise the bugzilla application to use it as an issue
tracking software not just a software bug tracking application. we want to
keep a track of all request(fault related request) that goes in to our
systems admin department(which we are treating as alternatives to software
bugs)and store them in our bugzilla database. what we want is to change the
interface of the software (that is the existing template) and design one for
our needs. what do i need in that case??

Deb

-----Original Message-----
From: developers-owner at bugzilla.org
[mailto:developers-owner at bugzilla.org]On Behalf Of Joel Peshkin
Sent: Thursday, May 08, 2003 8:30 PM
To: developers at bugzilla.org
Subject: Re: How to clone an existing bugzilla database


usmle Prep wrote:

>Dear developers,
>I just want to retain the same data structure as
>existing bugzilla database. The newly created database
>should have all the products,customfields similar to
>the existing database, but should n't contain any
>bugs.Is it possible to achieve this.
>Please let me know.
>Thanks,
>Srikant
>
>_
>
Sure...

Just copy the database and use SQL commands to delete all the records in
bugs, bug_group_map, attachments, etc....

If we knew the Bugzilla version you were using, we might even be able to
tell you the commands to use.

-Joel



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





From gerv at mozilla.org  Mon May 12 07:21:24 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Mon, 12 May 2003 08:21:24 +0100
Subject: interface change...
In-Reply-To: <NHBBIKJJEMEKMDMGOLKMAEMKCAAA.deb@techna.co.in>
References: <NHBBIKJJEMEKMDMGOLKMAEMKCAAA.deb@techna.co.in>
Message-ID: <3EBF4B74.7070302@mozilla.org>

DEBAJYOTI LAHIRI wrote:
> Hi. We want to customise the bugzilla application to use it as an issue
> tracking software not just a software bug tracking application. we want to
> keep a track of all request(fault related request) that goes in to our
> systems admin department(which we are treating as alternatives to software
> bugs)and store them in our bugzilla database. what we want is to change the
> interface of the software (that is the existing template) and design one for
> our needs. what do i need in that case??

A text editor? :-)

I'm not sure I understand the question.

Gerv



From gerv at mozilla.org  Mon May 12 07:24:43 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Mon, 12 May 2003 08:24:43 +0100
Subject: decentralization
In-Reply-To: <Pine.LNX.4.44.0305112320510.1471-100000@snowyowl.lukoil.uu.ru>
References: <Pine.LNX.4.44.0305112320510.1471-100000@snowyowl.lukoil.uu.ru>
Message-ID: <3EBF4C3B.3090207@mozilla.org>

> This specific syntax is not the best because it puts method
> (e.g. show_bug) before object, and perfect URI would name the object
> instead and then would allow different entry points to be modelled
> like:
> 
>   http://bugzilla.example.org/path/to/bugzilla/ID/12344/
>   http://bugzilla.example.org/path/to/bugzilla/ID/12344/show
>   http://bugzilla.example.org/path/to/bugzilla/ID/12344/xml-show
>   http://bugzilla.example.org/path/to/bugzilla/ID/12344/update-deps?...

I believe that last time this was proposed, several people commented 
that this sort of encoding was a nasty hack, and that URL parameters are 
there to do exactly this.

> Here "bug URI" is a plain HTTP URI , and various methods are "just"
> verbs appended.
> 
> As a side effect, this approach makes bugs cache-friendly and may
> reduce server load, as not all methods use parameters.

We don't want bugs to be cache-friendly; we want the page to be 
regenerated every time it's asked for - because it's different for 
different people.

Gerv



From gerv at mozilla.org  Mon May 12 07:27:55 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Mon, 12 May 2003 08:27:55 +0100
Subject: decentralization
In-Reply-To: <1052640466.9989.185.camel@larry.localnet>
References: <1052520106.23441.220.camel@larry.localnet>	 <3EBC35BB.5080508@mozilla.org> <1052640466.9989.185.camel@larry.localnet>
Message-ID: <3EBF4CFB.8060901@mozilla.org>

> Scoping the bug numbers to the individual project/products makes each
> project/product seem a bit more homey.  It's not quite so dauntng if you
> think of your particular project having only 40 bugs 

You can - just search for bugs in your project. Measuring things about a 
project by counting bugs is bogus anyway.

> rather than the
> hundreds of millions for all of the projects all over the internet that
> use bugzilla.

A centralised number allocation would also be bad, because it implies a 
central authority to hand out numbers.

> Here's the question right back at you:  What's the benefit of having a
> global counter for the number of bugs for all projects hosted at BMO? 

Ease of implementation. Lack of confusion when referring to bugs in 
newsgroups. Simple URLs, with just one thing to remember.

> If there's a benefit, wouldn't that benefit increase if it were expanded
> globally, and not just at BMO?  

No. See above. :-)

Gerv



From bunsterj at convergentdev.com  Mon May 12 15:37:31 2003
From: bunsterj at convergentdev.com (Jordi S. Bunster)
Date: 12 May 2003 11:37:31 -0400
Subject: Migrating from 2.14 to 2.16
Message-ID: <1052753858.723.2.camel@devpc2>

What is the preferred migration path for the tables? Just a dump and
restore? Or has table information changed?

 -- Jordi





From rodrigo at ximian.com  Mon May 12 10:35:12 2003
From: rodrigo at ximian.com (Rodrigo Moya)
Date: 12 May 2003 12:35:12 +0200
Subject: [Evolution-hackers] GnuBucks Follow-up
In-Reply-To: <1052712503.23240.149.camel@larry.localnet>
References: <1052712503.23240.149.camel@larry.localnet>
Message-ID: <1052735712.2013.11.camel@azkoyen>

On Mon, 2003-05-12 at 06:08, C.J. Collier wrote:
> 
> Evolution is a Personal Information Management tool.  All of these are
> personal information.  If Evolution were made modular, I would write
> modules (or help to write modules :) to access each of these services. 
>
Evolution is already modular. You can extend it as you wish, by writing
new modules.

cheers



From usmlekaplan at yahoo.com  Mon May 12 16:50:05 2003
From: usmlekaplan at yahoo.com (usmle Prep)
Date: Mon, 12 May 2003 09:50:05 -0700 (PDT)
Subject: Urgent Help Needed Please
Message-ID: <20030512165005.39768.qmail@web20202.mail.yahoo.com>

We are using Bugzilla 2.16.1 version and extensively
use the e-mail interface, the data/mimedump-tmp
directory is growing leaps and bounds. Can we just
delete the files in that directory?? When I looked at
the mail box of bugzilla there are thousands of
e-mails from friday to now most of them saying
permission denied messages. It's a mail from bugzilla
to bugzilla. What could be wrong.Any help is greatly
appreciated.
I modified bugzilla_email_append.pl recently but even
after reverting to the older version the mailbox 
still getting bigger and bigger.
Thanks a lot,
Srikant

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com


From gerv at mozilla.org  Mon May 12 17:26:02 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Mon, 12 May 2003 18:26:02 +0100
Subject: Migrating from 2.14 to 2.16
In-Reply-To: <1052753858.723.2.camel@devpc2>
References: <1052753858.723.2.camel@devpc2>
Message-ID: <3EBFD92A.9080900@mozilla.org>

Jordi S. Bunster wrote:

> What is the preferred migration path for the tables? Just a dump and
> restore? Or has table information changed?

None of the above. See the manual - but basically, install the new 
version over the top, and run checksetup.pl, which will migrate the 
database for you.

Gerv



From bunsterj at convergentdev.com  Mon May 12 18:08:33 2003
From: bunsterj at convergentdev.com (Jordi S. Bunster)
Date: 12 May 2003 14:08:33 -0400
Subject: Migrating from 2.14 to 2.16
In-Reply-To: <3EBFD92A.9080900@mozilla.org>
References: <1052753858.723.2.camel@devpc2>  <3EBFD92A.9080900@mozilla.org>
Message-ID: <1052762915.1659.1.camel@devpc2>

On Mon, 2003-05-12 at 13:26, Gervase Markham wrote:

> None of the above. See the manual - but basically, install the new 
> version over the top, and run checksetup.pl, which will migrate the 
> database for you.

You know what? It is so blatantly obvious, that if you would have
replied with a RTFM single line, I would definetly not have the right to
be pissed off. I'll SO try to do it next time.

 -- Jordi



From caseyg at chsamerica.com  Mon May 12 18:16:48 2003
From: caseyg at chsamerica.com (Casey Gregoire)
Date: Mon, 12 May 2003 14:16:48 -0400
Subject: Migrating from 2.14 to 2.16
Message-ID: <C3EB95A31BDAD511827C00B0D0F95AF577AFCC@BUCKWHEAT>

It might be important to note that this is a ONE-WAY migration. I did not
see it in the manual warning you that if you upgrade the database to a newer
version for Bugzilla you will not be able to go back with out making your
own reverse version of the checksetup.pl's upgrade code. Should this be in
the manual?

Thanks,
	Casey Gregoire

-----Original Message-----
From: Jordi S. Bunster [mailto:bunsterj at convergentdev.com]
Sent: Monday, May 12, 2003 2:09 PM
To: Bugzilla dev list
Subject: Re: Migrating from 2.14 to 2.16

On Mon, 2003-05-12 at 13:26, Gervase Markham wrote:

> None of the above. See the manual - but basically, install the new
> version over the top, and run checksetup.pl, which will migrate the
> database for you.

You know what? It is so blatantly obvious, that if you would have
replied with a RTFM single line, I would definetly not have the right to
be pissed off. I'll SO try to do it next time.

 -- Jordi

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


From caseyg at chsamerica.com  Mon May 12 20:00:23 2003
From: caseyg at chsamerica.com (Casey Gregoire)
Date: Mon, 12 May 2003 16:00:23 -0400
Subject: Security
Message-ID: <C3EB95A31BDAD511827C00B0D0F95AF577B08B@BUCKWHEAT>

Is it possible to have access rights to only edit certain products? At my
office we have about 10 projects, but we want managers on say two products
to add components to them, but not any other products. Or am I correct in
thinking that if you can edit products you can edit ALL of them? Is this
something you can control on 2.17.4? (I am on 2.17.4) I know you can be able
to only set certain bits for groups on certain users, but can your restrict
the right to change products, versions and milestones on a certain product
to only particular people?
 
Thank you,
            Casey Gregoire
            Programmer
            CHS of America
            100 1st Ave S. Suite 601
            St. Petersburg, FL 33701
            Phone - (727) 824-0800 ext 1236

Every great achievement was once impossible. -- Anonymous
I'd like to get started on time, if we can, inasmuch as we're late already.
-- Larry Gelbart
Nothing is accomplished without passion. -- My Fortune Cookie
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20030512/6916ae5e/attachment.html>

From bugreport at peshkin.net  Mon May 12 22:13:27 2003
From: bugreport at peshkin.net (Joel Peshkin)
Date: Mon, 12 May 2003 15:13:27 -0700
Subject: Security
In-Reply-To: <C3EB95A31BDAD511827C00B0D0F95AF577B08B@BUCKWHEAT>
References: <C3EB95A31BDAD511827C00B0D0F95AF577B08B@BUCKWHEAT>
Message-ID: <3EC01C87.90508@peshkin.net>

Casey Gregoire wrote:

> Is it possible to have access rights to only edit certain products? At 
> my office we have about 10 projects, but we want managers on say two 
> products to add components to them, but not any other products. Or am 
> I correct in thinking that if you can edit products you can edit ALL 
> of them? Is this something you can control on 2.17.4? (I am on 2.17.4) 
> I know you can be able to only set certain bits for groups on certain 
> users, but can your restrict the right to change products, versions 
> and milestones on a certain product to only particular people?
>
In 2.17.4, you can define an arbitrarily large number of groups and use 
them for roles if you don't mind hacking a bit.

To do this, you would have to create groups like....
"role_editproduct_foo" for product "foo" and "role_editproduct_bar" for 
product "bar"

Then, you alter the editproducts.cgi and editcomponents.cgi to add 
checks where you call UserInGroup() to check to see if the user is in a 
group called "role_editproduct_$productname" and throw an error if they 
are not permitted.

-Joel





From rms at gnu.org  Tue May 13 01:47:05 2003
From: rms at gnu.org (Richard Stallman)
Date: Mon, 12 May 2003 21:47:05 -0400
Subject: GnuBucks Follow-up
In-Reply-To: <1052712503.23240.149.camel@larry.localnet>
	(cjcollier@colliertech.org)
References: <1052712503.23240.149.camel@larry.localnet>
Message-ID: <E19FOsj-0005Eu-00@fencepost.gnu.org>

    First of all, in terms of Karma Points (Heretofore, GnuBucks), I
    apologize for using the GNU moniker without asking the GNU project first
    for permission.  I was not aware this was a faux pas.

I wouldn't want to make it sound so harsh.  I'm touched that you
thoght of doing this under GNU auspices.

    Since frendster.com is not a Free Software project, I've decided that
    the idea should be re-implemented

I don't know anything about friendster, so I have trouble
understanding what you say about this.  You're talking about how to
implement a system to do a job I don't know much about.

Rather than talking about the implementation, I would like to look at
the overall idea.  Why do I want a site to store my list of
acquaintances?  I'd rather do this on my own computer where the police
need a search warrant to get it.


From cjcollier at colliertech.org  Tue May 13 14:46:35 2003
From: cjcollier at colliertech.org (C.J. Collier)
Date: 13 May 2003 07:46:35 -0700
Subject: GnuBucks Follow-up
In-Reply-To: <E19FOsj-0005Eu-00@fencepost.gnu.org>
References: <1052712503.23240.149.camel@larry.localnet>
	 <E19FOsj-0005Eu-00@fencepost.gnu.org>
Message-ID: <1052837195.18340.58.camel@larry.localnet>

On Mon, 2003-05-12 at 18:47, Richard Stallman wrote:
>     First of all, in terms of Karma Points (Heretofore, GnuBucks), I
>     apologize for using the GNU moniker without asking the GNU project first
>     for permission.  I was not aware this was a faux pas.
> 
> I wouldn't want to make it sound so harsh.  I'm touched that you
> thoght of doing this under GNU auspices.

Then perhaps GnuBucks will be the internal code name for Karma Points
(or whatever it ends up being called). ;)

>     Since frendster.com is not a Free Software project, I've decided that
>     the idea should be re-implemented
> 
> I don't know anything about friendster, so I have trouble
> understanding what you say about this.  You're talking about how to
> implement a system to do a job I don't know much about.

Okey doke.  Give me a week or so.  I just got a couple of new contracts,
and I need to eat.  So I'll get on this after I finish a couple of
those.

In the meantime, I've set you up with an alias:

rms-friendster at colliertech.org: rms at gnu.org

which you can use if you're interested in looking at the current
implementation, but need an easy way to filter incoming mail from
friendster.  My profile is here:

http://www.friendster.com/user.jsp?id=69291

> Rather than talking about the implementation, I would like to look at
> the overall idea.  Why do I want a site to store my list of
> acquaintances?  I'd rather do this on my own computer where the police
> need a search warrant to get it.

And that's the end goal!  This whole ISPs-are-the-end-all-be-all stuff
kinda' scares me.  I like running my internet services from my house as
well.  But since ISPs are the ones that have the largest user base, they
are the easiest targets.  Making the software easy enough to install
that each user can run a server to catch, store and display incoming
requests on their own machine is, I agree, a better solution.  And I
think the same should be true of things like email, calendars, personal
software dev bug tracking, and e-money.  Why trust others with your data
if it'd be just as easy to trust yourself?

C.J.




From jamessmith449 at lycos.co.uk  Wed May 14 21:09:04 2003
From: jamessmith449 at lycos.co.uk (James Smith)
Date: Wed, 14 May 2003 16:09:04 -0500
Subject: Xml Responses
Message-ID: <005501c31a5d$0f20e2c0$1fec55c8@supercabletv.net.co>

Hi

I wanna know if there's any possiblity to send a flag, to inform bugzilla
that must return a xml response rather than html.

Is it implemented?

or is there any plan to do something similar?

Thanx



From rms at gnu.org  Wed May 14 21:04:37 2003
From: rms at gnu.org (Richard Stallman)
Date: Wed, 14 May 2003 17:04:37 -0400
Subject: GnuBucks Follow-up
In-Reply-To: <1052837195.18340.58.camel@larry.localnet>
	(cjcollier@colliertech.org)
References: <1052712503.23240.149.camel@larry.localnet>
	 <E19FOsj-0005Eu-00@fencepost.gnu.org> <1052837195.18340.58.camel@larry.localnet>
Message-ID: <E19G3QT-0002VO-00@fencepost.gnu.org>

      Why trust others with your data
    if it'd be just as easy to trust yourself?

You certainly cannot trust a business in the US with information.
The police can collect it without even a search warrant and the
business is not allowed to tell you it has happened.


From myk at mozilla.org  Wed May 14 23:18:50 2003
From: myk at mozilla.org (Myk Melez)
Date: Wed, 14 May 2003 16:18:50 -0700
Subject: Xml Responses
In-Reply-To: <005501c31a5d$0f20e2c0$1fec55c8@supercabletv.net.co>
References: <005501c31a5d$0f20e2c0$1fec55c8@supercabletv.net.co>
Message-ID: <3EC2CEDA.1080600@mozilla.org>

James Smith wrote:

>Hi
>
>I wanna know if there's any possiblity to send a flag, to inform bugzilla
>that must return a xml response rather than html.
>
>Is it implemented?
>
>or is there any plan to do something similar?
>  
>
Yes.  For buglist.cgi it's "&format=rdf".  For show_bug.cgi it's either 
"&format=xml" or xml.cgi depending on the age of your installation (the 
latter approach is older, the former approach might be so new it doesn't 
even work yet but will in the future).

-myk




From justdave at syndicomm.com  Wed May 14 23:24:04 2003
From: justdave at syndicomm.com (David Miller)
Date: Wed, 14 May 2003 19:24:04 -0400
Subject: Xml Responses
In-Reply-To: <3EC2CEDA.1080600@mozilla.org>
References: <005501c31a5d$0f20e2c0$1fec55c8@supercabletv.net.co>
 <3EC2CEDA.1080600@mozilla.org>
Message-ID: <a06001202bae8806e3701@[192.168.1.203]>

On 5/14/2003 4:18 PM -0700, Myk Melez wrote:

> James Smith wrote:
>
>>Hi
>>
>>I wanna know if there's any possiblity to send a flag, to inform bugzilla
>>that must return a xml response rather than html.
>>
>>Is it implemented?
>>
>>or is there any plan to do something similar?
>>
>>
> Yes.  For buglist.cgi it's "&format=rdf".  For show_bug.cgi it's either
> "&format=xml" or xml.cgi depending on the age of your installation (the
> latter approach is older, the former approach might be so new it doesn't
> even work yet but will in the future).

&ctype=, not &format=

xml is a content-type :)
-- 
Dave Miller      Project Leader, Bugzilla Bug Tracking System
http://www.justdave.net/             http://www.bugzilla.org/


From gerv at mozilla.org  Sat May 17 13:19:22 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Sat, 17 May 2003 14:19:22 +0100
Subject: Urgent Help Needed Please
In-Reply-To: <20030512165005.39768.qmail@web20202.mail.yahoo.com>
References: <20030512165005.39768.qmail@web20202.mail.yahoo.com>
Message-ID: <3EC636DA.1020208@mozilla.org>

usmle Prep wrote:
> We are using Bugzilla 2.16.1 version and extensively
> use the e-mail interface, the data/mimedump-tmp
> directory is growing leaps and bounds. Can we just
> delete the files in that directory??

The email interface is unsupported; you may well not find anyone who 
knows about it here.

Gerv



From gerv at mozilla.org  Sat May 17 13:35:04 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Sat, 17 May 2003 14:35:04 +0100
Subject: Migrating from 2.14 to 2.16
In-Reply-To: <C3EB95A31BDAD511827C00B0D0F95AF577AFCC@BUCKWHEAT>
References: <C3EB95A31BDAD511827C00B0D0F95AF577AFCC@BUCKWHEAT>
Message-ID: <3EC63A88.1060209@mozilla.org>

Casey Gregoire wrote:
> It might be important to note that this is a ONE-WAY migration. I did not
> see it in the manual warning you that if you upgrade the database to a newer
> version for Bugzilla you will not be able to go back with out making your
> own reverse version of the checksetup.pl's upgrade code. Should this be in
> the manual?

Quite possibly. Please file a bug :-)

Gerv



From jamessmith449 at lycos.co.uk  Sat May 17 18:43:58 2003
From: jamessmith449 at lycos.co.uk (James Smith)
Date: Sat, 17 May 2003 13:43:58 -0500
Subject: Notifications
References: <005501c31a5d$0f20e2c0$1fec55c8@supercabletv.net.co> <3EC2CEDA.1080600@mozilla.org>
Message-ID: <001701c31ca4$491c1fa0$1fec55c8@supercabletv.net.co>

Hi

I have an application, and I want it to catch the e-mail notifications sent
by bugzilla, or at least realize that a notification was sent, and then
using the notification information, do other things like send instant
messages.

Any ideas how to do that ?

Thanks,

James



From gerv at mozilla.org  Sat May 17 19:13:37 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Sat, 17 May 2003 20:13:37 +0100
Subject: Notifications
In-Reply-To: <001701c31ca4$491c1fa0$1fec55c8@supercabletv.net.co>
References: <005501c31a5d$0f20e2c0$1fec55c8@supercabletv.net.co> <3EC2CEDA.1080600@mozilla.org> <001701c31ca4$491c1fa0$1fec55c8@supercabletv.net.co>
Message-ID: <3EC689E1.2010300@mozilla.org>

James Smith wrote:
> I have an application, and I want it to catch the e-mail notifications sent
> by bugzilla, or at least realize that a notification was sent, and then
> using the notification information, do other things like send instant
> messages.
> 
> Any ideas how to do that ?

Yes; bzbot does this. Set up an email address/account to do the 
catching, and then set that account to watch basically everyone you care 
about, so it gets all bugmail. Then, parse the mails and off you go :-)

Gerv



From zach at zachlipton.com  Sat May 17 19:24:36 2003
From: zach at zachlipton.com (Zach Lipton)
Date: Sat, 17 May 2003 12:24:36 -0700
Subject: Notifications
In-Reply-To: <3EC689E1.2010300@mozilla.org>
Message-ID: <BAEBDA84.B38D%zach@zachlipton.com>

Another option would be to go to editparams.cgi as an admin and include a
line in the headers of newchanged mail like:

CC: myapplicationemailaddress at company.com

And then have your application check that address. That way, your
application would get a copy of every bugmail (not including new accounts or
password changes) sent out.


Zach

On 5/17/03 12:13 PM, "Gervase Markham" <gerv at mozilla.org> wrote:

> James Smith wrote:
>> I have an application, and I want it to catch the e-mail notifications sent
>> by bugzilla, or at least realize that a notification was sent, and then
>> using the notification information, do other things like send instant
>> messages.
>> 
>> Any ideas how to do that ?
> 
> Yes; bzbot does this. Set up an email address/account to do the
> catching, and then set that account to watch basically everyone you care
> about, so it gets all bugmail. Then, parse the mails and off you go :-)
> 
> Gerv
> 
> ----
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=zach at zachlipton.com>



From jake at bugzilla.org  Sat May 17 20:35:25 2003
From: jake at bugzilla.org (Jake)
Date: Sat, 17 May 2003 16:35:25 -0400 (EDT)
Subject: Notifications
In-Reply-To: <BAEBDA84.B38D%zach@zachlipton.com>
References: <3EC689E1.2010300@mozilla.org>
    <BAEBDA84.B38D%zach@zachlipton.com>
Message-ID: <33045.12.245.123.213.1053203725.squirrel@mail.steenhagen.us>

> Another option would be to go to editparams.cgi as an admin and include a
> line in the headers of newchanged mail like:
>
> CC: myapplicationemailaddress at company.com
>
> And then have your application check that address. That way, your
> application would get a copy of every bugmail (not including new accounts
> or password changes) sent out.
>

If you're going to do this, keep in mind that Bugzilla sends multiple
e-mails for each bug change (one for each person getting the message) so
you will most likely be cc'd on at least 2 (reporter, owner) and probably
more.



From caseyg at chsamerica.com  Mon May 19 15:57:45 2003
From: caseyg at chsamerica.com (Casey Gregoire)
Date: Mon, 19 May 2003 11:57:45 -0400
Subject: Adding a Resolution
Message-ID: <C3EB95A31BDAD511827C00B0D0F95AF57A3696@BUCKWHEAT>

The resolutions in bugs of like, fixed, wont fix and all that. Would a lot
have to be change to add a SOURCE CHANGED resolution? Its something my
manager would like to see in the system?
 
Thank you,
            Casey Gregoire
            Programmer
            CHS of America
            100 1st Ave S. Suite 601
            St. Petersburg, FL 33701
            Phone - (727) 824-0800 ext 1236

Every great achievement was once impossible. -- Anonymous
I'd like to get started on time, if we can, inasmuch as we're late already.
-- Larry Gelbart
Nothing is accomplished without passion. -- My Fortune Cookie
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20030519/db68e6a9/attachment.html>

From arvind at pixim.com  Mon May 19 17:21:12 2003
From: arvind at pixim.com (Arvind Singh)
Date: Mon, 19 May 2003 10:21:12 -0700
Subject: Adding a Resolution
Message-ID: <16020FEDDBAF5440A59EB485AC75B2BB310D55@exchange.pixim.com>

If you are not using any of the existing resolution you can chnage it to SOURCE CHANGED or
you can add a new one. The changes are simple.
The files affected are:
- bug_status.html
- checksetup.pl
- queryhelp.cgi
- localconfig.js
- collectstats.pl
 
The above changes are based on bugzilla-2.16.1 code.
 
Arvind.
-----Original Message-----
From: Casey Gregoire [mailto:caseyg at chsamerica.com]
Sent: Monday, May 19, 2003 8:58 AM
To: Bugzilla Developers (E-mail)
Subject: Adding a Resolution


The resolutions in bugs of like, fixed, wont fix and all that. Would a lot have to be change to add a SOURCE CHANGED resolution? Its something my manager would like to see in the system?
 
Thank you,
            Casey Gregoire
            Programmer
            CHS of America
            100 1st Ave S. Suite 601
            St. Petersburg, FL 33701
            Phone - (727) 824-0800 ext 1236

Every great achievement was once impossible. -- Anonymous
I'd like to get started on time, if we can, inasmuch as we're late already. -- Larry Gelbart
Nothing is accomplished without passion. -- My Fortune Cookie
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20030519/0d4fa570/attachment.html>

From RBartram at ceiamerica.com  Mon May 19 19:30:29 2003
From: RBartram at ceiamerica.com (Robert Bartram)
Date: Mon, 19 May 2003 15:30:29 -0400
Subject: Customizing Bugzilla Templates by Product
Message-ID: <DE15B6504F61D5119B10009027B0CA250394EFF0@BEAVER>

 
Hello, 
 
I'm very new to the whole Bugzilla administration and customization.  I
understand that version 2.16 as incorporated the use of templates.  I would
like to know if there is a way for a product to have it's own customized
template for entering a bug.  For instance I would like the components label
to read "Type of Issue" for one product and remain Components for all other
projects.
 
Also, is there a way to add a user defined drop down list?
 
I'm running 2.16.1 of Bugzilla.
 
I could really use a quick answer or direction on this.  Thank you in
advance, ...Rob
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20030519/26f72d51/attachment.html>

From usmlekaplan at yahoo.com  Mon May 19 20:38:22 2003
From: usmlekaplan at yahoo.com (usmle Prep)
Date: Mon, 19 May 2003 13:38:22 -0700 (PDT)
Subject: Can the bug list be sorted based on a custom field
Message-ID: <20030519203822.33402.qmail@web20209.mail.yahoo.com>

Can the bug list be sorted based on a custom_field? If
so please let me know if anyone has done and how to do
it.
Thanks a lot for your help,
Sri

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com


From gerv at mozilla.org  Mon May 19 22:05:02 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Mon, 19 May 2003 23:05:02 +0100
Subject: Customizing Bugzilla Templates by Product
In-Reply-To: <DE15B6504F61D5119B10009027B0CA250394EFF0@BEAVER>
References: <DE15B6504F61D5119B10009027B0CA250394EFF0@BEAVER>
Message-ID: <3EC9550E.7070509@mozilla.org>

Robert Bartram wrote:
> I'm very new to the whole Bugzilla administration and customization.  

This is a development list (as it probably said next to the instructions 
for subscribing.) In future, please ask administrator questions in 
netscape.public.mozilla.webtools/mozilla-webtools at mozilla.org. Thanks :-)

> I 
> understand that version 2.16 as incorporated the use of templates.  I 
> would like to know if there is a way for a product to have it's own 
> customized template for entering a bug.  For instance I would like the 
> components label to read "Type of Issue" for one product and remain 
> Components for all other projects.

Read the docs about "Bug Entry Templates". In short: yes, this is very easy.

> Also, is there a way to add a user defined drop down list?

If you just want to add it to the bug filing screen, see "Bug Entry 
Templates" again. If you want to add it everywhere, see 
http://www.gerv.net/hacking/custom-fields.html .

Gerv




From gerv at mozilla.org  Mon May 19 22:07:00 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Mon, 19 May 2003 23:07:00 +0100
Subject: Can the bug list be sorted based on a custom field
In-Reply-To: <20030519203822.33402.qmail@web20209.mail.yahoo.com>
References: <20030519203822.33402.qmail@web20209.mail.yahoo.com>
Message-ID: <3EC95584.2030800@mozilla.org>

usmle Prep wrote:
> Can the bug list be sorted based on a custom_field? 

It depends how you implemented custom fields!

In general, please ask user questions in the newsgroup; this is a 
developers mailing list really.

Gerv



From usmlekaplan at yahoo.com  Mon May 19 22:19:43 2003
From: usmlekaplan at yahoo.com (usmle Prep)
Date: Mon, 19 May 2003 15:19:43 -0700 (PDT)
Subject: Can the bug list be sorted based on a custom field
In-Reply-To: <3EC95584.2030800@mozilla.org>
Message-ID: <20030519221943.67091.qmail@web20205.mail.yahoo.com>

Hi Gerv,
Thanks for your response. Actually it's not a user
question. We are using 2.16.1 and we are unable to 
sort based on customfields. When I tried to sort based
on custom fields, it's throwing an error
"The custom sort order you specified in your form
submission contains an invalid column name
bcf26.value."
Do you know how to implement sorting on custom fields.
Thanks a lot,
Sri
 
--- Gervase Markham <gerv at mozilla.org> wrote:
> usmle Prep wrote:
> > Can the bug list be sorted based on a
> custom_field? 
> 
> It depends how you implemented custom fields!
> 
> In general, please ask user questions in the
> newsgroup; this is a 
> developers mailing list really.
> 
> Gerv
> 
> ----
> To view or change your list settings, click here:
>
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=usmlekaplan at yahoo.com>


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com


From gerv at mozilla.org  Tue May 20 08:50:01 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Tue, 20 May 2003 09:50:01 +0100
Subject: Can the bug list be sorted based on a custom field
In-Reply-To: <20030519221943.67091.qmail@web20205.mail.yahoo.com>
References: <20030519221943.67091.qmail@web20205.mail.yahoo.com>
Message-ID: <3EC9EC39.8000909@mozilla.org>

usmle Prep wrote:
> Hi Gerv,
> Thanks for your response. Actually it's not a user
> question. We are using 2.16.1 and we are unable to 
> sort based on customfields. 

2.16 doesn't support custom fields. Therefore, you either implemented 
them yourself, or used an unofficial patch. In either case, you need to 
ask the author of the code in question.

Gerv



From bunsterj at convergentdev.com  Tue May 20 15:18:56 2003
From: bunsterj at convergentdev.com (Jordi Bunster)
Date: Tue, 20 May 2003 11:18:56 -0400
Subject: Database changes
Message-ID: <oprpg8tu1jhn4c13@mail.convergentdev.com>


Hello Folks

I'm planning to introduce some big changes on bugzilla's internal logic and 
database. Here at my shop, we have much more modularity than just the two 
level (product, component) approach. What we want to do is, just have bug 
"targets", which can nest. Each one would have a unique ID, and a parent 
reference, and you can assign bugs to any of them, not just to the lowest 
level one.

It is also my intention to have a configuration file, where you can specify 
the way a target is called on the *webpages*, not internally, depending on 
its nesting depth. For example, level one would be called product, level 
two component, and three and on sub-component, so as to avoid breakage with 
existing bugzilla installations.

Knowing that this would make upgrading bugzilla here a nightmare, my 
question goes: Would the bugzilla team be willing to accept this changes, 
providing that the code is clean, follows the guidelines, and I add code to 
checksetup.pl so that it automagically migrates everything?

I'm also open to suggestions regarding the approach, if that means 
increasing the chances of the code being merged.

 -- Jordi



From bunsterj at convergentdev.com  Tue May 20 15:29:16 2003
From: bunsterj at convergentdev.com (Jordi Bunster)
Date: Tue, 20 May 2003 11:29:16 -0400
Subject: Absolute values as opposed to references
Message-ID: <oprpg9a2sshn4c13@mail.convergentdev.com>


Is there any reason in particular why certain things are static, such as 
the Operating system in a bug? Is there any particular reason why they're 
not simple references to another table with (opsysid, desc) or something 
similar?

Also, is there any particular policy that dictates that a bug description 
should not be changed, as opposed to just adding comments?

 -- Jordi



From caseyg at chsamerica.com  Tue May 20 15:47:07 2003
From: caseyg at chsamerica.com (Casey Gregoire)
Date: Tue, 20 May 2003 11:47:07 -0400
Subject: Absolute values as opposed to references
Message-ID: <C3EB95A31BDAD511827C00B0D0F95AF57A3B2E@BUCKWHEAT>

Even if its not a policy it's a good idea, because if you could change what
has been said about a bug, someone might delete information they don't think
is relevant when it really is. This seems as a protection against such a
thing. Its one of the things the people at my office who choose Bugzilla
liked most compared to the system we had made in house. (I mean aside from
the slew of features and the fact that it is web based. Unlike our old
system.)

Thanks,
	Casey Gregoire

-----Original Message-----
From: Jordi Bunster [mailto:bunsterj at convergentdev.com]
Sent: Tuesday, May 20, 2003 11:29 AM
To: developers at bugzilla.org
Subject: Absolute values as opposed to references


Is there any reason in particular why certain things are static, such as
the Operating system in a bug? Is there any particular reason why they're
not simple references to another table with (opsysid, desc) or something
similar?

Also, is there any particular policy that dictates that a bug description
should not be changed, as opposed to just adding comments?

 -- Jordi

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


From bugreport at peshkin.net  Tue May 20 16:55:12 2003
From: bugreport at peshkin.net (Joel Peshkin)
Date: Tue, 20 May 2003 09:55:12 -0700
Subject: Database changes
In-Reply-To: <oprpg8tu1jhn4c13@mail.convergentdev.com>
References: <oprpg8tu1jhn4c13@mail.convergentdev.com>
Message-ID: <3ECA5DF0.1070200@peshkin.net>

Jordi Bunster wrote:

> I'm planning to introduce some big changes on bugzilla's internal 
> logic and database. Here at my shop, we have much more modularity than 
> just the two level (product, component) approach. What we want to do 
> is, just have bug "targets", which can nest. Each one would have a 
> unique ID, and a parent reference, and you can assign bugs to any of 
> them, not just to the lowest level one.

There has been a lot of talk about doing this, but there have been an 
equal number of issues raised having to do with the UI, search 
capabilities, etc...

I strongly suggest you work on a very comprehensive proposal addressing 
all the details and showing the proposed schema changes and circulate it 
for comment before embarking on this.

>
> It is also my intention to have a configuration file, where you can 
> specify the way a target is called on the *webpages*, not internally, 
> depending on its nesting depth. For example, level one would be called 
> product, level two component, and three and on sub-component, so as to 
> avoid breakage with existing bugzilla installations.

We have been moving away from configuration files and favoring keeping 
this type of information in the database and administering it through 
the web interface.  As long as the existing components all wind up as 
components on migration, you should be OK.

>
> Knowing that this would make upgrading bugzilla here a nightmare, my 
> question goes: Would the bugzilla team be willing to accept this 
> changes, providing that the code is clean, follows the guidelines, and 
> I add code to checksetup.pl so that it automagically migrates everything?

You have to de-nightmare it in your proposal, probably through 
checksetup.  I am certain that a proposal posted here will get enough 
feedback so you will be able to tell if it is likely to get merged.  In 
particular, expect Gerv to be a major gatekeeper for the UI, expect me 
to be a stickler for group security, and expect bbaetz and myk to be 
major gatekeepers on system performance.

-Joel







From myk at mozilla.org  Tue May 20 17:15:12 2003
From: myk at mozilla.org (Myk Melez)
Date: Tue, 20 May 2003 10:15:12 -0700
Subject: Absolute values as opposed to references
In-Reply-To: <oprpg9a2sshn4c13@mail.convergentdev.com>
References: <oprpg9a2sshn4c13@mail.convergentdev.com>
Message-ID: <3ECA62A0.6080404@mozilla.org>

Jordi Bunster wrote:

>
> Is there any reason in particular why certain things are static, such 
> as the Operating system in a bug?

No reason, that's just the way it was done long ago, and we haven't had 
a need to change it yet (like we did with products and components).

> Also, is there any particular policy that dictates that a bug 
> description should not be changed, as opposed to just adding comments?

No policy, just practice.  There's a bug on changing it which has been 
open for a while and received a lot of debate, but no one has taken it 
and driven a fix (or marked it WONTFIX), so it's still an open question.

-myk




From gerv at mozilla.org  Tue May 20 23:34:01 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Wed, 21 May 2003 00:34:01 +0100
Subject: Absolute values as opposed to references
In-Reply-To: <oprpg9a2sshn4c13@mail.convergentdev.com>
References: <oprpg9a2sshn4c13@mail.convergentdev.com>
Message-ID: <3ECABB69.4020905@mozilla.org>

Jordi Bunster wrote:
> Is there any reason in particular why certain things are static, such as 
> the Operating system in a bug? Is there any particular reason why 
> they're not simple references to another table with (opsysid, desc) or 
> something similar?

Because that is the way they were originally, and it will eventually be 
fixed by a proper custom fields implementation, so there's no point 
implementing a halfway solution.

> Also, is there any particular policy that dictates that a bug 
> description should not be changed, as opposed to just adding comments?

The general sanity of not allowing people to change history :-)

Gerv



From dberlin at dberlin.org  Wed May 21 16:09:18 2003
From: dberlin at dberlin.org (Daniel Berlin)
Date: Wed, 21 May 2003 12:09:18 -0400
Subject: regex based groups and email address changing
Message-ID: <9338FE27-8BA6-11D7-AF07-000A95A34564@dberlin.org>

I have user groups based on regexes (like *.gcc.gnu.org)
If people change their email address, so that it doesn't match the 
regex anymore, are they auto-added to the approriate groups they used 
to be part of?
I've never seen a bug about it, so I assume they are, but i figured 
whoever implemented email address changing is on this list, and would 
know.

--Dan



From bugreport at peshkin.net  Wed May 21 16:31:41 2003
From: bugreport at peshkin.net (Joel Peshkin)
Date: Wed, 21 May 2003 09:31:41 -0700
Subject: regex based groups and email address changing
In-Reply-To: <9338FE27-8BA6-11D7-AF07-000A95A34564@dberlin.org>
References: <9338FE27-8BA6-11D7-AF07-000A95A34564@dberlin.org>
Message-ID: <3ECBA9ED.5030401@peshkin.net>

Daniel Berlin wrote:

> I have user groups based on regexes (like *.gcc.gnu.org)
> If people change their email address, so that it doesn't match the 
> regex anymore, are they auto-added to the approriate groups they used 
> to be part of?
> I've never seen a bug about it, so I assume they are, but i figured 
> whoever implemented email address changing is on this list, and would 
> know.
>
> --Dan 


For group regexps applied in 2.16.* and prior, the regexp only applies 
when an account is initially created and is then indistinguishable from 
an explicitly granted group permission.  For 2.17 and on, the group 
regexps are applied continuously so that a user will gain and lose group 
permissions as the email is changed.

-Joel





From dberlin at dberlin.org  Wed May 21 19:07:20 2003
From: dberlin at dberlin.org (Daniel Berlin)
Date: Wed, 21 May 2003 15:07:20 -0400
Subject: regex based groups and email address changing
In-Reply-To: <3ECBA9ED.5030401@peshkin.net>
Message-ID: <7230A780-8BBF-11D7-AF07-000A95A34564@dberlin.org>


On Wednesday, May 21, 2003, at 12:31  PM, Joel Peshkin wrote:

> Daniel Berlin wrote:
>
>> I have user groups based on regexes (like *.gcc.gnu.org)
>> If people change their email address, so that it doesn't match the 
>> regex anymore, are they auto-added to the approriate groups they used 
>> to be part of?
>> I've never seen a bug about it, so I assume they are, but i figured 
>> whoever implemented email address changing is on this list, and would 
>> know.
>>
>> --Dan
>
>
> For group regexps applied in 2.16.* and prior, the regexp only applies 
> when an account is initially created and is then indistinguishable 
> from an explicitly granted group permission.  For 2.17 and on, the 
> group regexps are applied continuously so that a user will gain and 
> lose group permissions as the email is changed.
>

Hmmm.
Okay. Is this by design? I can understand the arguments for and against 
it, i just want to know whether to file a bug on it.
>



From bugreport at peshkin.net  Wed May 21 21:53:42 2003
From: bugreport at peshkin.net (Joel Peshkin)
Date: Wed, 21 May 2003 14:53:42 -0700
Subject: regex based groups and email address changing
In-Reply-To: <7230A780-8BBF-11D7-AF07-000A95A34564@dberlin.org>
References: <7230A780-8BBF-11D7-AF07-000A95A34564@dberlin.org>
Message-ID: <3ECBF566.8020609@peshkin.net>

Daniel Berlin wrote:

>
> On Wednesday, May 21, 2003, at 12:31  PM, Joel Peshkin wrote:
>
>> For group regexps applied in 2.16.* and prior, the regexp only 
>> applies when an account is initially created and is then 
>> indistinguishable from an explicitly granted group permission.  For 
>> 2.17 and on, the group regexps are applied continuously so that a 
>> user will gain and lose group permissions as the email is changed.
>>
>
> Hmmm.
> Okay. Is this by design? I can understand the arguments for and 
> against it, i just want to know whether to file a bug on it.
>
>> -
>
Yes.  This is by design.   There is bug 181589 addressing adding a 
mass-edit capability for editgroups. 

-Joel







From arthur.barrett at march-hare.com  Wed May 21 23:40:13 2003
From: arthur.barrett at march-hare.com (Arthur Barrett)
Date: Thu, 22 May 2003 09:40:13 +1000
Subject: Sybase and/or MSSQL?
Message-ID: <EA4F8DA70D52D51193660080C8D5886B101858@NTSRVR01>

Hi all,

I posted here a couple of months back for information on using Bugzilla with
a Sybase or MSSQL database.

I got some great feedback (thanks) - the most notable of which was that
there were some changes coming that I should look out for.

Have these turned up?

If not - is there any chance of just getting the diff's ?

Thanks,



Arthur Barrett


From justdave at syndicomm.com  Wed May 21 23:57:42 2003
From: justdave at syndicomm.com (David Miller)
Date: Wed, 21 May 2003 19:57:42 -0400
Subject: Sybase and/or MSSQL?
In-Reply-To: <EA4F8DA70D52D51193660080C8D5886B101858@NTSRVR01>
References: <EA4F8DA70D52D51193660080C8D5886B101858@NTSRVR01>
Message-ID: <a06001206baf1bf3312b8@[192.168.1.204]>

On 5/22/2003 9:40 AM +1000, Arthur Barrett wrote:

> Hi all,
>
> I posted here a couple of months back for information on using Bugzilla with
> a Sybase or MSSQL database.
>
> I got some great feedback (thanks) - the most notable of which was that
> there were some changes coming that I should look out for.
>
> Have these turned up?

They haven't yet.  I'll probably get some of them up one of these days but
no idea how soon.  Every time I try, some other "emergency" comes up that I
have to fix instead of porting the patches out. :)

I will tell you that performance SUCKS with Sybase, compared to MySQL, at
least with the existing Bugzilla code.  Sybase seems designed for dealing
with HUGE amounts of data, and the only places we deal with a huge amount
of data is in buglist.cgi (and Sybase does buglist.cgi pretty well).
Everywhere else we're dealing with little tiny bits of information...
Sybase will spend 13 seconds analyzing and generating a query plan for a
query that takes .5 seconds to run once it actually runs it, and MySQL runs
the same query (including plan generation) in that same .5 seconds (this is
the query that loads an individual bug for the show_bug page).  So now
we're doing things like moving static queries into stored procedures
(because if it's in a procedure, the query plan gets compiled when the
procedure is stored, and is saved with the procedure) and moving frequent
lookup operations into versioncache, and so forth.
-- 
Dave Miller      Project Leader, Bugzilla Bug Tracking System
http://www.justdave.net/             http://www.bugzilla.org/


From dberlin at dberlin.org  Thu May 22 00:18:42 2003
From: dberlin at dberlin.org (Daniel Berlin)
Date: Wed, 21 May 2003 20:18:42 -0400
Subject: Sybase and/or MSSQL?
In-Reply-To: <a06001206baf1bf3312b8@[192.168.1.204]>
Message-ID: <F1F37B57-8BEA-11D7-AF07-000A95A34564@dberlin.org>


On Wednesday, May 21, 2003, at 07:57  PM, David Miller wrote:

> On 5/22/2003 9:40 AM +1000, Arthur Barrett wrote:
>
>> Hi all,
>>
>> I posted here a couple of months back for information on using 
>> Bugzilla with
>> a Sybase or MSSQL database.
>>
>> I got some great feedback (thanks) - the most notable of which was 
>> that
>> there were some changes coming that I should look out for.
>>
>> Have these turned up?
>
> They haven't yet.  I'll probably get some of them up one of these days 
> but
> no idea how soon.  Every time I try, some other "emergency" comes up 
> that I
> have to fix instead of porting the patches out. :)
>
> I will tell you that performance SUCKS with Sybase, compared to MySQL, 
> at
> least with the existing Bugzilla code.

Welcome to the wonders of sucky time-consuming query plan generators.
I've seen other DB's that do this, i just try to avoid them like the 
plague.

>  Sybase seems designed for dealing
> with HUGE amounts of data, and the only places we deal with a huge 
> amount
> of data is in buglist.cgi (and Sybase does buglist.cgi pretty well).
> Everywhere else we're dealing with little tiny bits of information...
> Sybase will spend 13 seconds analyzing and generating a query plan for 
> a
> query that takes .5 seconds to run once it actually runs it, and MySQL 
> runs
> the same query (including plan generation) in that same .5 seconds 
> (this is
> the query that loads an individual bug for the show_bug page).  So now
> we're doing things like moving static queries into stored procedures

Does Sybase have a prepared query type deal you could use?
Then you could use dbi's prepare_cached rather than stored procedures.

That + sharing DBI instances between bugzilla instances should make it 
fast enough.



From bbaetz at acm.org  Thu May 22 10:54:18 2003
From: bbaetz at acm.org (Bradley Baetz)
Date: Thu, 22 May 2003 20:54:18 +1000
Subject: Sybase and/or MSSQL?
In-Reply-To: <a06001206baf1bf3312b8@[192.168.1.204]>
References: <EA4F8DA70D52D51193660080C8D5886B101858@NTSRVR01> <a06001206baf1bf3312b8@[192.168.1.204]>
Message-ID: <20030522105418.GB12872@mango.home>

On Wed, May 21, 2003 at 07:57:42PM -0400, David Miller wrote:
> Sybase will spend 13 seconds analyzing and generating a query plan for a
> query that takes .5 seconds to run once it actually runs it, and MySQL runs
> the same query (including plan generation) in that same .5 seconds

If you use placeholders, will sybase optimise it for you like Oracle
does, and so you only pay that price once?

Bradley


From justdave at syndicomm.com  Thu May 22 11:35:38 2003
From: justdave at syndicomm.com (David Miller)
Date: Thu, 22 May 2003 07:35:38 -0400
Subject: Sybase and/or MSSQL?
In-Reply-To: <20030522105418.GB12872@mango.home>
References: <EA4F8DA70D52D51193660080C8D5886B101858@NTSRVR01>
 <a06001206baf1bf3312b8@[192.168.1.204]>
 <20030522105418.GB12872@mango.home>
Message-ID: <a06001201baf2661f324c@[192.168.1.204]>

On 5/22/2003 8:54 PM +1000, Bradley Baetz wrote:

> On Wed, May 21, 2003 at 07:57:42PM -0400, David Miller wrote:
>> Sybase will spend 13 seconds analyzing and generating a query plan for a
>> query that takes .5 seconds to run once it actually runs it, and MySQL runs
>> the same query (including plan generation) in that same .5 seconds
>
> If you use placeholders, will sybase optimise it for you like Oracle
> does, and so you only pay that price once?

Sure, because using placeholders puts it in a stored procedure temporarily
(which caches the query plan).  Unfortunately that's a rather large price
to pay, even once, and it normally only used once anyway, unless mod_perl
is working and it can be cached between connections.
-- 
Dave Miller      Project Leader, Bugzilla Bug Tracking System
http://www.justdave.net/             http://www.bugzilla.org/


From bbaetz at acm.org  Thu May 22 11:46:15 2003
From: bbaetz at acm.org (Bradley Baetz)
Date: Thu, 22 May 2003 21:46:15 +1000
Subject: Sybase and/or MSSQL?
In-Reply-To: <a06001201baf2661f324c@[192.168.1.204]>
References: <EA4F8DA70D52D51193660080C8D5886B101858@NTSRVR01> <a06001206baf1bf3312b8@[192.168.1.204]> <20030522105418.GB12872@mango.home> <a06001201baf2661f324c@[192.168.1.204]>
Message-ID: <20030522114615.GA13290@mango.home>

On Thu, May 22, 2003 at 07:35:38AM -0400, David Miller wrote:
> Sure, because using placeholders puts it in a stored procedure temporarily
> (which caches the query plan).  Unfortunately that's a rather large price
> to pay, even once, and it normally only used once anyway, unless mod_perl
> is working and it can be cached between connections.

Thats not what I meant. Oracle will cache the plan in the shared pool,
to be shared by all backends. Can't you just turn off its optimisaton
stuff for the simple queries?

Bradley


From justdave at syndicomm.com  Thu May 22 11:48:25 2003
From: justdave at syndicomm.com (David Miller)
Date: Thu, 22 May 2003 07:48:25 -0400
Subject: Sybase and/or MSSQL?
In-Reply-To: <20030522114615.GA13290@mango.home>
References: <EA4F8DA70D52D51193660080C8D5886B101858@NTSRVR01>
 <a06001206baf1bf3312b8@[192.168.1.204]>
 <20030522105418.GB12872@mango.home>
 <a06001201baf2661f324c@[192.168.1.204]>
 <20030522114615.GA13290@mango.home>
Message-ID: <a06001202baf2696bf857@[192.168.1.204]>

On 5/22/2003 9:46 PM +1000, Bradley Baetz wrote:

> On Thu, May 22, 2003 at 07:35:38AM -0400, David Miller wrote:
>> Sure, because using placeholders puts it in a stored procedure temporarily
>> (which caches the query plan).  Unfortunately that's a rather large price
>> to pay, even once, and it normally only used once anyway, unless mod_perl
>> is working and it can be cached between connections.
>
> Thats not what I meant. Oracle will cache the plan in the shared pool,
> to be shared by all backends. Can't you just turn off its optimisaton
> stuff for the simple queries?

Our DBA hasn't found a way to do that yet.
-- 
Dave Miller      Project Leader, Bugzilla Bug Tracking System
http://www.justdave.net/             http://www.bugzilla.org/


From bbaetz at acm.org  Thu May 22 12:01:35 2003
From: bbaetz at acm.org (Bradley Baetz)
Date: Thu, 22 May 2003 22:01:35 +1000
Subject: Sybase and/or MSSQL?
In-Reply-To: <a06001202baf2696bf857@[192.168.1.204]>
References: <EA4F8DA70D52D51193660080C8D5886B101858@NTSRVR01> <a06001206baf1bf3312b8@[192.168.1.204]> <20030522105418.GB12872@mango.home> <a06001201baf2661f324c@[192.168.1.204]> <20030522114615.GA13290@mango.home> <a06001202baf2696bf857@[192.168.1.204]>
Message-ID: <20030522120135.GB13290@mango.home>

On Thu, May 22, 2003 at 07:48:25AM -0400, David Miller wrote:
> 
> Our DBA hasn't found a way to do that yet.

Its a database feature - it either does or it doesn't. I don't know any
other db which does, though. Postgres lets you PREPARE a statement, but
its on a per connection basis and has to be done manually.

Bradley


From mrsantos at trust.com.br  Thu May 22 11:23:37 2003
From: mrsantos at trust.com.br (Mauricio Rodrigues)
Date: Thu, 22 May 2003 09:23:37 -0200
Subject: Help ME
Message-ID: <3ECCB339.7060307@trust.com.br>

Please, help me, my bugzilla it is not appearing no image, what I must 
make?



From geeta.tripathi at bhartitelesoft.com  Thu May 22 16:31:40 2003
From: geeta.tripathi at bhartitelesoft.com (geeta.tripathi at bhartitelesoft.com)
Date: Thu, 22 May 2003 16:31:40 GMT
Subject: Help ME
Message-ID: <200305221631.h4MGVdT05608@mail.bhartitelesoft.com>

Have you checked the Server Error log file , infact what 
error are you getting


 Please, help me, my bugzilla it is not appearing no image, 
what I must 
> make?
> 
> ----
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?
user=geeta.tripathi at bhartitelesoft.com>
> 


----------------------------------------------------------
http://www.bhartitelesoft.com
Telecommunication and E-Commerce solutions for the future.




From gerv at mozilla.org  Thu May 22 17:45:43 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Thu, 22 May 2003 18:45:43 +0100
Subject: Database changes
In-Reply-To: <oprpg8tu1jhn4c13@mail.convergentdev.com>
References: <oprpg8tu1jhn4c13@mail.convergentdev.com>
Message-ID: <3ECD0CC7.3070409@mozilla.org>

Jordi Bunster wrote:

> I'm planning to introduce some big changes on bugzilla's internal logic 
> and database. Here at my shop, we have much more modularity than just 
> the two level (product, component) approach. What we want to do is, just 
> have bug "targets", which can nest. Each one would have a unique ID, and 
> a parent reference, and you can assign bugs to any of them, not just to 
> the lowest level one.

Have you thought about how the UI would work for this? Have you ever 
seen Bugzilla's "intermediate screen" when you change products? How 
would you avoid that? Remember, we can't depend on JS at the client.

Past discussions have reached the conclusion that:
- A third level is desireable, and if someone implements it, great
- Arbitrary levels above 3 are too much of a UI and config nightmare
   for the relatively small extra benefit you'd get.

> It is also my intention to have a configuration file, where you can 
> specify the way a target is called on the *webpages*, not internally, 
> depending on its nesting depth. For example, level one would be called 
> product, level two component, and three and on sub-component, so as to 
> avoid breakage with existing bugzilla installations.

This sort of naming goes in templates, so it can be localised.

> Knowing that this would make upgrading bugzilla here a nightmare, my 
> question goes: Would the bugzilla team be willing to accept this 
> changes, providing that the code is clean, follows the guidelines, and I 
> add code to checksetup.pl so that it automagically migrates everything?

We certainly wouldn't commit to doing so without a more concrete 
proposal :-)

Gerv




From caseyg at chsamerica.com  Thu May 22 17:53:06 2003
From: caseyg at chsamerica.com (Casey Gregoire)
Date: Thu, 22 May 2003 13:53:06 -0400
Subject: Database changes
Message-ID: <C3EB95A31BDAD511827C00B0D0F95AF57BBE71@BUCKWHEAT>

One subcomponents more than three levels deep:

One way to handle multiple levels deep UI wise is to show them all as
component:subcomponent:subsubcomponent:subsubsubcomponent. This would only
require a larger, or scrollable box for the Component which is already
there. We actually simulate subcomponents this way by adding components in
the above naming convention. But when it comes to bugs by component reports
this does not give us what Jordi is trying to do would be able to give us. 

Thanks,
	Casey Gregoire

-----Original Message-----
From: Gervase Markham [mailto:gerv at mozilla.org]
Sent: Thursday, May 22, 2003 1:46 PM
To: developers at bugzilla.org
Subject: Re: Database changes

Jordi Bunster wrote:

> I'm planning to introduce some big changes on bugzilla's internal logic
> and database. Here at my shop, we have much more modularity than just
> the two level (product, component) approach. What we want to do is, just
> have bug "targets", which can nest. Each one would have a unique ID, and
> a parent reference, and you can assign bugs to any of them, not just to
> the lowest level one.

Have you thought about how the UI would work for this? Have you ever
seen Bugzilla's "intermediate screen" when you change products? How
would you avoid that? Remember, we can't depend on JS at the client.

Past discussions have reached the conclusion that:
- A third level is desireable, and if someone implements it, great
- Arbitrary levels above 3 are too much of a UI and config nightmare
   for the relatively small extra benefit you'd get.

> It is also my intention to have a configuration file, where you can
> specify the way a target is called on the *webpages*, not internally,
> depending on its nesting depth. For example, level one would be called
> product, level two component, and three and on sub-component, so as to
> avoid breakage with existing bugzilla installations.

This sort of naming goes in templates, so it can be localised.

> Knowing that this would make upgrading bugzilla here a nightmare, my
> question goes: Would the bugzilla team be willing to accept this
> changes, providing that the code is clean, follows the guidelines, and I
> add code to checksetup.pl so that it automagically migrates everything?

We certainly wouldn't commit to doing so without a more concrete
proposal :-)

Gerv


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


From gerv at mozilla.org  Thu May 22 18:04:32 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Thu, 22 May 2003 19:04:32 +0100
Subject: Custom fields design doc
In-Reply-To: <20030509065001.B47ABBCDC@diggity.schwag.org>
References: <20030509065001.B47ABBCDC@diggity.schwag.org>
Message-ID: <3ECD1130.7030702@mozilla.org>

Sean McAfee wrote:

> field_id integer auto_increment primary key,
> field_name tinytext not null,
> display_name tinytext not null,

If this isn't in templates, it can't be localised - i.e. you can only 
have a single value, no matter how many nationalities of people use your 
Bugzilla. I still think we should have a mechanism where it uses 
field_name to begin with, and you then define display names in templates 
on a per-language basis...

> field_type char binary not null,
> required bool not null,
> selection_id integer references cf_selections(selection_id)
> 
> The field_type column is 'i' for integer fields, 'c' for short string
> fields, 'C' for long string fields, 'd' for date-only fields, 'D' for
> date-time fields, 's' for single-selection fields, and 'S' for
> multiselection fields.

The following make more sense to me:
i: integer
s: string
l: long string
d: date
t: date-time
e: single-select (e for enum; OK, this one's a bit iffy)
m: multi-select

The upper/lower case distinction doesn't always mean the same thing, so 
is a bit confusing IMO.

> The selection_id column is an index to the cf_selections and
> cf_selection_labels tables for fields of type Selection, and is NULL
> for other types.
> 
> cf_groups
> ---------
> group_id integer auto_increment primary key,
> group_name tinytext
> 
> This table contains one row for every custom field group.  The name
> may be NULL for reasons described below.

I'm having trouble understanding this proposal, because of one big 
question: what's a custom field group?

> cf_product_members
> ------------------
> product smallint references products(id),
> group_id integer not null references cf_groups(group_id),
> display_index integer not null,
> index (product)
> 
> This table describes which groups belong to which products, and the
> order in which the groups should be displayed to users.  The global
> scope is described by rows with product = NULL.

"display_index" should have the same name as the fields which do the 
same thing in other tables (can't remember what it is offhand.)

> cf_selections
> -------------
> selection_id integer auto_increment primary key,
> unset_label tinytext not null
> 
> The unset_label column is the text which represents the "empty set"
> value of single-selection fields.
> 
> cf_selection_labels
> -------------------
> label_id integer auto_increment primary key,
> selection_id integer not null references cf_selections(selection_id),
> label_index integer not null,
> label tinytext not null,
> index (selection_id)

Why can these two tables not be combined?

> For each single-selection field, there is one row in the table.  The
> selection_id is NULL if the field is unset; otherwise it references a
> row in the cf_selection_labels table.

Surely "there's no row present if the field is unset"? This matches the 
behaviour for multi-selects.

> For each multiselection field, there are as many rows in the table as
> there are selected strings in the field's value.  Each selection_id
> references a row in the cf_selection_labels table.
> 
> *****
> 
> The following six tables hold bug activity data.

Dude, scrap this! Use our current tables for bug activity data. Please! 
:-) Store the name of the field, what it changed from, and what it 
changed to, just like now. That's fine. Really.

> FILE SYSTEM
> ===========
> 
> All custom-field-related templates go in the directory
> $BUGZILLA_ROOT/template/en/default/custom.

That's rather confusing, because we have a template/en/custom for custom 
templates. You could have "custom-fields", which would be better, but 
otherwise they'd just live in whichever part of the template tree they 
were relevant to.

> ADMINISTRATION
> ==============
> 
> Each page contains a single form, which always contains a hidden field
> called "context".

We call this "action" everywhere else.

> Initial page
> ------------
> Context:  choose-scope
> Template: template/en/default/custom/choose-scope.html.tmpl
> 
> The user may select a scope via either of the following three elements:

What is a scope?

Regarding the rest of the proposal: I may well have comments, but I 
can't make them until some of the big questions (like: what is all this 
groups stuff?) are answered.

And, importantly, if this is a design document, there is no place in it 
for code. It's just obfuscating, and premature detail.

If you are in fact in the middle of implementing this exactly as you've 
designed it above, you might as well say so and be done with it :-)

Gerv



From dberlin at dberlin.org  Fri May 23 01:25:01 2003
From: dberlin at dberlin.org (Daniel Berlin)
Date: Thu, 22 May 2003 21:25:01 -0400
Subject: Throw GCC on the HOF
Message-ID: <5FB93110-8CBD-11D7-85C9-000A95A34564@dberlin.org>

As of yesterday, we now are Bugzilla-only.

Yay!

I'll be filing some bugzilla.mozilla.org bugs for simple small things i 
noticed (The month and day are reversed in the date format string in 
GetLongDesciptionsAsText fer instance), and for some default template 
improvements (Like alternating background colors on the bug list 
table), etc.
--Dan



From etzwane at schwag.org  Fri May 23 02:32:23 2003
From: etzwane at schwag.org (Sean McAfee)
Date: Thu, 22 May 2003 22:32:23 -0400
Subject: Custom fields design doc
In-Reply-To: <3ECD1130.7030702@mozilla.org>
Message-ID: <20030523023223.B3224BC52@diggity.schwag.org>

Gervase Markham <gerv at mozilla.org> wrote:
>Sean McAfee wrote:
>> field_id integer auto_increment primary key,
>> field_name tinytext not null,
>> display_name tinytext not null,

>If this isn't in templates, it can't be localised - i.e. you can only 
>have a single value, no matter how many nationalities of people use your 
>Bugzilla. I still think we should have a mechanism where it uses 
>field_name to begin with, and you then define display names in templates 
>on a per-language basis...

By this time, my desire to avoid requiring the admin to twiddle templates is
well-known.  Hmmm.  OK, how about storing display names in a table like
this:

cf_names
--------
field_id integer not null references custom_fields(field_id),
locale tinytext not null,
display_name tinytext not null

A "Current locale:" selection field could be added to the main custom
fields admin screen.  Changing it would cause all of the display names to be
shown according to the new locale.

>> The field_type column is 'i' for integer fields, 'c' for short string
>> fields, 'C' for long string fields, 'd' for date-only fields, 'D' for
>> date-time fields, 's' for single-selection fields, and 'S' for
>> multiselection fields.

>The following make more sense to me:
>i: integer
>s: string
>l: long string
>d: date
>t: date-time
>e: single-select (e for enum; OK, this one's a bit iffy)
>m: multi-select

>The upper/lower case distinction doesn't always mean the same thing, so 
>is a bit confusing IMO.

Well, perhaps.  I was trying to let the case of the type take the place of
my old 'extended' field.

>> cf_groups
>> ---------
>> group_id integer auto_increment primary key,
>> group_name tinytext
>> 
>> This table contains one row for every custom field group.  The name
>> may be NULL for reasons described below.

>I'm having trouble understanding this proposal, because of one big 
>question: what's a custom field group?

It's my proposed mechanism for implementing field sharing.  Say a group
G contains fields Foo, Bar, and Baz.  Then every project that contains the
group G also has fields Foo, Bar, and Baz.  I probably didn't describe the
concept in enough detail, but I hoped the editcustomfields.html example page
I provided would get the idea across.

>> cf_product_members
>> ------------------
>> product smallint references products(id),
>> group_id integer not null references cf_groups(group_id),
>> display_index integer not null,
>> index (product)

>"display_index" should have the same name as the fields which do the 
>same thing in other tables (can't remember what it is offhand.)

Would that be "sortkey"?

>> cf_selections
>> -------------
>> selection_id integer auto_increment primary key,
>> unset_label tinytext not null
>> 
>> The unset_label column is the text which represents the "empty set"
>> value of single-selection fields.
>> 
>> cf_selection_labels
>> -------------------
>> label_id integer auto_increment primary key,
>> selection_id integer not null references cf_selections(selection_id),
>> label_index integer not null,
>> label tinytext not null,
>> index (selection_id)

>Why can these two tables not be combined?

Because then the unset_label column would have to be duplicated.

>> For each single-selection field, there is one row in the table.  The
>> selection_id is NULL if the field is unset; otherwise it references a
>> row in the cf_selection_labels table.

>Surely "there's no row present if the field is unset"? This matches the 
>behaviour for multi-selects.

Yes, I was erroneously conflating the UI behavior (where everything always
needs a label) with the DB behavior.

>> The following six tables hold bug activity data.

>Dude, scrap this! Use our current tables for bug activity data. Please! 
>:-) Store the name of the field, what it changed from, and what it 
>changed to, just like now. That's fine. Really.

I'm reluctant to do this for a few reasons.  First, the more orthogonal
the custom fields implementation is to the core, the less chance there
is of a buggy interaction between the two.  Second, queries against bug
activity would be complicated by cast functions if everything is stored
as a string.  Finally, the current activity table (bugs_activity) logs
changes in tinytext columns, which aren't big enough to log changes in
long string fields or some multiselect fields.  Even if the columns were
widened to the text type, multiselect changes could potentially still be too
large for them, as I've described in a previous message.

>> FILE SYSTEM
>> ===========
>> All custom-field-related templates go in the directory
>> $BUGZILLA_ROOT/template/en/default/custom.

>That's rather confusing, because we have a template/en/custom for custom 
>templates. You could have "custom-fields", which would be better, but 
>otherwise they'd just live in whichever part of the template tree they 
>were relevant to.

OK, custom-fields it is.

>> ADMINISTRATION
>> ==============
>> Each page contains a single form, which always contains a hidden field
>> called "context".

>We call this "action" everywhere else.

"context" is more intuitive to me, but oh well, viva consistency.

>> Initial page
>> ------------
>> Context:  choose-scope
>> Template: template/en/default/custom/choose-scope.html.tmpl
>> 
>> The user may select a scope via either of the following three elements:

>What is a scope?

A project, a group, or the global scope.

>And, importantly, if this is a design document, there is no place in it 
>for code. It's just obfuscating, and premature detail.

If I hadn't written it, I'd agree with you, at first glance.  However,
I found that creating those templates (which aren't code, not exactly)
helped me greatly in refining the design.  As just one example, in theory
it's sufficient to copy the "type" column from the custom_fields table
into a template-accessible hash, but in writing the template I found
that it's clearer to abstract the type information into several distinct
members--"is_integer", "is_string", etc.  Maybe this design approach
is peculiar to template programming; the template isn't in the realm
of the design document, strictly speaking, but the method of generating
the backend data on which the template depends is.

>If you are in fact in the middle of implementing this exactly as you've 
>designed it above, you might as well say so and be done with it :-)

*Now* I'm in the middle of implementing it, but at the time I posted the
document I hadn't yet begun.  Scout's honor!


-- 
Sean McAfee -- etzwane at schwag.org


From cmason at somanetworks.com  Fri May 23 13:55:22 2003
From: cmason at somanetworks.com (Chris L. Mason)
Date: Fri, 23 May 2003 09:55:22 -0400
Subject: Throw GCC on the HOF
In-Reply-To: <5FB93110-8CBD-11D7-85C9-000A95A34564@dberlin.org>
References: <5FB93110-8CBD-11D7-85C9-000A95A34564@dberlin.org>
Message-ID: <20030523135522.GB24379@somanetworks.com>

On Thu, May 22, 2003 at 09:25:01PM -0400, Daniel Berlin wrote:
> As of yesterday, we now are Bugzilla-only.
> 
> Yay!
> 
> I'll be filing some bugzilla.mozilla.org bugs for simple small things i 
> noticed (The month and day are reversed in the date format string in 
> GetLongDesciptionsAsText fer instance), and for some default template 
> improvements (Like alternating background colors on the bug list 
> table), etc.

FYI, I already created a bug for the alternating colours, with a simple
patch that lets you specify the colours in buglist.css.

http://bugzilla.mozilla.org/show_bug.cgi?id=195415


Chris

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20030523/1438cabd/attachment.sig>

From etzwane at schwag.org  Fri May 23 15:07:35 2003
From: etzwane at schwag.org (Sean McAfee)
Date: Fri, 23 May 2003 11:07:35 -0400
Subject: Custom fields design doc
In-Reply-To: <20030523023223.B3224BC52@diggity.schwag.org>
Message-ID: <20030523150735.28F16BCDC@diggity.schwag.org>

I wrote:
>Gervase Markham <gerv at mozilla.org> wrote:
>>Sean McAfee wrote:
>>> field_id integer auto_increment primary key,
>>> field_name tinytext not null,
>>> display_name tinytext not null,

>>If this isn't in templates, it can't be localised - i.e. you can only 
>>have a single value, no matter how many nationalities of people use your 
>>Bugzilla. I still think we should have a mechanism where it uses 
>>field_name to begin with, and you then define display names in templates 
>>on a per-language basis...

>By this time, my desire to avoid requiring the admin to twiddle templates is
>well-known.  Hmmm.  OK, how about storing display names in a table like
>this:
[snip]

OK, I had a better idea.  Leave the display_name in custom_fields as
I originally proposed.  The name in the table represents the field's
display name in a default locale, which can be a new Bugzilla parameter.
Those who want to provide alternate names for different locales can
override the default on a per-locale basis in an appropriate template.
This way, those who don't need to support multiple locales don't need to
edit templates, and those who do can do so using the mechanism you
suggested.

How's that?


-- 
Sean McAfee -- etzwane at schwag.org


From bugreport at peshkin.net  Fri May 23 15:43:56 2003
From: bugreport at peshkin.net (Joel Peshkin)
Date: Fri, 23 May 2003 08:43:56 -0700
Subject: Custom fields design doc
In-Reply-To: <20030523150735.28F16BCDC@diggity.schwag.org>
References: <20030523150735.28F16BCDC@diggity.schwag.org>
Message-ID: <3ECE41BC.6050602@peshkin.net>

Sean McAfee wrote:

>><snip>
>>    
>>
>>By this time, my desire to avoid requiring the admin to twiddle templates is
>>well-known.  Hmmm.  OK, how about storing display names in a table like
>>this:
>>    
>>
>[snip]
>
>OK, I had a better idea.  Leave the display_name in custom_fields as
>I originally proposed.  The name in the table represents the field's
>display name in a default locale, which can be a new Bugzilla parameter.
>Those who want to provide alternate names for different locales can
>override the default on a per-locale basis in an appropriate template.
>This way, those who don't need to support multiple locales don't need to
>edit templates, and those who do can do so using the mechanism you
>suggested.
>  
>
If you are going to do that, you may as well use a mechanism similar to 
the ThrowUserError() approach and have all the templates call a 
proceduere in a common template that takes the display name as an 
argument and either emits the Display name unchanged or looks it up. 
 Unlike ThrowUserError() where the normal case does the substitution and 
emitting the name verbatim would be the exception, this would very 
frequently leave the name verbatim.

-Joel





From JWilmoth at starbucks.com  Fri May 23 20:20:02 2003
From: JWilmoth at starbucks.com (Jon Wilmoth)
Date: Fri, 23 May 2003 13:20:02 -0700
Subject: Custom fields design doc
Message-ID: <E2291D136BD35647A074B1053785B05B02C4E26F@seams042.starbucks.net>

I think this is a good design.  I agree with Gerv's comment about
leveraging the existing audit tables.  Less work and more consistency ;)

-----Original Message-----
From: Sean McAfee [mailto:etzwane at schwag.org] 
Sent: Friday, May 23, 2003 8:08 AM
To: developers at bugzilla.org
Subject: Re: Custom fields design doc

I wrote:
>Gervase Markham <gerv at mozilla.org> wrote:
>>Sean McAfee wrote:
>>> field_id integer auto_increment primary key,
>>> field_name tinytext not null,
>>> display_name tinytext not null,

>>If this isn't in templates, it can't be localised - i.e. you can only 
>>have a single value, no matter how many nationalities of people use
your 
>>Bugzilla. I still think we should have a mechanism where it uses 
>>field_name to begin with, and you then define display names in
templates 
>>on a per-language basis...

>By this time, my desire to avoid requiring the admin to twiddle
templates is
>well-known.  Hmmm.  OK, how about storing display names in a table like
>this:
[snip]

OK, I had a better idea.  Leave the display_name in custom_fields as
I originally proposed.  The name in the table represents the field's
display name in a default locale, which can be a new Bugzilla parameter.
Those who want to provide alternate names for different locales can
override the default on a per-locale basis in an appropriate template.
This way, those who don't need to support multiple locales don't need to
edit templates, and those who do can do so using the mechanism you
suggested.

How's that?


-- 
Sean McAfee -- etzwane at schwag.org
----
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=jwilmoth at starbucks.com>



From caseyg at chsamerica.com  Fri May 23 20:41:18 2003
From: caseyg at chsamerica.com (Casey Gregoire)
Date: Fri, 23 May 2003 16:41:18 -0400
Subject: WORKED resolution
Message-ID: <C3EB95A31BDAD511827C00B0D0F95AF57BC28D@BUCKWHEAT>

I have trying to find out why the WORKED resolution does not show up on the
dropdowns but is in the code I changed the resolution field for. Just
couldn't find it.
 
Thank you,
            Casey Gregoire
            Programmer
            CHS of America
            100 1st Ave S. Suite 601
            St. Petersburg, FL 33701
            Phone - (727) 824-0800 ext 1236

Every great achievement was once impossible. -- Anonymous
I'd like to get started on time, if we can, inasmuch as we're late already.
-- Larry Gelbart
Nothing is accomplished without passion. -- My Fortune Cookie
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20030523/4986c29d/attachment.html>

From gerv at mozilla.org  Fri May 23 19:44:23 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Fri, 23 May 2003 20:44:23 +0100
Subject: Custom fields design doc
In-Reply-To: <20030523150735.28F16BCDC@diggity.schwag.org>
References: <20030523150735.28F16BCDC@diggity.schwag.org>
Message-ID: <3ECE7A17.10001@mozilla.org>

Sean McAfee wrote:
>>By this time, my desire to avoid requiring the admin to twiddle templates is
>>well-known.  Hmmm.  OK, how about storing display names in a table like
>>this:
> 
> [snip]
> 
> OK, I had a better idea.

The problem with your old idea, should you be interested, is that it 
assumes a Bugzilla will only be used in one language at once.

>  Leave the display_name in custom_fields as
> I originally proposed.  The name in the table represents the field's
> display name in a default locale, which can be a new Bugzilla parameter.
> Those who want to provide alternate names for different locales can
> override the default on a per-locale basis in an appropriate template.
> This way, those who don't need to support multiple locales don't need to
> edit templates, and those who do can do so using the mechanism you
> suggested.
> 
> How's that?

The invariants for our current localisation strategy are:

- There should be a single localisation mechanism.
- A localiser should be able to create a tarball which, when unzipped,
   places files which totally enable a Bugzilla for their language.
- An admin should be able to unzip said tarball, add the code for the
   language to a param, and all of Bugzilla starts working in that
   language, as well as the ones it currently works in.
- Bugzilla can be used at the same time by different people in different
   languages.

The first thing is invariant because it makes Bugzilla hackers lives as 
easy as possible. These next two things are invariants because they make 
localisers and admins lives as easy as possible. The last thing is an 
invariant because it pleases users.

This means that any solution which stores strings which need to be 
localised in the database just won't fly, because they can't be updated 
by a tarball.

There's no harm in you writing a shell script or even a web-based UI for 
your site to help people manage custom field labels in an easier way 
(even by directly editing templates; we could split them up to 
facilitate this), but breaking the above invariants breaks our entire 
strategy. Bugzilla is designed to be administered (and changing UI text 
counts as that) by those who are technically knowledgeable. Call it a 
limitation if you like. Writing tools to help the less knowledgeable is 
fine; breaking thing isn't.

I hate to be dogmatic about this, but I've spent the last year working 
on a lot of tedious bugs which move all strings out of every other 
possible location and into templates. 2.16 was somewhat localisable, 
2.18 will be a lot more so. I don't want to agree to something which is 
a backwards step.

Gerv




From bbaetz at acm.org  Sat May 24 08:36:30 2003
From: bbaetz at acm.org (Bradley Baetz)
Date: Sat, 24 May 2003 18:36:30 +1000
Subject: Custom fields design doc
In-Reply-To: <3ECE7A17.10001@mozilla.org>
References: <20030523150735.28F16BCDC@diggity.schwag.org> <3ECE7A17.10001@mozilla.org>
Message-ID: <20030524083630.GA3410@mango.home>

On Fri, May 23, 2003 at 08:44:23PM +0100, Gervase Markham wrote:
> The problem with your old idea, should you be interested, is that it 
> assumes a Bugzilla will only be used in one language at once.

> - A localiser should be able to create a tarball which, when unzipped,
>   places files which totally enable a Bugzilla for their language.
> - An admin should be able to unzip said tarball, add the code for the
>   language to a param, and all of Bugzilla starts working in that
>   language, as well as the ones it currently works in.
> - Bugzilla can be used at the same time by different people in different
>   languages.

We still haven't come up with a way to handle admin specified things
such as product names in this way. Custom field descriptions fall into
the same category, in that a localiaser cannot proivde them, since
they're specified by the admin. A template which the admin modifies ahs
the disadvantage that its not web editable. We're probably going to have
to end up wuth a {language,type,id,text} table at some point.

Bradley


From gerv at mozilla.org  Sat May 24 09:23:03 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Sat, 24 May 2003 10:23:03 +0100
Subject: Custom fields design doc
In-Reply-To: <20030523023223.B3224BC52@diggity.schwag.org>
References: <20030523023223.B3224BC52@diggity.schwag.org>
Message-ID: <3ECF39F7.4010303@mozilla.org>

>>I'm having trouble understanding this proposal, because of one big 
>>question: what's a custom field group?
> 
> It's my proposed mechanism for implementing field sharing.  Say a group
> G contains fields Foo, Bar, and Baz.  Then every project that contains the
> group G also has fields Foo, Bar, and Baz.  I probably didn't describe the
> concept in enough detail, but I hoped the editcustomfields.html example page
> I provided would get the idea across.

I'm not sure that the groups are really necessary... why not just have a 
mapping from custom field IDs to product IDs?

The UI would be something like:

Product: Foo-Bar Product

Choose the custom fields for this product:

|------------|
| SomeField  |
| OtherField |
| Priority   |   <- multi-select list box
| Severity   |
| Chip Name  |
|------------|

This seems, conceptually and in code, the easiest thing.

>>"display_index" should have the same name as the fields which do the 
>>same thing in other tables (can't remember what it is offhand.)
> 
> Would that be "sortkey"?

Yep :-)

>>>cf_selections
>>>-------------
>>>
>>>cf_selection_labels
>>>-------------------
> 
>>Why can these two tables not be combined?
> 
> Because then the unset_label column would have to be duplicated.

E.g. in the cf_selection_labels table, if the label_index was 0, or -1, 
or whatever special value you want, then that would be the unset_label. 
But actually, I don't really see the need for an unset_label at all. 
What's wrong with "the field should be blank if it's not been set".

>>>The following six tables hold bug activity data.
> 
>>Dude, scrap this! Use our current tables for bug activity data. Please! 
>>:-) Store the name of the field, what it changed from, and what it 
>>changed to, just like now. That's fine. Really.
> 
> I'm reluctant to do this for a few reasons.  First, the more orthogonal
> the custom fields implementation is to the core, the less chance there
> is of a buggy interaction between the two.

The more tested core code the custom fields implementation reuses, the 
less buggy it will be :-)

Do not think of custom fields as some sort of side bolt-on that can be 
unbolted later.

> Second, queries against bug
> activity would be complicated by cast functions if everything is stored
> as a string.  

I don't quite understand this statement. What problem is is highlighting 
that we don't currently have anyway?

> Finally, the current activity table (bugs_activity) logs
> changes in tinytext columns, which aren't big enough to log changes in
> long string fields or some multiselect fields.  Even if the columns were
> widened to the text type, multiselect changes could potentially still be too
> large for them, as I've described in a previous message.

The bugs_activity log is for auditing rather than rollback, and so it's 
not completely essential that it capture all changes, or all parts of a 
particular change. For example, it doesn't currently capture added 
comments.

I agree that this needs discussion, but truncating the stored parts of 
long string changes or multi-select changes to tinytexts might well be 
an acceptable solution. Expanding the field size might also be fine.

>>>ADMINISTRATION
>>>==============
>>>Each page contains a single form, which always contains a hidden field
>>>called "context".
> 
>>We call this "action" everywhere else.
> 
> "context" is more intuitive to me, but oh well, viva consistency.

(This assumes, of course, that I understand what this field does. Does 
it define what action the CGI takes when the form is submitted?)

>>>Initial page
>>>------------
>>>Context:  choose-scope
>>>Template: template/en/default/custom/choose-scope.html.tmpl
>>>
>>>The user may select a scope via either of the following three elements:
> 
>>What is a scope?
> 
> A project, a group, or the global scope.

What's a project?

> As just one example, in theory
> it's sufficient to copy the "type" column from the custom_fields table
> into a template-accessible hash, but in writing the template I found
> that it's clearer to abstract the type information into several distinct
> members--"is_integer", "is_string", etc.  

This sort of decision is also implementation, and has no place in a 
design document either :-) I wouldn't deny that implementing it gives 
you good ideas about implementation, but if you change the actual 
_design_ for technical reasons, there's usually something wrong (unless 
what you wanted is genuinely impossible.)

Gerv




From louie at ximian.com  Sat May 24 13:37:55 2003
From: louie at ximian.com (Luis Villa)
Date: 24 May 2003 09:37:55 -0400
Subject: Custom fields design doc
In-Reply-To: <3ECF39F7.4010303@mozilla.org>
References: <20030523023223.B3224BC52@diggity.schwag.org>
	 <3ECF39F7.4010303@mozilla.org>
Message-ID: <1053783474.3762.27.camel@localhost.localdomain>

On Sat, 2003-05-24 at 05:23, Gervase Markham wrote:
> >>I'm having trouble understanding this proposal, because of one big 
> >>question: what's a custom field group?
> > 
> > It's my proposed mechanism for implementing field sharing.  Say a group
> > G contains fields Foo, Bar, and Baz.  Then every project that contains the
> > group G also has fields Foo, Bar, and Baz.  I probably didn't describe the
> > concept in enough detail, but I hoped the editcustomfields.html example page
> > I provided would get the idea across.
> 
> I'm not sure that the groups are really necessary... why not just have a 
> mapping from custom field IDs to product IDs?

Just FWIW, in at least our setup, we have no need for per-product custom
fields, and if there is no way to say 'all products get this field',
it'll be quite inconvenient.

Luis (still wishing he had more time to contribute :/

> The UI would be something like:
> 
> Product: Foo-Bar Product
> 
> Choose the custom fields for this product:
> 
> |------------|
> | SomeField  |
> | OtherField |
> | Priority   |   <- multi-select list box
> | Severity   |
> | Chip Name  |
> |------------|
> 
> This seems, conceptually and in code, the easiest thing.
> 
> >>"display_index" should have the same name as the fields which do the 
> >>same thing in other tables (can't remember what it is offhand.)
> > 
> > Would that be "sortkey"?
> 
> Yep :-)
> 
> >>>cf_selections
> >>>-------------
> >>>
> >>>cf_selection_labels
> >>>-------------------
> > 
> >>Why can these two tables not be combined?
> > 
> > Because then the unset_label column would have to be duplicated.
> 
> E.g. in the cf_selection_labels table, if the label_index was 0, or -1, 
> or whatever special value you want, then that would be the unset_label. 
> But actually, I don't really see the need for an unset_label at all. 
> What's wrong with "the field should be blank if it's not been set".
> 
> >>>The following six tables hold bug activity data.
> > 
> >>Dude, scrap this! Use our current tables for bug activity data. Please! 
> >>:-) Store the name of the field, what it changed from, and what it 
> >>changed to, just like now. That's fine. Really.
> > 
> > I'm reluctant to do this for a few reasons.  First, the more orthogonal
> > the custom fields implementation is to the core, the less chance there
> > is of a buggy interaction between the two.
> 
> The more tested core code the custom fields implementation reuses, the 
> less buggy it will be :-)
> 
> Do not think of custom fields as some sort of side bolt-on that can be 
> unbolted later.
> 
> > Second, queries against bug
> > activity would be complicated by cast functions if everything is stored
> > as a string.  
> 
> I don't quite understand this statement. What problem is is highlighting 
> that we don't currently have anyway?
> 
> > Finally, the current activity table (bugs_activity) logs
> > changes in tinytext columns, which aren't big enough to log changes in
> > long string fields or some multiselect fields.  Even if the columns were
> > widened to the text type, multiselect changes could potentially still be too
> > large for them, as I've described in a previous message.
> 
> The bugs_activity log is for auditing rather than rollback, and so it's 
> not completely essential that it capture all changes, or all parts of a 
> particular change. For example, it doesn't currently capture added 
> comments.
> 
> I agree that this needs discussion, but truncating the stored parts of 
> long string changes or multi-select changes to tinytexts might well be 
> an acceptable solution. Expanding the field size might also be fine.
> 
> >>>ADMINISTRATION
> >>>==============
> >>>Each page contains a single form, which always contains a hidden field
> >>>called "context".
> > 
> >>We call this "action" everywhere else.
> > 
> > "context" is more intuitive to me, but oh well, viva consistency.
> 
> (This assumes, of course, that I understand what this field does. Does 
> it define what action the CGI takes when the form is submitted?)
> 
> >>>Initial page
> >>>------------
> >>>Context:  choose-scope
> >>>Template: template/en/default/custom/choose-scope.html.tmpl
> >>>
> >>>The user may select a scope via either of the following three elements:
> > 
> >>What is a scope?
> > 
> > A project, a group, or the global scope.
> 
> What's a project?
> 
> > As just one example, in theory
> > it's sufficient to copy the "type" column from the custom_fields table
> > into a template-accessible hash, but in writing the template I found
> > that it's clearer to abstract the type information into several distinct
> > members--"is_integer", "is_string", etc.  
> 
> This sort of decision is also implementation, and has no place in a 
> design document either :-) I wouldn't deny that implementing it gives 
> you good ideas about implementation, but if you change the actual 
> _design_ for technical reasons, there's usually something wrong (unless 
> what you wanted is genuinely impossible.)
> 
> Gerv
> 
> 
> ----
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=louie at ximian.com>
> 



From dberlin at dberlin.org  Mon May 26 06:27:44 2003
From: dberlin at dberlin.org (Daniel Berlin)
Date: Mon, 26 May 2003 02:27:44 -0400
Subject: Custom fields design doc
In-Reply-To: <20030524083630.GA3410@mango.home>
Message-ID: <290F1419-8F43-11D7-98AA-000A95A34564@dberlin.org>


On Saturday, May 24, 2003, at 04:36  AM, Bradley Baetz wrote:

> On Fri, May 23, 2003 at 08:44:23PM +0100, Gervase Markham wrote:
>> The problem with your old idea, should you be interested, is that it
>> assumes a Bugzilla will only be used in one language at once.
>
>> - A localiser should be able to create a tarball which, when unzipped,
>>   places files which totally enable a Bugzilla for their language.
>> - An admin should be able to unzip said tarball, add the code for the
>>   language to a param, and all of Bugzilla starts working in that
>>   language, as well as the ones it currently works in.
>> - Bugzilla can be used at the same time by different people in 
>> different
>>   languages.
>
> We still haven't come up with a way to handle admin specified things
> such as product names in this way.

Errr, isn't this type of thing a solved problem (IE haven't other 
internationalized projects been here before)?

In the DB, they are mostly only referred to by ID already (IE have 
separate namespaces)

Some (heavily, i would imagine) included perl file(s) that is/are in 
the template/<language> dir contains a hash table mapping the specific 
id's to strings.

Past that, what's so hard about making the current code use 
Data::Dumper (if you want readability) or IO::Storable (if you want 
speed of loading/storing) to rewrite the approriate file for the 
current language when someone edits a product name?  This makes it web 
editable.

It also seems simple to check if the current language file was modified 
since we last read it in and re-load the hash, and to do this check in 
get_product_name (or wherever).  This makes it hand editable.

>  Custom field descriptions fall into
> the same category, in that a localiaser cannot proivde them, since
> they're specified by the admin. A template which the admin modifies ahs
> the disadvantage that its not web editable.
How is the above not web editable?
Even if the file doesn't exist for the current language, we still know 
how many *things* we need names for, and what the keys are, and thus 
can make up "default" values like "unset localized product name 1", and 
write it out as the file for that language.


> We're probably going to have
> to end up wuth a {language,type,id,text} table at some point.
>
Only if you aren't willing to serialize perl structures in some form.  
If this is a requirement (not serializing perl structures, that is) you 
are pretty much left with the DB to do this.

> Bradley



From bbaetz at acm.org  Mon May 26 09:30:32 2003
From: bbaetz at acm.org (Bradley Baetz)
Date: Mon, 26 May 2003 19:30:32 +1000
Subject: Custom fields design doc
In-Reply-To: <290F1419-8F43-11D7-98AA-000A95A34564@dberlin.org>
References: <20030524083630.GA3410@mango.home> <290F1419-8F43-11D7-98AA-000A95A34564@dberlin.org>
Message-ID: <20030526093032.GB1252@mango.home>

On Mon, May 26, 2003 at 02:27:44AM -0400, Daniel Berlin wrote:

> Errr, isn't this type of thing a solved problem (IE haven't other 
> internationalized projects been here before)?

Sure. I'm not aware of any other project which wants this to be
adminable via the web rather than a config file, but thats not a big
difference.

> 
> In the DB, they are mostly only referred to by ID already (IE have 
> separate namespaces)
> 
> Some (heavily, i would imagine) included perl file(s) that is/are in 
> the template/<language> dir contains a hash table mapping the specific 
> id's to strings.


> Past that, what's so hard about making the current code use 
> Data::Dumper (if you want readability) or IO::Storable (if you want 
> speed of loading/storing) to rewrite the approriate file for the 
> current language when someone edits a product name?  This makes it web 
> editable.

None of this is hard. Its just that we don't currently do this, so
someone has to write the backend infrastruture too.

Personally, I'd prefer Data::Dumper but thats a side issue.

> 
> It also seems simple to check if the current language file was modified 
> since we last read it in and re-load the hash, and to do this check in 
> get_product_name (or wherever).  This makes it hand editable.
> 

When not running under mod_perl, theres nowhere to persist it anyway -
it will be loaded every time anyway.

> > Custom field descriptions fall into
> >the same category, in that a localiaser cannot proivde them, since
> >they're specified by the admin. A template which the admin modifies ahs
> >the disadvantage that its not web editable.
> How is the above not web editable?

Auto-generating the template won't quite work, because of the
permissions stuff - the webserver won't have the access to write out the
template in the template dir. Putting this in data/ means fudging with a
template provider a bit so that compiled templates are stuff under data.
I have a patch which makes those use abolute dirs anyway (needed for
mod_perl), so I guess thats not an issue.

> Even if the file doesn't exist for the current language, we still know 
> how many *things* we need names for, and what the keys are, and thus 
> can make up "default" values like "unset localized product name 1", and 
> write it out as the file for that language.
> 

Sure.
 
> >We're probably going to have
> >to end up wuth a {language,type,id,text} table at some point.
> >
> Only if you aren't willing to serialize perl structures in some form.  
> If this is a requirement (not serializing perl structures, that is) you 
> are pretty much left with the DB to do this.
> 

Even if we do serialise, we still want to persist stuff into the
database, and use the perl as a cache, similarly to how the versioncache
works. That gives us one place to back stuff up (the mysql db). If we do
it that way, then outputing to a TT template probably makes more sense.

Bradley


From olivier.lambert at francetelecom.com  Tue May 27 16:05:14 2003
From: olivier.lambert at francetelecom.com (LAMBERT Olivier URS TOULOUSE)
Date: Tue, 27 May 2003 18:05:14 +0200
Subject: l10n : French Localisation
Message-ID: <20030527160514.GA23490@stage2.gsn12.francetelecom.fr>

Hi everybody !

First of all, Hello everybody, as I'm quite new to this list...

I'm actually planning in translating Bugzilla for my enterprise needs...
Rather than working alone, i'd like to share my work with other l10n
folks... "Given enough eyeballs... "

I've already spent some time reading l10n guide :
http://www.bugzilla.org/dev/l10n-guide.html
and had a look at deep code...

Before starting to work like a nut, i'd like to know if some translation
work had already be done, and who should I contact...

What's more, that might prevent me from doing the "already done
thousands" mistake... :))

Best regards, 

Olivier (ceituna) LAMBERT


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20030527/7d5760bd/attachment.sig>

From jon at vmware.com  Tue May 27 16:33:16 2003
From: jon at vmware.com (Jonathan Schatz)
Date: 27 May 2003 09:33:16 -0700
Subject: {Spam?} disabling keyboard shortcuts
Message-ID: <1054053196.25548.3.camel@jonschatz-lx.vmware.com>

ok, we officially launched our bugzilla installation today (can someone
update the HOF?). I've gotten some complaints from people w/r/t the
keyboard shortcuts. when they exist, normal IE commands (alt-e, alt-h)
don't work.

is there a way in ie to disable the rendering of these shortcuts? has
anyone else heard this complaint before?

-jon
-- 
Jonathan Schatz
Engineering System Administrator
VMware, Inc
"Te occidere possunt sed te edere non possunt nefas est."





From cbendell at point2.com  Tue May 27 21:16:24 2003
From: cbendell at point2.com (Colin Bendell)
Date: Tue, 27 May 2003 15:16:24 -0600
Subject: Taint check
Message-ID: <85339FA608200E43BA1A364F09C337D67AE8C6@bruno.point2.com>

What is the reasoning for using the Taint check on many of the perl
scripts in bugzilla?  I've had to remove them to get Perl working under
win32 (worked as is in the linux configuration).  

Forgive me if this has been discussed ad nausea, but the 'developers'
news group doesn't seem to have a 'search' feature.

/colin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20030527/0cd8f47a/attachment.html>

From jake at bugzilla.org  Tue May 27 22:10:06 2003
From: jake at bugzilla.org (Jake)
Date: Tue, 27 May 2003 18:10:06 -0400
Subject: Throw GCC on the HOF
In-Reply-To: <5FB93110-8CBD-11D7-85C9-000A95A34564@dberlin.org>
References: <5FB93110-8CBD-11D7-85C9-000A95A34564@dberlin.org>
Message-ID: <3ED3E23E.1040103@bugzilla.org>

Daniel Berlin wrote:

> As of yesterday, we now are Bugzilla-only.

Just updated the HOF page...



From jake at bugzilla.org  Tue May 27 22:12:59 2003
From: jake at bugzilla.org (Jake)
Date: Tue, 27 May 2003 18:12:59 -0400
Subject: {Spam?} disabling keyboard shortcuts
In-Reply-To: <1054053196.25548.3.camel@jonschatz-lx.vmware.com>
References: <1054053196.25548.3.camel@jonschatz-lx.vmware.com>
Message-ID: <3ED3E2EB.7070206@bugzilla.org>

Jonathan Schatz wrote:

>ok, we officially launched our bugzilla installation today (can someone
>update the HOF?).
>
VMWare is already on the list, but without a link; is your installation 
public?

> I've gotten some complaints from people w/r/t the
>keyboard shortcuts. when they exist, normal IE commands (alt-e, alt-h)
>don't work.
>
>is there a way in ie to disable the rendering of these shortcuts? has
>anyone else heard this complaint before?
>  
>
I can't say that I've heard the complain, but maybe I just wasn't 
listening. I don't know of any method to tell IE to have its own 
shortcuts take precedence. Not much help, am I?




From jimw at bugopolis.com  Tue May 27 22:36:28 2003
From: jimw at bugopolis.com (Jim Walters)
Date: 27 May 2003 15:36:28 -0700
Subject: Throw GCC on the HOF
In-Reply-To: <3ED3E23E.1040103@bugzilla.org>
References: <5FB93110-8CBD-11D7-85C9-000A95A34564@dberlin.org>
	 <3ED3E23E.1040103@bugzilla.org>
Message-ID: <1054074988.25748.179.camel@localhost.localdomain>

Ran across this one today...

http://bugzilla.bricolage.cc/

On Tue, 2003-05-27 at 15:10, Jake wrote:

> Daniel Berlin wrote:
> 
> > As of yesterday, we now are Bugzilla-only.
> 
> Just updated the HOF page...
> 
> ----
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=jimw at bugopolis.com>

__________________________
Jim Walters   Director of Technology
Bugopolis, Inc.

phone: +1 206 447 8315 
email: jimw at bugopolis.com
web: http://www.bugopolis.com
_________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20030527/25aab475/attachment.html>

From gerv at mozilla.org  Tue May 27 23:04:27 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Wed, 28 May 2003 00:04:27 +0100
Subject: {Spam?} disabling keyboard shortcuts
In-Reply-To: <1054053196.25548.3.camel@jonschatz-lx.vmware.com>
References: <1054053196.25548.3.camel@jonschatz-lx.vmware.com>
Message-ID: <3ED3EEFB.7050103@mozilla.org>

Jonathan Schatz wrote:
> ok, we officially launched our bugzilla installation today (can someone
> update the HOF?). I've gotten some complaints from people w/r/t the
> keyboard shortcuts. when they exist, normal IE commands (alt-e, alt-h)
> don't work.

They do if you press and release Alt, then press the letter. That's 
solution 1.

> is there a way in ie to disable the rendering of these shortcuts? 

No; you can remove them from the templates by removing the "accesskey=" 
attributes. That's solution 2.

Gerv



From gerv at mozilla.org  Tue May 27 23:05:36 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Wed, 28 May 2003 00:05:36 +0100
Subject: Throw GCC on the HOF
In-Reply-To: <3ED3E23E.1040103@bugzilla.org>
References: <5FB93110-8CBD-11D7-85C9-000A95A34564@dberlin.org> <3ED3E23E.1040103@bugzilla.org>
Message-ID: <3ED3EF40.2020300@mozilla.org>

Jake wrote:
> Daniel Berlin wrote:
> 
>> As of yesterday, we now are Bugzilla-only.
> 
> Just updated the HOF page...

Er... it's autogenerated from a plain text source file, so you probably 
don't want to do that, as changes will get overwritten. I'll add GCC and 
republish, along with the other changes I got recently.

Gerv



From etzwane at schwag.org  Wed May 28 01:14:36 2003
From: etzwane at schwag.org (Sean McAfee)
Date: Tue, 27 May 2003 21:14:36 -0400
Subject: Custom fields design doc
In-Reply-To: <3ECE7A17.10001@mozilla.org>
Message-ID: <20030528011436.3C5E5BC52@diggity.schwag.org>

Gervase Markham <gerv at mozilla.org> wrote:
>The invariants for our current localisation strategy are:
>
>- There should be a single localisation mechanism.
>- A localiser should be able to create a tarball which, when unzipped,
>   places files which totally enable a Bugzilla for their language.
>- An admin should be able to unzip said tarball, add the code for the
>   language to a param, and all of Bugzilla starts working in that
>   language, as well as the ones it currently works in.
>- Bugzilla can be used at the same time by different people in different
>   languages.

It seems to me that a distinction can be drawn between relatively
static localized text, such as the static content of an HTML document,
and relatively variable localized text, such as field display names or
the labels of a selection field, either of which an administrator might
update frequently.  The former clearly belongs in a template file, but it's
not so obvious to me that the latter does as well.

>The first thing is invariant because it makes Bugzilla hackers lives as 
>easy as possible.

Modifying template files in-place programmatically, with all of the
necessary locking mechanisms, doesn't seem particularly easy.

>These next two things are invariants because they make 
>localisers and admins lives as easy as possible. The last thing is an 
>invariant because it pleases users.

>This means that any solution which stores strings which need to be 
>localised in the database just won't fly, because they can't be updated 
>by a tarball.

But custom field information is metadata particular to a specific
Bugzilla installation.  Obviously it's desirable to be able to unpack
(say) a French localization tarball onto an existing installation and
have Bugzilla immediately start presenting pages in French, but of what
use would it be to include in that tarball localization information
for custom fields from some other installation that don't exist in the
target installation?


-- 
Sean McAfee -- etzwane at schwag.org


From jake at bugzilla.org  Wed May 28 02:02:54 2003
From: jake at bugzilla.org (Jake)
Date: Tue, 27 May 2003 22:02:54 -0400
Subject: Throw GCC on the HOF
In-Reply-To: <3ED3EF40.2020300@mozilla.org>
References: <5FB93110-8CBD-11D7-85C9-000A95A34564@dberlin.org> <3ED3E23E.1040103@bugzilla.org> <3ED3EF40.2020300@mozilla.org>
Message-ID: <3ED418CE.1090201@bugzilla.org>

Gervase Markham wrote:

> Er... it's autogenerated from a plain text source file, so you 
> probably don't want to do that, as changes will get overwritten. I'll 
> add GCC and republish, along with the other changes I got recently.

I didn't know that... you may want to add Yahoo, Inc. to your plain text 
file as well, then :)

> Gerv

Jake




From etzwane at schwag.org  Wed May 28 02:46:23 2003
From: etzwane at schwag.org (Sean McAfee)
Date: Tue, 27 May 2003 22:46:23 -0400
Subject: Custom fields design doc
In-Reply-To: <3ECF39F7.4010303@mozilla.org>
Message-ID: <20030528024623.5C24FBC52@diggity.schwag.org>

Gervase Markham <gerv at mozilla.org> wrote:
>> It's my proposed mechanism for implementing field sharing.  Say a group
>> G contains fields Foo, Bar, and Baz.  Then every project that contains the
>> group G also has fields Foo, Bar, and Baz.  I probably didn't describe the
>> concept in enough detail, but I hoped the editcustomfields.html example page
>> I provided would get the idea across.
>
>I'm not sure that the groups are really necessary... why not just have a 
>mapping from custom field IDs to product IDs?
>
>The UI would be something like:
>
>Product: Foo-Bar Product
>
>Choose the custom fields for this product:
>
>|------------|
>| SomeField  |
>| OtherField |
>| Priority   |   <- multi-select list box
>| Severity   |
>| Chip Name  |
>|------------|
>
>This seems, conceptually and in code, the easiest thing.

My objections:

1.  Lack of context.  The administrator could easily add the wrong field
if its name is similar to that of the desired field.

2.  This interface provides no high-level view of the relationship
between products and fields.  Suppose an administrator wants to change
some property of a field Foo.  The admin won't be able to know which
products the change will affect without examining the field list for
every product in the installation.

3.  I think it'll be more common than not that fields will be shared
in related groups.  Suppose ten products share ten related fields.
To add a single new related field to each product, or to remove one of
the existing fields, would require ten separate operations under your
scheme, but only one under mine.

>>>>cf_selections
>>>>-------------
>>>>
>>>>cf_selection_labels
>>>>-------------------
>> 
>>>Why can these two tables not be combined?
>> 
>> Because then the unset_label column would have to be duplicated.

>E.g. in the cf_selection_labels table, if the label_index was 0, or -1, 
>or whatever special value you want, then that would be the unset_label. 

I was designing defensively, letting the sole meaning of label_index be
in its value relative to the indices of other labels of the same field.
It's my expectation that the indices will always be in the range 1 .. N,
but I wanted to leave the door open for other schemes.

>But actually, I don't really see the need for an unset_label at all. 
>What's wrong with "the field should be blank if it's not been set".

How then does the user unset a single-selection field?  With a blank
selection option?

<select name="selection_field">
  <option value="">&nbsp;</option>
  <option value="Foo">Foo</option>
  <option value="Bar">Bar</option>
</select>

I wouldn't find that particularly intuitive.

>> I'm reluctant to do this for a few reasons.  First, the more orthogonal
>> the custom fields implementation is to the core, the less chance there
>> is of a buggy interaction between the two.

>The more tested core code the custom fields implementation reuses, the 
>less buggy it will be :-)
>
>Do not think of custom fields as some sort of side bolt-on that can be 
>unbolted later.

I wasn't thinking of unbolting, but of modularity, which has many well-known
benefits.

>> Second, queries against bug
>> activity would be complicated by cast functions if everything is stored
>> as a string.  

>I don't quite understand this statement. What problem is is highlighting 
>that we don't currently have anyway?

Well, I don't know all of the current problems, so I can't answer this.
I'd just think it's cleaner to have where clauses like
"WHERE new_value > 20030101" rather than
"WHERE CAST(added AS DATETIME) > 20030101".  Come to think of it, it's
impossible to unambiguously disinguish stringified selection field
changes if some of the possible values are alike at the beginning or end.
For example, if a selection field's domain was "FOO", "BAR", and "FOO BAR",
and the string "FOO BAR" was stored in bugs_activity's "added" column, does
that mean the single value "FOO BAR" was added, or the two values "FOO" and
"BAR"?

>> Finally, the current activity table (bugs_activity) logs
>> changes in tinytext columns, which aren't big enough to log changes in
>> long string fields or some multiselect fields.  Even if the columns were
>> widened to the text type, multiselect changes could potentially still be too
>> large for them, as I've described in a previous message.

>The bugs_activity log is for auditing rather than rollback, and so it's 
>not completely essential that it capture all changes, or all parts of a 
>particular change. For example, it doesn't currently capture added 
>comments.

I had accurate auditing in mind, not rollback.

>I agree that this needs discussion, but truncating the stored parts of 
>long string changes or multi-select changes to tinytexts might well be 
>an acceptable solution. Expanding the field size might also be fine.

I'm reluctant to accept lossy auditing.

>>>>ADMINISTRATION
>>>>==============
>>>>Each page contains a single form, which always contains a hidden field
>>>>called "context".
>> 
>>>We call this "action" everywhere else.
>> 
>> "context" is more intuitive to me, but oh well, viva consistency.
>
>(This assumes, of course, that I understand what this field does. Does 
>it define what action the CGI takes when the form is submitted?)

No, it describes the page from which editcustomfields.cgi was invoked.  It's
"main-menu" on the main menu, "create-field" from any of the field-creation
pages, etc.  In the main-menu case, I use the "action" parameter to identify
which submit control was pressed, like so:

<input type="hidden" name="context" value="main-menu">
<input type="submit" name="action" value="Move"> a custom field.
<input type="submit" name="action" value="Edit"> a custom field.
<!-- and so on -->

>>>What is a scope?
>> 
>> A project, a group, or the global scope.
>
>What's a project?

Sorry, I slipped back into my Teamshare vocabulary there.
Project == Product.

>> As just one example, in theory
>> it's sufficient to copy the "type" column from the custom_fields table
>> into a template-accessible hash, but in writing the template I found
>> that it's clearer to abstract the type information into several distinct
>> members--"is_integer", "is_string", etc.  

>This sort of decision is also implementation, and has no place in a 
>design document either :-)

You seem to be saying that no Perl-related design document should
ever decide what names to use as hash keys.  I disagree.  In this case
particularly, the keys are a crucial part of the interface between code
and template.  What if one person were assigned to implement the code,
and another the templates?  Each should be able to independently do his
job solely from the design doc, but this would be impossible without
fixed keys.


-- 
Sean McAfee -- etzwane at schwag.org


From pym at qad.com  Wed May 28 05:50:54 2003
From: pym at qad.com (Patrick McGoldrick)
Date: Tue, 27 May 2003 22:50:54 -0700
Subject: Dependancy Graphs
Message-ID: <OFDDACC96D.6998BFA0-ON88256D34.001FFB4A@qad.com>

I can't seem to get Dependancy graphs working on the 2.16.3 stable build.
I just get a blue vertical line on the left side.

Any suggestions?

      -Patrick McGoldrick




From pym at qad.com  Wed May 28 06:20:31 2003
From: pym at qad.com (Patrick McGoldrick)
Date: Tue, 27 May 2003 23:20:31 -0700
Subject: Dependancy Graphs
Message-ID: <OF61E58920.1DDD4976-ON88256D34.00229A3A@qad.com>

I am making bug 1 2 and 3.
1 depends on 2, 2 depends on 3.

I go to the Dependancy tree and see the relationship.

But I go to the dependancy graph and nothing but the word 'Dependacy Graph'

I am now trying version 2.17.4

Any insite would be helpful.

      -Patrick



From preed at sigkill.com  Wed May 28 07:19:01 2003
From: preed at sigkill.com (J. Paul Reed)
Date: Wed, 28 May 2003 00:19:01 -0700
Subject: Taint check
In-Reply-To: <85339FA608200E43BA1A364F09C337D67AE8C6@bruno.point2.com>; from cbendell@point2.com on Tue, May 27, 2003 at 03:16:24PM -0600
References: <85339FA608200E43BA1A364F09C337D67AE8C6@bruno.point2.com>
Message-ID: <20030528001901.B5453@sigkill.com>

On 27 May 2003 at 15:16:24, Colin Bendell moved bits on my disk to say:

> What is the reasoning for using the Taint check on many of the perl
> scripts in bugzilla?  

See bug 108982. Basically, taint mode provides some modicum of security for
certain types of things in perl.

> I've had to remove them to get Perl working under win32 (worked as is in
> the linux configuration).  

That's probably not the proper solution to the problem; doing so reduces
the security of your BZ installation. 

Are you using IIS?
 
> Forgive me if this has been discussed ad nausea, but the 'developers'
> news group doesn't seem to have a 'search' feature.

It does.

Find it at http://groups.google.com.

Later,
Paul
------------------------------------------------------------------------
J. Paul Reed -- 0xDF8708F8 || preed at sigkill.com || web.sigkill.com/preed
To hold on to sanity too tight is insane.   -- Nick Falzone, Pushing Tin

I use PGP; you should use PGP too... if only to piss off John Ashcroft


From bbaetz at acm.org  Wed May 28 09:31:57 2003
From: bbaetz at acm.org (Bradley Baetz)
Date: Wed, 28 May 2003 19:31:57 +1000
Subject: Taint check
In-Reply-To: <85339FA608200E43BA1A364F09C337D67AE8C6@bruno.point2.com>
References: <85339FA608200E43BA1A364F09C337D67AE8C6@bruno.point2.com>
Message-ID: <20030528093157.GA1222@mango.home>

On Tue, May 27, 2003 at 03:16:24PM -0600, Colin Bendell wrote:
> What is the reasoning for using the Taint check on many of the perl
> scripts in bugzilla?

Security. DBI is configured to taint check all its arguments, so we
ensure that data has been validated. We fixed a ton of security holes
when I added this.

> I've had to remove them to get Perl working under
> win32 (worked as is in the linux configuration).  

What broke?

Bradley


From caseyg at chsamerica.com  Wed May 28 13:49:17 2003
From: caseyg at chsamerica.com (Casey Gregoire)
Date: Wed, 28 May 2003 09:49:17 -0400
Subject: enter_bug.cgi at bugzilla
Message-ID: <C3EB95A31BDAD511827C00B0D0F95AF57BC9EC@BUCKWHEAT>

What is that makes the bugzilla.mozilla.org's enter_bug.cgi separate the
products into groups like Client Software, Client Support, Components, Etc.?
 
Thank you,
            Casey Gregoire
            Programmer
            CHS of America
            100 1st Ave S. Suite 601
            St. Petersburg, FL 33701
            Phone - (727) 824-0800 ext 1236

Every great achievement was once impossible. -- Anonymous
I'd like to get started on time, if we can, inasmuch as we're late already.
-- Larry Gelbart
Nothing is accomplished without passion. -- My Fortune Cookie
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20030528/f08922ce/attachment.html>

From jake at bugzilla.org  Wed May 28 14:37:39 2003
From: jake at bugzilla.org (Jake)
Date: Wed, 28 May 2003 10:37:39 -0400
Subject: Taint check
In-Reply-To: <20030528001901.B5453@sigkill.com>
References: <85339FA608200E43BA1A364F09C337D67AE8C6@bruno.point2.com> <20030528001901.B5453@sigkill.com>
Message-ID: <3ED4C9B3.7010604@bugzilla.org>

J. Paul Reed wrote:

>It does.
>
>Find it at http://groups.google.com.
>
That's a great way to search the newsgroup, but it doesn't do anything 
for this list. AFAICT, there is no search feature for this list (the 
archives are at bugzilla.org, but they aren't indexed by google nor do 
they have their own search function).




From jake at bugzilla.org  Wed May 28 14:38:35 2003
From: jake at bugzilla.org (Jake)
Date: Wed, 28 May 2003 10:38:35 -0400
Subject: enter_bug.cgi at bugzilla
In-Reply-To: <C3EB95A31BDAD511827C00B0D0F95AF57BC9EC@BUCKWHEAT>
References: <C3EB95A31BDAD511827C00B0D0F95AF57BC9EC@BUCKWHEAT>
Message-ID: <3ED4C9EB.1000704@bugzilla.org>

Casey Gregoire wrote:

> What is that makes the bugzilla.mozilla.org?s enter_bug.cgi separate 
> the products into groups like Client Software, Client Support, 
> Components, Etc.?
>
> //
>
A custom template.



From justdave at syndicomm.com  Wed May 28 14:45:13 2003
From: justdave at syndicomm.com (David Miller)
Date: Wed, 28 May 2003 10:45:13 -0400
Subject: Taint check
In-Reply-To: <3ED4C9B3.7010604@bugzilla.org>
References: <85339FA608200E43BA1A364F09C337D67AE8C6@bruno.point2.com>
 <20030528001901.B5453@sigkill.com> <3ED4C9B3.7010604@bugzilla.org>
Message-ID: <a06001208bafa7bb5670d@[192.168.1.204]>

On 5/28/2003 10:37 AM -0400, Jake wrote:

> J. Paul Reed wrote:
>
>>It does.
>>
>>Find it at http://groups.google.com.
>>
> That's a great way to search the newsgroup, but it doesn't do anything
> for this list. AFAICT, there is no search feature for this list (the
> archives are at bugzilla.org, but they aren't indexed by google nor do
> they have their own search function).

The discussion he's looking for actually occurred on the
netscape.public.mozilla.webtools newsgroup though, so the Google search
would work for this specific instance.  That's an admin/setup issue, not a
development issue, so it would have been discussed on the newsgroup rather
than the developers mailing list.
-- 
Dave Miller      Project Leader, Bugzilla Bug Tracking System
http://www.justdave.net/             http://www.bugzilla.org/


From preed at sigkill.com  Wed May 28 14:48:30 2003
From: preed at sigkill.com (J. Paul Reed)
Date: Wed, 28 May 2003 07:48:30 -0700
Subject: Taint check
In-Reply-To: <3ED4C9B3.7010604@bugzilla.org>; from jake@bugzilla.org on Wed, May 28, 2003 at 10:37:39AM -0400
References: <85339FA608200E43BA1A364F09C337D67AE8C6@bruno.point2.com> <20030528001901.B5453@sigkill.com> <3ED4C9B3.7010604@bugzilla.org>
Message-ID: <20030528074830.A7311@sigkill.com>

On 28 May 2003 at 10:37:39, Jake moved bits on my disk to say:

> That's a great way to search the newsgroup, but it doesn't do anything
> for this list. AFAICT, there is no search feature for this list (the
> archives are at bugzilla.org, but they aren't indexed by google nor do
> they have their own search function).

Ahh.. I thought he was talking about about the newsgroup (he said "but the
'developers' news group doesn't seem to have a 'search' feature.")

That actually is kind of annoying. I played around with Google, but it
doesn't seem to spider those pages. Dave: is there anything in robots.txt
for those pages that would make it not spider the mailing list archives?

Later,
Paul
------------------------------------------------------------------------
J. Paul Reed -- 0xDF8708F8 || preed at sigkill.com || web.sigkill.com/preed
To hold on to sanity too tight is insane.   -- Nick Falzone, Pushing Tin

I use PGP; you should use PGP too... if only to piss off John Ashcroft


From justdave at syndicomm.com  Wed May 28 14:59:14 2003
From: justdave at syndicomm.com (David Miller)
Date: Wed, 28 May 2003 10:59:14 -0400
Subject: Taint check
In-Reply-To: <20030528074830.A7311@sigkill.com>
References: <85339FA608200E43BA1A364F09C337D67AE8C6@bruno.point2.com>
 <20030528001901.B5453@sigkill.com> <3ED4C9B3.7010604@bugzilla.org>
 <20030528074830.A7311@sigkill.com>
Message-ID: <a06001209bafa7e18f64a@[192.168.1.204]>

On 5/28/2003 7:48 AM -0700, J. Paul Reed wrote:

> That actually is kind of annoying. I played around with Google, but it
> doesn't seem to spider those pages. Dave: is there anything in robots.txt
> for those pages that would make it not spider the mailing list archives?

No, but they're all fed by scripts in the cgi-bin directory, and Google
purposely avoids CGI pages.
-- 
Dave Miller      Project Leader, Bugzilla Bug Tracking System
http://www.justdave.net/             http://www.bugzilla.org/


From bbaetz at acm.org  Wed May 28 15:10:53 2003
From: bbaetz at acm.org (Bradley Baetz)
Date: Thu, 29 May 2003 01:10:53 +1000
Subject: Taint check
In-Reply-To: <a06001209bafa7e18f64a@[192.168.1.204]>
References: <85339FA608200E43BA1A364F09C337D67AE8C6@bruno.point2.com> <20030528001901.B5453@sigkill.com> <3ED4C9B3.7010604@bugzilla.org> <20030528074830.A7311@sigkill.com> <a06001209bafa7e18f64a@[192.168.1.204]>
Message-ID: <20030528151053.GA2721@mango.home>

On Wed, May 28, 2003 at 10:59:14AM -0400, David Miller wrote:
> No, but they're all fed by scripts in the cgi-bin directory, and Google
> purposely avoids CGI pages.

will explicit listing in robots.txt override that, or can we add
mod_rewrite rules so that they don't look like cgis?

Bradley



From cbendell at point2.com  Wed May 28 14:55:20 2003
From: cbendell at point2.com (Colin Bendell)
Date: Wed, 28 May 2003 08:55:20 -0600
Subject: Taint check
Message-ID: <85339FA608200E43BA1A364F09C337D67AE8C8@bruno.point2.com>

> -----Original Message-----
> From: J. Paul Reed [mailto:preed at sigkill.com]
> Sent: Wednesday, May 28, 2003 1:19 AM
> 
> On 27 May 2003 at 15:16:24, Colin Bendell moved bits on my disk to
say:
> > I've had to remove them to get Perl working under win32 (worked as
is in
> > the linux configuration).
> 
> That's probably not the proper solution to the problem; doing so
reduces
> the security of your BZ installation.
> 
> Are you using IIS?

Yes, and this seems to be the problem.  I'm using ActiveState's
perlis.dll to execute the perl cgi which doesn't support the taint check
(because it is loaded early).

Isn't the taint check just as much a problem when using mod_perl?  

For now I'm content to remove the -T switch and let cvs do the diffs for
me :)

Thanks for the pointer.

/colin



From cbendell at point2.com  Wed May 28 14:52:18 2003
From: cbendell at point2.com (Colin Bendell)
Date: Wed, 28 May 2003 08:52:18 -0600
Subject: Taint check
Message-ID: <85339FA608200E43BA1A364F09C337D60130C786@bruno.point2.com>

Sorry, 'news groups' was the wrong choice of words.  I should have said
'this mailing list'.

/colin

-----Original Message-----
From: J. Paul Reed [mailto:preed at sigkill.com] 
Sent: Wednesday, May 28, 2003 8:49 AM
To: developers at bugzilla.org
Subject: Re: Taint check

On 28 May 2003 at 10:37:39, Jake moved bits on my disk to say:

> That's a great way to search the newsgroup, but it doesn't do anything
> for this list. AFAICT, there is no search feature for this list (the
> archives are at bugzilla.org, but they aren't indexed by google nor do
> they have their own search function).

Ahh.. I thought he was talking about about the newsgroup (he said "but
the
'developers' news group doesn't seem to have a 'search' feature.")

That actually is kind of annoying. I played around with Google, but it
doesn't seem to spider those pages. Dave: is there anything in
robots.txt
for those pages that would make it not spider the mailing list archives?

Later,
Paul
------------------------------------------------------------------------
J. Paul Reed -- 0xDF8708F8 || preed at sigkill.com || web.sigkill.com/preed
To hold on to sanity too tight is insane.   -- Nick Falzone, Pushing Tin

I use PGP; you should use PGP too... if only to piss off John Ashcroft
----
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=cbendell at point2.com>



From cbendell at point2.com  Wed May 28 15:20:06 2003
From: cbendell at point2.com (Colin Bendell)
Date: Wed, 28 May 2003 09:20:06 -0600
Subject: Taint check
Message-ID: <85339FA608200E43BA1A364F09C337D67AE8CA@bruno.point2.com>

Mod_rewrite is the way to go.  The robots.txt will allow you to get a
limited depth but any links with a parameter in it
(search.cgi?p1=1&p2=2) will be avoided by the google spider like a
person with SARS.

/colin

-----Original Message-----
From: Bradley Baetz [mailto:bbaetz at acm.org] 
Sent: Wednesday, May 28, 2003 9:11 AM
To: developers at bugzilla.org
Subject: Re: Taint check

On Wed, May 28, 2003 at 10:59:14AM -0400, David Miller wrote:
> No, but they're all fed by scripts in the cgi-bin directory, and
Google
> purposely avoids CGI pages.

will explicit listing in robots.txt override that, or can we add
mod_rewrite rules so that they don't look like cgis?

Bradley




From justdave at syndicomm.com  Wed May 28 15:25:54 2003
From: justdave at syndicomm.com (David Miller)
Date: Wed, 28 May 2003 11:25:54 -0400
Subject: Taint check
In-Reply-To: <20030528151053.GA2721@mango.home>
References: <85339FA608200E43BA1A364F09C337D67AE8C6@bruno.point2.com>
 <20030528001901.B5453@sigkill.com> <3ED4C9B3.7010604@bugzilla.org>
 <20030528074830.A7311@sigkill.com>
 <a06001209bafa7e18f64a@[192.168.1.204]> <20030528151053.GA2721@mango.home>
Message-ID: <a0600120abafa83873c35@[192.168.1.204]>

On 5/29/2003 1:10 AM +1000, Bradley Baetz wrote:

> On Wed, May 28, 2003 at 10:59:14AM -0400, David Miller wrote:
>> No, but they're all fed by scripts in the cgi-bin directory, and Google
>> purposely avoids CGI pages.
>
> will explicit listing in robots.txt override that, or can we add
> mod_rewrite rules so that they don't look like cgis?

Preliminary search form via htdig available at
http://www.bugzilla.org/discussion.html

-- 
Dave Miller      Project Leader, Bugzilla Bug Tracking System
http://www.justdave.net/             http://www.bugzilla.org/


From preed at sigkill.com  Wed May 28 15:35:01 2003
From: preed at sigkill.com (J. Paul Reed)
Date: Wed, 28 May 2003 08:35:01 -0700
Subject: Taint check
In-Reply-To: <85339FA608200E43BA1A364F09C337D67AE8C8@bruno.point2.com>; from cbendell@point2.com on Wed, May 28, 2003 at 08:55:20AM -0600
References: <85339FA608200E43BA1A364F09C337D67AE8C8@bruno.point2.com>
Message-ID: <20030528083501.B7311@sigkill.com>

On 28 May 2003 at 08:55:20, Colin Bendell moved bits on my disk to say:

> Yes, and this seems to be the problem.  I'm using ActiveState's
> perlis.dll to execute the perl cgi which doesn't support the taint check
> (because it is loaded early).

You might also take a look at bug 140784; I only skimmed it, but a comment
in another bug said "If you're using IIS, there's some additional
setup you have to do for taint mode to work." That would seem to imply that
taint mode *does* work with Win32, with a workaround.

If you're having problems, I think this is a bug that we might have to fix
for 2.18... but we should confirm that it is indeed a bug.

> Isn't the taint check just as much a problem when using mod_perl?  

I don't know, but I don't think so... bbaetz would know for sure.

> For now I'm content to remove the -T switch and let cvs do the diffs for
> me :)

I wouldn't do that on a public installation if I were you; that's not
really the solution to the problem, especially on Win32.

Later,
Paul
------------------------------------------------------------------------
J. Paul Reed -- 0xDF8708F8 || preed at sigkill.com || web.sigkill.com/preed
To hold on to sanity too tight is insane.   -- Nick Falzone, Pushing Tin

I use PGP; you should use PGP too... if only to piss off John Ashcroft


From caseyg at chsamerica.com  Wed May 28 15:47:06 2003
From: caseyg at chsamerica.com (Casey Gregoire)
Date: Wed, 28 May 2003 11:47:06 -0400
Subject: enter_bug.cgi at bugzilla
Message-ID: <C3EB95A31BDAD511827C00B0D0F95AF57BCB43@BUCKWHEAT>

Does the custom template use something to group them? Can I get this
template as a base for what I would like to do?

Thanks,
	Casey Gregoire

-----Original Message-----
From: Jake [mailto:jake at bugzilla.org]
Sent: Wednesday, May 28, 2003 10:39 AM
To: developers at bugzilla.org
Subject: Re: enter_bug.cgi at bugzilla

Casey Gregoire wrote:

> What is that makes the bugzilla.mozilla.org's enter_bug.cgi separate
> the products into groups like Client Software, Client Support,
> Components, Etc.?
>
> //
>
A custom template.

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


From justdave at syndicomm.com  Wed May 28 15:57:13 2003
From: justdave at syndicomm.com (David Miller)
Date: Wed, 28 May 2003 11:57:13 -0400
Subject: Taint check
In-Reply-To: <20030528083501.B7311@sigkill.com>
References: <85339FA608200E43BA1A364F09C337D67AE8C8@bruno.point2.com>
 <20030528083501.B7311@sigkill.com>
Message-ID: <a0600120bbafa8c44486a@[192.168.1.204]>

On 5/28/2003 8:35 AM -0700, J. Paul Reed wrote:

> On 28 May 2003 at 08:55:20, Colin Bendell moved bits on my disk to say:
>
>> Yes, and this seems to be the problem.  I'm using ActiveState's
>> perlis.dll to execute the perl cgi which doesn't support the taint check
>> (because it is loaded early).
>
> You might also take a look at bug 140784; I only skimmed it, but a comment
> in another bug said "If you're using IIS, there's some additional
> setup you have to do for taint mode to work." That would seem to imply that
> taint mode *does* work with Win32, with a workaround.
>
> If you're having problems, I think this is a bug that we might have to fix
> for 2.18... but we should confirm that it is indeed a bug.

IIRC, the deal with Win32 is that everything runs on extension mappings.
You either have ALL of your Perl scripts run in taint mode, or none of
them.  And several of the admin scripts won't yet.

In order for taint mode to work on a file-by-file basis on Win32, you would
have to give a different filename extension to files that need taint mode,
and add a new mapping in the control pannel for the new extension to run
Perl in taint mode.  Doing this would also mean changing all of the links
to said files to look for the new filename extension.
-- 
Dave Miller      Project Leader, Bugzilla Bug Tracking System
http://www.justdave.net/             http://www.bugzilla.org/


From cbendell at point2.com  Wed May 28 16:33:45 2003
From: cbendell at point2.com (Colin Bendell)
Date: Wed, 28 May 2003 10:33:45 -0600
Subject: Taint check
Message-ID: <85339FA608200E43BA1A364F09C337D60130C78B@bruno.point2.com>

The only way to get IIS working is to do the all or none approach and
use the perl.exe mapping, not the perils.dll aspi mapping.  As I
understand it, not all the admin pages with this approach.

/colin

-----Original Message-----
From: J. Paul Reed [mailto:preed at sigkill.com] 
Sent: Wednesday, May 28, 2003 9:35 AM
To: developers at bugzilla.org
Subject: Re: Taint check

On 28 May 2003 at 08:55:20, Colin Bendell moved bits on my disk to say:

> Yes, and this seems to be the problem.  I'm using ActiveState's
> perlis.dll to execute the perl cgi which doesn't support the taint
check
> (because it is loaded early).

You might also take a look at bug 140784; I only skimmed it, but a
comment
in another bug said "If you're using IIS, there's some additional
setup you have to do for taint mode to work." That would seem to imply
that
taint mode *does* work with Win32, with a workaround.

If you're having problems, I think this is a bug that we might have to
fix
for 2.18... but we should confirm that it is indeed a bug.

> Isn't the taint check just as much a problem when using mod_perl?  

I don't know, but I don't think so... bbaetz would know for sure.

> For now I'm content to remove the -T switch and let cvs do the diffs
for
> me :)

I wouldn't do that on a public installation if I were you; that's not
really the solution to the problem, especially on Win32.

Later,
Paul
------------------------------------------------------------------------
J. Paul Reed -- 0xDF8708F8 || preed at sigkill.com || web.sigkill.com/preed
To hold on to sanity too tight is insane.   -- Nick Falzone, Pushing Tin

I use PGP; you should use PGP too... if only to piss off John Ashcroft
----
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=cbendell at point2.com>



From myk at mozilla.org  Wed May 28 17:27:03 2003
From: myk at mozilla.org (Myk Melez)
Date: Wed, 28 May 2003 10:27:03 -0700
Subject: Throw GCC on the HOF
In-Reply-To: <3ED3EF40.2020300@mozilla.org>
References: <5FB93110-8CBD-11D7-85C9-000A95A34564@dberlin.org> <3ED3E23E.1040103@bugzilla.org> <3ED3EF40.2020300@mozilla.org>
Message-ID: <3ED4F167.3040405@mozilla.org>

Gervase Markham wrote:

> Jake wrote:
>
>> Daniel Berlin wrote:
>>
>>> As of yesterday, we now are Bugzilla-only.
>>
>>
>> Just updated the HOF page...
>
>
> Er... it's autogenerated from a plain text source file, so you 
> probably don't want to do that, as changes will get overwritten.

Can you check in the plain-text file and the script that auto-generates 
so other folks can update the page when necessary?

-myk




From bbaetz at acm.org  Wed May 28 21:06:58 2003
From: bbaetz at acm.org (Bradley Baetz)
Date: Thu, 29 May 2003 07:06:58 +1000
Subject: Taint check
In-Reply-To: <85339FA608200E43BA1A364F09C337D67AE8C8@bruno.point2.com>
References: <85339FA608200E43BA1A364F09C337D67AE8C8@bruno.point2.com>
Message-ID: <20030528210658.GA1604@mango.home>

On Wed, May 28, 2003 at 08:55:20AM -0600, Colin Bendell wrote:
> 
> Yes, and this seems to be the problem.  I'm using ActiveState's
> perlis.dll to execute the perl cgi which doesn't support the taint check
> (because it is loaded early).

Really? Not even with an option? Does the IIS persistence stuff work?
Dont we have the same issue swith global variables that we do with
mod_perl?

> 
> Isn't the taint check just as much a problem when using mod_perl?  

We have to enable it in the mod_perl config, yes. And that will then
apply for all mod_perl instances on teh same host, so if you're running
another perl app which doesn't support taint mode then I guess you will
have issues.

> 
> For now I'm content to remove the -T switch and let cvs do the diffs for
> me :)
> 

Taint mode isn't to stop problems we know about, its to stop ones we
don't know about.

Bradley


From cbendell at point2.com  Wed May 28 21:50:08 2003
From: cbendell at point2.com (Colin Bendell)
Date: Wed, 28 May 2003 15:50:08 -0600
Subject: Taint check
Message-ID: <85339FA608200E43BA1A364F09C337D67AE8CE@bruno.point2.com>

> -----Original Message-----
> From: Bradley Baetz [mailto:bbaetz at acm.org]
> Sent: Wednesday, May 28, 2003 3:07 PM
> On Wed, May 28, 2003 at 08:55:20AM -0600, Colin Bendell wrote:
> >
> > Yes, and this seems to be the problem.  I'm using ActiveState's
> > perlis.dll to execute the perl cgi which doesn't support the taint
check
> > (because it is loaded early).
> 
> Really? Not even with an option? Does the IIS persistence stuff work?
> Dont we have the same issue swith global variables that we do with
> mod_perl?

As far as I know there aren't any global options available for the isapi
plugin perlis.dll .  If I switch to using the perl executable, then
certainly I can specify a global taint check setting.  

I've read that some admin components don't work with the global taint
setting turned on.  Is this correct? If so, which pages are these?




From gerv at mozilla.org  Wed May 28 22:27:10 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Wed, 28 May 2003 23:27:10 +0100
Subject: Throw GCC on the HOF
In-Reply-To: <3ED4F167.3040405@mozilla.org>
References: <5FB93110-8CBD-11D7-85C9-000A95A34564@dberlin.org> <3ED3E23E.1040103@bugzilla.org> <3ED3EF40.2020300@mozilla.org> <3ED4F167.3040405@mozilla.org>
Message-ID: <3ED537BE.3060309@mozilla.org>

Myk Melez wrote:
> Can you check in the plain-text file and the script that auto-generates 
> so other folks can update the page when necessary?

Sure. I'll clean it up and check it in.

Gerv



From gerv at mozilla.org  Wed May 28 22:31:24 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Wed, 28 May 2003 23:31:24 +0100
Subject: enter_bug.cgi at bugzilla
In-Reply-To: <C3EB95A31BDAD511827C00B0D0F95AF57BCB43@BUCKWHEAT>
References: <C3EB95A31BDAD511827C00B0D0F95AF57BCB43@BUCKWHEAT>
Message-ID: <3ED538BC.9080108@mozilla.org>

Casey Gregoire wrote:
> Does the custom template use something to group them? Can I get this
> template as a base for what I would like to do?

I wrote it; I think it works by hard-coding some categories, and then 
printing everything else at the end. It'll be attached to some closed 
buy somewhere, either in the Bugzilla or mozilla.org products. I'm sure 
you can hunt it down :-)

Gerv



From gerv at mozilla.org  Wed May 28 22:32:59 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Wed, 28 May 2003 23:32:59 +0100
Subject: Dependancy Graphs
In-Reply-To: <OFDDACC96D.6998BFA0-ON88256D34.001FFB4A@qad.com>
References: <OFDDACC96D.6998BFA0-ON88256D34.001FFB4A@qad.com>
Message-ID: <3ED5391B.1050704@mozilla.org>

Patrick McGoldrick wrote:
> I can't seem to get Dependancy graphs working on the 2.16.3 stable build.
> I just get a blue vertical line on the left side.

How have you set them up? Which instructions did you follow? What 
settings have you got in editparams for the relevant params?

And... why are you not asking end-user questions in the newsgroup, given 
that everywhere this list is mentioned on any web page, it says it's a 
developers' list? :-)

Gerv



From gerv at mozilla.org  Wed May 28 23:22:27 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Thu, 29 May 2003 00:22:27 +0100
Subject: Throw GCC on the HOF
In-Reply-To: <3ED4F167.3040405@mozilla.org>
References: <5FB93110-8CBD-11D7-85C9-000A95A34564@dberlin.org> <3ED3E23E.1040103@bugzilla.org> <3ED3EF40.2020300@mozilla.org> <3ED4F167.3040405@mozilla.org>
Message-ID: <3ED544B3.2010300@mozilla.org>

> Can you check in the plain-text file and the script that auto-generates 
> so other folks can update the page when necessary?

I've checked it all into a new "installation-list" subdirectory, and 
moved the list into there. It hasn't been around long, so I figured it 
was OK to change the URL before it got well-known.

The script has usage instructions in the comment.

Gerv



From justdave at syndicomm.com  Wed May 28 23:24:21 2003
From: justdave at syndicomm.com (David Miller)
Date: Wed, 28 May 2003 19:24:21 -0400
Subject: Throw GCC on the HOF
In-Reply-To: <3ED544B3.2010300@mozilla.org>
References: <5FB93110-8CBD-11D7-85C9-000A95A34564@dberlin.org>
 <3ED3E23E.1040103@bugzilla.org> <3ED3EF40.2020300@mozilla.org>
 <3ED4F167.3040405@mozilla.org> <3ED544B3.2010300@mozilla.org>
Message-ID: <a0600120dbafaf58ef61f@[192.168.1.204]>

On 5/29/2003 12:22 AM +0100, Gervase Markham wrote:

>> Can you check in the plain-text file and the script that auto-generates
>> so other folks can update the page when necessary?
>
> I've checked it all into a new "installation-list" subdirectory, and
> moved the list into there. It hasn't been around long, so I figured it
> was OK to change the URL before it got well-known.
>
> The script has usage instructions in the comment.

Did you change the links to it from other places on the website?

about.html is the only place I know of off-hand.
-- 
Dave Miller      Project Leader, Bugzilla Bug Tracking System
http://www.justdave.net/             http://www.bugzilla.org/


From jake at bugzilla.org  Thu May 29 02:46:37 2003
From: jake at bugzilla.org (Jake)
Date: Wed, 28 May 2003 22:46:37 -0400
Subject: Throw GCC on the HOF
In-Reply-To: <3ED544B3.2010300@mozilla.org>
References: <5FB93110-8CBD-11D7-85C9-000A95A34564@dberlin.org> <3ED3E23E.1040103@bugzilla.org> <3ED3EF40.2020300@mozilla.org> <3ED4F167.3040405@mozilla.org> <3ED544B3.2010300@mozilla.org>
Message-ID: <3ED5748D.7070306@bugzilla.org>

Gervase Markham wrote:

> I've checked it all into a new "installation-list" subdirectory, and 
> moved the list into there. It hasn't been around long, so I figured it 
> was OK to change the URL before it got well-known.

I had placed a link to it in the documentation source (haven't 
recompiled yet) that I was going to update but it looks like the 
installation-list directory is empty.




From gerv at mozilla.org  Thu May 29 08:30:39 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Thu, 29 May 2003 09:30:39 +0100
Subject: Throw GCC on the HOF
In-Reply-To: <a0600120dbafaf58ef61f@[192.168.1.204]>
References: <5FB93110-8CBD-11D7-85C9-000A95A34564@dberlin.org> <3ED3E23E.1040103@bugzilla.org> <3ED3EF40.2020300@mozilla.org> <3ED4F167.3040405@mozilla.org> <3ED544B3.2010300@mozilla.org> <a0600120dbafaf58ef61f@[192.168.1.204]>
Message-ID: <3ED5C52F.4020506@mozilla.org>

David Miller wrote:
> Did you change the links to it from other places on the website?
> 
> about.html is the only place I know of off-hand.

Yep - I grepped, and that was the only one.

Gerv



From bbaetz at acm.org  Thu May 29 14:45:12 2003
From: bbaetz at acm.org (Bradley Baetz)
Date: Fri, 30 May 2003 00:45:12 +1000
Subject: Taint check
In-Reply-To: <85339FA608200E43BA1A364F09C337D67AE8CE@bruno.point2.com>
References: <85339FA608200E43BA1A364F09C337D67AE8CE@bruno.point2.com>
Message-ID: <20030529144512.GA1368@mango.home>

On Wed, May 28, 2003 at 03:50:08PM -0600, Colin Bendell wrote:
> As far as I know there aren't any global options available for the isapi
> plugin perlis.dll .  If I switch to using the perl executable, then
> certainly I can specify a global taint check setting. 

Hmm. You may not be able to turn it off individually, but can't you copy
the dll, rename it, and have one with taint on, and one with taint off?

> 
> I've read that some admin components don't work with the global taint
> setting turned on.  Is this correct? If so, which pages are these?
> 


Most of edit*.cgi. They're not user facing, and you need to login first
for
them, so they're less important. They should still be converted at some
stage though

Bradley


From preed at sigkill.com  Thu May 29 14:59:16 2003
From: preed at sigkill.com (J. Paul Reed)
Date: Thu, 29 May 2003 07:59:16 -0700
Subject: Taint check
In-Reply-To: <20030529144512.GA1368@mango.home>; from bbaetz@acm.org on Fri, May 30, 2003 at 12:45:12AM +1000
References: <85339FA608200E43BA1A364F09C337D67AE8CE@bruno.point2.com> <20030529144512.GA1368@mango.home>
Message-ID: <20030529075916.A13622@sigkill.com>

On 30 May 2003 at 00:45:12, Bradley Baetz moved bits on my disk to say:

> Most of edit*.cgi. They're not user facing, and you need to login first
> for them, so they're less important. They should still be converted at
> some stage though

This is bug 141006, which now sports the [needed for Win32bz] status
whiteboard, and has a target of 2.18 (which it's had for about a year).

Later,
Paul
------------------------------------------------------------------------
J. Paul Reed -- 0xDF8708F8 || preed at sigkill.com || web.sigkill.com/preed
To hold on to sanity too tight is insane.   -- Nick Falzone, Pushing Tin

I use PGP; you should use PGP too... if only to piss off John Ashcroft


From cbendell at point2.com  Thu May 29 15:24:21 2003
From: cbendell at point2.com (Colin Bendell)
Date: Thu, 29 May 2003 09:24:21 -0600
Subject: Taint check
Message-ID: <85339FA608200E43BA1A364F09C337D67AE8D1@bruno.point2.com>

> -----Original Message-----
> From: Bradley Baetz [mailto:bbaetz at acm.org]
> Sent: Thursday, May 29, 2003 8:45 AM
> On Wed, May 28, 2003 at 03:50:08PM -0600, Colin Bendell wrote:
> > As far as I know there aren't any global options available for the
isapi
> > plugin perlis.dll .  If I switch to using the perl executable, then
> > certainly I can specify a global taint check setting.
> 
> Hmm. You may not be able to turn it off individually, but can't you
copy
> the dll, rename it, and have one with taint on, and one with taint
off?

Unfortunately its not as simple as that.  Using the isapi dll's you
can't set taint check on or off not unless you modify the code, which is
not available since ActiveState has kept this closed source.  Oh well.
Guess I'll have to just live with the performance penalty of executing
perl for each page visit.

For posterity sake, the change that has to be made in IIS (5) is to
associate .cgi scripts with:
c:\perl\bin\perl.exe -T "%s" "%s"

thanks
/colin



From gerv at mozilla.org  Thu May 29 16:17:12 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Thu, 29 May 2003 17:17:12 +0100
Subject: Taint check
In-Reply-To: <20030529075916.A13622@sigkill.com>
References: <85339FA608200E43BA1A364F09C337D67AE8CE@bruno.point2.com> <20030529144512.GA1368@mango.home> <20030529075916.A13622@sigkill.com>
Message-ID: <3ED63288.1000603@mozilla.org>

J. Paul Reed wrote:
> On 30 May 2003 at 00:45:12, Bradley Baetz moved bits on my disk to say:
> 
>>Most of edit*.cgi. They're not user facing, and you need to login first
>>for them, so they're less important. They should still be converted at
>>some stage though
> 
> This is bug 141006, which now sports the [needed for Win32bz] status
> whiteboard, and has a target of 2.18 (which it's had for about a year).

Admin refactoring, templatisation and taint is something I'm planning to 
do - but I want to get bug 16009 finished first, and that's still 
waiting for review...

Gerv



From gerv at mozilla.org  Thu May 29 17:12:04 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Thu, 29 May 2003 18:12:04 +0100
Subject: Custom fields design doc
In-Reply-To: <20030528011436.3C5E5BC52@diggity.schwag.org>
References: <20030528011436.3C5E5BC52@diggity.schwag.org>
Message-ID: <3ED63F64.3080701@mozilla.org>

Sean McAfee wrote:

> Gervase Markham <gerv at mozilla.org> wrote:
> 
>>The invariants for our current localisation strategy are:
>>
>>- There should be a single localisation mechanism.
>>- A localiser should be able to create a tarball which, when unzipped,
>>  places files which totally enable a Bugzilla for their language.
>>- An admin should be able to unzip said tarball, add the code for the
>>  language to a param, and all of Bugzilla starts working in that
>>  language, as well as the ones it currently works in.
>>- Bugzilla can be used at the same time by different people in different
>>  languages.
> 
> It seems to me that a distinction can be drawn between relatively
> static localized text, such as the static content of an HTML document,
> and relatively variable localized text, such as field display names or
> the labels of a selection field, either of which an administrator might
> update frequently.  The former clearly belongs in a template file, but it's
> not so obvious to me that the latter does as well.

I agree that this is not as obvious. Do you have another solution which 
maintains the invariants (or breaks them, but explains why it's not bad 
to break them in that particular way)?

>>The first thing is invariant because it makes Bugzilla hackers lives as 
>>easy as possible.
> 
> Modifying template files in-place programmatically, with all of the
> necessary locking mechanisms, doesn't seem particularly easy.

I don't know about other OSes, but Unix seems to do a pretty good job of 
making sure someone doesn't try and read a file while someone else is 
writing to it :-)

> But custom field information is metadata particular to a specific
> Bugzilla installation.  Obviously it's desirable to be able to unpack
> (say) a French localization tarball onto an existing installation and
> have Bugzilla immediately start presenting pages in French, but of what
> use would it be to include in that tarball localization information
> for custom fields from some other installation that don't exist in the
> target installation?

Because it could be that some of Bugzilla's default fields move to using 
the custom field mechanism.

Gerv



From gerv at mozilla.org  Thu May 29 17:26:21 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Thu, 29 May 2003 18:26:21 +0100
Subject: Custom fields design doc
In-Reply-To: <20030528024623.5C24FBC52@diggity.schwag.org>
References: <20030528024623.5C24FBC52@diggity.schwag.org>
Message-ID: <3ED642BD.7090805@mozilla.org>

Sean McAfee wrote:
> Gervase Markham <gerv at mozilla.org> wrote:
>>The UI would be something like:
>>
>>Product: Foo-Bar Product
>>
>>Choose the custom fields for this product:
>>
>>|------------|
>>| SomeField  |
>>| OtherField |
>>| Priority   |   <- multi-select list box
>>| Severity   |
>>| Chip Name  |
>>|------------|
>>
>>This seems, conceptually and in code, the easiest thing.
> 
> My objections:
> 
> 1.  Lack of context.  The administrator could easily add the wrong field
> if its name is similar to that of the desired field.

Then don't give your fields similar names. :-) That's like saying "A bug 
filer could accidentally choose the wrong product if you give them 
similar names." - "Well, don't do that, then :-)"

> 2.  This interface provides no high-level view of the relationship
> between products and fields.  Suppose an administrator wants to change
> some property of a field Foo.  The admin won't be able to know which
> products the change will affect without examining the field list for
> every product in the installation.

I didn't define the sum total of the interface to custom fields, merely 
the one under question. I anticipate that, on the screen for altering 
the properties of a particular field, it would list which products it is 
currently used by. It might even let you change them there too, so you 
could attack the mapping from either angle.

> 3.  I think it'll be more common than not that fields will be shared
> in related groups.  Suppose ten products share ten related fields.
> To add a single new related field to each product, or to remove one of
> the existing fields, would require ten separate operations under your
> scheme, but only one under mine.

Assuming for the moment that your assertion about grouping being common 
is correct, this might, then, take an admin one or two minutes instead 
of five seconds. Is that worth the extra complexity (both UI and code) 
introduced by field groups, given that adding new fields would not (or 
definitely should not!) be an every day activity?

In addition, the UI for defining a new field would probably have a 
multi-select which allowed you to define the initial products it was a 
member of. So it wouldn't take even two minutes unless you added it later.

I'm happy to do a complete UI design for the admin interface to custom 
fields, if that'll help clear up any ambiguities.

>>But actually, I don't really see the need for an unset_label at all. 
>>What's wrong with "the field should be blank if it's not been set".
> 
> How then does the user unset a single-selection field?  With a blank
> selection option?

It depends what you mean by "unset". If the admin wants to allow a "none 
of the above" option, they'll add one, calling it "", "<none>", or 
whatever they like.

They may, however, want to make it so that this field always has one of 
the set values (i.e. it's compulsory on bug filing, and can never be 
unset.) This can't be done if there's an ever-present unset value.

The provision of a blank, none-of-the-above or unset value should be up 
to the admin, not us.

>>>I'm reluctant to do this for a few reasons.  First, the more orthogonal
>>>the custom fields implementation is to the core, the less chance there
>>>is of a buggy interaction between the two.
> 
>>The more tested core code the custom fields implementation reuses, the 
>>less buggy it will be :-)
>>
>>Do not think of custom fields as some sort of side bolt-on that can be 
>>unbolted later.
> 
> I wasn't thinking of unbolting, but of modularity, which has many well-known
> benefits.

As does code reuse :-)

>>>Second, queries against bug
>>>activity would be complicated by cast functions if everything is stored
>>>as a string.  
> 
>>I don't quite understand this statement. What problem is is highlighting 
>>that we don't currently have anyway?
> 
> Well, I don't know all of the current problems, so I can't answer this.
> I'd just think it's cleaner to have where clauses like
> "WHERE new_value > 20030101" rather than
> "WHERE CAST(added AS DATETIME) > 20030101".  Come to think of it, it's
> impossible to unambiguously disinguish stringified selection field
> changes if some of the possible values are alike at the beginning or end.
> For example, if a selection field's domain was "FOO", "BAR", and "FOO BAR",
> and the string "FOO BAR" was stored in bugs_activity's "added" column, does
> that mean the single value "FOO BAR" was added, or the two values "FOO" and
> "BAR"?

I believe that (for the only multi-valued field we have, CC list) the 
field separator is a comma. But I'd have to check.

>>I agree that this needs discussion, but truncating the stored parts of 
>>long string changes or multi-select changes to tinytexts might well be 
>>an acceptable solution. Expanding the field size might also be fine.
> 
> I'm reluctant to accept lossy auditing.

Then upgrade the current bugs_activity system. But no-one has ever 
complained about it before. What exactly do you plan to audit that would 
require such detail?

>>(This assumes, of course, that I understand what this field does. Does 
>>it define what action the CGI takes when the form is submitted?)
> 
> No, it describes the page from which editcustomfields.cgi was invoked.  It's
> "main-menu" on the main menu, "create-field" from any of the field-creation
> pages, etc.  In the main-menu case, I use the "action" parameter to identify
> which submit control was pressed, like so:
> 
> <input type="hidden" name="context" value="main-menu">
> <input type="submit" name="action" value="Move"> a custom field.
> <input type="submit" name="action" value="Edit"> a custom field.
> <!-- and so on -->

Right. So why do you need both "action" and "context"? Surely a single 
parameter, defining what is actually to be done, is sufficient?

>>>As just one example, in theory
>>>it's sufficient to copy the "type" column from the custom_fields table
>>>into a template-accessible hash, but in writing the template I found
>>>that it's clearer to abstract the type information into several distinct
>>>members--"is_integer", "is_string", etc.  
> 
>>This sort of decision is also implementation, and has no place in a 
>>design document either :-)
> 
> You seem to be saying that no Perl-related design document should
> ever decide what names to use as hash keys.  I disagree.  In this case
> particularly, the keys are a crucial part of the interface between code
> and template.  What if one person were assigned to implement the code,
> and another the templates?  

I'd say that you don't implement from a high-level design (which this 
is.) You implement from a low-level design or an API specification (e.g. 
hash key names.) If this document is going to eventually define 
everything you'd need to know to implement the function, then we'll be 
here all year :-) But perhaps this is getting off-topic.

Gerv




From gerv at mozilla.org  Thu May 29 17:34:05 2003
From: gerv at mozilla.org (Gervase Markham)
Date: Thu, 29 May 2003 18:34:05 +0100
Subject: l10n : French Localisation
In-Reply-To: <20030527160514.GA23490@stage2.gsn12.francetelecom.fr>
References: <20030527160514.GA23490@stage2.gsn12.francetelecom.fr>
Message-ID: <3ED6448D.6020905@mozilla.org>

LAMBERT Olivier URS TOULOUSE wrote:

> Before starting to work like a nut, i'd like to know if some translation
> work had already be done, and who should I contact...

Dave is the fount of all knowledge; but I don't know of any French 
localisation.

Gerv



From justdave at syndicomm.com  Thu May 29 17:41:32 2003
From: justdave at syndicomm.com (David Miller)
Date: Thu, 29 May 2003 13:41:32 -0400
Subject: l10n : French Localisation
In-Reply-To: <3ED6448D.6020905@mozilla.org>
References: <20030527160514.GA23490@stage2.gsn12.francetelecom.fr>
 <3ED6448D.6020905@mozilla.org>
Message-ID: <a06001214bafbf6391b6e@[192.168.1.204]>

On 5/29/2003 6:34 PM +0100, Gervase Markham wrote:

> LAMBERT Olivier URS TOULOUSE wrote:
>
>> Before starting to work like a nut, i'd like to know if some translation
>> work had already be done, and who should I contact...
>
> Dave is the fount of all knowledge; but I don't know of any French
> localisation.

Someone mentioned one a while back, wanting to make sure they weren't
duplicating anything.  They said they were going to start a bugzilla-fr
project on Sourceforge if nobody had one going yet.  As of now there is
still no such project on Sourceforge, and I have never heard from that
person again, so I would assume they lost interest and nobody's doing it
yet.
-- 
Dave Miller      Project Leader, Bugzilla Bug Tracking System
http://www.justdave.net/             http://www.bugzilla.org/


From caseyg at chsamerica.com  Thu May 29 18:49:26 2003
From: caseyg at chsamerica.com (Casey Gregoire)
Date: Thu, 29 May 2003 14:49:26 -0400
Subject: Bug Dependancy
Message-ID: <C3EB95A31BDAD511827C00B0D0F95AF57D8031@BUCKWHEAT>

Is there a reason why if one bug is dependant upon another that you can
still close the dependant bug? Say for example bug 231 blocks bug 233. if
you try to resolve bug 233 it does not even give you a message saying that
it shouldn't be closed until 231 is since it 'depends' on that bug. Is this
way it is meant to be?
 
Thank you,
            Casey Gregoire
            Programmer
            CHS of America
            100 1st Ave S. Suite 601
            St. Petersburg, FL 33701
            Phone - (727) 824-0800 ext 1236

Every great achievement was once impossible. -- Anonymous
I'd like to get started on time, if we can, inasmuch as we're late already.
-- Larry Gelbart
Nothing is accomplished without passion. -- My Fortune Cookie
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20030529/1df4637f/attachment.html>

From jeff.hedlund at matrixsi.com  Thu May 29 19:05:14 2003
From: jeff.hedlund at matrixsi.com (Jeff Hedlund)
Date: Thu, 29 May 2003 15:05:14 -0400
Subject: Bug Dependancy
In-Reply-To: <C3EB95A31BDAD511827C00B0D0F95AF57D8031@BUCKWHEAT>
References: <C3EB95A31BDAD511827C00B0D0F95AF57D8031@BUCKWHEAT>
Message-ID: <3ED659EA.2050105@matrixsi.com>



Casey Gregoire wrote:
> Is there a reason why if one bug is dependant upon another that you can 
> still close the dependant bug? Say for example bug 231 blocks bug 233. 
> if you try to resolve bug 233 it does not even give you a message saying 
> that it shouldn?t be closed until 231 is since it ?depends? on that bug. 
> Is this way it is meant to be?

http://bugzilla.mozilla.org/show_bug.cgi?id=24496

Jeff
-- 

   /\  /\              ..    ..    ..    jeff.hedlund at matrixsi.com
  /  \/  \ a t r i x  .  .  .  .  .  .  .           (770) 794-7233
  s o f t w a r e  i n c  ..    ..    ..   http://www.matrixsi.com



From olivier.lambert at francetelecom.com  Fri May 30 07:22:51 2003
From: olivier.lambert at francetelecom.com (LAMBERT Olivier URS TOULOUSE)
Date: Fri, 30 May 2003 09:22:51 +0200
Subject: l10n : French Localisation
In-Reply-To: <a06001214bafbf6391b6e@[192.168.1.204]>
References: <20030527160514.GA23490@stage2.gsn12.francetelecom.fr> <3ED6448D.6020905@mozilla.org> <a06001214bafbf6391b6e@[192.168.1.204]>
Message-ID: <20030530072251.GB27953@stage2.gsn12.francetelecom.fr>

Le Thu, May 29, 2003 at 01:41:32PM -0400, David Miller prit son clavier pour nous commenter que :
> On 5/29/2003 6:34 PM +0100, Gervase Markham wrote:
> 
> > LAMBERT Olivier URS TOULOUSE wrote:
> >
> >> Before starting to work like a nut, i'd like to know if some translation
> >> work had already be done, and who should I contact...
> >
> > Dave is the fount of all knowledge; but I don't know of any French
> > localisation.
> 
> Someone mentioned one a while back, wanting to make sure they weren't
> duplicating anything.  They said they were going to start a bugzilla-fr
> project on Sourceforge if nobody had one going yet.  As of now there is
> still no such project on Sourceforge, and I have never heard from that
> person again, so I would assume they lost interest and nobody's doing it
> yet.

No problem if I have to start from scratch...

Just I didn't want to duplicate work...

All that work will be done, but I might not be able to mantain a full
sourceforge project... Depends on how much time I can rely on...

Best regards...

Olivier
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20030530/8d439d64/attachment.sig>

From jimw at bugopolis.com  Fri May 30 16:43:43 2003
From: jimw at bugopolis.com (Jim Walters)
Date: 30 May 2003 09:43:43 -0700
Subject: data directory
Message-ID: <1054313023.22563.71.camel@localhost.localdomain>

For our customers we configure the servers to backup the database. There
is a variety of schemes depending on what their requirements are. One
thing I've wondered about are the pros and cons of placing the
information currently living in the data directory into the mysql
database. Are there reasons this won't work (in theory)?

Regards,

Jim Walters
__________________________
Jim Walters   Director of Technology
Bugopolis, Inc.

phone: +1 206 447 8315 
email: jimw at bugopolis.com
web: http://www.bugopolis.com
_________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20030530/7a307d1b/attachment.html>

From jon at vmware.com  Fri May 30 16:52:00 2003
From: jon at vmware.com (Jonathan Schatz)
Date: 30 May 2003 09:52:00 -0700
Subject: a slightly silly bug
Message-ID: <1054313520.20684.3.camel@jonschatz-lx.vmware.com>

ok, the short version is that there's a bug in the rand() function of
certain versions of mysql. i'm going to search b.m.o to see if this has
been filed before.

the longer (more fun) version of this story is attached.

-jon

-- 
Jonathan Schatz
Engineering System Administrator
VMware, Inc
"Te occidere possunt sed te edere non possunt nefas est."
-------------- next part --------------

Full Text Bug Listing
 
Bug 27294 - the train was only scary the first few times
Bug#: 27294 Category: Bugzilla Product: Any Platform: IA32
Host OS/Version: Unknown Guest OS/Version: Unknown Status: closed Severity: non-critical Priority: cleanup
Resolution: fixed Assigned To: jon Reported By: mginzton QA Contact: doug
Component: bugzilla Milestone: unknown
URL: 
Summary: the train was only scary the first few times
Opened: 2003-05-27 15:36 PST
Description:

Only the first quip in the quip list (which is, "The light at the end of the 
tunnel is an oncoming train") ever seems to show up, even though there are many 
others in the list (http://bugzilla/quips.cgi?action=show).


------- Additional Comment #1 From Benjamin Chambers 2003-05-27 15:43 PST -------

I've seen others, but I agree the train seems to be bugzilla's favorite. No
coincidence that it's first on the list, probably. Someone's random number
generator is heavily biased toward zero, perhaps?


------- Additional Comment #2 From Jonathan Schatz 2003-05-28 14:54 PST -------

erm, it seems to have resolved itself. i haven't seen the train since yesterday.


------- Additional Comment #3 From Matthew Delco 2003-05-28 14:56 PST -------

I've seen it several times today.


------- Additional Comment #4 From Matt Ginzton 2003-05-28 14:57 PST -------

I still see it most of the time.  After hitting reload about 30 times, I'd say 
about 90%.


------- Additional Comment #5 From Jonathan Schatz 2003-05-28 14:58 PST -------

heh, after i resolved this bug the quote showed back up on my buglist. go figure.


------- Additional Comment #6 From Nolan Leake 2003-05-28 15:11 PST -------

SendSQL("SELECT quip FROM quips WHERE approved = 1 ORDER BY RAND() LIMIT 1"); in
buglist.cgi is the code that that should sort the quips table randomly, and then
return the first quip.  Well, hopefully the query optimizer picks a better plan
than that, but I digress.

Sounds like whatever database we use has a shitty RAND() function.  I'd say that
nothing but MySQL can suck this much, but that's just a guess based on personal
prejudices.


------- Additional Comment #7 From Jonathan Schatz 2003-05-28 15:44 PST -------

the random distribution isn't so bad. i wrote a quick test program to run the
query 1000 times (well, almost the same query, but for queryid instead of the
actual query). here's the distribution:

quipid 1 : 0.022%
quipid 2 : 0.025%
quipid 3 : 0.028%
quipid 4 : 0.021%
quipid 5 : 0.016%
quipid 6 : 0.020%
quipid 7 : 0.017%
quipid 8 : 0.023%
quipid 9 : 0.026%
quipid 10 : 0.018%
quipid 11 : 0.023%
quipid 12 : 0.024%
quipid 13 : 0.017%
quipid 14 : 0.022%
quipid 15 : 0.021%
quipid 16 : 0.022%
quipid 17 : 0.016%
quipid 18 : 0.017%
quipid 19 : 0.020%
quipid 20 : 0.031%
quipid 21 : 0.026%
quipid 22 : 0.028%
quipid 23 : 0.017%
quipid 24 : 0.020%
quipid 25 : 0.024%
quipid 26 : 0.030%
quipid 27 : 0.022%
quipid 28 : 0.026%
quipid 29 : 0.019%
quipid 30 : 0.022%
quipid 31 : 0.026%
quipid 32 : 0.019%
quipid 33 : 0.035%
quipid 34 : 0.027%
quipid 35 : 0.023%
quipid 36 : 0.020%
quipid 37 : 0.011%
quipid 38 : 0.020%
quipid 39 : 0.022%
quipid 40 : 0.024%
quipid 41 : 0.016%
quipid 42 : 0.022%
quipid 43 : 0.022%
quipid 44 : 0.028%
quipid 45 : 0.022%

but i have bigger bugs to look at right now.


------- Additional Comment #8 From Jonathan Schatz 2003-05-28 15:45 PST -------

ok, my division was off by a factor of 100. but you get the point.


------- Additional Comment #9 From Nolan Leake 2003-05-28 16:26 PST -------

The repeated "shift-reload" test on buglist.cgi disagrees violently with your
results: in 50 trials, I got 9 quips that were not the train one.  The 9 were
evenly distributed.

One possible explanation is that the "train" quip is duplicated many times in
the quips table.  This would explain the disparity between your quipid based
results and my quip based results.

Of course, pretty much every other bug is higher priority than this one, but it
is certainly interesting.


------- Additional Comment #10 From Jonathan Schatz 2003-05-28 17:06 PST -------

ok, i re-ran the trial with the exact query, and the results are the same. maybe
a proxy issue? who knows. i'm buying a beer for the person who figures out the
problem.


------- Additional Comment #11 From Nolan Leake 2003-05-28 17:22 PST -------

Using wget, I got "train" 40/50 times going through the proxy, and 43/50 times
going directly to bugzilla.

That would seem to eliminate both the proxy's cache and my browser's cache.


------- Additional Comment #12 From Nolan Leake 2003-05-28 18:09 PST -------

Beer me.

MySQL appears to pick a very close to constant seed (I'm not sick enough to go
spelunking into MySQL's code to find out how they fucked this one up) at the
start of each connection to the database.  Your test app didn't hit this
problem, because unlike bugzilla, it doesn't reconnect to the database every time.

So the easy workaround is (both seed RAND and work around its output clustering
problems):
SendSQL("SELECT quip FROM quips ORDER BY MD5(RAND(NOW())) LIMIT 1");

Alternately, we can upgrade to MySQL 3.23.56, which I believe fixes it.  4.0
does for sure.

Finally, this points to a latent scalability problem in bugzilla.  It should be
using a connection pool of some sort.  Ideally, using a threaded MPM in Apache
2.0, so the connection pool can be shared.


------- Additional Comment #13 From Jonathan Schatz 2003-05-28 18:24 PST -------

what's your drink?

as for the scalability issue, i tried using apache 2.0. queries slowed by ~50%.
this is still possible to do on the db side, but buzilla's not mod_perl safe, so
i can't use the Apache::DBI module to do this. it's a known issue on
bugzilla.mozilla.org (http://bugzilla.mozilla.org/show_bug.cgi?id=87406) . 


------- Additional Comment #14 From Jonathan Schatz 2003-05-28 18:30 PST -------

Change 87063 by jon at jonschatz-lx on 2003/05/28 18:29:43

	quips should be random now
	
	QA Notes:
	Bug Number:27294
	Reviewed by:nolan
	Testing done:
	Mailto:

Affected files ...

... //depot/bugzilla/bugzilla-release/buglist.cgi#2 edit
... //depot/bugzilla/main/buglist.cgi#7 edit


------- Additional Comment #15 From Jonathan Schatz 2003-05-28 18:32 PST -------

fixed, checked in, and live.


------- Additional Comment #16 From Matt Ginzton 2003-05-28 18:51 PST -------

Awesome.  This is so much cooler now.


From cbendell at point2.com  Fri May 30 16:51:13 2003
From: cbendell at point2.com (Colin Bendell)
Date: Fri, 30 May 2003 10:51:13 -0600
Subject: data directory
Message-ID: <85339FA608200E43BA1A364F09C337D60130C7A2@bruno.point2.com>

In fact, all the 'data' elements (including most of the configuration) should be database driven, thus creating a clearer separation of content and presentation.

/colin

-----Original Message-----
From: Jim Walters [mailto:jimw at bugopolis.com] 
Sent: Friday, May 30, 2003 10:44 AM
To: developers at bugzilla.org
Subject: data directory

For our customers we configure the servers to backup the database. There is a variety of schemes depending on what their requirements are. One thing I've wondered about are the pros and cons of placing the information currently living in the data directory into the mysql database. Are there reasons this won't work (in theory)?

Regards,

Jim Walters
__________________________
Jim Walters?? Director of Technology
Bugopolis, Inc.

phone: +1 206 447 8315 
email: jimw at bugopolis.com
web: http://www.bugopolis.com
_________________________ 




From jon at vmware.com  Fri May 30 17:48:58 2003
From: jon at vmware.com (Jonathan Schatz)
Date: 30 May 2003 10:48:58 -0700
Subject: a slightly silly bug
In-Reply-To: <1054313520.20684.3.camel@jonschatz-lx.vmware.com>
References: <1054313520.20684.3.camel@jonschatz-lx.vmware.com>
Message-ID: <1054316937.20716.6.camel@jonschatz-lx.vmware.com>

heh, found the b.m.o bug:

http://bugzilla.mozilla.org/show_bug.cgi?id=192247

it's pretty interesting (to me anyway) that the sequence of events in
the comments were almost identical. 

-jon
-- 
Jonathan Schatz
Engineering System Administrator
VMware, Inc
"Te occidere possunt sed te edere non possunt nefas est."





From timeless at myrealbox.com  Fri May 30 18:03:07 2003
From: timeless at myrealbox.com (timeless)
Date: Fri, 30 May 2003 14:03:07 -0400
Subject: a slightly silly bug
In-Reply-To: <1054313520.20684.3.camel@jonschatz-lx.vmware.com>
References: <1054313520.20684.3.camel@jonschatz-lx.vmware.com>
Message-ID: <3ED79CDB.2010906@myrealbox.com>

Jonathan Schatz wrote:
> ok, the short version is that there's a bug in the rand() function of
> certain versions of mysql. i'm going to search b.m.o to see if this has
> been filed before.

http://bugzilla.mozilla.org/show_bug.cgi?id=192247

> the longer (more fun) version of this story is attached.

and was appreciated



From preed at sigkill.com  Fri May 30 19:45:05 2003
From: preed at sigkill.com (J. Paul Reed)
Date: Fri, 30 May 2003 12:45:05 -0700
Subject: data directory
In-Reply-To: <85339FA608200E43BA1A364F09C337D60130C7A2@bruno.point2.com>; from cbendell@point2.com on Fri, May 30, 2003 at 10:51:13AM -0600
References: <85339FA608200E43BA1A364F09C337D60130C7A2@bruno.point2.com>
Message-ID: <20030530124505.A20540@sigkill.com>

On 30 May 2003 at 10:51:13, Colin Bendell moved bits on my disk to say:

> In fact, all the 'data' elements (including most of the configuration)
> should be database driven, thus creating a clearer separation of content
> and presentation.

Most of the stuff in the data directory isn't "presented" to the user, so I
don't see that argument.

That, and using a scheme like 'versioncache' and 'params' allows us to
exploit features unique to perl to speed stuff up. There *may* be a bug on
moving all that into the database, but... I couldn't find it... which
wouldn't surprise me at all.

Later,
Paul
------------------------------------------------------------------------
J. Paul Reed -- 0xDF8708F8 || preed at sigkill.com || web.sigkill.com/preed
To hold on to sanity too tight is insane.   -- Nick Falzone, Pushing Tin

I use PGP; you should use PGP too... if only to piss off John Ashcroft