From mkanat at bugzilla.org  Wed Aug  1 11:22:48 2007
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Wed, 1 Aug 2007 04:22:48 -0700
Subject: Perl 5.9.5 available on landfill
Message-ID: <20070801112607.8FB1A888007@help.trusthosting.net>

	The most recent development release of Perl is 5.9.5, and it
was released just a few days ago. It is supposed to be the last
development release before 5.10.

	So, I've installed a copy on landfill. It's /usr/bin/perl5.9.5
and I've installed all of the required Perl modules for Bugzilla (and
most of the optional ones too).

	For anybody interested in having their own Perl 5.9.5 installed
in /opt/ on their RHEL4 server, I've made the RPM packages available
here:

	http://landfill.bugzilla.org/perl/

	It's the "perl595" packages. They install in /opt/, and
shouldn't interfere with your local Perl at all. (But if you use CPAN,
remember to set the .cpan directory to something other than /root/.cpan
when you configure it.)

	-Max
-- 
http://www.everythingsolved.com/
Competent, Friendly Bugzilla Services. And Everything Else, too.


From mkanat at bugzilla.org  Mon Aug  6 14:04:57 2007
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Mon, 6 Aug 2007 07:04:57 -0700
Subject: Changing the Versioning Scheme
Message-ID: <20070806140823.0112985000A@help.trusthosting.net>

	I've seen far too many confused people who say in their blogs
and news articles, "Wow, it took 9 years to go from 2.0 to 3.0, Bugzilla
development must be slow."

	To remedy this, I think we should just start doing releases as
4.0, 5.0, 6.0, etc.

	I'm not sure what to call the bug-fix releases then,
though--3.0.1 or 3.1. Perhaps we could stick with 3.0.1 for the 3.0
series, and do 4.1, 4.2 for the 4.0 series.

	-Max
-- 
http://www.everythingsolved.com/
Competent, Friendly Bugzilla Services. And Everything Else, too.


From lpsolit at gmail.com  Mon Aug  6 14:10:22 2007
From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=)
Date: Mon, 06 Aug 2007 16:10:22 +0200
Subject: Changing the Versioning Scheme
In-Reply-To: <20070806140823.0112985000A@help.trusthosting.net>
References: <20070806140823.0112985000A@help.trusthosting.net>
Message-ID: <46B72BCE.4090602@gmail.com>

Max Kanat-Alexander a ?crit :
> 	To remedy this, I think we should just start doing releases as
> 4.0, 5.0, 6.0, etc.


Keep this discussion for the Bugzilla meeting we have tomorrow. Add it
to the agenda so that we don't forget to talk about it.

LpSolit


PS: I already have my opinion on this question. :)


From mkanat at bugzilla.org  Tue Aug  7 00:26:48 2007
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Mon, 6 Aug 2007 17:26:48 -0700
Subject: Changing the Versioning Scheme
In-Reply-To: <46B72BCE.4090602@gmail.com>
References: <20070806140823.0112985000A@help.trusthosting.net>
	<46B72BCE.4090602@gmail.com>
Message-ID: <20070807003014.C538F85000A@help.trusthosting.net>

On Mon, 06 Aug 2007 16:10:22 +0200 Fr?d?ric Buclin <lpsolit at gmail.com>
wrote:
> Keep this discussion for the Bugzilla meeting we have tomorrow. Add it
> to the agenda so that we don't forget to talk about it.

	Okay, all done.

	-Max
-- 
http://www.everythingsolved.com/
Competent, Friendly Bugzilla Services. And Everything Else, too.


From lpsolit at gmail.com  Tue Aug  7 01:25:22 2007
From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=)
Date: Tue, 07 Aug 2007 03:25:22 +0200
Subject: Bugzilla meeting tomorrow, Tuesday, August 7 at 18:00 GMT (11:00
 PST, 20:00 CEST)
Message-ID: <46B7CA02.1090101@gmail.com>

We have another Bugzilla meeting this Tuesday at 18:00 GMT (11:00 PST,
20:00 CEST) on IRC in the #bugzilla-meeting channel. This one should be
pretty short, I suppose.

So if you have time, feel free to join us.

LpSolit


From mkanat at bugzilla.org  Thu Aug  9 21:05:47 2007
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Thu, 9 Aug 2007 14:05:47 -0700
Subject: Customizability vs. Shipping a Good Product
Message-ID: <20070809210917.CC1C785000B@help.trusthosting.net>

	There is a classic article about Free Software UI by Havoc
Pennington of GNOME:

	http://ometer.com/free-software-ui.html

	In particular, I found the section "The Question of
Preferences" very enlightening, and I think all Bugzilla developers
should read at least that section of the article.

	Lately, we've had a lot of focus on making Bugzilla very
customizable. That's OK, but we also need to focus on making Bugzilla a
good product "out of the box". That is, we *can not* just avoid that
subject by saying, "Well, users can customize their own installation."
We should be *shipping* the best possible bug tracker that we can.

	-Max
-- 
http://www.everythingsolved.com/
Competent, Friendly Bugzilla Services. And Everything Else, too.


From lpsolit at gmail.com  Sun Aug 12 23:32:30 2007
From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=)
Date: Mon, 13 Aug 2007 01:32:30 +0200
Subject: QA tests for 3.0.1, 2.22.3 and 2.20.5 are over!
Message-ID: <46BF988E.5090202@gmail.com>

A quick note to let you know that QA tests for all branches are over.
Releases will be available as soon as the remaining 3 blockers for 3.1.1
have been fixed and the tarballs have been built. Keep in mind that
3.1.1 hasn't been tested by the QA team and shouldn't be used on
production; it's a development snapshot only and which is currently
unstable due to heavy changes we did these last few months.

I would like to thank the QA team for their work and a new QA tester
(achild) who jumped in the game to help us. I hope to see you all for
3.0.2 in a few months. :)

LpSolit


From vladd at bugzilla.org  Mon Aug 13 22:11:46 2007
From: vladd at bugzilla.org (Vlad Dascalu)
Date: Tue, 14 Aug 2007 01:11:46 +0300
Subject: All QA tests done. a=qa_team for 3.0 RC1
In-Reply-To: <45DC4A23.6000702@gmail.com>
References: <45DC4A23.6000702@gmail.com>
Message-ID: <a16d8c9b0708131511i1808416fj891597c86ac05b29@mail.gmail.com>

There are currently 7 non-security bugs pending approval? for Bugzilla 3.0.

Some of them are trivial changes and some fix important bugs; it will
certainly be worthy in my opinion to take some of them in the 3.0.1
train, especially since most of them can be tested easily for QA
individually due to their scoped changes.

Releasing 3.0.1 with some of those problems when we have patches for
them would be suboptimal. Now that QA is done, someone needs to review
them and decide which are 3.0.1 worthy based on how easy is to do QA
for them individually, the probability to regress something and their
overall worthiness.

https://bugzilla.mozilla.org/show_bug.cgi?id=391945
Staggered headers don't check dotweak properly

https://bugzilla.mozilla.org/show_bug.cgi?id=390370
Products should be Other Classifications

https://bugzilla.mozilla.org/show_bug.cgi?id=365060
Edit products is missing a :

https://bugzilla.mozilla.org/show_bug.cgi?id=387607
detect and accommodate restored "edit attachment as comment" mode

https://bugzilla.mozilla.org/show_bug.cgi?id=365088
(Voters) is a strange way to let me see other people who voted for a bug

https://bugzilla.mozilla.org/show_bug.cgi?id=356807
CSV export expose text/plain as MIME content type

https://bugzilla.mozilla.org/show_bug.cgi?id=221827
Missing Bug ID shouldn't be handled as Invalid Bug ID


On 2/21/07, Fr?d?ric Buclin <lpsolit at gmail.com> wrote:
> Except some minor bugs with dependency trees (bugs 309108 and 370883)
> and the UI issue some users are experiencing when viewing bugs (bug
> 370739), Bugzilla 3.0 RC1 is ready for release. a=qa_team. :)
>
> The bugs mentioned above won't block RC1 and it will be available for
> download as soon as the release stuff is complete, which could happen
> this week.
>
> LpSolit
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=vladd at bugzilla.org>
>


From lpsolit at gmail.com  Mon Aug 13 23:53:40 2007
From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=)
Date: Tue, 14 Aug 2007 01:53:40 +0200
Subject: All QA tests done. a=qa_team for 3.0 RC1
In-Reply-To: <a16d8c9b0708131511i1808416fj891597c86ac05b29@mail.gmail.com>
References: <45DC4A23.6000702@gmail.com> <a16d8c9b0708131511i1808416fj891597c86ac05b29@mail.gmail.com>
Message-ID: <46C0EF04.90706@gmail.com>

Vlad Dascalu a ?crit :
> There are currently 7 non-security bugs pending approval? for Bugzilla 3.0.
> 
> Some of them are trivial changes and some fix important bugs


None of them is important, QA is done, we are now focused on the release
process itself, so they will all wait for 3.0.2.

PS: don't you have a more recent email to reply to? :)

LpSolit


From gerv at mozilla.org  Tue Aug 14 10:55:57 2007
From: gerv at mozilla.org (Gervase Markham)
Date: Tue, 14 Aug 2007 11:55:57 +0100
Subject: Changing the Versioning Scheme
In-Reply-To: <20070806140823.0112985000A@help.trusthosting.net>
References: <20070806140823.0112985000A@help.trusthosting.net>
Message-ID: <46C18A3D.50608@mozilla.org>

Max Kanat-Alexander wrote:
> 	To remedy this, I think we should just start doing releases as
> 4.0, 5.0, 6.0, etc.

I missed the meeting; but I think that the problem was our psychological 
hangup about the number 3 (caused by Hixie's earlier efforts). From now 
on, we can adopt a more normal scheme. But I think that revving the 
major version number with _every_ release would swing things too far the 
other way.

Gerv



From gerv at mozilla.org  Tue Aug 14 13:54:35 2007
From: gerv at mozilla.org (Gervase Markham)
Date: Tue, 14 Aug 2007 14:54:35 +0100
Subject: Customizability vs. Shipping a Good Product
In-Reply-To: <20070809210917.CC1C785000B@help.trusthosting.net>
References: <20070809210917.CC1C785000B@help.trusthosting.net>
Message-ID: <46C1B41B.5010700@mozilla.org>

Max Kanat-Alexander wrote:
> 	In particular, I found the section "The Question of
> Preferences" very enlightening, and I think all Bugzilla developers
> should read at least that section of the article.

Some of the arguments in that section were the reason I opposed adding a 
user preferences panel to Bugzilla. And now, on b.m.o., we have 11 
preferences, including preferences for several things ("Field separator 
character for .csv files" - guys, CSV stands for "Comma-Separated 
Values"!) which Havoc would raise his eyebrows at.

> 	Lately, we've had a lot of focus on making Bugzilla very
> customizable. That's OK, but we also need to focus on making Bugzilla a
> good product "out of the box". That is, we *can not* just avoid that
> subject by saying, "Well, users can customize their own installation."
> We should be *shipping* the best possible bug tracker that we can.

I see you are more looking at our bloated Parameters section here rather 
than User Preferences. And I agree, it has many of the same problems. E.g.:

docs_urlbase: would it really have hurt us to always make the docs 
available at <url_base>/docs?

sslbase: who puts the HTTP version of their Bugzilla on one domain and 
the SSL version on another?

cookiepath: Could we really have not DTRT and worked this out from 
<urlbase>?

timezone: Is there really no programmatic way of asking a database 
server what timezone it's in?

proxy_url: If the webserver's OS can't access the web, there's probably 
a reason for it.

And that's just the first page, which is "Required Settings" (most of 
which seem that they are nothing of the sort)!

(Note: my point here is not to debate the reasoning for the above, which 
is off the top of my head and may be wrong in the odd case. Look at the 
big picture.)

Gerv



From mkanat at bugzilla.org  Tue Aug 14 14:13:36 2007
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Tue, 14 Aug 2007 07:13:36 -0700
Subject: Changing the Versioning Scheme
In-Reply-To: <46C18A3D.50608@mozilla.org>
References: <20070806140823.0112985000A@help.trusthosting.net>
	<46C18A3D.50608@mozilla.org>
Message-ID: <20070814141338.6695018016@help.trusthosting.net>

On Tue, 14 Aug 2007 11:55:57 +0100 Gervase Markham <gerv at mozilla.org>
wrote:
> Max Kanat-Alexander wrote:
> > 	To remedy this, I think we should just start doing releases
> > as 4.0, 5.0, 6.0, etc.
> 
> I missed the meeting; but I think that the problem was our
> psychological hangup about the number 3 (caused by Hixie's earlier
> efforts). From now on, we can adopt a more normal scheme. But I think
> that revving the major version number with _every_ release would
> swing things too far the other way.

	Yeah, that's basically what we agreed at the meeting.

	3.4 will probably be 4.0.

	-Max
-- 
http://www.everythingsolved.com/
Competent, Friendly Bugzilla Services. And Everything Else, too.


From mkanat at bugzilla.org  Tue Aug 14 14:15:55 2007
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Tue, 14 Aug 2007 07:15:55 -0700
Subject: Customizability vs. Shipping a Good Product
In-Reply-To: <46C1B41B.5010700@mozilla.org>
References: <20070809210917.CC1C785000B@help.trusthosting.net>
	<46C1B41B.5010700@mozilla.org>
Message-ID: <20070814141557.74BEB18016@help.trusthosting.net>

On Tue, 14 Aug 2007 14:54:35 +0100 Gervase Markham <gerv at mozilla.org>
wrote:
> I see you are more looking at our bloated Parameters section here
> rather than User Preferences. And I agree, it has many of the same
> problems. E.g.:
> [snip]

	I think all those problems you pointed out are quite valid, and
we should handle all of those, at least. We should generally audit the
Parameters page for params that we really don't need.

	The only one I've found useful is docs_urlbase (mostly for
landfill), but that's it.

	-Max
-- 
http://www.everythingsolved.com/
Competent, Friendly Bugzilla Services. And Everything Else, too.


From jake at bugzilla.org  Tue Aug 14 14:35:13 2007
From: jake at bugzilla.org (Jake)
Date: Tue, 14 Aug 2007 10:35:13 -0400
Subject: Changing the Versioning Scheme
In-Reply-To: <46C18A3D.50608@mozilla.org>
References: <20070806140823.0112985000A@help.trusthosting.net>
	 <46C18A3D.50608@mozilla.org>
Message-ID: <eb66d7610708140735j2ecf6cc6ra1278995d237fa83@mail.gmail.com>

On 8/14/07, Gervase Markham <gerv at mozilla.org> wrote:
>
> Max Kanat-Alexander wrote:
> >       To remedy this, I think we should just start doing releases as
> > 4.0, 5.0, 6.0, etc.
>
> I missed the meeting; but I think that the problem was our psychological
> hangup about the number 3 (caused by Hixie's earlier efforts). From now
> on, we can adopt a more normal scheme. But I think that revving the
> major version number with _every_ release would swing things too far the
> other way.
>

I didn't make it to the meeting either and I'm way out of the loop, but I
kinda like the idea that the major version number is indicative of a certain
set of criteria being met rather than an arbitrary "I think we should be at
3.0 now" type of decision. The Linux kernel is only at 2.6.22, after all,
and people seem to be able to live with that.

-- 
http://jacob.steenhagen.us
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20070814/6a979d75/attachment.html>

From lpsolit at gmail.com  Tue Aug 14 19:06:38 2007
From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=)
Date: Tue, 14 Aug 2007 21:06:38 +0200
Subject: Minutes of our last Bugzilla meeting
Message-ID: <46C1FD3E.8080304@gmail.com>

Here you have:

http://wiki.mozilla.org/Bugzilla:Meetings:2007-08-07

