From lpsolit at gmail.com  Mon Sep  3 11:24:22 2007
From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=)
Date: Mon, 03 Sep 2007 13:24:22 +0200
Subject: Bugzilla meeting tomorrow, September 4th
Message-ID: <46DBEEE6.3050308@gmail.com>

We have another Bugzilla meeting on Tuesday, September 4 at 11:00 PST
(18:00 GMT, 20:00 CEST) on IRC in the #bugzilla-meeting channel. The
main topic will be about the removal of some (useless?) parameters
currently used by Bugzilla (see the initial discussion in a thread in
this mailing list). If you want to keep some threatened parameter,
please join the meeting to give us your opinion and explain why we
shouldn't remove it. Or tell us why we should get rid of some specific
parameter.

See you tomorrow,

Fr?d?ric


From john at redux.org.uk  Tue Sep  4 19:48:14 2007
From: john at redux.org.uk (John Beranek)
Date: Tue, 04 Sep 2007 20:48:14 +0100
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: <46DDB67E.9060904@redux.org.uk>

Gervase Markham wrote:
> 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/

Let's reverse that. Let's say that the site's SSL server is

https://secure.foo.com/

and they only have an SSL certificate for secure.foo.com

they wouldn't want to have to have Bugzilla live at
http://secure.foo.com/ but rather have, say,

https://secure.foo.com/bugzilla/

and

http://bugzilla.foo.com/

John.

-- 
John Beranek                         To generalise is to be an idiot.
http://redux.org.uk/                                 -- William Blake


From bugreport at peshkin.net  Tue Sep  4 20:27:14 2007
From: bugreport at peshkin.net (Joel Peshkin)
Date: Tue, 04 Sep 2007 13:27:14 -0700
Subject: Prefs Removal Proposal
In-Reply-To: <46DDB67E.9060904@redux.org.uk>
References: <46D59A28.1040207@mozilla.org> <e75283b10708290931t5d929735m8bd195608d13d815@mail.gmail.com> <46D5A10D.1030407@mozilla.org> <46DDB67E.9060904@redux.org.uk>
Message-ID: <46DDBFA2.5000002@peshkin.net>

John Beranek wrote:
> Let's reverse that. Let's say that the site's SSL server is
>
> https://secure.foo.com/
>
> and they only have an SSL certificate for secure.foo.com
>
> they wouldn't want to have to have Bugzilla live at
> http://secure.foo.com/ but rather have, say,
>
> https://secure.foo.com/bugzilla/
>
> and
>
> http://bugzilla.foo.com/
>
> John.
>
>   

The other way to deal with some of these uncommon prefs would be to 
combine them.

For example, if URLBASE is "http://bugzilla.foo.com/" and SSL is 
enabled, then SSLBASE is "https://bugzilla.foo.com/"

If, on the other hand URLBASE is set to "http://bugzilla.foo.com/  
https://secure.foo.com/bugzilla/", (a list), then URLBASE and SSL BASE 
differ by more than just the protocol field.

This would prevent adding extra fields for rare configurations at the 
expense of making it a bit trickier for the few who need the less common 
configuration.

I suspect that some fo the shadowdb parameters could be combined into a 
one-liner as well.



From gerv at mozilla.org  Tue Sep  4 21:35:05 2007
From: gerv at mozilla.org (Gervase Markham)
Date: Tue, 04 Sep 2007 22:35:05 +0100
Subject: Prefs Removal Proposal
In-Reply-To: <46DDB67E.9060904@redux.org.uk>
References: <46D59A28.1040207@mozilla.org> <e75283b10708290931t5d929735m8bd195608d13d815@mail.gmail.com> <46D5A10D.1030407@mozilla.org> <46DDB67E.9060904@redux.org.uk>
Message-ID: <46DDCF89.2090502@mozilla.org>

John Beranek wrote:
> Let's reverse that. Let's say that the site's SSL server is
> 
> https://secure.foo.com/
> 
> and they only have an SSL certificate for secure.foo.com
> 
> they wouldn't want to have to have Bugzilla live at
> http://secure.foo.com/ but rather have, say,
> 
> https://secure.foo.com/bugzilla/
> 
> and
> 
> http://bugzilla.foo.com/

Then they can have http://bugzilla.foo.com/ redirect to 
http://secure.foo.com/bugzilla/ , and/or DNS alias bugzilla.foo.com to 
secure.foo.com.

Gerv


From mkanat at bugzilla.org  Tue Sep  4 21:52:16 2007
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Tue, 4 Sep 2007 14:52:16 -0700
Subject: $class-> in Bugzilla.pm, not Bugzilla->
Message-ID: <20070904215217.DE3D785000A@help.trusthosting.net>

	See:

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

	If you're editing methods inside of Bugzilla.pm, don't use
"request_cache()" or "Bugzilla->" anymore, instead
"$class->request_cache" and "$class->".

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


From lpsolit at gmail.com  Tue Sep  4 21:59:33 2007
From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=)
Date: Tue, 04 Sep 2007 23:59:33 +0200
Subject: Results of the discussion about parameters removal
Message-ID: <46DDD545.6000904@gmail.com>

Hi all,

The Bugzilla meeting ended right now with 18 people attending today
(probably a record), and we are going towards the removal of 23
parameters(!). You can see our decisions on this page:

http://wiki.mozilla.org/Bugzilla:Params

We also decided to wait one month, i.e. till our next meeting on October
2, before definitely validating the list. We think this will give all of
you enough time to object if you have a very good reason why we
shouldn't remove some parameters. Note that a few parameters will be
replaced by a constant so that you still have a way to edit them if you
really want to/have to. But most of the ones we want to remove will be
simply killed.

Please do not edit the page itself as it contains the results of our
discussion at the meeting. Probably better is to reply to this email and
keep the discussion in this thread. We will update the list ourselves if
there is a good reason to, based on the discussion we might have per email.

LpSolit


From dmarshal at yahoo-inc.com  Tue Sep  4 22:34:49 2007
From: dmarshal at yahoo-inc.com (David Marshall)
Date: Tue, 4 Sep 2007 15:34:49 -0700
Subject: Prefs Removal Proposal
In-Reply-To: <46DDCF89.2090502@mozilla.org>
References: <46D59A28.1040207@mozilla.org> <e75283b10708290931t5d929735m8bd195608d13d815@mail.gmail.com> <46D5A10D.1030407@mozilla.org> <46DDB67E.9060904@redux.org.uk> <46DDCF89.2090502@mozilla.org>
Message-ID: <AE51B5B9-18DB-47A0-AF44-3BAB00A44928@yahoo-inc.com>


On Sep 4, 2007, at 2:35 PM, Gervase Markham wrote:

> John Beranek wrote:
>> Let's reverse that. Let's say that the site's SSL server is
>> https://secure.foo.com/
>> and they only have an SSL certificate for secure.foo.com
>> they wouldn't want to have to have Bugzilla live at
>> http://secure.foo.com/ but rather have, say,
>> https://secure.foo.com/bugzilla/
>> and
>> http://bugzilla.foo.com/
>
> Then they can have http://bugzilla.foo.com/ redirect to http:// 
> secure.foo.com/bugzilla/ , and/or DNS alias bugzilla.foo.com to  
> secure.foo.com.
>
>

It's a false savings to get rid of sslbase if some users must  
reconfigure Apache.  If that also includes an actual redirection  
being sent back to the browser, that's even worse.

It is likely that someone out there has a set of circumstances in  
which he needs urlbase & sslbase to be entirely different and for  
whom Apache reconfiguration is not feasible.

Pushing things like this off to Apache for the sake of getting rid of  
a parameter is discourteous to say the least.




From bugreport at peshkin.net  Tue Sep  4 22:41:49 2007
From: bugreport at peshkin.net (Joel Peshkin)
Date: Tue, 04 Sep 2007 15:41:49 -0700
Subject: Results of the discussion about parameters removal
In-Reply-To: <46DDD545.6000904@gmail.com>
References: <46DDD545.6000904@gmail.com>
Message-ID: <46DDDF2D.2070108@peshkin.net>




We should be able to get rid of shadowdbhost, shadowdbsock, shadowdbport.

   shadowdb can be redefined to be the DSN of the database.  So, that can be
    myshadowdb
    database=myshadowdb
    database=myshadowdb;host=myshadowhost
    database=myshadowdb;host=myshadowhost;port=8900
    database=myshadowdb;mysql_socket=/var/mysql.sock
Oracle and Pg seem to support similar syntaxes.

Also, as we move various *group items to groups, we risk cluttering up 
the groups UI just as badly.  We should consider reserving the group 
names, but not pre-creating them so, if the group isn't defined, the 
feature is disabled.



   