Our next meeting will take place on September 4, at 11:00 PDT (18:00 GMT).

LpSolit


From gerv at mozilla.org  Wed Aug 15 08:39:54 2007
From: gerv at mozilla.org (Gervase Markham)
Date: Wed, 15 Aug 2007 09:39:54 +0100
Subject: Customizability vs. Shipping a Good Product
In-Reply-To: <20070814141557.74BEB18016@help.trusthosting.net>
References: <20070809210917.CC1C785000B@help.trusthosting.net>	<46C1B41B.5010700@mozilla.org> <20070814141557.74BEB18016@help.trusthosting.net>
Message-ID: <46C2BBDA.9000202@mozilla.org>

Max Kanat-Alexander wrote:
> 	The only one I've found useful is docs_urlbase (mostly for
> landfill), but that's it.

JOOI, is there any reason landfill wouldn't work with a scheme where 
docs_urlbase was <urlbase>/docs ?

Gerv



From lpsolit at gmail.com  Wed Aug 15 09:26:11 2007
From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=)
Date: Wed, 15 Aug 2007 11:26:11 +0200
Subject: Customizability vs. Shipping a Good Product
In-Reply-To: <46C2BBDA.9000202@mozilla.org>
References: <20070809210917.CC1C785000B@help.trusthosting.net>	<46C1B41B.5010700@mozilla.org> <20070814141557.74BEB18016@help.trusthosting.net> <46C2BBDA.9000202@mozilla.org>
Message-ID: <46C2C6B3.7040505@gmail.com>

Gervase Markham a ?crit :
> JOOI, is there any reason landfill wouldn't work with a scheme where
> docs_urlbase was <urlbase>/docs ?


Some installations compile their own documentation, some others (which
e.g. don't have openjade or all DSSSL librairies installed) point to
bugzilla.org or to some other external reference. Having it hardcoded is
a mistake. This param is useful as it's used in error messages to give
some help to users.

LpSolit


From gerv at mozilla.org  Wed Aug 15 09:37:33 2007
From: gerv at mozilla.org (Gervase Markham)
Date: Wed, 15 Aug 2007 10:37:33 +0100
Subject: Customizability vs. Shipping a Good Product
In-Reply-To: <46C2C6B3.7040505@gmail.com>
References: <20070809210917.CC1C785000B@help.trusthosting.net>	<46C1B41B.5010700@mozilla.org> <20070814141557.74BEB18016@help.trusthosting.net> <46C2BBDA.9000202@mozilla.org> <46C2C6B3.7040505@gmail.com>
Message-ID: <46C2C95D.1060906@mozilla.org>

Fr?d?ric Buclin wrote:
> Some installations compile their own documentation, some others (which
> e.g. don't have openjade or all DSSSL librairies installed) point to
> bugzilla.org or to some other external reference. Having it hardcoded is
> a mistake. This param is useful as it's used in error messages to give
> some help to users.

OK, let me turn the question round. Why do we make _anyone_ compile 
their own documentation? (I seem to remember it being a right pain; 
perhaps it's got easier since.) Why don't we ship the HTML version in 
the tarball? 99% of installs aren't going to modify it; those who do can 
read our docs on how to do so correctly, then recompile it into the same 
location.

Gerv


From myk at mozilla.org  Wed Aug 15 14:04:09 2007
From: myk at mozilla.org (Myk Melez)
Date: Wed, 15 Aug 2007 07:04:09 -0700
Subject: Customizability vs. Shipping a Good Product
In-Reply-To: <46C1B41B.5010700@mozilla.org>
References: <20070809210917.CC1C785000B@help.trusthosting.net> <46C1B41B.5010700@mozilla.org>
Message-ID: <46C307D9.4020809@mozilla.org>

Gervase Markham wrote:
> I see you are more looking at our bloated Parameters section here 
> rather than User Preferences. And I agree, it has many of the same 
> problems. E.g.:
>
> docs_urlbase: would it really have hurt us to always make the docs 
> available at <url_base>/docs?
I somewhat agree, except that I take a Firefox view of things, where we 
expose a small set of preferences to regular users but make a much 
broader set of preferences available to power users (and never use 
preferences as an excuse not to make hard decisions about the default 
out-of-the-box experience).

I think that's the right model for Bugzilla too, and that most if not 
all of the questionable preferences have their place in the application, 
but we should distinguish between those we place front-and-center on 
Preference and Parameter pages and those we hide in alternate UIs 
(which, for administrators, could be simply direct access to the 
localconfig file and the MySQL prefs table).

-myk



From justdave at bugzilla.org  Wed Aug 15 18:24:13 2007
From: justdave at bugzilla.org (David Miller)
Date: Wed, 15 Aug 2007 11:24:13 -0700
Subject: Customizability vs. Shipping a Good Product
In-Reply-To: <46C2C95D.1060906@mozilla.org>
References: <20070809210917.CC1C785000B@help.trusthosting.net>	<46C1B41B.5010700@mozilla.org> <20070814141557.74BEB18016@help.trusthosting.net> <46C2BBDA.9000202@mozilla.org> <46C2C6B3.7040505@gmail.com> <46C2C95D.1060906@mozilla.org>
Message-ID: <46C344CD.1060801@bugzilla.org>

Gervase Markham wrote on 8/15/07 2:37 AM:
> Fr?d?ric Buclin wrote:
>> Some installations compile their own documentation, some others (which
>> e.g. don't have openjade or all DSSSL librairies installed) point to
>> bugzilla.org or to some other external reference. Having it hardcoded is
>> a mistake. This param is useful as it's used in error messages to give
>> some help to users.
> 
> OK, let me turn the question round. Why do we make _anyone_ compile
> their own documentation? (I seem to remember it being a right pain;
> perhaps it's got easier since.) Why don't we ship the HTML version in
> the tarball? 99% of installs aren't going to modify it; those who do can
> read our docs on how to do so correctly, then recompile it into the same
> location.

The only people that have to compile their own docs are the people who
either 1) check Bugzilla out from CVS, or 2) modify their documentation.

We *do* ship compiled versions in all of the tarballs.

-- 
Dave Miller                                   http://www.justdave.net/
System Administrator, Mozilla Corporation      http://www.mozilla.com/
Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/


From samf at CollectiveStudios.Com  Wed Aug 15 23:45:31 2007
From: samf at CollectiveStudios.Com (Sam Fu)
Date: Wed, 15 Aug 2007 16:45:31 -0700
Subject: Bugzilla handling heavy load
Message-ID: <586133FEA1374B4CBD88BE56C0D0DE30010D89B7@npbmail01.f9.internal>

Hey All, I was wondering if anyone had any information about this.  I've
managed to Web 2.0/Ajax Bugzilla 3.0 for my company's use.  From a UI
and user experience perspective it has been well received.  The only
adverse effect that I've noticed from doing this is the heavy load in
terms of CPU usage on the server.  This is due in part to asynchronous
connections that each individual calls to the server.  While looking at
the server I've noticed that Perl handles each individual request by
creating a new process.  So if an individual makes 5 requests to the
server (to update 5 different parts of the UI), the server handles it by
opening 5 individual Perl.exe processes rather than, for example keeping
a process open and running thread support.  

 

I believe that this problem is causing my other problem.  Occasionally,
I receive a response from the server that is 'undefined'.  I haven't
been able to track this down, but I believe it has to either be Bugzilla
or Perl that's responding in the chain with this value.

 

We're running a quad-core for our Bugzilla server, so our load is fine,
but another studio is using a regular workstation and they are suffering
performance issues.  I was wondering if anyone could make any
suggestions as to how I can identify and handle these issues.  Thanks
much...

 

Sam Fu

Web Programmer

SamF at collectivestudios.com

1900 Quail Street

Newport Beach CA 92660

TEL: 949-255-1900 x865

FAX: 949-724-9667

 A Foundation 9 Entertainment company

 

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

From justdave at bugzilla.org  Thu Aug 16 01:14:50 2007
From: justdave at bugzilla.org (David Miller)
Date: Wed, 15 Aug 2007 18:14:50 -0700
Subject: Bugzilla handling heavy load
In-Reply-To: <586133FEA1374B4CBD88BE56C0D0DE30010D89B7@npbmail01.f9.internal>
References: <586133FEA1374B4CBD88BE56C0D0DE30010D89B7@npbmail01.f9.internal>
Message-ID: <46C3A50A.5090806@bugzilla.org>

Sam Fu wrote on 8/15/07 4:45 PM:
> Hey All, I was wondering if anyone had any information about this.  I?ve
> managed to Web 2.0/Ajax Bugzilla 3.0 for my company?s use.  From a UI
> and user experience perspective it has been well received.  The only
> adverse effect that I?ve noticed from doing this is the heavy load in
> terms of CPU usage on the server.  This is due in part to asynchronous
> connections that each individual calls to the server.  While looking at
> the server I?ve noticed that Perl handles each individual request by
> creating a new process.  So if an individual makes 5 requests to the
> server (to update 5 different parts of the UI), the server handles it by
> opening 5 individual Perl.exe processes rather than, for example keeping
> a process open and running thread support. 

This is probably better to go on the support list than here (see
http://www.bugzilla.org/support/ ) so I'm CCing there on my reply (and
please follow-up there if you reply).

This sounds like exactly the problem mod_perl was designed to tackle.
It embeds the perl interpreter into the webserver and keeps Bugzilla in
memory so that requests can be served rapidly without the overhead of
spawning a new Perl process on every request.  Bugzilla 3.0 supports
mod_perl, so as long as you followed good coding practices while making
your modifications, you should be okay.  (See
http://www.bugzilla.org/docs/developer.html#perl and
https://bugzilla.mozilla.org/show_bug.cgi?id=173629 )

Instructions for setting up Bugzilla with mod_perl are at
http://www.bugzilla.org/docs/3.0/html/configuration.html#http-apache-mod_perl

-- 
Dave Miller                                   http://www.justdave.net/
System Administrator, Mozilla Corporation      http://www.mozilla.com/
Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/


From ghendricks at novell.com  Thu Aug 16 15:44:05 2007
From: ghendricks at novell.com (Gregary Hendricks)
Date: Thu, 16 Aug 2007 09:44:05 -0600
Subject: Bugzilla handling heavy load
Message-ID: <46C41C65020000D20000FB60@sinclair.provo.novell.com>

On Wed, 2007-08-15 at 16:45 -0700, Sam Fu wrote:
> Hey All, I was wondering if anyone had any information about this.
> I?ve managed to Web 2.0/Ajax Bugzilla 3.0 for my company?s use.  From
> a UI and user experience perspective it has been well received.  The
> only adverse effect that I?ve noticed from doing this is the heavy
> load in terms of CPU usage on the server.  This is due in part to
> asynchronous connections that each individual calls to the server.
> While looking at the server I?ve noticed that Perl handles each
> individual request by creating a new process.  So if an individual
> makes 5 requests to the server (to update 5 different parts of the
> UI), the server handles it by opening 5 individual Perl.exe processes
> rather than, for example keeping a process open and running thread
> support.  
> 
Are you running mod_perl? That might alleviate a good share of the
performance issues.
I am curious, what kinds of AJAXifications have you made? Are you
willing to submit a patch of them?
>  
> 
Greg



From tm at sci.fi  Fri Aug 17 06:25:34 2007
From: tm at sci.fi (tm at sci.fi)
Date: Fri, 17 Aug 2007 09:25:34 +0300
Subject: Customizability vs. Shipping a Good Product
In-Reply-To: <46C307D9.4020809@mozilla.org>
References: <20070809210917.CC1C785000B@help.trusthosting.net> <46C1B41B.5010700@mozilla.org> <46C307D9.4020809@mozilla.org>
Message-ID: <46C53F5E.3020309@sci.fi>

On 15.08.2007 17:04, Myk Melez wrote:
> (which, for administrators, could be simply direct access to the 
> localconfig file and the MySQL prefs table).

I really don't like the idea of requiring direct DB changes for any 
supported preferences. Even Firefox has a rudimentary UI for "hidden" 
preferences instead of requiring hacking JS files directly.

I also don't think we should have different system for such preferences 
because our current one can be extended easily. If we really want to 
"hide" some parameters we could simply not make links available to some 
of them in the normal Preferences page.

This doesn't mean I don't agree to make sure every preference is really 
required and that there's no way to automatically determine correct 
values to use.
-- 
"Anything is possible. It's all about probabilities."



From justdave at bugzilla.org  Fri Aug 17 06:54:18 2007
From: justdave at bugzilla.org (David Miller)
Date: Thu, 16 Aug 2007 23:54:18 -0700
Subject: Customizability vs. Shipping a Good Product
In-Reply-To: <46C53F5E.3020309@sci.fi>
References: <20070809210917.CC1C785000B@help.trusthosting.net> <46C1B41B.5010700@mozilla.org> <46C307D9.4020809@mozilla.org> <46C53F5E.3020309@sci.fi>
Message-ID: <46C5461A.7050407@bugzilla.org>

tm at sci.fi wrote on 8/16/07 11:25 PM:
> I also don't think we should have different system for such preferences
> because our current one can be extended easily. If we really want to
> "hide" some parameters we could simply not make links available to some
> of them in the normal Preferences page.

We could list them on the index page but not have a tab for some of them
on the left or something.  Then clicking that pref name in the index
would go to the magical hidden page...  Or just have a suffix to add to
the URL and document it...

-- 
Dave Miller                                   http://www.justdave.net/
System Administrator, Mozilla Corporation      http://www.mozilla.com/
Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/


From lpsolit at gmail.com  Fri Aug 17 09:19:12 2007
From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=)
Date: Fri, 17 Aug 2007 11:19:12 +0200
Subject: Customizability vs. Shipping a Good Product
In-Reply-To: <46C5461A.7050407@bugzilla.org>
References: <20070809210917.CC1C785000B@help.trusthosting.net> <46C1B41B.5010700@mozilla.org> <46C307D9.4020809@mozilla.org> <46C53F5E.3020309@sci.fi> <46C5461A.7050407@bugzilla.org>
Message-ID: <46C56810.6050608@gmail.com>

> We could list them on the index page but not have a tab for some of them
> on the left or something.  Then clicking that pref name in the index
> would go to the magical hidden page


Either a parameter is removed completely, or we keep it visible. I don't
want to explain someone that the pref he is looking for is hidden. It's
already hard enough for some of these admins to find them.

LpSolit


From mkanat at bugzilla.org  Sat Aug 18 00:13:49 2007
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Fri, 17 Aug 2007 17:13:49 -0700
Subject: Customizability vs. Shipping a Good Product
In-Reply-To: <46C56810.6050608@gmail.com>
References: <20070809210917.CC1C785000B@help.trusthosting.net>
	<46C1B41B.5010700@mozilla.org>
	<46C307D9.4020809@mozilla.org>
	<46C53F5E.3020309@sci.fi>
	<46C5461A.7050407@bugzilla.org>
	<46C56810.6050608@gmail.com>
Message-ID: <20070818001352.5B4BC85000A@help.trusthosting.net>

On Fri, 17 Aug 2007 11:19:12 +0200 Fr?d?ric Buclin <lpsolit at gmail.com>
wrote:
> Either a parameter is removed completely, or we keep it visible. I
> don't want to explain someone that the pref he is looking for is
> hidden. It's already hard enough for some of these admins to find
> them.

	Yes. It's easy enough to hack data/params if you have to.

	But even the existence of these parameters requires maintenance
work, even if they're hidden. So I'm all for *removing* as many
preferences as possible, when possible.

	-Max


From samf at CollectiveStudios.Com  Sat Aug 18 21:12:19 2007
From: samf at CollectiveStudios.Com (Sam Fu)
Date: Sat, 18 Aug 2007 14:12:19 -0700
Subject: Bugzilla handling heavy load
In-Reply-To: <46C41C65020000D20000FB60@sinclair.provo.novell.com>
References: <46C41C65020000D20000FB60@sinclair.provo.novell.com>
Message-ID: <586133FEA1374B4CBD88BE56C0D0DE300114000A@npbmail01.f9.internal>

I basically reworked the whole UI.  It runs more like the Yahoo 2.0
Mailer.  
	- Layout of North, South, East, West, and Center where the North
has	the title and the quicksearch input.  South has the footer. West
has a 	customize icon paired	menu, and East has all the customized
and 	saved searches.
	- The saved-search panel is auto-refreshed telling the user how
many 	bugs are in that search ( i.e. My Custom Search (15) ).
	- Tabbing, where individual bugs are in each tab.
	- A persistent search tab, that returns results in a grid where,
the 	columns are sortable.  This grid, is completely done in
Javascript, so 	it looks more like excel with CSS.  It's resizeable and
draggable 	where you can reorder the columns
	- Modal popups for errors
	- Separate dialog boxes for searching for bugs.
	- The system uses JSON so I had to reformat some of things (i.e.
created my own custom list.json.tmpl for search results and modified
buglist.cgi)
	- Created hierarchy for bugs b/c I'm currently designing a agile
scheduler into it.
	- Etc...

I'd include a picture, but I don't think that'd post correctly.  

By the way, I'm wanting to port this over for mod_perl b/c of
performance.  The only thing I've noticed with mod_perl is that the
Response Header is formatted differently.  My UI is dependent that when
a non-200 OK header response is sent, it'll throw up a error modal box
informing the user of the problem.  I modified the Error.pm to throw
this error, but with mod_perl I never get an error in the response
header.  I was wondering if someone could help me out and tell me how to
do this.  (I'm new to mod_perl development).  

I noticed that the mod_perl.pl was always sending OK which according to
the mod_perl docs is supposed to happen.  I thought that the PerlOptions
+ParseHeaders would actually take the printed headers (maybe my error.pm
modification), but that doesn't seem to be happening.  Any help would be
appreciated, thanks.

	--Sam

-----Original Message-----
From: developers-owner at bugzilla.org
[mailto:developers-owner at bugzilla.org] On Behalf Of Gregary Hendricks
Sent: Thursday, August 16, 2007 8:44 AM
To: developers at bugzilla.org
Subject: Re: Bugzilla handling heavy load

On Wed, 2007-08-15 at 16:45 -0700, Sam Fu wrote:
> Hey All, I was wondering if anyone had any information about this.
> I've managed to Web 2.0/Ajax Bugzilla 3.0 for my company's use.  From
> a UI and user experience perspective it has been well received.  The
> only adverse effect that I've noticed from doing this is the heavy
> load in terms of CPU usage on the server.  This is due in part to
> asynchronous connections that each individual calls to the server.
> While looking at the server I've noticed that Perl handles each
> individual request by creating a new process.  So if an individual
> makes 5 requests to the server (to update 5 different parts of the
> UI), the server handles it by opening 5 individual Perl.exe processes
> rather than, for example keeping a process open and running thread
> support.  
> 
Are you running mod_perl? That might alleviate a good share of the
performance issues.
I am curious, what kinds of AJAXifications have you made? Are you
willing to submit a patch of them?
>  
> 
Greg

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


From timello at gmail.com  Wed Aug 22 17:45:29 2007
From: timello at gmail.com (Tiago)
Date: Wed, 22 Aug 2007 14:45:29 -0300
Subject: LDAP lookup methods
Message-ID: <975214730708221045qe9c8edbv12498a4a18d7125a@mail.gmail.com>

Hi guys,

I would like to implement LDAP lookups methods. Today when searching
for an user it only returns users that are already registered. For
Bugzilla admin does not matter either if they has already logged in or
not when editing an account once every user in the LDAP can be a
possible Bugzilla user.

What I would suggest is to allow non-registered LDAP users start being
shown in the search and highlight the result saying if it is
registered or not.

mkanat, what do you think about it?

Thank you!

timello


From eseyman at linagora.com  Fri Aug 24 10:01:14 2007
From: eseyman at linagora.com (Emmanuel Seyman)
Date: Fri, 24 Aug 2007 12:01:14 +0200 (CEST)
Subject: LDAP lookup methods
In-Reply-To: <975214730708221045qe9c8edbv12498a4a18d7125a@mail.gmail.com>
References: <975214730708221045qe9c8edbv12498a4a18d7125a@mail.gmail.com>
Message-ID: <1321.10.0.0.1.1187949674.squirrel@intranet.linagora.com>

* Tiago :
>
> What I would suggest is to allow non-registered LDAP users start being
> shown in the search and highlight the result saying if it is
> registered or not.

There's a script called syncLDAP.pl in the contrib directory that
creates every person from your LDAP tree in the Bugzilla database.

I don't think we highlight results in user search so you'll have
to file a request in bugzilla.mozilla.org for that to happen.

Emmanuel

PS: This kind of question probably belongs on
support-bugzilla at lists.mozilla.org, not developers at bugzilla.org .



From gerv at mozilla.org  Wed Aug 29 16:09:12 2007
From: gerv at mozilla.org (Gervase Markham)
Date: Wed, 29 Aug 2007 17:09:12 +0100
Subject: Prefs Removal Proposal
Message-ID: <46D59A28.1040207@mozilla.org>

Here is a proposal for removing some prefs. Perhaps other people have 
other ideas.

*Prefs to remove*

docs_urlbase: hardcode to "<urlbase>/docs" and make sure the built docs 
are shipped in that location.

sslbase: hardcode to <urlbase> with s/http/https/.

proxy_url: Instead, use OS's mechanism for getting web content.

supportwatchers: hardcode to "on"

musthavemilestoneonaccept: just get rid of it; it's trivial to work around

commentonreassignbycomponent: don't see the point of this

usebugaliases: hardcode to "on"

Bug Moving: rip it all out; I bet it no longer works

mybugstemplate: the My Bugs link should be a saved search added to the 
new account, and treated like one, rather than a special undeletable 
link. This means it's not necessary for admins to be able to edit it.

*Other changes*

We need to move some prefs out of "Required Settings" which are 
blatantly not required (and that's most of them).

We should also reorder some prefs pages (e.g. Auth) to have the prefs in 
a more logical order.

Also, make some prefs only appear when necessary. E.g. the RADIUS 
category should only appear when RADIUS is being used. Same for LDAP. 
This would reduce complexity.

Gerv


From gerv at mozilla.org  Wed Aug 29 16:11:10 2007
From: gerv at mozilla.org (Gervase Markham)
Date: Wed, 29 Aug 2007 17:11:10 +0100
Subject: Customizability vs. Shipping a Good Product
In-Reply-To: <46C56810.6050608@gmail.com>
References: <20070809210917.CC1C785000B@help.trusthosting.net> <46C1B41B.5010700@mozilla.org> <46C307D9.4020809@mozilla.org> <46C53F5E.3020309@sci.fi> <46C5461A.7050407@bugzilla.org> <46C56810.6050608@gmail.com>
Message-ID: <46D59A9E.3070102@mozilla.org>

Fr?d?ric Buclin wrote:
>> We could list them on the index page but not have a tab for some of them
>> on the left or something.  Then clicking that pref name in the index
>> would go to the magical hidden page
> 
> Either a parameter is removed completely, or we keep it visible. I don't
> want to explain someone that the pref he is looking for is hidden. It's
> already hard enough for some of these admins to find them.

But that's backwards logic. Let's reverse it:

It's hard for admins to find prefs.

-> We should have fewer, better organised prefs

But we don't want to remove any (or many) prefs

-> We put the less-used ones somewhere out of the way.

Anyway, let's start by trying to remove some, and then we can see how 
many are left, and whether we need further simplification.

Gerv


From jochen.wiedmann at gmail.com  Wed Aug 29 16:31:04 2007
From: jochen.wiedmann at gmail.com (Jochen Wiedmann)
Date: Wed, 29 Aug 2007 18:31:04 +0200
Subject: Prefs Removal Proposal
In-Reply-To: <46D59A28.1040207@mozilla.org>
References: <46D59A28.1040207@mozilla.org>
Message-ID: <e75283b10708290931t5d929735m8bd195608d13d815@mail.gmail.com>

On 8/29/07, Gervase Markham <gerv at mozilla.org> wrote:

> sslbase: hardcode to <urlbase> with s/http/https/.

Difficult. We've got to keep in mind, that it is very easy to have
virtual hosts for http, but not for https. I can very well imagine
that someone has different URL's.


> proxy_url: Instead, use OS's mechanism for getting web content.

What OS mechanism in the case of Linux/Unix? I have the *_proxy
environment variables set for my *personal* environment, but I prefer
if the httpd doesn't have them.

Jochen


-- 
"Besides, manipulating elections is under penalty of law, resulting in
a preventative effect against manipulating elections.

The german government justifying the use of electronic voting machines
and obviously  believing that we don't need a police, because all
illegal actions are forbidden.

http://dip.bundestag.de/btd/16/051/1605194.pdf


From gerv at mozilla.org  Wed Aug 29 16:38:37 2007
From: gerv at mozilla.org (Gervase Markham)
Date: Wed, 29 Aug 2007 17:38:37 +0100
Subject: Prefs Removal Proposal
In-Reply-To: <e75283b10708290931t5d929735m8bd195608d13d815@mail.gmail.com>
References: <46D59A28.1040207@mozilla.org> <e75283b10708290931t5d929735m8bd195608d13d815@mail.gmail.com>
Message-ID: <46D5A10D.1030407@mozilla.org>

Jochen Wiedmann wrote:
>> sslbase: hardcode to <urlbase> with s/http/https/.
> 
> Difficult. We've got to keep in mind, that it is very easy to have
> virtual hosts for http, but not for https. I can very well imagine
> that someone has different URL's.

Let's assume that their HTTPS URL is:

https://bugzilla.foo.com/

What possible technical reason could there be for their HTTP URL _not_ 
to be:

http://bugzilla.foo.com/

?

>> proxy_url: Instead, use OS's mechanism for getting web content.
> 
> What OS mechanism in the case of Linux/Unix? I have the *_proxy
> environment variables set for my *personal* environment, but I prefer
> if the httpd doesn't have them.

But the httpd can read Bugzilla's config file, so if you want Bugzilla 
to be able to get update info, then the httpd does "have them" (in one 
way or another).

"Either set up your OS to be able to access the web, or expect Bugzilla 
not to be able to when running on it" seems like a reasonable position 
to me.

Gerv


From jochen.wiedmann at gmail.com  Wed Aug 29 16:48:01 2007
From: jochen.wiedmann at gmail.com (Jochen Wiedmann)
Date: Wed, 29 Aug 2007 18:48:01 +0200
Subject: Prefs Removal Proposal
In-Reply-To: <46D5A10D.1030407@mozilla.org>
References: <46D59A28.1040207@mozilla.org>
	 <e75283b10708290931t5d929735m8bd195608d13d815@mail.gmail.com>
	 <46D5A10D.1030407@mozilla.org>
Message-ID: <e75283b10708290948i603d790dy138843dc9bf2de5d@mail.gmail.com>

On 8/29/07, Gervase Markham <gerv at mozilla.org> wrote:

> Let's assume that their HTTPS URL is:
>
> https://bugzilla.foo.com/
>
> What possible technical reason could there be for their HTTP URL _not_
> to be:
>
> http://bugzilla.foo.com/
>
> ?

I can't think of any, so you might be right.



> "Either set up your OS to be able to access the web, or expect Bugzilla
> not to be able to when running on it" seems like a reasonable position
> to me.

Ok, you've got a point. :-) At least as long as the proxy access is
used for nothing else.


Jochen


-- 
"Besides, manipulating elections is under penalty of law, resulting in
a preventative effect against manipulating elections.

The german government justifying the use of electronic voting machines
and obviously  believing that we don't need a police, because all
illegal actions are forbidden.

http://dip.bundestag.de/btd/16/051/1605194.pdf


From lpsolit at gmail.com  Wed Aug 29 17:18:58 2007
From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=)
Date: Wed, 29 Aug 2007 19:18:58 +0200
Subject: Prefs Removal Proposal
In-Reply-To: <46D59A28.1040207@mozilla.org>
References: <46D59A28.1040207@mozilla.org>
Message-ID: <46D5AA82.1040000@gmail.com>

> proxy_url: Instead, use OS's mechanism for getting web content.

Many users reported problems about their proxy not being used correctly.
That's the reason we introduced it and I *really* see no reason to
remove this parameter.


> commentonreassignbycomponent: don't see the point of this

No reason to remove this one but leaving the other ones alone.


> Bug Moving: rip it all out; I bet it no longer works

It always worked correctly and still works fine.


> mybugstemplate: the My Bugs link should be a saved search added to the
> new account, and treated like one, rather than a special undeletable
> link. This means it's not necessary for admins to be able to edit it.

And how do you set the default one for new accounts without the ability
to define it in a parameter?


I remind you that this topic will be discussed at our next Bugzilla
meeting next Tuesday (Sept. 4th).

LpSolit


From dwilliss at microimages.com  Wed Aug 29 17:54:03 2007
From: dwilliss at microimages.com (Dave Williss)
Date: Wed, 29 Aug 2007 12:54:03 -0500
Subject: Prefs Removal Proposal
In-Reply-To: <46D59A28.1040207@mozilla.org>
References: <46D59A28.1040207@mozilla.org>
Message-ID: <46D5B2BB.4010506@microimages.com>



Gervase Markham wrote:
> Here is a proposal for removing some prefs. Perhaps other people have 
> other ideas.
>
> *Prefs to remove*
>
> musthavemilestoneonaccept: just get rid of it; it's trivial to work 
> around
Trivial to work around how? 

We don't want to force milestone on accept.  We *would* like to force 
milestone when setting certain resolved states (FIXED and WORKSFORME but 
not INVALID, NEEDINFO or WONTFIX).  Instead of using Target Milestone 
for "when we want it done by" (as implied by the name *Target* 
Milestone), we use it for "earliest version it was fixed in".

> commentonreassignbycomponent: don't see the point of this 
My removing it, would it then force you to comment on reassign by 
component or not?  I would hope not.  We do set the pref to force a 
comment on normal reassign so the new assignee knows why they're getting 
it, but changing the component tells them the component was changed 
which should be enough explanation.


From gerv at mozilla.org  Wed Aug 29 18:10:54 2007
From: gerv at mozilla.org (Gervase Markham)
Date: Wed, 29 Aug 2007 19:10:54 +0100
Subject: Prefs Removal Proposal
In-Reply-To: <46D5AA82.1040000@gmail.com>
References: <46D59A28.1040207@mozilla.org> <46D5AA82.1040000@gmail.com>
Message-ID: <46D5B6AE.1020209@mozilla.org>

Fr?d?ric Buclin wrote:
>> proxy_url: Instead, use OS's mechanism for getting web content.
> 
> Many users reported problems about their proxy not being used correctly.
> That's the reason we introduced it and I *really* see no reason to
> remove this parameter.

So instead of telling users to correctly configure their machines, we 
provide an additional configuration mechanism?

>> commentonreassignbycomponent: don't see the point of this
> 
> No reason to remove this one but leaving the other ones alone.

It seems more irrelevant than the others. I can see vague use cases for 
them (although yes, of course, they are just as easy to work around).

>> Bug Moving: rip it all out; I bet it no longer works
> 
> It always worked correctly and still works fine.

Really? Including classifications, for example?

Who uses this stuff these days?

>> mybugstemplate: the My Bugs link should be a saved search added to the
>> new account, and treated like one, rather than a special undeletable
>> link. This means it's not necessary for admins to be able to edit it.
> 
> And how do you set the default one for new accounts without the ability
> to define it in a parameter?

We hard-code a default, which is the default we've been using for N 
years now. As it's editable, people can always edit it if they don't 
like it.

> I remind you that this topic will be discussed at our next Bugzilla
> meeting next Tuesday (Sept. 4th).

I must have missed that. Thanks :-)

Gerv



From gerv at mozilla.org  Wed Aug 29 18:11:39 2007
From: gerv at mozilla.org (Gervase Markham)
Date: Wed, 29 Aug 2007 19:11:39 +0100
Subject: Prefs Removal Proposal
In-Reply-To: <46D5B2BB.4010506@microimages.com>
References: <46D59A28.1040207@mozilla.org> <46D5B2BB.4010506@microimages.com>
Message-ID: <46D5B6DB.1050709@mozilla.org>

Dave Williss wrote:
> Gervase Markham wrote:
>> Here is a proposal for removing some prefs. Perhaps other people have 
>> other ideas.
>>
>> *Prefs to remove*
>>
>> musthavemilestoneonaccept: just get rid of it; it's trivial to work 
>> around
> Trivial to work around how?

The usual method on b.m.o. is to put a single dot in the comment box.

>> commentonreassignbycomponent: don't see the point of this 
> My removing it, would it then force you to comment on reassign by 
> component or not?  I would hope not.

Not.

Gerv


From lpsolit at gmail.com  Wed Aug 29 18:23:50 2007
From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=)
Date: Wed, 29 Aug 2007 20:23:50 +0200
Subject: Prefs Removal Proposal
In-Reply-To: <46D5B6AE.1020209@mozilla.org>
References: <46D59A28.1040207@mozilla.org> <46D5AA82.1040000@gmail.com> <46D5B6AE.1020209@mozilla.org>
Message-ID: <46D5B9B6.2040103@gmail.com>


> So instead of telling users to correctly configure their machines, we
> provide an additional configuration mechanism?

We provide something which works for all users who had problems with
their proxy. That's enough for me to keep it.


> It seems more irrelevant than the others. I can see vague use cases for
> them (although yes, of course, they are just as easy to work around).

Your workaround (adding a dot in a comment) is irritating. Better to
turn off the parameters in this case.


> Really? Including classifications, for example?

Irrelevant as the product automatically defines the classification the
bug belongs to.


> Who uses this stuff these days?

Probably not you. Not a reason to remove it, though. And e.g. Novell
uses it a lot, from what I heard.


> We hard-code a default, which is the default we've been using for N
> years now. As it's editable, people can always edit it if they don't
> like it.

And you still need a mechanism for this "special" saved search. Not very
helpful.


LpSolit



From fergus at yahoo-inc.com  Wed Aug 29 18:31:33 2007
From: fergus at yahoo-inc.com (Fergus Sullivan)
Date: Wed, 29 Aug 2007 11:31:33 -0700
Subject: Self-Introduction: Fergus Sullivan
Message-ID: <6EC47187-7F9E-4C19-9701-8FB03254AEAE@yahoo-inc.com>

== Full name ==
Fergus Sullivan

== Your IRC nick on irc.mozilla.org ==
ferg2k

== City, Country ==
Sunnyvale, California, United States.

== Profession or Student status ==
Engineering Manager

== Company, School, or other affiliation ==
Yahoo

== What do you want to help out with? ==
Scaling for enterprise level use.
UI overhaul

== Historical qualifications ==
Master's degree in medieval archaeology.  Although I suspect that's  
not what the question is alluding to.  That said, it does help when  
digging through layers of modifications and additions.

I've been managing our Bugzilla instance for the last 4 years, and  
spent much of the last year coding, albeit mostly UI. Other members  
of my team are the hard-core sql guys, and ttk jocks.

== Anything else you'd like to say ==
Yahoo has been happily using Bugzilla for the last six years.  We now  
have a mandate from our top-level management to contribute to the  
open source effort.

We are currently using a customized version of 2.22.  We serve  
Bugzilla on FreeBSD 6, mysql 4.1, perl 5.6.  We use a mixture of  
MyISAM and InnoDB.  We have a dual-master database (we have our own  
proxy that can switch as needed) and a VIP handling 3 front-end and  
servers and search slaves.  We have a second colo for BCP with an  
equivalent architecture.  We have additional machines as reporting  
slaves.

Our database currently stands at about 1.5 million bugs and grows at  
about 50k per month.  We have 20,000 named accounts (one per  
employee, plus many internal mailing lists), of whom about 8,300 are  
active in any one month.  In terms of active users and new bugs  
opened, our load has increased 50% in the last year.  We have 2,400  
separate products in our DB.

Nobody outside of Yahoo has access to our database.  All our  
customers are internal.

We test against IE 6, IE 7, Firefox 2, Safari 2 and 3.  We currently  
also support Opera.  We support Mac 10.4, Windows 2000, XP, and  
Vista, FreeBSD 4 and 6, RHEL 4 and 5.

In addition to myself, we have two developers and one QA assigned  
full time on Bugzilla.  We have another two guys working full time on  
it at the moment, although they may move to other tasks in a few  
months time.

I have an open req for a visual designer to polish up the UI in  
Bugzilla, and then in our other internal tools.

The core functionality has mostly met our needs, but we have had to  
customize in the following areas.

Speed
  - The core SQL within Bugzilla did not scale to meet our needs.  We  
reached a tipping point at around 800,000 bugs.  The main cause was  
lock contention within the DB.  The causes and solutions would fill  
an academic paper.  We rewrote search.pm and greatly increased  
performance.  Some of the changes were trivial.  A two line change  
improved our "search for bugs where person X is cced" from 45 seconds  
to 0.4 seconds.  Other changes were vast.  The overall effect was  
search times have dropped from up to 45 seconds in typical usage to  
about six seconds.

Product Management
  - With 2,400 different products, the vanilla product chooser does  
not scale for us.  We have built an entirely different version.

UI
  - We have made many minor and a few major changes to the UI.  One  
interesting one is the use of a JavaScript datatable for client-side  
sorting of buglist results.  This greatly reduces server load.
  - We have unified comments and the bug activity table.  Both appear  
inline in the show bug page.
  - We are making increasing use of the YUI library.  These allow our  
fancier functions to work on all platforms.

Company-integration
  - We have many contact points with other developer tools within  
Yahoo.  Our Bugzilla interfaces with our CVS repository, with  
Perforce and with Subversion.
  - We integrate with our employee directory to show pictures of  
employees in bugs, and to provide other information.
  - We integrate with our build and release system, and with our  
change management process.


As you can tell, we take Bugzilla seriously here.  I'm looking  
forward to contributing to the bugzilla.org effort!

  /ferg

-- 
fergus sullivan | developer tools team | fergus at yahoo-inc.com | o.  
408.349.6807 | m. 408.203.FERG


From gerv at mozilla.org  Wed Aug 29 18:31:50 2007
From: gerv at mozilla.org (Gervase Markham)
Date: Wed, 29 Aug 2007 19:31:50 +0100
Subject: Prefs Removal Proposal
In-Reply-To: <46D5B9B6.2040103@gmail.com>
References: <46D59A28.1040207@mozilla.org> <46D5AA82.1040000@gmail.com> <46D5B6AE.1020209@mozilla.org> <46D5B9B6.2040103@gmail.com>
Message-ID: <46D5BB96.7020006@mozilla.org>

Fr?d?ric Buclin wrote:
>> It seems more irrelevant than the others. I can see vague use cases for
>> them (although yes, of course, they are just as easy to work around).
> 
> Your workaround (adding a dot in a comment) is irritating. Better to
> turn off the parameters in this case.

You've missed my point. In installations where they _want_ this feature, 
people who can't be bothered to provide the information can work around 
the setting by putting a dot in the comment box. So why bother having 
the setting anyway?

>> We hard-code a default, which is the default we've been using for N
>> years now. As it's editable, people can always edit it if they don't
>> like it.
> 
> And you still need a mechanism for this "special" saved search. Not very
> helpful.

I don't understand your point here. My entire idea is that this saved 
search is not "special" in any way. It's just another saved search. It 
just happens to have been created automatically when you create the 
account (i.e. one line of SQL in the account creation script) rather 
than created by you. After that, it's managed the same way as any others 
the user might create.

Gerv


From lpsolit at gmail.com  Wed Aug 29 18:46:53 2007
From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=)
Date: Wed, 29 Aug 2007 20:46:53 +0200
Subject: Self-Introduction: Fergus Sullivan
In-Reply-To: <6EC47187-7F9E-4C19-9701-8FB03254AEAE@yahoo-inc.com>
References: <6EC47187-7F9E-4C19-9701-8FB03254AEAE@yahoo-inc.com>
Message-ID: <46D5BF1D.5040503@gmail.com>

> Yahoo has been happily using Bugzilla for the last six years.  We now
> have a mandate from our top-level management to contribute to the open
> source effort.

Great news!


> 0.4 seconds.  Other changes were vast.  The overall effect was search
> times have dropped from up to 45 seconds in typical usage to about six
> seconds.

Impressive! When will this be implemented in the Bugzilla source code? ;)