From mkanat at bugzilla.org  Tue Sep  4 22:52:12 2007
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Tue, 4 Sep 2007 15:52:12 -0700
Subject: Results of the discussion about parameters removal
In-Reply-To: <46DDDF2D.2070108@peshkin.net>
References: <46DDD545.6000904@gmail.com>
	<46DDDF2D.2070108@peshkin.net>
Message-ID: <20070904225214.8A59A85000A@help.trusthosting.net>

On Tue, 04 Sep 2007 15:41:49 -0700 Joel Peshkin <bugreport at peshkin.net>
wrote:
>    shadowdb can be redefined to be the DSN of the database.  So, that
> can be myshadowdb

	Unfortunately, that just won't work very well with Bugzilla::DB.
The separate parameters are as necessary for shadowdb as they are in
localconfig.

> Also, as we move various *group items to groups, we risk cluttering
> up the groups UI just as badly.  We should consider reserving the
> group names, but not pre-creating them so, if the group isn't
> defined, the feature is disabled.

	I'm more OK with having lots of groups. We can perhaps switch
things around for System Groups at some point so that they display
differently in the UI, but I think reserving but not pre-creating
groups would add a lot of complexity to the code.

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


From kevin.benton at amd.com  Tue Sep  4 22:52:23 2007
From: kevin.benton at amd.com (Benton, Kevin)
Date: Tue, 4 Sep 2007 15:52:23 -0700
Subject: Prefs Removal Proposal
In-Reply-To: <AE51B5B9-18DB-47A0-AF44-3BAB00A44928@yahoo-inc.com>
References: <46D59A28.1040207@mozilla.org>
 <e75283b10708290931t5d929735m8bd195608d13d815@mail.gmail.com>
 <46D5A10D.1030407@mozilla.org> <46DDB67E.9060904@redux.org.uk>
 <46DDCF89.2090502@mozilla.org>
 <AE51B5B9-18DB-47A0-AF44-3BAB00A44928@yahoo-inc.com>
Message-ID: <D85E06673A2DFF44B221CF78D1CBB11B0182BF3A@SSVLEXMB1.amd.com>

> On Sep 4, 2007, at 2:35 PM, Gervase Markham wrote:
> 
> > John Beranek wrote:
> >> Let's reverse that. Let's say that the site's SSL server is
> >> https://secure.foo.com/
> >> and they only have an SSL certificate for secure.foo.com
> >> they wouldn't want to have to have Bugzilla live at
> >> http://secure.foo.com/ but rather have, say,
> >> https://secure.foo.com/bugzilla/
> >> and
> >> http://bugzilla.foo.com/
> >
> > Then they can have http://bugzilla.foo.com/ redirect to http:// 
> > secure.foo.com/bugzilla/ , and/or DNS alias bugzilla.foo.com to  
> > secure.foo.com.
> >
> >
> 
> It's a false savings to get rid of sslbase if some users must  
> reconfigure Apache.  If that also includes an actual redirection  
> being sent back to the browser, that's even worse.
> 
> It is likely that someone out there has a set of circumstances in  
> which he needs urlbase & sslbase to be entirely different and for  
> whom Apache reconfiguration is not feasible.
> 
> Pushing things like this off to Apache for the sake of 
> getting rid of  
> a parameter is discourteous to say the least.

Okay - I have to ask - what is the real advantage of making Bugzilla
"less" configurable than it has been previously?  There seems to be
enough people out there that would really not like to see urlbase and
sslbase removed from Bugzilla.

I can accept that some might say that there are too many parameters to
configure.  For those in that camp, I suggest adding another parameter
configuration layer - basic and advanced.  Those who need to tune
certain things that are not commonly accessed can head for advanced.
Those who are just getting started with Bugzilla will want to use basic
and leave the rest alone.

What am I missing?

Kevin

---

Kevin Benton
MySQL DBA #5739
Senior Software Developer
MSS Silicon Design Engineering
Advanced Micro Devices
2950 E Harmony Rd
Fort Collins, CO  80528
 
The opinions stated in this communication do not necessarily reflect the
view of Advanced Micro Devices and have not been reviewed by management.
This communication may contain sensitive and/or confidential and/or
proprietary information.  Distribution of such information is strictly
prohibited without prior consent of Advanced Micro Devices.  This
communication is for the intended recipient(s) only.  If you have
received this communication in error, please notify the sender, then
destroy any remaining copies of this communication.




From lpsolit at gmail.com  Tue Sep  4 22:55:25 2007
From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=)
Date: Wed, 05 Sep 2007 00:55:25 +0200
Subject: Results of the discussion about parameters removal
In-Reply-To: <20070904225214.8A59A85000A@help.trusthosting.net>
References: <46DDD545.6000904@gmail.com>	<46DDDF2D.2070108@peshkin.net> <20070904225214.8A59A85000A@help.trusthosting.net>
Message-ID: <46DDE25D.10802@gmail.com>

> 	I'm more OK with having lots of groups. We can perhaps switch
> things around for System Groups at some point so that they display
> differently in the UI

We could have a toggle button to show/hide system groups in the group
list. Doesn't look like a problem to me either.


From lpsolit at gmail.com  Tue Sep  4 22:59:11 2007
From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=)
Date: Wed, 05 Sep 2007 00:59:11 +0200
Subject: Prefs Removal Proposal
In-Reply-To: <D85E06673A2DFF44B221CF78D1CBB11B0182BF3A@SSVLEXMB1.amd.com>
References: <46D59A28.1040207@mozilla.org> <e75283b10708290931t5d929735m8bd195608d13d815@mail.gmail.com> <46D5A10D.1030407@mozilla.org> <46DDB67E.9060904@redux.org.uk> <46DDCF89.2090502@mozilla.org> <AE51B5B9-18DB-47A0-AF44-3BAB00A44928@yahoo-inc.com> <D85E06673A2DFF44B221CF78D1CBB11B0182BF3A@SSVLEXMB1.amd.com>
Message-ID: <46DDE33F.40200@gmail.com>

> configuration layer - basic and advanced.  Those who need to tune
> certain things that are not commonly accessed can head for advanced.
> Those who are just getting started with Bugzilla will want to use basic
> and leave the rest alone.
> 
> What am I missing?

It's not only a question of basic/advanced UI, but also a question about
how the logic works. Some params force the code to be complicated while
it could be highly simplified when guessing the param value correctly.

LpSolit


From john at redux.org.uk  Wed Sep  5 13:29:45 2007
From: john at redux.org.uk (John Beranek)
Date: Wed, 05 Sep 2007 14:29:45 +0100
Subject: Results of the discussion about parameters removal
In-Reply-To: <46DDD545.6000904@gmail.com>
References: <46DDD545.6000904@gmail.com>
Message-ID: <46DEAF49.404@redux.org.uk>

Fr?d?ric Buclin wrote:
> Hi all,
> 
> The Bugzilla meeting ended right now with 18 people attending today
> (probably a record), and we are going towards the removal of 23
> parameters(!). You can see our decisions on this page:
> 
> http://wiki.mozilla.org/Bugzilla:Params

I wonder how you can make decisions like this without actually polling
your users? Perhaps at least on the support list?

There are far more users of Bugzilla than there are developers that read
this list, and the diversity of those users could certainly mean that
they would have reasons that particular parameters are an absolute
necessity, something which you've not thought of yourself.

I've already brought up possible issues with removing sslbase, and
looking at your list I see others that may cause issues. A particular
one is cookie path - on another project I work on the cookie path was
worked out from the PHP_SELF variable (admittedly different than getting
 it from urlbase in Bugzilla but stick with me), and this caused issues
with a particular setup where the web app was fetched through a proxying
setup, which masked the real path from the actual path. What I had to do
is add a cookie path override config parameter. If Bugzilla were to
remove its cookie path config parameter similar configurations may then
start to fail...not really the friendliest thing to do to the user...

Just my tuppence.

John.

-- 
John Beranek                         To generalise is to be an idiot.
http://redux.org.uk/                                 -- William Blake



From lpsolit at gmail.com  Wed Sep  5 13:39:56 2007
From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=)
Date: Wed, 05 Sep 2007 15:39:56 +0200
Subject: Results of the discussion about parameters removal
In-Reply-To: <46DEAF49.404@redux.org.uk>
References: <46DDD545.6000904@gmail.com> <46DEAF49.404@redux.org.uk>
Message-ID: <46DEB1AC.6070906@gmail.com>

John Beranek a ?crit :
> I wonder how you can make decisions like this without actually polling
> your users? Perhaps at least on the support list?


We already started talking about params per email last week, and as I
said, we give one month to discuss if something should be kept. Without
an initial discussion/decision, it's hard for people to comment.

LpSolit