> As you can tell, we take Bugzilla seriously here.  I'm looking forward
> to contributing to the bugzilla.org effort!
> 
>  /ferg

Let me address you a big "Welcome!" and I hope you will enjoy working
with us. :)


LpSolit


From justdave at bugzilla.org  Wed Aug 29 18:47:04 2007
From: justdave at bugzilla.org (David Miller)
Date: Wed, 29 Aug 2007 14:47:04 -0400
Subject: Prefs Removal Proposal
In-Reply-To: <46D5BB96.7020006@mozilla.org>
References: <46D59A28.1040207@mozilla.org> <46D5AA82.1040000@gmail.com> <46D5B6AE.1020209@mozilla.org> <46D5B9B6.2040103@gmail.com> <46D5BB96.7020006@mozilla.org>
Message-ID: <46D5BF28.9090709@bugzilla.org>

Gervase Markham wrote on 8/29/07 2:31 PM:
> Fr?d?ric Buclin wrote:
>>> It seems more irrelevant than the others. I can see vague use cases for
>>> them (although yes, of course, they are just as easy to work around).
>>
>> Your workaround (adding a dot in a comment) is irritating. Better to
>> turn off the parameters in this case.
> 
> You've missed my point. In installations where they _want_ this feature,
> people who can't be bothered to provide the information can work around
> the setting by putting a dot in the comment box. So why bother having
> the setting anyway?

Someone who puts a . in the comment is obviously trying to get around
it, and can be socially engineered if people care about it.  For
installations that want it, the message you get with it completely blank
is a reminder for people who are forgetful, not an attempt at outright
enforcement.

>>> We hard-code a default, which is the default we've been using for N
>>> years now. As it's editable, people can always edit it if they don't
>>> like it.
>>
>> And you still need a mechanism for this "special" saved search. Not very
>> helpful.
> 
> I don't understand your point here. My entire idea is that this saved
> search is not "special" in any way. It's just another saved search. It
> just happens to have been created automatically when you create the
> account (i.e. one line of SQL in the account creation script) rather
> than created by you. After that, it's managed the same way as any others
> the user might create.

You need a way for an admin to edit the query that gets created by
default on new accounts.  Once the account is created, it's all on the
user, but new account defaults should all be settable by the admin of
course.

-- 
Dave Miller                                   http://www.justdave.net/
System Administrator, Mozilla Corporation      http://www.mozilla.com/
Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/


From mkanat at bugzilla.org  Wed Aug 29 19:17:48 2007
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Wed, 29 Aug 2007 12:17:48 -0700
Subject: Prefs Removal Proposal
In-Reply-To: <46D59A28.1040207@mozilla.org>
References: <46D59A28.1040207@mozilla.org>
Message-ID: <20070829191750.290E03FF55B@help.trusthosting.net>

On Wed, 29 Aug 2007 17:09:12 +0100 Gervase Markham <gerv at mozilla.org>
wrote:
> docs_urlbase: hardcode to "<urlbase>/docs" and make sure the built
> docs are shipped in that location.
> 
> sslbase: hardcode to <urlbase> with s/http/https/.
> 
> proxy_url: Instead, use OS's mechanism for getting web content.
> 
> supportwatchers: hardcode to "on"
> 
> musthavemilestoneonaccept: just get rid of it; it's trivial to work
> around
> 
> commentonreassignbycomponent: don't see the point of this
> 
> usebugaliases: hardcode to "on"

	Agreed, with all of these. (I have yet to read the thread below
this, I will soon.)

> Bug Moving: rip it all out; I bet it no longer works

	It does work, but I don't think it's used. I think importxml.pl
is used for other reasons.

> mybugstemplate: the My Bugs link should be a saved search added to
> the new account, and treated like one, rather than a special
> undeletable link. This means it's not necessary for admins to be able
> to edit it.

	That also makes sense.

	Also, "usermatchmode" should be set to "search" by default, and
we then only need to keep "confirmuniqueusermatch".

> Also, make some prefs only appear when necessary. E.g. the RADIUS 
> category should only appear when RADIUS is being used. Same for LDAP. 
> This would reduce complexity.

	The RADIUS and LDAP settings have to be set before they're
turned on, so that wouldn't work, currently.

	-Max
-- 
http://www.everythingsolved.com/
Competent, Friendly Bugzilla Services. And Everything Else, too.


From gerv at mozilla.org  Wed Aug 29 19:19:00 2007
From: gerv at mozilla.org (Gervase Markham)
Date: Wed, 29 Aug 2007 20:19:00 +0100
Subject: Self-Introduction: Fergus Sullivan
In-Reply-To: <6EC47187-7F9E-4C19-9701-8FB03254AEAE@yahoo-inc.com>
References: <6EC47187-7F9E-4C19-9701-8FB03254AEAE@yahoo-inc.com>
Message-ID: <46D5C6A4.5040904@mozilla.org>

So much to ask about!

Fergus Sullivan wrote:
> == Anything else you'd like to say ==
> Yahoo has been happily using Bugzilla for the last six years.  We now 
> have a mandate from our top-level management to contribute to the open 
> source effort.

Wahey!

> We are currently using a customized version of 2.22.  

Do you have an upgrade plan?

> We serve Bugzilla 
> on FreeBSD 6, mysql 4.1, perl 5.6.  We use a mixture of MyISAM and 
> InnoDB.  

As in, different tables use different engines? Which uses which?

> We have a dual-master database (we have our own proxy that can 
> switch as needed) 

So MySQL supports this?

> and a VIP handling 3 front-end and servers and search 
> slaves.  We have a second colo for BCP with an equivalent architecture.  
> We have additional machines as reporting slaves.

As in, they have read-only mirrors of the DB and are used for running 
reports?

> Our database currently stands at about 1.5 million bugs and grows at 
> about 50k per month.  

That's the biggest known Bugzilla database, by about 3x. GNOME is at 
about 470,000.

> We have 20,000 named accounts (one per employee, 
> plus many internal mailing lists), of whom about 8,300 are active in any 
> one month. 

LDAP? RADIUS? Or a mirror of your internal employee database into the 
Bugzilla DB?

> In terms of active users and new bugs opened, our load has 
> increased 50% in the last year.  We have 2,400 separate products in our DB.

Red Hat has 7814 components in a single product, but I don't know of 
anyone who has that many products.

> In addition to myself, we have two developers and one QA assigned full 
> time on Bugzilla.  We have another two guys working full time on it at 
> the moment, although they may move to other tasks in a few months time.

Presumably you have a testing installation?

> Speed
>  - The core SQL within Bugzilla did not scale to meet our needs.  We 
> reached a tipping point at around 800,000 bugs.  The main cause was lock 
> contention within the DB.  The causes and solutions would fill an 
> academic paper.  We rewrote search.pm and greatly increased 
> performance.  Some of the changes were trivial.  A two line change 
> improved our "search for bugs where person X is cced" from 45 seconds to 
> 0.4 seconds.  Other changes were vast.  The overall effect was search 
> times have dropped from up to 45 seconds in typical usage to about six 
> seconds.

I'm certainly looking forward to seeing these! Do you have any idea of 
how well the changes fit with our changes between 2.22 and now?

Was it only search that was a problem?

> Product Management
>  - With 2,400 different products, the vanilla product chooser does not 
> scale for us.  We have built an entirely different version.

Have you been eyeing Classifications with interest, or do they not help? 
How do you do the UI for this?

> UI
>  - We have made many minor and a few major changes to the UI.  One 
> interesting one is the use of a JavaScript datatable for client-side 
> sorting of buglist results.  This greatly reduces server load.

I use a Greasemonkey script for this. I agree, it needs to be a core 
feature.

>  - We have unified comments and the bug activity table.  Both appear 
> inline in the show bug page.

Do you find this useful in practice?

Gerv


From mkanat at bugzilla.org  Wed Aug 29 19:21:32 2007
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Wed, 29 Aug 2007 12:21:32 -0700
Subject: Prefs Removal Proposal
In-Reply-To: <46D5BF28.9090709@bugzilla.org>
References: <46D59A28.1040207@mozilla.org>
	<46D5AA82.1040000@gmail.com>
	<46D5B6AE.1020209@mozilla.org>
	<46D5B9B6.2040103@gmail.com>
	<46D5BB96.7020006@mozilla.org>
	<46D5BF28.9090709@bugzilla.org>
Message-ID: <20070829192133.0765F3FF55B@help.trusthosting.net>

On Wed, 29 Aug 2007 14:47:04 -0400 David Miller <justdave at bugzilla.org>
wrote:
> You need a way for an admin to edit the query that gets created by
> default on new accounts.  Once the account is created, it's all on the
> user, but new account defaults should all be settable by the admin of
> course.

	That would be fairly easy to do with the User Preferences and
the Default Preferences.

	-Max
-- 
http://www.everythingsolved.com/
Competent, Friendly Bugzilla Services. And Everything Else, too.


From gerv at mozilla.org  Wed Aug 29 19:21:39 2007
From: gerv at mozilla.org (Gervase Markham)
Date: Wed, 29 Aug 2007 20:21:39 +0100
Subject: Prefs Removal Proposal
In-Reply-To: <20070829191750.290E03FF55B@help.trusthosting.net>
References: <46D59A28.1040207@mozilla.org> <20070829191750.290E03FF55B@help.trusthosting.net>
Message-ID: <46D5C743.2070006@mozilla.org>

Max Kanat-Alexander wrote:
> 	The RADIUS and LDAP settings have to be set before they're
> turned on, so that wouldn't work, currently.

To be clear: what I mean was that, when RADIUS or LDAP are raised above 
the "active" bar in user_verify_class, then the relevant links should 
appear in the sidebar. (And a little message should appear telling you 
to configure them.)

Gerv


From lpsolit at gmail.com  Wed Aug 29 19:27:47 2007
From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=)
Date: Wed, 29 Aug 2007 21:27:47 +0200
Subject: Self-Introduction: Fergus Sullivan
In-Reply-To: <46D5C6A4.5040904@mozilla.org>
References: <6EC47187-7F9E-4C19-9701-8FB03254AEAE@yahoo-inc.com> <46D5C6A4.5040904@mozilla.org>
Message-ID: <46D5C8B3.9050302@gmail.com>

Gervase Markham a ?crit :
>> In terms of active users and new bugs opened, our load has increased
>> 50% in the last year.  We have 2,400 separate products in our DB.
> 
> Red Hat has 7814 components in a single product, but I don't know of
> anyone who has that many products.


Mandriva had 32,000 products not so long ago.


From gerv at mozilla.org  Wed Aug 29 19:28:34 2007
From: gerv at mozilla.org (Gervase Markham)
Date: Wed, 29 Aug 2007 20:28:34 +0100
Subject: Self-Introduction: Fergus Sullivan
In-Reply-To: <46D5C8B3.9050302@gmail.com>
References: <6EC47187-7F9E-4C19-9701-8FB03254AEAE@yahoo-inc.com> <46D5C6A4.5040904@mozilla.org> <46D5C8B3.9050302@gmail.com>
Message-ID: <46D5C8E2.7@mozilla.org>

Fr?d?ric Buclin wrote:
> Mandriva had 32,000 products not so long ago.

Yeah, I checked http://bugzilla.mandriva.com/query.cgi - they now only 
have 9. They must have had a pretty drastic reorganisation :-)

Gerv


From mkanat at bugzilla.org  Wed Aug 29 19:48:52 2007
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Wed, 29 Aug 2007 12:48:52 -0700
Subject: Self-Introduction: Fergus Sullivan
In-Reply-To: <6EC47187-7F9E-4C19-9701-8FB03254AEAE@yahoo-inc.com>
References: <6EC47187-7F9E-4C19-9701-8FB03254AEAE@yahoo-inc.com>
Message-ID: <20070829194853.C68AD85000A@help.trusthosting.net>

On Wed, 29 Aug 2007 11:31:33 -0700 Fergus Sullivan
<fergus at yahoo-inc.com> wrote:
> == Anything else you'd like to say ==
> Yahoo has been happily using Bugzilla for the last six years.  We
> now have a mandate from our top-level management to contribute to
> the open source effort.

	Yay! :-) Welcome!

> We use a mixture of MyISAM and InnoDB.

	Yeah, we do the same thing upstream now (In 3.1).

> We have a dual-master database (we have our own  proxy that can
> switch as needed)

	Wow, dual master for MySQL, eh? I assume by "our own" means
that your wrote it yourself? What are you using to dual-master them?

>  We have a second colo for BCP

	BCP?

> Our database currently stands at about 1.5 million bugs and grows at  
> about 50k per month.

	That makes you, as far as I'm aware, the second largest
Bugzilla installation in the world, and because nobody knows anything
about the largest, you may be the largest.

> I have an open req for a visual designer to polish up the UI in  
> Bugzilla, and then in our other internal tools.

	We'd definitely love that. Have you seen any of our upstream
work on that?

> The main cause was lock contention within the DB.

	Ha! I *knew* that would happen on large installations!! I feel
vindicated. :-) It's just that it's nearly impossible to discover that
in a test environment.

	Anyhow, upstream is going wholly into transactions, which
should resolve it.

> A two line change improved our "search for bugs where person X is
> cced" from 45 seconds to 0.4 seconds.

	I seem to recall making a similar fix upstream, also. :-)

>  Other changes were vast.  The
> overall effect was search times have dropped from up to 45 seconds in
> typical usage to about six seconds.

	You'll see even more improvement with mod_perl, too. :-) That
six seconds is probably a lot of page-load and compile time.

> Product Management
>   - With 2,400 different products, the vanilla product chooser does  
> not scale for us.  We have built an entirely different version.

	Yeah, that's a well-known thing. Our idea was to AJAX it. What
did you guys do?

>   - We have made many minor and a few major changes to the UI.  One  
> interesting one is the use of a JavaScript datatable for client-side  
> sorting of buglist results.  This greatly reduces server load.

	Yeah, a definitely common request:

	https://bugzilla.mozilla.org/show_bug.cgi?id=151686

>   - We have unified comments and the bug activity table.  Both
> appear inline in the show bug page.

	Also a common request:

	https://bugzilla.mozilla.org/show_bug.cgi?id=11368

>   - We are making increasing use of the YUI library.  These allow
> our fancier functions to work on all platforms.

	We might be willing to consider that upstream, but we'd have to
see that it was a technical advantage over other solutions, and that the
licensing allowed it to be shipped with Bugzilla.

	Of course, within Yahoo it's the obvious choice, but for
upstream we have to have technical proof that it's the best choice. :-)

>   - We have many contact points with other developer tools within  
> Yahoo.  Our Bugzilla interfaces with our CVS repository, with  
> Perforce and with Subversion.

	This is probably shameless self-promotion, but you might be
interested in VCI. :-)

	http://search.cpan.org/dist/VCI/

>   - We integrate with our employee directory to show pictures of  
> employees in bugs, and to provide other information.

	That's neat. We just added a feature to show a picture for
groups, but pictures for individuals might be handy as well. Launchpad
does something like that.

> As you can tell, we take Bugzilla seriously here.  I'm looking  
> forward to contributing to the bugzilla.org effort!

	Wow, and we're looking forward to your contributions! :-)

	-Max
-- 
http://www.everythingsolved.com/
Competent, Friendly Bugzilla Services. And Everything Else, too.


From dmarshal at yahoo-inc.com  Wed Aug 29 19:49:08 2007
From: dmarshal at yahoo-inc.com (David Marshall)
Date: Wed, 29 Aug 2007 12:49:08 -0700
Subject: Self-Introduction: Fergus Sullivan
In-Reply-To: <46D5C6A4.5040904@mozilla.org>
References: <6EC47187-7F9E-4C19-9701-8FB03254AEAE@yahoo-inc.com> <46D5C6A4.5040904@mozilla.org>
Message-ID: <0F02C1FF-4D91-473D-BD2A-CFAA01222BF3@yahoo-inc.com>

Note: I work for Fergus and will compose a self-introduction soon...

One of the things I asked about when deciding to come work for Yahoo!  
was whether we would be sharing changes with Mozilla.  The idea got a  
very warm reception.  The only reason we haven't been sharing is  
because our code isn't quite up to snuff and there have been greater  
priorities.  We are finally starting to settle down into a steady  
state of code joy, so there has been more recent discussion of how  
and when to contribute.

On Aug 29, 2007, at 12:19 PM, Gervase Markham wrote:

> So much to ask about!
>
> Fergus Sullivan wrote:
>> == Anything else you'd like to say ==
>> Yahoo has been happily using Bugzilla for the last six years.  We  
>> now have a mandate from our top-level management to contribute to  
>> the open source effort.
>
> Wahey!
>
>> We are currently using a customized version of 2.22.
>
> Do you have an upgrade plan?

Yes, but it's slow going.  (I have been at Yahoo! since January, so  
my information may be slightly incorrect.)  There have been competing  
factions in the past that have pushed for either forking our Bugzilla  
from b.m.o, followed by at least one effort to defork.  We have  
wrestled with this question at length, and what we want to do is to  
make all the changes that made 2.22 -> 3.0 happen, but it's a large  
effort.

>
>> We serve Bugzilla on FreeBSD 6, mysql 4.1, perl 5.6.  We use a  
>> mixture of MyISAM and InnoDB.
>
> As in, different tables use different engines? Which uses which?

Basically, everything that doesn't need a full-text index is in  
InnoDB.  We are exploring how to use InnoDB for all the tables.

>
>> We have a dual-master database (we have our own proxy that can  
>> switch as needed)
>
> So MySQL supports this?

Er, no, it doesn't... :)  read "We have our own proxy" again.

>
>> and a VIP handling 3 front-end and servers and search slaves.  We  
>> have a second colo for BCP with an equivalent architecture.  We  
>> have additional machines as reporting slaves.
>
> As in, they have read-only mirrors of the DB and are used for  
> running reports?
>

Yes, we give RO-access to  people who want to run their own reports.   
It beats having to tell someone why we aren't going to add their  
spiffy feature.

>> Our database currently stands at about 1.5 million bugs and grows  
>> at about 50k per month.
>
> That's the biggest known Bugzilla database, by about 3x. GNOME is  
> at about 470,000.
>
>> We have 20,000 named accounts (one per employee, plus many  
>> internal mailing lists), of whom about 8,300 are active in any one  
>> month.
>
> LDAP? RADIUS? Or a mirror of your internal employee database into  
> the Bugzilla DB?

We have several databases from which we extract information for our  
own database.

>
>> In terms of active users and new bugs opened, our load has  
>> increased 50% in the last year.  We have 2,400 separate products  
>> in our DB.
>
> Red Hat has 7814 components in a single product, but I don't know  
> of anyone who has that many products.
>
>> In addition to myself, we have two developers and one QA assigned  
>> full time on Bugzilla.  We have another two guys working full time  
>> on it at the moment, although they may move to other tasks in a  
>> few months time.
>
> Presumably you have a testing installation?

sort of...

>
>> Speed
>>  - The core SQL within Bugzilla did not scale to meet our needs.   
>> We reached a tipping point at around 800,000 bugs.  The main cause  
>> was lock contention within the DB.  The causes and solutions would  
>> fill an academic paper.  We rewrote search.pm and greatly  
>> increased performance.  Some of the changes were trivial.  A two  
>> line change improved our "search for bugs where person X is cced"  
>> from 45 seconds to 0.4 seconds.  Other changes were vast.  The  
>> overall effect was search times have dropped from up to 45 seconds  
>> in typical usage to about six seconds.
>
> I'm certainly looking forward to seeing these! Do you have any idea  
> of how well the changes fit with our changes between 2.22 and now?
>

I think they will fit in reasonably well, although it remains to be  
seen whether anyone who doesn't have a million rows in bugs would  
notice any particular improvement.

> Was it only search that was a problem?

I have found a couple of places (unknown whether they're Mozilla or  
Yahoo! code) that would gather information about products/components/ 
etc one row at a time with separate queries.  For most installations,  
it's probably not a noticeable performance hit to do this.  For us,  
it was a killer, and I have altered those to hit the database once.

>
>> Product Management
>>  - With 2,400 different products, the vanilla product chooser does  
>> not scale for us.  We have built an entirely different version.
>
> Have you been eyeing Classifications with interest, or do they not  
> help? How do you do the UI for this?

We use classifications, but I don't think it's well integrated in our  
product-choosing workflow.  (Although I'm not a typical Bugzilla  
user, of course.)

>
>> UI
>>  - We have made many minor and a few major changes to the UI.  One  
>> interesting one is the use of a JavaScript datatable for client- 
>> side sorting of buglist results.  This greatly reduces server load.
>
> I use a Greasemonkey script for this. I agree, it needs to be a  
> core feature.
>
>>  - We have unified comments and the bug activity table.  Both  
>> appear inline in the show bug page.
>
> Do you find this useful in practice?

This is still new, so we don't have a lot of feedback about it yet.   
I think it will be very useful, especially as we allow users to  
collapse this detail.

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



From olav at bkor.dhs.org  Wed Aug 29 19:57:32 2007
From: olav at bkor.dhs.org (Olav Vitters)
Date: Wed, 29 Aug 2007 21:57:32 +0200
Subject: Self-Introduction: Fergus Sullivan
In-Reply-To: <6EC47187-7F9E-4C19-9701-8FB03254AEAE@yahoo-inc.com>
References: <6EC47187-7F9E-4C19-9701-8FB03254AEAE@yahoo-inc.com>
Message-ID: <20070829195732.GA12869@bkor.dhs.org>

On Wed, Aug 29, 2007 at 11:31:33AM -0700, Fergus Sullivan wrote:
> == Full name ==
> Fergus Sullivan

Welcome!

> Speed
>  - The core SQL within Bugzilla did not scale to meet our needs.  We 
> reached a tipping point at around 800,000 bugs.  The main cause was lock 
> contention within the DB.  The causes and solutions would fill an academic 
> paper.  We rewrote search.pm and greatly increased performance.  Some of 
> the changes were trivial.  A two line change improved our "search for bugs 
> where person X is cced" from 45 seconds to 0.4 seconds.  Other changes were 
> vast.  The overall effect was search times have dropped from up to 45 
> seconds in typical usage to about six seconds.

I'm very interested in all speed improvements.

> Product Management
>  - With 2,400 different products, the vanilla product chooser does not 
> scale for us.  We have built an entirely different version.
>
> UI
>  - We have made many minor and a few major changes to the UI.  One 
> interesting one is the use of a JavaScript datatable for client-side 
> sorting of buglist results.  This greatly reduces server load.