From bugzilla at colinogilvie.co.uk  Wed Sep  5 14:28:53 2007
From: bugzilla at colinogilvie.co.uk (Colin Ogilvie)
Date: Wed, 05 Sep 2007 15:28:53 +0100
Subject: Results of the discussion about parameters removal
In-Reply-To: <46DDD545.6000904@gmail.com>
References: <46DDD545.6000904@gmail.com>
Message-ID: <46DEBD25.3020700@colinogilvie.co.uk>

Fr?d?ric Buclin wrote:
> Note that a few parameters will be
> replaced by a constant so that you still have a way to edit them if you
> really want to/have to. But most of the ones we want to remove will be
> simply killed.

Shouldn't we find some 'better' way of doing it that doesn't mean having 
to edit the file each time you update?


From bugreport at peshkin.net  Wed Sep  5 14:58:17 2007
From: bugreport at peshkin.net (Joel Peshkin)
Date: Wed, 5 Sep 2007 07:58:17 -0700 (PDT)
Subject: Results of the discussion about parameters removal
In-Reply-To: <46DEBD25.3020700@colinogilvie.co.uk>
References: <46DDD545.6000904@gmail.com>
    <46DEBD25.3020700@colinogilvie.co.uk>
Message-ID: <59279.206.169.229.170.1189004297.squirrel@peshkin.net>

> Fr?d?ric Buclin wrote:
>> Note that a few parameters will be
>> replaced by a constant so that you still have a way to edit them if you
>> really want to/have to. But most of the ones we want to remove will be
>> simply killed.
>
> Shouldn't we find some 'better' way of doing it that doesn't mean having
> to edit the file each time you update?
> -

This sounds like a case where we should provide a file that sets the
defaults so the user can copy to their own location.  So, if we provide
"settings.pl", the user can provide "settings.pl.local" and override those
settings.

This file could look like...


# DO NOT EDIT THIS ORIGINAL FILE (settings.pl)
# Copy this file to settings.pl.local and make changes there

package Settings;   # is there a better way to set a namespace?

# usermatchmode can be search, none, or wildcard
$usermatchmode = 'search';

# cookiepath, if not specified will be inferred from urlbase
# $cookiepath = '/';

# ...etc...
1;





From lpsolit at gmail.com  Wed Sep  5 15:42:14 2007
From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=)
Date: Wed, 05 Sep 2007 17:42:14 +0200
Subject: Results of the discussion about parameters removal
In-Reply-To: <59279.206.169.229.170.1189004297.squirrel@peshkin.net>
References: <46DDD545.6000904@gmail.com>    <46DEBD25.3020700@colinogilvie.co.uk> <59279.206.169.229.170.1189004297.squirrel@peshkin.net>
Message-ID: <46DECE56.2090802@gmail.com>

Note that only 2 params will be replaced by a constant. The other 21
params will be removed. Not sure we want to implement settings.pl.local
for 2 exceptions only.

LpSolit


From bugzilla at colinogilvie.co.uk  Wed Sep  5 16:06:55 2007
From: bugzilla at colinogilvie.co.uk (Colin Ogilvie)
Date: Wed, 05 Sep 2007 17:06:55 +0100
Subject: Results of the discussion about parameters removal
In-Reply-To: <46DECE56.2090802@gmail.com>
References: <46DDD545.6000904@gmail.com>    <46DEBD25.3020700@colinogilvie.co.uk> <59279.206.169.229.170.1189004297.squirrel@peshkin.net> <46DECE56.2090802@gmail.com>
Message-ID: <46DED41F.9040000@colinogilvie.co.uk>

Fr?d?ric Buclin wrote:
> Note that only 2 params will be replaced by a constant. The other 21
> params will be removed. Not sure we want to implement settings.pl.local
> for 2 exceptions only.
>   

Not sure we should remove them then... if they are the ones we are 
expecting people to want to change (by providing a constant) we should 
give them the scope without breaking upgrades for them.

Colin


From mkanat at bugzilla.org  Wed Sep  5 19:44:58 2007
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Wed, 5 Sep 2007 12:44:58 -0700
Subject: Results of the discussion about parameters removal
In-Reply-To: <46DED41F.9040000@colinogilvie.co.uk>
References: <46DDD545.6000904@gmail.com>
	<46DEBD25.3020700@colinogilvie.co.uk>
	<59279.206.169.229.170.1189004297.squirrel@peshkin.net>
	<46DECE56.2090802@gmail.com>
	<46DED41F.9040000@colinogilvie.co.uk>
Message-ID: <20070905194459.D53D185000A@help.trusthosting.net>

On Wed, 05 Sep 2007 17:06:55 +0100 Colin Ogilvie
<bugzilla at colinogilvie.co.uk> wrote:
> Not sure we should remove them then... if they are the ones we are 
> expecting people to want to change (by providing a constant) we
> should give them the scope without breaking upgrades for them.

	We are expecting an extremely minor fraction of installations
to change them. Thus constants are acceptable.

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


From fergus at yahoo-inc.com  Wed Sep  5 19:49:28 2007
From: fergus at yahoo-inc.com (Fergus Sullivan)
Date: Wed, 5 Sep 2007 12:49:28 -0700
Subject: Bugzilla, Yahoo and SCM interfaces
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: <ECF7A6AE-55ED-48E6-B696-D283BB33D44E@yahoo-inc.com>

I missed the following in the thread on Yahoo's use of Bugzilla and  
our integration with other systems.  Sorry for the delayed response,  
Kristis.

On Wed 29-Aug-07, at 1p44 , Kristis Makris wrote:

> 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/

Until last year, Yahoo used its own custom email gateway to allow  
mails to be sent to our Bugzilla instance.  (We now use the vanilla  
Bugzilla.org gateway, with a few small tweaks.)

An early expansion of this was a set of CVS hooks whereby anything  
checked into our CVS with a commit message of "[bug 1234] Foo" would  
add the comment "Foo" to bug 1234.  This soon expanded to allow "[fix  
bug 1234] I am fixing this bug" would also mark the bug as resolved  
fixed.  These instructions would be sent from our CVS repository to  
Bugzilla via our email gateway.  In each case we'd include a link to  
a viewcvs page showing the diffs of all files impacted.

Fast forward a few years, through a few corporate acquisitions, and  
we realize the following:
   - Email is not a good machine-to-machine messaging system.
   - We need much better auditing and controls of check-ins.
   - Parts of the company use CVS, but some use Perforce, and some  
use Subversion.  Some use a different CVS repository.  Some use a  
different instance of Bugzilla.
   - We have a legal requirement to follow the life-cycle of revenue- 
impacting code.
   - We need process, Dagnabit!

Accordingly, a large division of yahoo (although not the entire  
company) implements the following rules.
1) You can only check in code if you reference a bug when doing so.
2) You can only check in code for a bug that is assigned to you.
3) You can only check in code on a branch that corresponds to the  
target milestone of the bug.  We maintain a mapping of these  
relationships.

Obviously, this cannot be achieved using the old email interface, so  
instead we built web services connecting source code with bugzilla.

So our current Bugzilla interface with SCM is a mixture of of email  
and web services.  Some projects have permissive check-in policies,  
some restrictive.  And we have three different SCM technologies.  We  
have merged our multiple Bugzilla instances.

In the future, we plan to integrate Bugzilla and SCM more tightly  
with automated builds and automated testing.  The nirvana, of course,  
is to have failed regression tests automatically open or reopen the  
appropriate bug, and newly passing tests to annotate that fact in  
bugzilla.

Thus any solution we use needs to be sufficiently modular to allow  
for acquisitions and changes in coding practice.

I can't properly comment on Scmbag without exploring it more fully.   
It certainly looks as though it shares many of the same goals as our  
own initial implementation.  I very much like the idea of a  
many::many relationship between scm and bug tracking system.  Yahoo's  
implementation will need to be properly rationalized at some point in  
the next year so we'll certainly come back and look more closely at  
Scmbag then.

   /ferg

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


From bugzilla at colinogilvie.co.uk  Wed Sep  5 20:00:00 2007
From: bugzilla at colinogilvie.co.uk (Colin Ogilvie)
Date: Wed, 05 Sep 2007 21:00:00 +0100
Subject: Results of the discussion about parameters removal
In-Reply-To: <20070905194459.D53D185000A@help.trusthosting.net>
References: <46DDD545.6000904@gmail.com>	<46DEBD25.3020700@colinogilvie.co.uk>	<59279.206.169.229.170.1189004297.squirrel@peshkin.net>	<46DECE56.2090802@gmail.com>	<46DED41F.9040000@colinogilvie.co.uk> <20070905194459.D53D185000A@help.trusthosting.net>
Message-ID: <46DF0AC0.5000906@colinogilvie.co.uk>

Max Kanat-Alexander wrote:
> 	We are expecting an extremely minor fraction of installations
> to change them. Thus constants are acceptable.
>   