Please push upstream!

>  - We have unified comments and the bug activity table.  Both appear inline 
> in the show bug page.

Same, very welcome upstream.

>  - We are making increasing use of the YUI library.  These allow our 
> fancier functions to work on all platforms.

No idea what that is.

-- 
Regards,
Olav


From kristis.makris at asu.edu  Wed Aug 29 20:44:30 2007
From: kristis.makris at asu.edu (Kristis Makris)
Date: Wed, 29 Aug 2007 13:44:30 -0700
Subject: Self-Introduction: Fergus Sullivan
In-Reply-To: <20070829194853.C68AD85000A@help.trusthosting.net>
References: <6EC47187-7F9E-4C19-9701-8FB03254AEAE@yahoo-inc.com>
	 <20070829194853.C68AD85000A@help.trusthosting.net>
Message-ID: <1188420270.4107.8.camel@localhost>

On Wed, 2007-08-29 at 12:48 -0700, Max Kanat-Alexander wrote:
> >   - We have many contact points with other developer tools within  
> > Yahoo.  Our Bugzilla interfaces with our CVS repository, with  
> > Perforce and with Subversion.
> 
>         This is probably shameless self-promotion, but you might be
> interested in VCI. :-)
> 
>         http://search.cpan.org/dist/VCI/ 

Why didn't I know about VCI for so long ?? Mmm... yum! Thanks Max.

Could you elaborate on how Bugzilla "interfaces" with the SCM
repositories ? Do your repositories also interface with Bugzilla ? How
do you handle change management in such a big organization ? Could
Scmbug be of help ?

http://freshmeat.net/projects/scmbug/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20070829/2bec589e/attachment.sig>

From mkanat at bugzilla.org  Wed Aug 29 20:57:37 2007
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Wed, 29 Aug 2007 13:57:37 -0700
Subject: Self-Introduction: Fergus Sullivan
In-Reply-To: <1188420270.4107.8.camel@localhost>
References: <6EC47187-7F9E-4C19-9701-8FB03254AEAE@yahoo-inc.com>
	<20070829194853.C68AD85000A@help.trusthosting.net>
	<1188420270.4107.8.camel@localhost>
Message-ID: <20070829205738.D1E6D3FF55B@help.trusthosting.net>

On Wed, 29 Aug 2007 13:44:30 -0700 Kristis Makris
<kristis.makris at asu.edu> wrote:
> Why didn't I know about VCI for so long ?? Mmm... yum! Thanks Max.

	Yeah, you're welcome! :-) I figured you'd be a big consumer of
it. :-)

	You didn't know about it for so long because I just wrote
it. :-)

	-Max
-- 
http://www.everythingsolved.com/
Competent, Friendly Bugzilla Services. And Everything Else, too.


From gargp at acm.org  Wed Aug 29 21:28:42 2007
From: gargp at acm.org (Pankaj K Garg)
Date: Wed, 29 Aug 2007 14:28:42 -0700
Subject: Self-Introduction: Fergus Sullivan
In-Reply-To: <20070829195732.GA12869@bkor.dhs.org>
References: <6EC47187-7F9E-4C19-9701-8FB03254AEAE@yahoo-inc.com> <20070829195732.GA12869@bkor.dhs.org>
Message-ID: <8A6F5851-5088-4509-AC9D-225218221196@acm.org>

I second the idea of looking into YUI (Yahoo User Interface Library)  
as the means of providing a more Web 2.0 and AJAX'y interface to  
Bugzilla. It comes with a BSD license, and so should be compatible (I  
think) with the Mozilla license.

I've found the abstractions for XML/HTTP calls and various UI  
elements (Panels, Dialogs, DataTable, etc.) very well-thought out and  
simple to use.

The same version that is distributed as Open Source is also used in  
all Yahoo properties so it is very stable and robust.

We had updated Bug 325501 (https://bugzilla.mozilla.org/show_bug.cgi? 
id=325501) with this suggestion a few weeks ago.

Pankaj

P.S. I'll be posting a self-introduction soon.

On Aug 29, 2007, at 12:57 PM, Olav Vitters wrote:

>>  - We are making increasing use of the YUI library.  These allow our
>> fancier functions to work on all platforms.
>
> No idea what that is.
>
> -- 
> Regards,
> Olav
> -

  --
  Pankaj K Garg                         garg at zeesource.net
  1684 Nightingale Avenue     408-373-4027
  Suite 201                                  408-733-2737(fax)
  Sunnyvale, CA 94087            http://www.zeesource.net
		Your Open Source Partner




From myk at mozilla.org  Wed Aug 29 21:38:26 2007
From: myk at mozilla.org (Myk Melez)
Date: Wed, 29 Aug 2007 14:38:26 -0700
Subject: Self-Introduction: Fergus Sullivan
In-Reply-To: <8A6F5851-5088-4509-AC9D-225218221196@acm.org>
References: <6EC47187-7F9E-4C19-9701-8FB03254AEAE@yahoo-inc.com> <20070829195732.GA12869@bkor.dhs.org> <8A6F5851-5088-4509-AC9D-225218221196@acm.org>
Message-ID: <46D5E752.3030303@mozilla.org>

Pankaj K Garg wrote:
> I second the idea of looking into YUI (Yahoo User Interface Library) 
> as the means of providing a more Web 2.0 and AJAX'y interface to Bugzilla.
Thirded.  I used YUI for a recent project, and although I had some 
issues with it, I was impressed overall with the architecture and design.

> It comes with a BSD license, and so should be compatible (I think) 
> with the Mozilla license.
Gerv'll know more (and correct my presumption), but my understanding is 
that YUI's BSD license <http://developer.yahoo.com/yui/#license> is 
indeed compatible with (presumably because more liberal than) the MPL 
license that Bugzilla uses.

-myk

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

From justdave at bugzilla.org  Wed Aug 29 21:49:31 2007
From: justdave at bugzilla.org (David Miller)
Date: Wed, 29 Aug 2007 17:49:31 -0400
Subject: Prefs Removal Proposal
In-Reply-To: <20070829192133.0765F3FF55B@help.trusthosting.net>
References: <46D59A28.1040207@mozilla.org>	<46D5AA82.1040000@gmail.com>	<46D5B6AE.1020209@mozilla.org>	<46D5B9B6.2040103@gmail.com>	<46D5BB96.7020006@mozilla.org>	<46D5BF28.9090709@bugzilla.org> <20070829192133.0765F3FF55B@help.trusthosting.net>
Message-ID: <46D5E9EB.3020905@bugzilla.org>

Max Kanat-Alexander wrote on 8/29/07 3:21 PM:
> On Wed, 29 Aug 2007 14:47:04 -0400 David Miller <justdave at bugzilla.org>
> wrote:
>> You need a way for an admin to edit the query that gets created by
>> default on new accounts.  Once the account is created, it's all on the
>> user, but new account defaults should all be settable by the admin of
>> course.
> 
> 	That would be fairly easy to do with the User Preferences and
> the Default Preferences.

Doesn't really make sense to have it there actually.  Once the user has
it, it's in their save searches to edit.  There's no reason to make any
preference related to it visible to users, even if it is locked down
(it'll affect the creation of their account, once it's created, it's no
longer needed by their account).

-- 
Dave Miller                                   http://www.justdave.net/
System Administrator, Mozilla Corporation      http://www.mozilla.com/
Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/


From justdave at bugzilla.org  Wed Aug 29 21:52:59 2007
From: justdave at bugzilla.org (David Miller)
Date: Wed, 29 Aug 2007 17:52:59 -0400
Subject: Prefs Removal Proposal
In-Reply-To: <20070829191750.290E03FF55B@help.trusthosting.net>
References: <46D59A28.1040207@mozilla.org> <20070829191750.290E03FF55B@help.trusthosting.net>
Message-ID: <46D5EABB.6000504@bugzilla.org>

Max Kanat-Alexander wrote on 8/29/07 3:17 PM:
> On Wed, 29 Aug 2007 17:09:12 +0100 Gervase Markham <gerv at mozilla.org>
> wrote:
>> Also, make some prefs only appear when necessary. E.g. the RADIUS 
>> category should only appear when RADIUS is being used. Same for LDAP. 
>> This would reduce complexity.
> 
> 	The RADIUS and LDAP settings have to be set before they're
> turned on, so that wouldn't work, currently.

Yeah, Max is right, here, unfortunately...  Maybe we need three-state
selectors for the auth methods... instead of just on and off, have on,
staging, and off, or somethign.  Off doesn't show the prefs, staging
shows the prefs but doesn't actually use them, and on actually uses them?

-- 
Dave Miller                                   http://www.justdave.net/
System Administrator, Mozilla Corporation      http://www.mozilla.com/
Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/


From fergus at yahoo-inc.com  Wed Aug 29 22:51:00 2007
From: fergus at yahoo-inc.com (Fergus Sullivan)
Date: Wed, 29 Aug 2007 15:51:00 -0700
Subject: Self-Introduction: Fergus Sullivan
In-Reply-To: <6EC47187-7F9E-4C19-9701-8FB03254AEAE@yahoo-inc.com>
References: <6EC47187-7F9E-4C19-9701-8FB03254AEAE@yahoo-inc.com>
Message-ID: <D35D362E-9B67-4579-A312-CA7DE221836F@yahoo-inc.com>

Many thanks to each of you for the very kind welcome.  We're looking  
forward to working with you guys.

There are a couple of open questions that we haven't yet covered, so  
there's more info below.

   /ferg


== How do we have dual-master sql proxies? ==
We have our own secret sauce for this.  It's in use across Yahoo and  
is central to our BCP/HA planning.  It's proprietary, and not  
currently on our list to release to open source.  I have, however,  
prodded its owners about that.  Essentially it allows us to switch  
from Master A to Master B the moment Master A fails a health check.   
We put the two masters in different server farms so as to reduce  
their vulnerability.

== What is BCP/HA? ==
Business Continuity Planning is a means to ensure that if our primary  
colo goes down we can switch to another as needed.  It assumes a  
certain amount of downtime as dns records are switched and boxes are  
spun up.  This could be anywhere from 30 minutes to a couple of hours.

High Availability means that the service should never go down, and  
automatically switch to a backup server farm as needed.

In both cases, the systems exist to allow for natural disasters,  
power outages, war, insurrection, comets or acts of god.  Read your  
insurance policy's exclusion policy for more...

In both cases, data in each location needs to be up to date.

== How many Bugzilla servers does Yahoo have ==
A couple of years ago we had 1.  Then we bumped up to three.   
Currently we're at one db master and three slaves which share the  
http and search load.  These sit behind a load-balancer.

Our next hardware revision will bump us to one master and four slaves  
in each of two server farms.  One farm is on the US west coast, the  
other on the east.  The primary goal of this is HA, not server load.

We are evaluating the need for mirrors local to our users in Asia and  
Europe.

We have one read-only mirror where we let users run their own raw sql  
queries.

And we have "The Bug Hole", which is where your query is sent if it  
requires a full table scan.  This type of query was blocking other  
users and hogging our search resources.

Incoming mail has always been a part of our instance and shares one  
of the other servers.

== What's this YUI thing, and why will Ferg be harping on about it  
for the next six months? ==
YUI is the Yahoo User Interface libraries.  These were released under  
the FreeBSD license a year and a half ago.  They are widely used,  
both at Yahoo and outside.  Airline sites like southwest.com and  
northwest.com make heavy use of them.

The YUI libraries include widgets like datatables, grid management,  
dialog management, CSS levelling, trees, drag and drop etc.  They are  
fully functional cross-platform and cross-browser.

I joke with the YUI guys that their work makes bad engineers look  
good.  My point is that a little time with the libraries can make the  
trickiest tasks easy.  For example, we decided to pipe the content of  
buglist.cgi into a datatable so that we could sort it client-side.   
It took one of our guys two days to get it working.

The YUI team sit across the aisle from us.  When we need a new  
feature, we wander over and ask.  We dreamed up the idea of how cool  
it would be to be able to edit a bug list in place, like an excel  
sheet.  We walked over to the YUI guys and asked them if it could be  
done.  And lo, inline editing in the datatable was born.

Here are some of my favorite examples, and how we could use them in  
Bugzilla.

Datatable - inline editing of the buglist.  Browse around to see  
examples of client-side sorting and pagination goodies.  Don't  
neglect the client-side pagination with browser history.
http://developer.yahoo.com/yui/examples/datatable/dt_cellediting.html

TreeView - Dependencies anyone?
http://developer.yahoo.com/yui/examples/treeview/default_tree.html

Calendar and Autocomplete - We already use these in our Bugzilla code  
Yahoo
http://developer.yahoo.com/yui/examples/calendar/quickstart.html

Grids - For clean layout
http://developer.yahoo.com/yui/examples/calendar/quickstart.html

There are many, many other uses besides.  For us, use of the YUI  
libraries has been the best thing ever.  The only catch bugzilla.org  
needs to consider is that if we all go with YUI we'll never want to  
turn back.

== Test harnesses ==
As dwm mentioned, we have a suite of tests that use an internal Yahoo  
tool.  We try hard to keep our tests up to date with a 100% pass rate.

We have a number of test machines.  These are mainly for load testing  
in the form of log replays.

== The Yahoo Product Chooser ==
With 2,500 products we needed an optimized product chooser.  To be  
honest, I'm not at all happy with its current form, so we may well  
change it in the near future.  We're thinking of something analogous  
to an address book module in a mail client.  Essentially we want to  
make it easier to select one or many products, and steer people away  
from searching 'all'.

== When can Yahoo start offering its patches for review ==
It depends.  We have an internal legal process to approve  
engagement.  That'll take a few weeks to complete.  We should be able  
to offer minor patches soon after.

The larger patches will be tricky, as they work for us right now with  
the rest of our code base.  Remember our code is based on 2.22 and  
chunks of it are modified.  That said, our Search.pm is a thing of  
beauty...




From mkanat at bugzilla.org  Wed Aug 29 23:43:18 2007
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Wed, 29 Aug 2007 16:43:18 -0700
Subject: Prefs Removal Proposal
In-Reply-To: <46D5E9EB.3020905@bugzilla.org>
References: <46D59A28.1040207@mozilla.org>
	<46D5AA82.1040000@gmail.com>
	<46D5B6AE.1020209@mozilla.org>
	<46D5B9B6.2040103@gmail.com>
	<46D5BB96.7020006@mozilla.org>
	<46D5BF28.9090709@bugzilla.org>
	<20070829192133.0765F3FF55B@help.trusthosting.net>
	<46D5E9EB.3020905@bugzilla.org>
Message-ID: <20070829234320.72CB185000B@help.trusthosting.net>

On Wed, 29 Aug 2007 17:49:31 -0400 David Miller <justdave at bugzilla.org>
wrote:
> > 	That would be fairly easy to do with the User Preferences
> > and the Default Preferences.
> 
> Doesn't really make sense to have it there actually.  Once the user
> has it, it's in their save searches to edit.  There's no reason to
> make any preference related to it visible to users, even if it is
> locked down (it'll affect the creation of their account, once it's
> created, it's no longer needed by their account).

	Yeah, good point. We could just make it a Constant. The admin
can still edit that.

	-Max
-- 
http://www.everythingsolved.com/
Competent, Friendly Bugzilla Services. And Everything Else, too.


From justdave at bugzilla.org  Thu Aug 30 00:08:36 2007
From: justdave at bugzilla.org (David Miller)
Date: Wed, 29 Aug 2007 20:08:36 -0400
Subject: Self-Introduction: Fergus Sullivan
In-Reply-To: <0F02C1FF-4D91-473D-BD2A-CFAA01222BF3@yahoo-inc.com>
References: <6EC47187-7F9E-4C19-9701-8FB03254AEAE@yahoo-inc.com> <46D5C6A4.5040904@mozilla.org> <0F02C1FF-4D91-473D-BD2A-CFAA01222BF3@yahoo-inc.com>
Message-ID: <46D60A84.4070708@bugzilla.org>

David Marshall wrote on 8/29/07 3:49 PM:
> On Aug 29, 2007, at 12:19 PM, Gervase Markham wrote:
>>> We have a dual-master database (we have our own proxy that can switch
>>> as needed)
>>
>> So MySQL supports this?
> 
> Er, no, it doesn't... :)  read "We have our own proxy" again.

Actually, it does.  Sort of.  We've been looking into it for Mozilla.
It's by no means easy to implement, and there's a few nasty
give-and-take hacks you have to use (like each autoincrement key gets
ranges assigned in advance per-server, and the masters have to
periodically coordinate with each other on reassigning new ranges as
they run out - which means the bug IDs won't necessarily line up with
the order the bugs are filed, and so forth).  It's difficult enough to
pull off that there's a few commercial products for rather huge $$$ that
are supposed to make it easy. ;)

-- 
Dave Miller                                   http://www.justdave.net/
System Administrator, Mozilla Corporation      http://www.mozilla.com/
Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/


From mkanat at bugzilla.org  Thu Aug 30 00:29:56 2007
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Wed, 29 Aug 2007 17:29:56 -0700
Subject: Announcing VCI: The Version Control Interface for Perl
Message-ID: <20070830002958.8DA4385000B@help.trusthosting.net>

	[This is slightly off-topic for this list, but I thought it
would be of interest to a lot of people here, and I think otherwise
I'd be getting lots of questions and "Oh, you never told me about
that!" :-)]

	"Long have we toiled on our tools that interact with CVS. Oh,
wait, you mean we're switching to Subversion? Oh...long have we toiled
on...what, we're switching to Git?" -The Oppressed Development Tools
Maintainer

	So, I wanted to write a simple tool that displayed some
information about version-control systems (or "software change
management" systems, as some are called). I went looking through CPAN,
thinking, "Surely, there must be a single module that can interact with
many different VCSes, right?"

	But surprisingly, there wasn't. There was the "VCS" module, and
I spoke with its maintainer and he said that he'd always wanted to
re-write it in an object-oriented fashion, but had never found the time
to do so.

	So, I wrote VCI, the generic Version Control Interface.
Currently it can display the history and contents of CVS, Subversion,
Bazaar, Mercurial, and Git. It's easy to write new drivers for other
VCSes, you just make a new package in the VCI::VCS namespace. (And if
you read the VCI code and documentation, you'll see it's easy to write
a driver.)

	VCI is object-oriented. It uses Moose.

	VCI aims to provide a broad set of features while still working
well with all the different VCSes commonly in use. The rationale,
structure, and functionality of VCI is described in the documentation
of the VCI module.

	You can find VCI on the CPAN at:

	http://search.cpan.org/dist/VCI/

	VCI also has a (currently minimal) homepage at:

	http://vci.everythingsolved.com/

	VCI is currently alpha-quality. Stability and performance
improvements are coming in the future.

	I'm very interested in knowing who's using VCI, and am very
willing to have contributions and new drivers from any programmer who
feels competent enough to design quality code.

	You can direct any questions, comments, or patches to me at
mkanat(at)cpan(dot)org.

	I hope that you find VCI useful!

	-Max
-- 
http://www.everythingsolved.com/
Competent, Friendly Bugzilla Services. And Everything Else, too.


From justdave at bugzilla.org  Thu Aug 30 00:40:55 2007
From: justdave at bugzilla.org (David Miller)
Date: Wed, 29 Aug 2007 20:40:55 -0400
Subject: Prefs Removal Proposal
In-Reply-To: <20070829234320.72CB185000B@help.trusthosting.net>
References: <46D59A28.1040207@mozilla.org>	<46D5AA82.1040000@gmail.com>	<46D5B6AE.1020209@mozilla.org>	<46D5B9B6.2040103@gmail.com>	<46D5BB96.7020006@mozilla.org>	<46D5BF28.9090709@bugzilla.org>	<20070829192133.0765F3FF55B@help.trusthosting.net>	<46D5E9EB.3020905@bugzilla.org> <20070829234320.72CB185000B@help.trusthosting.net>
Message-ID: <46D61217.7090908@bugzilla.org>

Max Kanat-Alexander wrote on 8/29/07 7:43 PM:
> On Wed, 29 Aug 2007 17:49:31 -0400 David Miller <justdave at bugzilla.org>
> wrote:
>>> 	That would be fairly easy to do with the User Preferences
>>> and the Default Preferences.
>> Doesn't really make sense to have it there actually.  Once the user
>> has it, it's in their save searches to edit.  There's no reason to
>> make any preference related to it visible to users, even if it is
>> locked down (it'll affect the creation of their account, once it's
>> created, it's no longer needed by their account).
> 
> 	Yeah, good point. We could just make it a Constant. The admin
> can still edit that.

I like that idea.

-- 
Dave Miller                                   http://www.justdave.net/
System Administrator, Mozilla Corporation      http://www.mozilla.com/
Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/


From lyhenry at speakeasy.net  Thu Aug 30 01:25:16 2007
From: lyhenry at speakeasy.net (Lisa Henry)
Date: Wed, 29 Aug 2007 18:25:16 -0700
Subject: 'related to' bugs vs. dependent bugs
Message-ID: <46D61C7C.7090808@speakeasy.net>

Hello,

One of our groups uses bug cloning in their workflow, but the bug 
dependency that is set up is not always what they want.  We have 
'noresolveonopenblockers' turned on.  A user poll showed that some 
people do want the resolution blocking feature, others find it annoying, 
and just clear the 'blocks' or 'depends on' field in order to resolve 
the bug.  Several users suggested that a third field (something like 
'related to') along with the 'blocks' and 'depends on'  would be a 
solution.  We would want the tree view and graphing  capability, but 
would not want related bugs to block resolution.

Before I start looking into this, does anyone have suggestions as to the 
best way to accomplish this?  I've done a bit of customization, but 
prefer not to if there is a more supported method.

We are running Bugzilla version: 3.0 (very nice! We just upgraded a 
month or so ago).

Thanks for any help you can offer,
Lisa







From fergus at yahoo-inc.com  Thu Aug 30 01:34:00 2007
From: fergus at yahoo-inc.com (Fergus Sullivan)
Date: Wed, 29 Aug 2007 18:34:00 -0700
Subject: 'related to' bugs vs. dependent bugs
In-Reply-To: <46D61C7C.7090808@speakeasy.net>
References: <46D61C7C.7090808@speakeasy.net>
Message-ID: <E4EF7DC3-6C08-40DB-B619-F89F2088B325@yahoo-inc.com>

Me too</aol>

In a similar vein to 'related bugs', we have a long-standing request  
to implement 'favorite bugs' or 'bugs I'm watching'.  This would be  
different to CC, insofar as it would be a shorter list of items I'm  
really interested in.

  /ferg

-- 
fergus sullivan | developer tools team | fergus at yahoo-inc.com | o.  
408.349.6807 | m. 408.203.FERG


On Wed 29-Aug-07, at 6p25 , Lisa Henry wrote:

> Hello,
>
> One of our groups uses bug cloning in their workflow, but the bug  
> dependency that is set up is not always what they want.  We have  
> 'noresolveonopenblockers' turned on.  A user poll showed that some  
> people do want the resolution blocking feature, others find it  
> annoying, and just clear the 'blocks' or 'depends on' field in  
> order to resolve the bug.  Several users suggested that a third  
> field (something like 'related to') along with the 'blocks' and  
> 'depends on'  would be a solution.  We would want the tree view and  
> graphing  capability, but would not want related bugs to block  
> resolution.
>
> Before I start looking into this, does anyone have suggestions as  
> to the best way to accomplish this?  I've done a bit of  
> customization, but prefer not to if there is a more supported method.
>
> We are running Bugzilla version: 3.0 (very nice! We just upgraded a  
> month or so ago).
>
> Thanks for any help you can offer,
> Lisa
>
>
>
>
>
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=fergus at yahoo-inc.com>



From mkanat at bugzilla.org  Thu Aug 30 02:07:24 2007
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Wed, 29 Aug 2007 19:07:24 -0700
Subject: 'related to' bugs vs. dependent bugs
In-Reply-To: <46D61C7C.7090808@speakeasy.net>
References: <46D61C7C.7090808@speakeasy.net>
Message-ID: <20070830020726.4DB88888007@help.trusthosting.net>

On Wed, 29 Aug 2007 18:25:16 -0700 Lisa Henry <lyhenry at speakeasy.net>
wrote:
> One of our groups uses bug cloning in their workflow, but the bug 
> dependency that is set up is not always what they want.  We have 
> 'noresolveonopenblockers' turned on.  A user poll showed that some 
> people do want the resolution blocking feature, others find it
> annoying, and just clear the 'blocks' or 'depends on' field in order
> to resolve the bug.  Several users suggested that a third field
> (something like 'related to') along with the 'blocks' and 'depends
> on'  would be a solution.  We would want the tree view and graphing
> capability, but would not want related bugs to block resolution.

	That sounds like you just shouldn't be using
noresolveonopenblockers.

> Before I start looking into this, does anyone have suggestions as to
> the best way to accomplish this?  I've done a bit of customization,
> but prefer not to if there is a more supported method.

	We've had some discussion about it (about 8 years worth,
apparently):

	https://bugzilla.mozilla.org/show_bug.cgi?id=12286

	-Max
-- 
http://www.everythingsolved.com/
Competent, Friendly Bugzilla Services. And Everything Else, too.


From gerv at mozilla.org  Thu Aug 30 09:22:14 2007
From: gerv at mozilla.org (Gervase Markham)
Date: Thu, 30 Aug 2007 10:22:14 +0100
Subject: Self-Introduction: Fergus Sullivan
In-Reply-To: <D35D362E-9B67-4579-A312-CA7DE221836F@yahoo-inc.com>
References: <6EC47187-7F9E-4C19-9701-8FB03254AEAE@yahoo-inc.com> <D35D362E-9B67-4579-A312-CA7DE221836F@yahoo-inc.com>
Message-ID: <46D68C46.6080205@mozilla.org>

Fergus Sullivan wrote:
> == How do we have dual-master sql proxies? ==
> We have our own secret sauce for this.  It's in use across Yahoo and is 
> central to our BCP/HA planning.  It's proprietary, and not currently on 
> our list to release to open source.

I think the interest expressed here was more "hey, cool" rather than "we 
need this for Bugzilla". Of course, a free software release would be 
great too.

> Calendar and Autocomplete - We already use these in our Bugzilla code Yahoo
> http://developer.yahoo.com/yui/examples/calendar/quickstart.html
> 
> Grids - For clean layout
> http://developer.yahoo.com/yui/examples/calendar/quickstart.html

Wrong URL?

> == When can Yahoo start offering its patches for review ==
> It depends.  We have an internal legal process to approve engagement.  
> That'll take a few weeks to complete.  We should be able to offer minor 
> patches soon after.
> 
> The larger patches will be tricky, as they work for us right now with 
> the rest of our code base.  Remember our code is based on 2.22 and 
> chunks of it are modified.  That said, our Search.pm is a thing of 
> beauty...

Code thrown over the wall is still better than no code at all. Perhaps 
you might consider posting a giant diff of your code compared to 2.22, 
as well as pursuing a parallel strategy of submitting small, clean 
patches against the trunk?

Gerv



From gerv at mozilla.org  Thu Aug 30 09:26:07 2007
From: gerv at mozilla.org (Gervase Markham)
Date: Thu, 30 Aug 2007 10:26:07 +0100
Subject: Self-Introduction: Fergus Sullivan
In-Reply-To: <8A6F5851-5088-4509-AC9D-225218221196@acm.org>
References: <6EC47187-7F9E-4C19-9701-8FB03254AEAE@yahoo-inc.com> <20070829195732.GA12869@bkor.dhs.org> <8A6F5851-5088-4509-AC9D-225218221196@acm.org>
Message-ID: <46D68D2F.9090001@mozilla.org>

Pankaj K Garg wrote:
> I second the idea of looking into YUI (Yahoo User Interface Library) as 
> the means of providing a more Web 2.0 and AJAX'y interface to Bugzilla. 
> It comes with a BSD license, and so should be compatible (I think) with 
> the Mozilla license.

Recently, several frameworks of this sort have been developed. They all 
seem very cool and have capabilities far beyond what we want or need. 
Unless other Bugzilla developers have a strong preference for another 
one, if the Yahoo! team have YUI-based improvements to Bugzilla, that 
swings it for me.

The only thing is that we shouldn't end up using two!

BTW, there are no problems from a licensing point of view.

Gerv


From dmarshal at yahoo-inc.com  Thu Aug 30 17:03:22 2007
From: dmarshal at yahoo-inc.com (David Marshall)
Date: Thu, 30 Aug 2007 10:03:22 -0700
Subject: Self-Introduction: David Marshall
Message-ID: <1A9138DD-C0B7-4DDB-B093-C3E6A87A4FEE@yahoo-inc.com>

== Full name ==
David Marshall

== Your IRC nick on irc.mozilla.org ==
dwm

== City, Country ==
Sunnyvale, California, United States.

== Profession or Student status ==
Senior Technical Yahoo!

== Company, School, or other affiliation ==
Yahoo!

== What do you want to help out with? ==
contributing Yahoo! changes to b.m.o
general bug fixes as soon as all Y! bugzilla bugs fixed (Real Soon Now)

== Historical qualifications ==
several journeys through perl maintenance hell

== Anything else you'd like to say ==
looking forward to sharing the work that my predecessors and I have  
put into Bugzilla



From lyhenry at speakeasy.net  Thu Aug 30 17:23:20 2007
From: lyhenry at speakeasy.net (Lisa Henry)
Date: Thu, 30 Aug 2007 10:23:20 -0700
Subject: 'related to' bugs vs. dependent bugs
In-Reply-To: <20070830020726.4DB88888007@help.trusthosting.net>
References: <46D61C7C.7090808@speakeasy.net> <20070830020726.4DB88888007@help.trusthosting.net>
Message-ID: <46D6FD08.5020306@speakeasy.net>

Thanks, I'll watch that bug.  Sounds like this is a useful feature for 
others, as well.

Max Kanat-Alexander wrote:
> On Wed, 29 Aug 2007 18:25:16 -0700 Lisa Henry <lyhenry at speakeasy.net>
> wrote:
>   
>> One of our groups uses bug cloning in their workflow, but the bug 
>> dependency that is set up is not always what they want.  We have 
>> 'noresolveonopenblockers' turned on.  A user poll showed that some 
>> people do want the resolution blocking feature, others find it
>> annoying, and just clear the 'blocks' or 'depends on' field in order
>> to resolve the bug.  Several users suggested that a third field
>> (something like 'related to') along with the 'blocks' and 'depends
>> on'  would be a solution.  We would want the tree view and graphing
>> capability, but would not want related bugs to block resolution.
>>     
>
> 	That sounds like you just shouldn't be using
> noresolveonopenblockers.
>
>   
>> Before I start looking into this, does anyone have suggestions as to
>> the best way to accomplish this?  I've done a bit of customization,
>> but prefer not to if there is a more supported method.
>>     
>
> 	We've had some discussion about it (about 8 years worth,
> apparently):
>
> 	https://bugzilla.mozilla.org/show_bug.cgi?id=12286
>
> 	-Max
>   



From mkanat at bugzilla.org  Thu Aug 30 20:35:10 2007
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Thu, 30 Aug 2007 13:35:10 -0700
Subject: Self-Introduction: David Marshall
In-Reply-To: <1A9138DD-C0B7-4DDB-B093-C3E6A87A4FEE@yahoo-inc.com>
References: <1A9138DD-C0B7-4DDB-B093-C3E6A87A4FEE@yahoo-inc.com>
Message-ID: <20070830203512.62D4F85000B@help.trusthosting.net>

	Hey David! I think we gave you a pretty good welcome on IRC
yesterday, but welcome to the Bugzilla Project! :-) We're glad to have
you. :-)

	-Max