Based on what evidence? Do we know how many installations have
customised them?

Surely the goal is to make it easier for people to upgrade -- forcing
them to change something that we ship, and could (potentially) break
their upgrade path seems to me to be a VERY bad idea.

Colin



From bugreport at peshkin.net  Wed Sep  5 20:22:32 2007
From: bugreport at peshkin.net (Joel Peshkin)
Date: Wed, 5 Sep 2007 13:22:32 -0700 (PDT)
Subject: Bugzilla, Yahoo and SCM interfaces
In-Reply-To: <ECF7A6AE-55ED-48E6-B696-D283BB33D44E@yahoo-inc.com>
References: <6EC47187-7F9E-4C19-9701-8FB03254AEAE@yahoo-inc.com>
    <20070829194853.C68AD85000A@help.trusthosting.net>
    <1188420270.4107.8.camel@localhost>
    <ECF7A6AE-55ED-48E6-B696-D283BB33D44E@yahoo-inc.com>
Message-ID: <42297.206.169.229.170.1189023752.squirrel@peshkin.net>



I've made some hacks to bonsai (which shares database formats with
viewcvs2, I believe) so that Bugzilla can create a URL for bonsai's
query.cgi with ?bug=xxxxx and bonsai shows the checkins that have comments
mentioning that bug number.

It's pretty hacky, but someone could build on it if they like.




From mkanat at bugzilla.org  Wed Sep  5 20:56:15 2007
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Wed, 5 Sep 2007 13:56:15 -0700
Subject: Results of the discussion about parameters removal
In-Reply-To: <46DF0AC0.5000906@colinogilvie.co.uk>
References: <46DDD545.6000904@gmail.com>
	<46DEBD25.3020700@colinogilvie.co.uk>
	<59279.206.169.229.170.1189004297.squirrel@peshkin.net>
	<46DECE56.2090802@gmail.com>
	<46DED41F.9040000@colinogilvie.co.uk>
	<20070905194459.D53D185000A@help.trusthosting.net>
	<46DF0AC0.5000906@colinogilvie.co.uk>
Message-ID: <20070905205616.E6E8185000A@help.trusthosting.net>

On Wed, 05 Sep 2007 21:00:00 +0100 Colin Ogilvie
<bugzilla at colinogilvie.co.uk> wrote:
> Based on what evidence? Do we know how many installations have
> customised them?

	I personally have installed and configured Bugzilla at many
different organizations. LpSolit, myself, and the other developers
involved in the discussion have also been providing Bugzilla support to
many, many people for many, many years.

> Surely the goal is to make it easier for people to upgrade -- forcing
> them to change something that we ship, and could (potentially) break
> their upgrade path seems to me to be a VERY bad idea.

	The goal is to make our code simpler and the UI easier to use.
If only a tiny fraction of people are using the parameters, making life
ever-so-slightly difficult for that tiny fraction is OK as long as we
note it in the Release Notes.

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


From bugreport at peshkin.net  Wed Sep  5 21:35:42 2007
From: bugreport at peshkin.net (Joel Peshkin)
Date: Wed, 5 Sep 2007 14:35:42 -0700 (PDT)
Subject: Results of the discussion about parameters removal
In-Reply-To: <20070905205616.E6E8185000A@help.trusthosting.net>
References: <46DDD545.6000904@gmail.com>
    <46DEBD25.3020700@colinogilvie.co.uk>
    <59279.206.169.229.170.1189004297.squirrel@peshkin.net>
    <46DECE56.2090802@gmail.com> <46DED41F.9040000@colinogilvie.co.uk>
    <20070905194459.D53D185000A@help.trusthosting.net>
    <46DF0AC0.5000906@colinogilvie.co.uk>
    <20070905205616.E6E8185000A@help.trusthosting.net>
Message-ID: <39935.206.169.229.170.1189028142.squirrel@peshkin.net>


Actually, I think that
a) we should have checksetup warn users if they had non-default settings
for any parameters that are going away.
b) I have used wildcard usermatchmode (rather than search) at several
sites and it has been required.



> On Wed, 05 Sep 2007 21:00:00 +0100 Colin Ogilvie
> <bugzilla at colinogilvie.co.uk> wrote:
>> Based on what evidence? Do we know how many installations have
>> customised them?
>
> 	I personally have installed and configured Bugzilla at many
> different organizations. LpSolit, myself, and the other developers
> involved in the discussion have also been providing Bugzilla support to
> many, many people for many, many years.
>





From bugzilla at colinogilvie.co.uk  Wed Sep  5 21:18:47 2007
From: bugzilla at colinogilvie.co.uk (Colin Ogilvie)
Date: Wed, 05 Sep 2007 22:18:47 +0100
Subject: Results of the discussion about parameters removal
In-Reply-To: <20070905205616.E6E8185000A@help.trusthosting.net>
References: <46DDD545.6000904@gmail.com>	<46DEBD25.3020700@colinogilvie.co.uk>	<59279.206.169.229.170.1189004297.squirrel@peshkin.net>	<46DECE56.2090802@gmail.com>	<46DED41F.9040000@colinogilvie.co.uk>	<20070905194459.D53D185000A@help.trusthosting.net>	<46DF0AC0.5000906@colinogilvie.co.uk> <20070905205616.E6E8185000A@help.trusthosting.net>
Message-ID: <46DF1D37.9000402@colinogilvie.co.uk>

Max Kanat-Alexander wrote:
> 	The goal is to make our code simpler and the UI easier to use.
> If only a tiny fraction of people are using the parameters, making life
> ever-so-slightly difficult for that tiny fraction is OK as long as we
> note it in the Release Notes.
>   

Moving two parameters to a constant doesn't seem worth it - it won't
make the code any simpler (since the parameters will still exist) and I
doubt it will make the UI any easier to use... and if the UI being
easier to use is an argument for removing two parameters then I would
suggest that we have more important things to be worrying about.

Colin




From gerv at mozilla.org  Thu Sep  6 09:30:04 2007
From: gerv at mozilla.org (Gervase Markham)
Date: Thu, 06 Sep 2007 10:30:04 +0100
Subject: Prefs Removal Proposal
In-Reply-To: <D85E06673A2DFF44B221CF78D1CBB11B0182BF3A@SSVLEXMB1.amd.com>
References: <46D59A28.1040207@mozilla.org> <e75283b10708290931t5d929735m8bd195608d13d815@mail.gmail.com> <46D5A10D.1030407@mozilla.org> <46DDB67E.9060904@redux.org.uk> <46DDCF89.2090502@mozilla.org> <AE51B5B9-18DB-47A0-AF44-3BAB00A44928@yahoo-inc.com> <D85E06673A2DFF44B221CF78D1CBB11B0182BF3A@SSVLEXMB1.amd.com>
Message-ID: <46DFC89C.2020202@mozilla.org>

Benton, Kevin wrote:
> Okay - I have to ask - what is the real advantage of making Bugzilla
> "less" configurable than it has been previously?  

People asked the same question about Firefox with respect to the Mozilla 
Suite.

> There seems to be
> enough people out there that would really not like to see urlbase and
> sslbase removed from Bugzilla.

No-one is suggesting removing urlbase.

Gerv


From gerv at mozilla.org  Thu Sep  6 09:34:01 2007
From: gerv at mozilla.org (Gervase Markham)
Date: Thu, 06 Sep 2007 10:34:01 +0100
Subject: Bugzilla, Yahoo and SCM interfaces
In-Reply-To: <ECF7A6AE-55ED-48E6-B696-D283BB33D44E@yahoo-inc.com>
References: <6EC47187-7F9E-4C19-9701-8FB03254AEAE@yahoo-inc.com> <20070829194853.C68AD85000A@help.trusthosting.net> <1188420270.4107.8.camel@localhost> <ECF7A6AE-55ED-48E6-B696-D283BB33D44E@yahoo-inc.com>
Message-ID: <46DFC989.4090609@mozilla.org>

Fergus Sullivan wrote:
> The nirvana, of course, is to 
> have failed regression tests automatically open or reopen the 
> appropriate bug, and newly passing tests to annotate that fact in bugzilla.

Just a small comment: I'm not completely sure that's an "of course". The 
amount of work, configuration and mapping required to make this sort of 
thing happen seems likely to be much greater than the effort expended in 
opening and closing bugs manually.

Just a thought...

Gerv


From gerv at mozilla.org  Thu Sep  6 09:39:21 2007
From: gerv at mozilla.org (Gervase Markham)
Date: Thu, 06 Sep 2007 10:39:21 +0100
Subject: Results of the discussion about parameters removal
In-Reply-To: <46DDD545.6000904@gmail.com>
References: <46DDD545.6000904@gmail.com>
Message-ID: <46DFCAC9.3050205@mozilla.org>

Fr?d?ric Buclin wrote:
> http://wiki.mozilla.org/Bugzilla:Params

Is discussion continuing here on the list, or on the wiki?

We should rename "Required Settings" to something else, because none are 
Required any more.

Gerv


From Jesse.J.Clark at nasa.gov  Fri Sep  7 23:52:31 2007
From: Jesse.J.Clark at nasa.gov (Jesse J. Clark)
Date: Fri, 7 Sep 2007 16:52:31 -0700
Subject: Self-Introduction: Jesse Clark
Message-ID: <1C8BC237-0294-4AE4-BCC7-B60556C096FD@nasa.gov>

== Full legal name ==
Jesse J Clark


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


== City, Country ==
Mountain View, California, United States


== Profession or Student status ==
Computer Scientist, Civil Servant


== Company, School, or other affiliation ==
HCI Group at NASA Ames Research Center
http://hci.arc.nasa.gov/


== What do you want to help out with? ==
We have modified Bugzilla to manage Problem Reporting and Corrective  
Action (PRACA) data at NASA, and would like to contribute  
improvements back to the main Bugzilla codebase. Max Kanat-Alexander  
has helped us with many of these things and I am sure he will  
appreciate our efforts to make them more modular and generalizable.

Among the changes we have made:

- UI improvements such as AJAX field changes, tabbed bug display  
pages, resizing text entry fields.

- Reworking of interfaces for search, reports, saved searches, and  
whines.

- Customizable field titles, which may help with internationalization  
and large product bases.


== Historical qualifications ==
I have a Bachelor's degree in Computer Science from Carnegie Mellon  
University and have extensive network programming and Unix admin  
experience. I have been working at NASA for the last three years.

Recently, I have written a Perl-DL interpreter to convert legacy  
(1965-1975) binary satellite image data into modern formats such as HDF.

Less recently, I have written a Perl-Tk frontend to a database of  
medical data, allowing patient records to be sent to any of several  
applications from a single UI.



From mkanat at bugzilla.org  Tue Sep 11 06:45:02 2007
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Mon, 10 Sep 2007 23:45:02 -0700
Subject: Self-Introduction: Jesse Clark
In-Reply-To: <1C8BC237-0294-4AE4-BCC7-B60556C096FD@nasa.gov>
References: <1C8BC237-0294-4AE4-BCC7-B60556C096FD@nasa.gov>
Message-ID: <20070910234502.7516d82f@es-compy>

	Hey Jesse! I've said hi to you on IRC already, but welcome! :-)
We're glad to have you contributing to Bugzilla. :-)

	Do you guys have some plan on the order in which you want to
contribute things back?

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


From mkanat at bugzilla.org  Tue Sep 11 06:47:54 2007
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Mon, 10 Sep 2007 23:47:54 -0700
Subject: Fixed The Checksetup Tinderbox
Message-ID: <20070910234754.71f9f74a@es-compy>

	Hey all. So, anybody who hangs out in IRC or watches the
Tinderboxes knows that the MySQL checksetup tinderbox dies all the time
for no reason.

	Basically the tinderbox client machine has to copy the tip
database and the 3.0-branch database from landfill (the tinderbox
clients aren't actually on landfill, they're on a separate VM), and
MySQL gets a little unreliable there and mysqldump dies for no reason,
sometimes, while copying the databases.

	I've modified that particular tinderbox to retry the copies up
to three times each before giving up, so now the tinderbox should work
just fine.

	So from now on, if you see the checksetup tinderbox burn, that
really means it's burning. :-)

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


From oliveroyston at hotmail.com  Tue Sep 11 09:27:48 2007
From: oliveroyston at hotmail.com (Oliver Oyston)
Date: Tue, 11 Sep 2007 09:27:48 +0000
Subject: Self-Introduction: Oliver Oyston
Message-ID: <BAY124-W5399A854BA660E24507EBDD4C10@phx.gbl>


Oliver Oyston


Leeds, United Kingdom


Technical Specialist for Luminary Solutions


I want to help out with making Bugzilla compatible with the Ingres RDBMS. 

 