-- 
http://www.everythingsolved.com/
Competent, Friendly Bugzilla Services. And Everything Else, too.


From ghendricks at novell.com  Thu Aug 30 22:09:14 2007
From: ghendricks at novell.com (Gregary Hendricks)
Date: Thu, 30 Aug 2007 16:09:14 -0600
Subject: Self-Introduction: Fergus Sullivan
Message-ID: <46D6EBAA020000D200010854@sinclair.provo.novell.com>

On Thu, 2007-08-30 at 10:26 +0100, Gervase Markham wrote:
> Recently, several frameworks of this sort have been developed. They all 
> seem very cool and have capabilities far beyond what we want or need. 
> Unless other Bugzilla developers have a strong preference for another 
> one, if the Yahoo! team have YUI-based improvements to Bugzilla, that 
> swings it for me.
> 

I second this. I have been using Dojo for Testopia but I am fed up with
it. I am looking for a new tool that can do the basic ajax without the
overhead and YUI seems to have alot better command of the situation.

> The only thing is that we shouldn't end up using two!
> 

I am ready and willing to switch.

Greg



From bugzilla at colinogilvie.co.uk  Thu Aug 30 23:15:16 2007
From: bugzilla at colinogilvie.co.uk (Colin Ogilvie)
Date: Fri, 31 Aug 2007 00:15:16 +0100
Subject: Self-Introduction: Fergus Sullivan
In-Reply-To: <46D68D2F.9090001@mozilla.org>
References: <6EC47187-7F9E-4C19-9701-8FB03254AEAE@yahoo-inc.com> <20070829195732.GA12869@bkor.dhs.org> <8A6F5851-5088-4509-AC9D-225218221196@acm.org> <46D68D2F.9090001@mozilla.org>
Message-ID: <46D74F84.4010205@colinogilvie.co.uk>

Gervase Markham wrote:
> Recently, several frameworks of this sort have been developed. They
> all seem very cool and have capabilities far beyond what we want or
> need. Unless other Bugzilla developers have a strong preference for
> another one, if the Yahoo! team have YUI-based improvements to
> Bugzilla, that swings it for me.
>
> The only thing is that we shouldn't end up using two!
>
> BTW, there are no problems from a licensing point of view. 

Shouldn't we look to evaluate different libraries / frameworks based on
what we actually want to do with AJAX/DHTML/JavaScript rather than just
picking YUI because the Yahoo! team have used it?

There may be other frameworks that provide the functionality that we
need / want to use and it seems a bit naive to just use the first one
suggested.

Colin


From bugzilla at glob.com.au  Fri Aug 31 00:30:33 2007
From: bugzilla at glob.com.au (byron)
Date: Fri, 31 Aug 2007 08:30:33 +0800
Subject: Self-Introduction: Fergus Sullivan
In-Reply-To: <46D74F84.4010205@colinogilvie.co.uk>
References: <6EC47187-7F9E-4C19-9701-8FB03254AEAE@yahoo-inc.com> <20070829195732.GA12869@bkor.dhs.org> <8A6F5851-5088-4509-AC9D-225218221196@acm.org> <46D68D2F.9090001@mozilla.org> <46D74F84.4010205@colinogilvie.co.uk>
Message-ID: <20070831003032.GA8022@bur.st>

> Shouldn't we look to evaluate different libraries / frameworks based on
> what we actually want to do with AJAX/DHTML/JavaScript rather than just
> picking YUI because the Yahoo! team have used it?

i don't think so -- we need willing developers more than we need the
correct javascript library.

yui is very good anyhow :)


-b

begin-base64 644 signature.gif
R0lGODlhbQAHAIAAAABPo////ywAAAAAbQAHAAACfAxuGAnch+Bibkn7FL1p
XgVl4Ig1jjlZRoqybgun2Cur5uOunq7u/Ipq7WIyIc7XG9JquEgumPzdlhTf
h0O83kDJaXEm8mRHwXKJy5sac7qYOpT+gtv0n+0ujQOfdqh16caWt0foBViH
N1PRMXimiLUGt3ElVimlgbllWAAAOw==


From justdave at bugzilla.org  Fri Aug 31 00:52:59 2007
From: justdave at bugzilla.org (David Miller)
Date: Thu, 30 Aug 2007 20:52:59 -0400
Subject: Self-Introduction: Fergus Sullivan
In-Reply-To: <46D6EBAA020000D200010854@sinclair.provo.novell.com>
References: <46D6EBAA020000D200010854@sinclair.provo.novell.com>
Message-ID: <46D7666B.6090607@bugzilla.org>

Gregary Hendricks wrote on 8/30/07 6:09 PM:
> On Thu, 2007-08-30 at 10:26 +0100, Gervase Markham wrote:
>> Recently, several frameworks of this sort have been developed. They all 
>> seem very cool and have capabilities far beyond what we want or need. 
>> Unless other Bugzilla developers have a strong preference for another 
>> one, if the Yahoo! team have YUI-based improvements to Bugzilla, that 
>> swings it for me.
> 
> I second this. I have been using Dojo for Testopia but I am fed up with
> it. I am looking for a new tool that can do the basic ajax without the
> overhead and YUI seems to have alot better command of the situation.

After seeing it mentioned here, I grabbed YUI and I've been using it on
an internal project at Mozilla for the last couple days, and I'm
suitably impressed as well.  Seems to be well thought out at first glance.

-- 
Dave Miller                                   http://www.justdave.net/
System Administrator, Mozilla Corporation      http://www.mozilla.com/
Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/


From gerv at mozilla.org  Fri Aug 31 09:17:54 2007
From: gerv at mozilla.org (Gervase Markham)
Date: Fri, 31 Aug 2007 10:17:54 +0100
Subject: Self-Introduction: Fergus Sullivan
In-Reply-To: <46D74F84.4010205@colinogilvie.co.uk>
References: <6EC47187-7F9E-4C19-9701-8FB03254AEAE@yahoo-inc.com> <20070829195732.GA12869@bkor.dhs.org> <8A6F5851-5088-4509-AC9D-225218221196@acm.org> <46D68D2F.9090001@mozilla.org> <46D74F84.4010205@colinogilvie.co.uk>
Message-ID: <46D7DCC2.2030007@mozilla.org>

Colin Ogilvie wrote:
> Shouldn't we look to evaluate different libraries / frameworks based on
> what we actually want to do with AJAX/DHTML/JavaScript rather than just
> picking YUI because the Yahoo! team have used it?

My assertion is that there is no significant difference between all of 
these frameworks in terms of developer ramp-up or capabilities - at 
least, when it comes to the sort of things Bugzilla might need (which 
will not stretch their capabilities to the limit; we aren't writing 
another Zimbra).

However, I have only limited evidence for that assertion, and am quite 
willing to be swayed by counter-evidence presented. However, we do need 
actual evidence :-)

> There may be other frameworks that provide the functionality that we
> need / want to use and it seems a bit naive to just use the first one
> suggested.

If they all provide the functionality, why not use the first one suggested?

Gerv



From jochen.wiedmann at gmail.com  Fri Aug 31 09:37:56 2007
From: jochen.wiedmann at gmail.com (Jochen Wiedmann)
Date: Fri, 31 Aug 2007 11:37:56 +0200
Subject: Self-Introduction: Fergus Sullivan
In-Reply-To: <46D7DCC2.2030007@mozilla.org>
References: <6EC47187-7F9E-4C19-9701-8FB03254AEAE@yahoo-inc.com>
	 <20070829195732.GA12869@bkor.dhs.org>
	 <8A6F5851-5088-4509-AC9D-225218221196@acm.org>
	 <46D68D2F.9090001@mozilla.org> <46D74F84.4010205@colinogilvie.co.uk>
	 <46D7DCC2.2030007@mozilla.org>
Message-ID: <e75283b10708310237w4d09eff1je23deb47131018e@mail.gmail.com>

On 8/31/07, Gervase Markham <gerv at mozilla.org> wrote:

> If they all provide the functionality, why not use the first one suggested?

Is it clear, that this framework, or these frameworks play nicely with
the Template Toolkit? Loosing that would be, IMO, very unfortunate.


Jochen


-- 
"Besides, manipulating elections is under penalty of law, resulting in
a preventative effect against manipulating elections.

The german government justifying the use of electronic voting machines
and obviously  believing that we don't need a police, because all
illegal actions are forbidden.

http://dip.bundestag.de/btd/16/051/1605194.pdf


From gerv at mozilla.org  Fri Aug 31 09:54:25 2007
From: gerv at mozilla.org (Gervase Markham)
Date: Fri, 31 Aug 2007 10:54:25 +0100
Subject: Self-Introduction: Fergus Sullivan
In-Reply-To: <e75283b10708310237w4d09eff1je23deb47131018e@mail.gmail.com>
References: <6EC47187-7F9E-4C19-9701-8FB03254AEAE@yahoo-inc.com>	 <20070829195732.GA12869@bkor.dhs.org>	 <8A6F5851-5088-4509-AC9D-225218221196@acm.org>	 <46D68D2F.9090001@mozilla.org> <46D74F84.4010205@colinogilvie.co.uk>	 <46D7DCC2.2030007@mozilla.org> <e75283b10708310237w4d09eff1je23deb47131018e@mail.gmail.com>
Message-ID: <46D7E551.4050507@mozilla.org>

Jochen Wiedmann wrote:
> Is it clear, that this framework, or these frameworks play nicely with
> the Template Toolkit? Loosing that would be, IMO, very unfortunate.

The two serve different purposes. Template Toolkit is a server-side 
templating language. YUI helps enhance the resulting HTML generated by 
the Template Toolkit without requiring a page reload.

Gerv


From jochen.wiedmann at gmail.com  Fri Aug 31 10:56:15 2007
From: jochen.wiedmann at gmail.com (Jochen Wiedmann)
Date: Fri, 31 Aug 2007 12:56:15 +0200
Subject: Self-Introduction: Fergus Sullivan
In-Reply-To: <46D7E551.4050507@mozilla.org>
References: <6EC47187-7F9E-4C19-9701-8FB03254AEAE@yahoo-inc.com>
	 <20070829195732.GA12869@bkor.dhs.org>
	 <8A6F5851-5088-4509-AC9D-225218221196@acm.org>
	 <46D68D2F.9090001@mozilla.org> <46D74F84.4010205@colinogilvie.co.uk>
	 <46D7DCC2.2030007@mozilla.org>
	 <e75283b10708310237w4d09eff1je23deb47131018e@mail.gmail.com>
	 <46D7E551.4050507@mozilla.org>
Message-ID: <e75283b10708310356r77c8e320u3dc2e6c0b617334d@mail.gmail.com>

On 8/31/07, Gervase Markham <gerv at mozilla.org> wrote:

> The two serve different purposes. Template Toolkit is a server-side
> templating language. YUI helps enhance the resulting HTML generated by
> the Template Toolkit without requiring a page reload.

Of course they do serve different purposes. But, particularly in the
case of AJAX, it is quite common that client side stuff depends on
server side components as well.

Jochen

-- 
"Besides, manipulating elections is under penalty of law, resulting in
a preventative effect against manipulating elections.

The german government justifying the use of electronic voting machines
and obviously  believing that we don't need a police, because all
illegal actions are forbidden.

http://dip.bundestag.de/btd/16/051/1605194.pdf


From gargp at acm.org  Fri Aug 31 14:37:53 2007
From: gargp at acm.org (Pankaj K Garg)
Date: Fri, 31 Aug 2007 07:37:53 -0700
Subject: Self-Introduction: Fergus Sullivan
In-Reply-To: <e75283b10708310356r77c8e320u3dc2e6c0b617334d@mail.gmail.com>
References: <6EC47187-7F9E-4C19-9701-8FB03254AEAE@yahoo-inc.com> <20070829195732.GA12869@bkor.dhs.org> <8A6F5851-5088-4509-AC9D-225218221196@acm.org> <46D68D2F.9090001@mozilla.org> <46D74F84.4010205@colinogilvie.co.uk> <46D7DCC2.2030007@mozilla.org> <e75283b10708310237w4d09eff1je23deb47131018e@mail.gmail.com> <46D7E551.4050507@mozilla.org> <e75283b10708310356r77c8e320u3dc2e6c0b617334d@mail.gmail.com>
Message-ID: <E9544571-3A26-4B69-A453-B5506C08AE62@acm.org>

On Aug 31, 2007, at 3:56 AM, Jochen Wiedmann wrote:

> On 8/31/07, Gervase Markham <gerv at mozilla.org> wrote:
>
>> The two serve different purposes. Template Toolkit is a server-side
>> templating language. YUI helps enhance the resulting HTML  
>> generated by
>> the Template Toolkit without requiring a page reload.
>
> Of course they do serve different purposes. But, particularly in the
> case of AJAX, it is quite common that client side stuff depends on
> server side components as well.

It really doesn't matter, as Gervase said they are server-side vs.  
client-side issues.  Whichever library we use will require server  
side to generate the proper results.

That said, in my experience with YUI, from the server side you should  
be able to generate JSON objects as necessary and be able to populate  
Javascript code with values from the DB. In both these cases I've  
found the Bugzilla's use of Template Toolkit to be very handy and  
useful.

Pankaj

  --
  Pankaj K Garg                         garg at zeesource.net
  1684 Nightingale Avenue     408-373-4027
  Suite 201                                  408-733-2737(fax)
  Sunnyvale, CA 94087            http://www.zeesource.net






From mkanat at bugzilla.org  Fri Aug 31 19:46:38 2007
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Fri, 31 Aug 2007 12:46:38 -0700
Subject: Self-Introduction: Fergus Sullivan
In-Reply-To: <E9544571-3A26-4B69-A453-B5506C08AE62@acm.org>
References: <6EC47187-7F9E-4C19-9701-8FB03254AEAE@yahoo-inc.com>
	<20070829195732.GA12869@bkor.dhs.org>
	<8A6F5851-5088-4509-AC9D-225218221196@acm.org>
	<46D68D2F.9090001@mozilla.org>
	<46D74F84.4010205@colinogilvie.co.uk>
	<46D7DCC2.2030007@mozilla.org>
	<e75283b10708310237w4d09eff1je23deb47131018e@mail.gmail.com>
	<46D7E551.4050507@mozilla.org>
	<e75283b10708310356r77c8e320u3dc2e6c0b617334d@mail.gmail.com>
	<E9544571-3A26-4B69-A453-B5506C08AE62@acm.org>
Message-ID: <20070831194640.65DC7318013@help.trusthosting.net>

On Fri, 31 Aug 2007 07:37:53 -0700 Pankaj K Garg <gargp at acm.org> wrote:
> That said, in my experience with YUI, from the server side you
> should be able to generate JSON objects as necessary and be able to
> populate Javascript code with values from the DB. In both these cases
> I've found the Bugzilla's use of Template Toolkit to be very handy
> and useful.

	Just as a note here, I think this would be a cool opportunity
to make Bugzilla::WebService able to return data in different formats,
and extend it to also return JSON sometimes. So we'd have
Bugzilla::WebService::XML-RPC and Bugzilla::WebService::JSON, both
would call the exact same functions but take their arguments and return
their data in a different way.

	-Max
-- 
http://www.everythingsolved.com/
Competent, Friendly Bugzilla Services. And Everything Else, too.