My technical background is mainly Microsoft technologies (SQL Server,
C#, ASP). I also have knowledge of web design and the associated
technologies. I am currently contracted out to Otto UK Ltd where I am
working on oli.co.uk, grattan.co.uk, freemans.com along with the
companies other catalogue websites. 

 

I have a Masters degree in Theoretical Physics.


My Perl and Ingres knowledge are not the best in the world (yet!),
but I have a strong technical background and would really like to get
involved in the open source community. 


I'm going to try and take ownership of bug 249400, "Make Bugzilla's
SQL compatible with Ingres". It is only a P4 bug, but it is in a field
that I am interested in. I work for Luminary Solutions, the leading
Ingres services provider in the United Kingdom, and so I will be able
to get help and advice from my colleagues if necessary.

 

Thanks,

 

Oliver Oyston

_________________________________________________________________
Feel like a local wherever you go.
http://www.backofmyhand.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20070911/3f5a2ec0/attachment.html>

From dkl at redhat.com  Tue Sep 11 18:48:02 2007
From: dkl at redhat.com (Dave Lawrence)
Date: Tue, 11 Sep 2007 14:48:02 -0400
Subject: Self-Introduction: David Lawrence
Message-ID: <46E6E2E2.1080409@redhat.com>

== Full legal name ==
David K. Lawrence

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

== City, Country ==
Raleigh, North Carolina USA

== Profession or Student status ==
Software Engineer, Part-time College Student

== Company, School, or other affiliation ==
Red Hat, Inc.
http://www.redhat.com
https://bugzilla.redhat.com

== What do you want to help out with? ==
We are using a heavily customized version of 2.18 for most of our
internal development bug tracking. We just recently moved from a 
PostgreSQL based backend to a MySQL backend mainly for the more robust 
replication ability. We hope to continue on our plan to migrate to the 
3.x codebase in the next few months. Currently we are working on some 
performance optimizations in our current code base to address some 
usability concerns with the UI. We are currently pushing some of 
Bugzilla's limits in number of products, components, etc. and are 
testing new features utilizing Ajax to help speed some parts of the UI. 
We host the Fedora project in our instance of Bugzilla and just that 
product alone has over 5500 components.

We also utilize a custom XMLRPC API pretty heavily within the company. 
Using the API, many of our departments have written custom applications 
to help manage their bugs and processes. We are planning on converting 
all of our XMLRPC code to the new 3.x WebServices code during our 
development and to submit patches for the changes for review.
Also the Ajax functionality will be ported over. We will be working very 
hard to make all of these changes as generic as possible and submit all 
patches upstream so that they might be incorporated into the mainline 
3.x codebase.

We also hope to improve our interaction with the Bugzilla community in 
the coming months. We have several people to help out with Bugzilla now 
full-time whereas in the past it has been hard due to resource 
restraints to help out as much as we wanted.

== Historical qualifications ==
I have been maintaining our company instance of Bugzilla on and off for 
the last 8 years. I originally converted our instance to work on Oracle
for a while in hopes of integrating with our corporate support database.
Then when we came out with our own database product called Red Hat 
Database based on PostgreSQL we decided to convert Bugzilla to work with 
that where we stayed until recently. I also created our current
Hardware Certification database (https://hardware.redhat.com) which is 
using Bugzilla as it's backend with heavily customized templates on
the frontend. I have worked with other departments as well to help 
Bugzilla communicate with their tracking tools. Many of our internal
applications also communicate with Bugzilla for single sign on 
authentication. I have also spent some of my time working on RHTS ( Red 
Hat Test System) which is our automated testing framework for the 
distribution. For a stretch I headed up our QA efforts in testing a RHEL
update release which took me away from Bugzilla for a while.

I look forward to working with my team and the Bugzilla community
in the future.

David Lawrence
Red Hat, Inc.


From jochen.wiedmann at gmail.com  Tue Sep 11 19:09:03 2007
From: jochen.wiedmann at gmail.com (Jochen Wiedmann)
Date: Tue, 11 Sep 2007 21:09:03 +0200
Subject: Self-Introduction: David Lawrence
In-Reply-To: <46E6E2E2.1080409@redhat.com>
References: <46E6E2E2.1080409@redhat.com>
Message-ID: <e75283b10709111209p7ab487f9q62d04a064c36620b@mail.gmail.com>

On 9/11/07, Dave Lawrence <dkl at redhat.com> wrote:

> Bugzilla communicate with their tracking tools. Many of our internal
> applications also communicate with Bugzilla for single sign on
> authentication.

May I ask, whether you've got something better than mod_authn_bugzilla
(see bug 392482)? If so, are you interested in sharing it?

Thanks,

Jochen


-- 
Look, that's why there's rules, understand? So that you think before
you break 'em.

    -- (Terry Pratchett, Thief of Time)


From mkanat at bugzilla.org  Tue Sep 11 19:56:22 2007
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Tue, 11 Sep 2007 12:56:22 -0700
Subject: Self-Introduction: Oliver Oyston
In-Reply-To: <BAY124-W5399A854BA660E24507EBDD4C10@phx.gbl>
References: <BAY124-W5399A854BA660E24507EBDD4C10@phx.gbl>
Message-ID: <20070911125622.0715cc9f@es-compy>

On Tue, 11 Sep 2007 09:27:48 +0000 Oliver Oyston
<oliveroyston at hotmail.com> wrote:
> I want to help out with making Bugzilla compatible with the Ingres
> RDBMS. 

	Hey, wow! Sure, we'd love to have support for it, as long as
you're willing to stick around and support it after it's in.

	Any questions you have, feel free to ask me, I'm the DB "owner"
for Bugzilla. I'm "mkanat" on IRC.

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


From dkl at redhat.com  Tue Sep 11 20:40:31 2007
From: dkl at redhat.com (Dave Lawrence)
Date: Tue, 11 Sep 2007 16:40:31 -0400
Subject: Self-Introduction: David Lawrence
In-Reply-To: <e75283b10709111209p7ab487f9q62d04a064c36620b@mail.gmail.com>
References: <46E6E2E2.1080409@redhat.com> <e75283b10709111209p7ab487f9q62d04a064c36620b@mail.gmail.com>
Message-ID: <46E6FD3F.5000208@redhat.com>

No, but that does look promising for when we go to 3.x. Currently we 
just have the
external applications use their respective xmlrpc client to connect to 
bugzilla.login($username, $password)
which simply auths the user and then returns the same cookies that would 
be returned if using the
web UI. The calling client caches these cookies or passes them on to the 
browser connecting
to the external app. Then when the user connects again to the external 
app, it gets the login cookies,
remaps the domain to the Bugzilla server's and calls bugzilla.login() 
again (minus any parameters)
which will use the passed cookies. Or they can call any other xmlrpc 
method that is exported
using the cookies instead of passing in a username and password.

Dave


Jochen Wiedmann wrote:
> On 9/11/07, Dave Lawrence <dkl at redhat.com> wrote:
>
>   
>> Bugzilla communicate with their tracking tools. Many of our internal
>> applications also communicate with Bugzilla for single sign on
>> authentication.
>>     
>
> May I ask, whether you've got something better than mod_authn_bugzilla
> (see bug 392482)? If so, are you interested in sharing it?
>
> Thanks,
>
> Jochen
>
>
>   

-- 
David Lawrence, RHCE  dkl at redhat.com
------------------------------------
Red Hat, Inc.    Web: www.redhat.com
1801 Varsity Drive Raleigh, NC 27606




From altlist at gmail.com  Tue Sep 11 21:47:14 2007
From: altlist at gmail.com (Albert Ting)
Date: Tue, 11 Sep 2007 14:47:14 -0700
Subject: Self-Introduction: Albert Ting
Message-ID: <3e89616e0709111447i4b90a272o5f1a2848768a4dfc@mail.gmail.com>

== Full name ==
Albert Ting

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

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

== Profession or Student status ==
Software Manager

== Company, School, or other affiliation ==
ARM, PIPD division

== What do you want to help out with? ==
Enterprise level enhancements

== Historical qualifications ==
Got a BS in electrical engineering, computer engineering, and math.  Then a
MS in electrical and computer engineering.  Started out as a chip designer
to gain hardware design experience before switching over to software
development.

My main desire is software automation, currently in the EDA industry.  Have
deployed applications in a various languages: java, python, perl, c, php,
scheme/lisp, etc., even a little ocaml and bliss.  Notice I didn't mention
C++, I rarely need it!  I have a blast working in other OOP/AOP/MOP
environments.

I deployed Bugzilla in a previous company, back in 2002, and then we got
bought out by ARM.  Have been enhancing BZ to become a more enterprise level
system.  My main contribution has been the Bugzilla Classification feature.


== Anything else you'd like to say ==

Even though I am a manager, I am the only Bugzilla developer for our server,
it is my "side" job.  But I should get more resource allocations as this
becomes part of my group charter.

Our Bugzilla is now integrated with our customer-side ticket system.  In
particular, BZ auto-syncs a selected list of
products/components/versions/etc.  Of course, BZ holds a fair number of
internal-only products.   At this point, we have ~600 products, ~700 users.
I expect the product count to increase significantly when we start
synchronizing all the products.  We also make good use of email_in and bug
aliases.

I find the quality of the Bugzilla code stream to be excellent, hence tend
to use the latest releases.  It also helps that our system is intranet
only.  Yes, there are bugs, but they can be patched up until they're
permanently fixed.  We're currently using a customized 3.1+ in production.
And I'm glad that I can use the custom status workflow.  The system works
great!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20070911/9fbdf58e/attachment.html>

From mkanat at bugzilla.org  Tue Sep 11 23:29:31 2007
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Tue, 11 Sep 2007 16:29:31 -0700
Subject: Seeking Part-Time Bugzilla Contractors
Message-ID: <20070911162931.1ec921e5@es-compy>

	Everything Solved, Inc. does professional Bugzilla
customizations for large and small companies around the world. We have
lots of clients, we just need more engineers!

	If you work for Everything Solved, you would be a contractor.
You can work from home, at whatever time you want, as long as your code
is delivered on time. The work isn't guaranteed to be any particular
number of hours per week, but it's unlikely to ever be more than 20
hours.

	As we expand more, if your code is of good quality, we will
have more and more work for you.

	All your work will be reviewed by me or another professional
Bugzilla reviewer before being submitted to any client, so this is also
a great chance to brush up on your Perl/Bugzilla skills.

	To be considered as a possible contractor, submit an example
of Bugzilla customizations or other Perl code that you have developed
to bugzilla-job at everythingsolved.com. You may also want to include a
resume and a description of your skills & experience as a Perl or
Bugzilla developer.

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


From timello at gmail.com  Wed Sep 12 14:24:04 2007
From: timello at gmail.com (Tiago)
Date: Wed, 12 Sep 2007 11:24:04 -0300
Subject: How templates hooks are suppose to work?
Message-ID: <975214730709120724w2f5cc145pdc0ae7a1a144053e@mail.gmail.com>

Hi guys,

I'm experiencing some problems with Bugzilla template hooks.

Here are some points:

1. I cannot make it work as described in the documentation
(http://www.bugzilla.org/docs/tip/html/cust-hooks.html). It says the
templates for the hooks need to be located in
"BUGZILLA_ROOT/extensions/projman/template/en/hook/global/useful-links-edit.html.tmpl",
but it only works if we remove the hook directory from the structure
and looking at the code we really miss the 'hook' in the
Template::Plugin::Hook line:

....

my $extensiontemplate =
$subpath.'/'.$templatename.'-'.$hook_name.'.'.$type.'.tmpl';
my @extensions = glob(bz_locations()->{'extensionsdir'} . "/*");
my @usedlanguages = getLanguages();
foreach my $extension (@extensions) {
    foreach my $language (@usedlanguages) {
        my $file = $extension.'/template/'.$language.'/'.$extensiontemplate;
        if (-e $file) {
.....

Then, it expects something like:
BUGZILLA_ROOT/extensions/my_extension/template/en/global/useful-links-end.html.tmpl,
where 'end' is the name of the hook in the template
useful-links.html.tmpl.

2. If I use the structure in the
BUGZILLA_ROOT/template/en/extension/... the checksetup.pl complains
and show the error message:

file error - hook/global/useful-links.html.tmpl/end/foo.html.tmpl: not found

On this structure it only works if you put it in:
BUGZILLA_ROOT/template/en/default/hook/global/useful-links.html.tmpl/end/foo.html.tmpl
as well as in the custom directory.

My questions are:

1. How exactly the hooks for templates are suppose to work?
2. Why does the directory BUGZILLA_ROOT/template/en/extension exist?
Why checksetup.pl complains if we put something there?
3. Can you help me indentify the bugs we have here?

Thank you very much in advance,

Tiago - timello


From oliveroyston at hotmail.com  Tue Sep 11 09:10:17 2007
From: oliveroyston at hotmail.com (Oliver Oyston)
Date: Tue, 11 Sep 2007 09:10:17 +0000
Subject: Self-Introduction: Oliver Oyston
Message-ID: <BAY124-W212929B1866968DD846AA4D4C10@phx.gbl>







Oliver Oyston


Leeds, United Kingdom


Technical Specialist for Luminary Solutions


I want to help out with making Bugzilla compatible with the Ingres RDBMS. 

 

My technical background is mainly Microsoft technologies (SQL Server, C#, ASP). I also have knowledge of web design and the associated technologies. I am currently contracted out to Otto UK Ltd where I am working on oli.co.uk, grattan.co.uk, freemans.com along with the companies other catalogue websites. 

 

I have a Masters degree in Theoretical Physics.


My Perl and Ingres knowledge are not the best in the world (yet!), but I have a strong technical background and would really like to get involved in the open source community. 


I'm going to try and take ownership of bug 249400, "Make Bugzilla's SQL compatible with Ingres". It is only a P4 bug, but it is in a field that I am interested in. I work for Luminary Solutions, the leading Ingres services provider in the United Kingdom, and so I will be able to get help and advice from my colleagues if necessary.

 

Thanks,

 

Oliver Oyston


_________________________________________________________________
Celeb spotting ? Play CelebMashup and win cool prizes
https://www.celebmashup.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20070911/a4607b72/attachment.html>

From mkanat at bugzilla.org  Fri Sep 21 02:31:51 2007
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Thu, 20 Sep 2007 19:31:51 -0700
Subject: Backups for landfill
Message-ID: <20070920193151.55b3bde3@es-compy>

	landfill now has daily and monthly backups on a server outside
of its data center. It will keep 10 days of daily backups, and 3
monthly backups.

	Certain things are not backed up, but all of /home/
and /var/www/ are definitely backed up. (With the exception of a few
gigantic but unimportant things in /home/, and all of mxr in /var/www).

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


From minaavictor at hotmail.com  Mon Sep 24 13:20:59 2007
From: minaavictor at hotmail.com (Mina Amin)
Date: Mon, 24 Sep 2007 13:20:59 +0000
Subject: java xml-rpc
Message-ID: <BAY114-W21DB8A2AB21966185F8EC9B0B60@phx.gbl>

Dear all ...
   I'm developing a bugzilla client under java application that use bugzilla xml-rpc API, when using the "User.login" method a cast exception occurs.. any help
 
NOTE: i'm using java 6 with apach xml-rpc library
 
 
_________________________________________________________________
Capture your memories in an online journal!
http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20070924/dd2282ca/attachment.html>

From mkanat at bugzilla.org  Mon Sep 24 23:17:21 2007
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Mon, 24 Sep 2007 16:17:21 -0700
Subject: java xml-rpc
In-Reply-To: <BAY114-W21DB8A2AB21966185F8EC9B0B60@phx.gbl>
References: <BAY114-W21DB8A2AB21966185F8EC9B0B60@phx.gbl>
Message-ID: <20070924161721.7dd411a6@es-compy>

On Mon, 24 Sep 2007 13:20:59 +0000 Mina Amin <minaavictor at hotmail.com>
wrote:
>    I'm developing a bugzilla client under java application that use
> bugzilla xml-rpc API, when using the "User.login" method a cast
> exception occurs.. any help NOTE: i'm using java 6 with apach xml-rpc
> library 

	You're going to have to be way more specific than that. Show us
what code you wrote, and show us the exact error.

	Also, you're probably better off asking the people who wrote
the library, instead of us. As long as you're following the Bugzilla
API, you should be fine. Just realize that all arguments are a hash (a
Map in Java terms).

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


From jochen.wiedmann at gmail.com  Mon Sep 24 23:27:31 2007
From: jochen.wiedmann at gmail.com (Jochen Wiedmann)
Date: Tue, 25 Sep 2007 01:27:31 +0200
Subject: java xml-rpc
In-Reply-To: <20070924161721.7dd411a6@es-compy>
References: <BAY114-W21DB8A2AB21966185F8EC9B0B60@phx.gbl>
	 <20070924161721.7dd411a6@es-compy>
Message-ID: <e75283b10709241627i1520d323x3feac4222af5558@mail.gmail.com>

On 9/25/07, Max Kanat-Alexander <mkanat at bugzilla.org> wrote:

>         Also, you're probably better off asking the people who wrote
> the library, instead of us. As long as you're following the Bugzilla
> API, you should be fine. Just realize that all arguments are a hash (a
> Map in Java terms).

Depends. I am the author of the latest version of Apache XML-RPC, and
am listening here. There seems to be a problem indeed, whether its in
the Bugzilla code or in the Apache XML-RPC code, I do not know.
However, this is the third such bug report I've seen.

In both previous cases, I asked the reporters for traces generated
with Wireshark or tcpmon, but never got such a trace.


Jochen


-- 
Look, that's why there's rules, understand? So that you think before
you break 'em.

    -- (Terry Pratchett, Thief of Time)


From nelhawar at redhat.com  Wed Sep 26 01:08:36 2007
From: nelhawar at redhat.com (Noura Elhawary)
Date: Wed, 26 Sep 2007 11:08:36 +1000
Subject: Self-Introduction: Noura Elhawary
Message-ID: <1190768917.4000.2.camel@dhcp-64-210.bne.redhat.com>

== Full legal name ==
Noura Elhawary

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

== City, Country ==
Brisbane, Queensland Australia

== Profession or Student status ==
Web Engineer

== Company, School, or other affiliation ==
Red Hat, Inc.
http://www.redhat.com
https://bugzilla.redhat.com

== What do you want to help out with? ==
We have just finished migrating our Red Hat Bugzilla version 2.18 from
Postgres to Mysql. We are planning to upgrade to version 3.x in the next
few months. As XMLRPC API is used quite heavily in our company we are
planning to upgrade our currently customized XMLRPC code to the new 3.x
WebServices code. We will try to make our changes generic as much as we
can and submit all our patches upstream. Also we will be changing our
Bugzilla code to comply with the code standards for upstream Bugzilla
and its Developer's Guide.

== Historical qualifications ==
I am a recent University Graduate with Bachelor of Information
Technology. I joined Red Hat January 2007. Since then I have been
working on Bugzilla Database migration from Postgres to mysql project.
I got quite familiar with the Bugzilla Application in its both sides UI
and XMLRPC.

I look forward to working with my team and the Bugzilla community
in the future.

Noura Elhawary
Red Hat, Inc.



From mbd at dbc.dk  Mon Sep 24 14:01:45 2007
From: mbd at dbc.dk (Mads Bondo Dydensborg)
Date: Mon, 24 Sep 2007 16:01:45 +0200
Subject: java xml-rpc
In-Reply-To: <BAY114-W21DB8A2AB21966185F8EC9B0B60@phx.gbl>
References: <BAY114-W21DB8A2AB21966185F8EC9B0B60@phx.gbl>
Message-ID: <200709241601.45282.mbd@dbc.dk>

mandag 24 September 2007 skrev Mina Amin:
> Dear all ...
>    I'm developing a bugzilla client under java application that use bugzilla 
xml-rpc API, when using the "User.login" method a cast exception occurs.. any 
help

The text of the exception would probably be helpful.

Regards,

Mads

-- 
Med venlig hilsen/Regards

Systemudvikler/Systemsdeveloper cand.scient.dat, Ph.d., Mads Bondo Dydensborg
Dansk BiblioteksCenter A/S, Tempovej 7-11, 2750 Ballerup, Tlf. +45 44 86 77 34


From minaavictor at hotmail.com  Tue Sep 25 14:09:43 2007
From: minaavictor at hotmail.com (Mina Amin)
Date: Tue, 25 Sep 2007 14:09:43 +0000
Subject: java xml-rpc
Message-ID: <BAY114-W1345D45002A552A5FDED63B0B70@phx.gbl>

This is the code, i use to invoke the Bugzilla API, also I'm using version 3.0.1 and when invoking the Version API it return the it correctly.but the problem with the User.login API. XmlRpcClientConfigImpl config = new XmlRpcClientConfigImpl();
config.setServerURL(new URL("http://<VMware virtual IP>/bugzilla/xmlrpc.cgi"));
 
XmlRpcClient client = new XmlRpcClient();client.setConfig(config);
 
Object result = client.execute("User.login", new Object[] {"mina at bugzilla.com", "password"});System.out.println(result);Note that execute takes a list or object[] as its second parameter.and the exception is 
Exception in thread "main" java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Integer
at org.apache.xmlrpc.parser.XmlRpcResponseParser.addResult(XmlRpcResponseParser.java:58)
at org.apache.xmlrpc.parser.RecursiveTypeParserImpl.endValueTag(RecursiveTypeParserImpl.java:71)
at org.apache.xmlrpc.parser.XmlRpcResponseParser.endElement(XmlRpcResponseParser.java:183)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
at org.apache.xmlrpc.client.XmlRpcStreamTransport.readResponse(XmlRpcStreamTransport.java:175)
at org.apache.xmlrpc.client.XmlRpcStreamTransport.sendRequest(XmlRpcStreamTransport.java:145)
at org.apache.xmlrpc.client.XmlRpcHttpTransport.sendRequest(XmlRpcHttpTransport.java:94)
at org.apache.xmlrpc.client.XmlRpcSunHttpTransport.sendRequest(XmlRpcSunHttpTransport.java:44)
at org.apache.xmlrpc.client.XmlRpcClientWorker.execute(XmlRpcClientWorker.java:53)
at org.apache.xmlrpc.client.XmlRpcClient.execute(XmlRpcClient.java:166)
at org.apache.xmlrpc.client.XmlRpcClient.execute(XmlRpcClient.java:136)
at org.apache.xmlrpc.client.XmlRpcClient.execute(XmlRpcClient.java:125)at com.newportmediainc.bzc.executer.BZCApplication.main(BZCApplication.java:31) and the TCP dump using wiresharkfaultString
Can't use string ("<email account>") as a HASH ref while "strict refs" in use at Bugzilla/WebService/User.pm line 39.\nfaultcode 
server // i think this is the problem as it must return a numerical code.
I believe that the problem in how to send a parameters with the method name. so if anyone did it via java and apach xml-rpc please give a hand.
 
thx.
 
Mina

> Date: Mon, 24 Sep 2007 16:17:21 -0700> From: mkanat at bugzilla.org> To: developers at bugzilla.org> Subject: Re: java xml-rpc> > On Mon, 24 Sep 2007 13:20:59 +0000 Mina Amin <minaavictor at hotmail.com>> wrote:> > I'm developing a bugzilla client under java application that use> > bugzilla xml-rpc API, when using the "User.login" method a cast> > exception occurs.. any help NOTE: i'm using java 6 with apach xml-rpc> > library > > You're going to have to be way more specific than that. Show us> what code you wrote, and show us the exact error.> > Also, you're probably better off asking the people who wrote> the library, instead of us. As long as you're following the Bugzilla> API, you should be fine. Just realize that all arguments are a hash (a> Map in Java terms).> > -Max> -- > http://www.everythingsolved.com/> Competent, Friendly Bugzilla Services. And Everything Else, too.
_________________________________________________________________
More photos; more messages; more whatever ? Get MORE with Windows Live? Hotmail?. NOW with 5GB storage.
http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_5G_0907
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20070925/3eb66191/attachment.html>

From jochen.wiedmann at gmail.com  Wed Sep 26 11:52:34 2007
From: jochen.wiedmann at gmail.com (Jochen Wiedmann)
Date: Wed, 26 Sep 2007 13:52:34 +0200
Subject: java xml-rpc
In-Reply-To: <200709241601.45282.mbd@dbc.dk>
References: <BAY114-W21DB8A2AB21966185F8EC9B0B60@phx.gbl>
	 <200709241601.45282.mbd@dbc.dk>
Message-ID: <e75283b10709260452ta68868fgc59e167a84f09c82@mail.gmail.com>

On 9/24/07, Mads Bondo Dydensborg <mbd at dbc.dk> wrote:

> The text of the exception would probably be helpful.

The exception is a ClassCastException. I do not know, whether Bugzilla
produces wrong output (causing Apache XML-RPC to cast the object to a
wrong type) or whether the bug is in Apache XML-RPC. That's the reason
I am asking for a trace of the HTTP traffic.

Jochen

-- 
Look, that's why there's rules, understand? So that you think before
you break 'em.

    -- (Terry Pratchett, Thief of Time)


From mkanat at bugzilla.org  Wed Sep 26 12:18:09 2007
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Wed, 26 Sep 2007 05:18:09 -0700
Subject: java xml-rpc
In-Reply-To: <BAY114-W1345D45002A552A5FDED63B0B70@phx.gbl>
References: <BAY114-W1345D45002A552A5FDED63B0B70@phx.gbl>
Message-ID: <20070926051809.0581c767@es-compy>

On Tue, 25 Sep 2007 14:09:43 +0000 Mina Amin <minaavictor at hotmail.com>
wrote:
> IP>client.execute("User.login", new Object[] {"mina at bugzilla.com",
> IP>"password"});

	Like I said, User.login takes *named* parameters, not
positional parameters.

> faultString Can't use string ("<email
> account>") as a HASH ref while "strict refs" in use at
> account>Bugzilla/WebService/User.pm line 39.\nfaultcode server // i

	And on top of that, something isn't processing the returned
fault properly.

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


From mbd at dbc.dk  Thu Sep 27 06:51:56 2007
From: mbd at dbc.dk (Mads Bondo Dydensborg)
Date: Thu, 27 Sep 2007 08:51:56 +0200
Subject: java xml-rpc
In-Reply-To: <20070926051809.0581c767@es-compy>
References: <BAY114-W1345D45002A552A5FDED63B0B70@phx.gbl> <20070926051809.0581c767@es-compy>
Message-ID: <200709270851.56465.mbd@dbc.dk>

onsdag 26 September 2007 skrev Max Kanat-Alexander:
> On Tue, 25 Sep 2007 14:09:43 +0000 Mina Amin <minaavictor at hotmail.com>
> wrote:

> > faultString Can't use string ("<email
> > account>") as a HASH ref while "strict refs" in use at
> > account>Bugzilla/WebService/User.pm line 39.\nfaultcode server // i
> 
> 	And on top of that, something isn't processing the returned
> fault properly.

Are you sure about this? The fault is an perl semantics error - are you sure 
that an error _number_ is returned in this case?

I ask, because I seem to recall having similar problems with the .net stuff I 
made.

I agree that the arguments are not passed correctly.

Mads

-- 
Med venlig hilsen/Regards

Systemudvikler/Systemsdeveloper cand.scient.dat, Ph.d., Mads Bondo Dydensborg
Dansk BiblioteksCenter A/S, Tempovej 7-11, 2750 Ballerup, Tlf. +45 44 86 77 34


From mkanat at bugzilla.org  Thu Sep 27 07:14:14 2007
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Thu, 27 Sep 2007 00:14:14 -0700
Subject: java xml-rpc
In-Reply-To: <200709270851.56465.mbd@dbc.dk>
References: <BAY114-W1345D45002A552A5FDED63B0B70@phx.gbl>
	<20070926051809.0581c767@es-compy>
	<200709270851.56465.mbd@dbc.dk>
Message-ID: <20070927001414.1c8a72fc@es-compy>

On Thu, 27 Sep 2007 08:51:56 +0200 Mads Bondo Dydensborg <mbd at dbc.dk>
wrote:
> Are you sure about this? The fault is an perl semantics error - are
> you sure that an error _number_ is returned in this case?

	Hrm...I wonder, actually. You know, you might be on to
something. I don't think we actually install a $SIG{__DIE__} handler,
and we should!

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


From lpsolit at gmail.com  Thu Sep 27 19:03:46 2007
From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=)
Date: Thu, 27 Sep 2007 21:03:46 +0200
Subject: Bugzilla meeting on Tuesday, October 2 at 18:00 GMT
Message-ID: <46FBFE92.5010002@gmail.com>

Hi all,

We will meet again on IRC next Tuesday, October 2 at 11:00 PST (18:00
GMT, 20:00 CEST) in the #bugzilla-meeting channel. The meeting is public
and everybody is free to attend. We are getting closer to the freezing
date for Bugzilla 3.2, so tell us soon enough if something important
should land for 3.2 RC1. Features which won't be implemented on time
will be delayed till Bugzilla 4.0.

See you soon,

LpSolit


From christian.masopust at siemens.com  Fri Sep 28 10:34:15 2007
From: christian.masopust at siemens.com (Masopust, Christian)
Date: Fri, 28 Sep 2007 12:34:15 +0200
Subject: Best way to move Product....
Message-ID: <60721B67EAF0994EAFFB561767B700140125DAC3@nets13ha.ww300.siemens.net>

.... from one Bugzilla-Database to another.
 
Hi all,
 
is there a way to move a whole product from one Bugzilla to an other??
 
Thanks a lot,
Christian
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20070928/90a403d5/attachment.html>

From mkanat at bugzilla.org  Fri Sep 28 22:24:24 2007
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Fri, 28 Sep 2007 15:24:24 -0700
Subject: Best way to move Product....
In-Reply-To: <60721B67EAF0994EAFFB561767B700140125DAC3@nets13ha.ww300.siemens.net>
References: <60721B67EAF0994EAFFB561767B700140125DAC3@nets13ha.ww300.siemens.net>
Message-ID: <20070928152424.0de5edf9@es-compy>

On Fri, 28 Sep 2007 12:34:15 +0200 "Masopust, Christian"
<christian.masopust at siemens.com> wrote:
> is there a way to move a whole product from one Bugzilla to an other??

	Hi Christian. This question belongs on the support list, and
I've answered it there. You can find out about the support list here:

	http://www.bugzilla.org/support/

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