From saadsj at gmail.com  Tue Jul  1 04:55:04 2008
From: saadsj at gmail.com (Scott Saad)
Date: Mon, 30 Jun 2008 22:55:04 -0600
Subject: WebServices: quick code walk through
In-Reply-To: <20080630020639.5d305ef3@es-compy>
References: <f597d8f90806292217w77d33cb9me5f64f5210ac67a0@mail.gmail.com>
	 <20080630020639.5d305ef3@es-compy>
Message-ID: <f597d8f90806302155v6104bad6sdf449e93058e67e1@mail.gmail.com>

Hi Max,

I spent some time today looking through the code, starting with the
xmlrpc.cgi. Your walk through did help lead me in the right direction. Thank
you for that.

Please bare with me for a bit while I try and familiarize myself with the
code base and surrounding environment. Sometimes I feel that having some way
to debug or test the code is a great way to help the learning process. Can
you recommend ways of doing this? Meaning, can a debugger be used, or test
environments setup to help step through code, etc?

Any help would be greatly appreciated.

Best regards,
Scott

On Mon, Jun 30, 2008 at 3:06 AM, Max Kanat-Alexander <mkanat at bugzilla.org>
wrote:

> On Sun, 29 Jun 2008 23:17:11 -0600 "Scott Saad" <saadsj at gmail.com>
> wrote:
> > If this is not the right forum for a question like this, please let
> > me know. Would IRC be better?
>
>         Hey Scott. Yeah, catch me on IRC (mkanat). This is a more
> interactive sort of question.
>
>        But as a start, xmlrpc.cgi is:
>
>        1) Making sure that extensions (in the extensions/ dir) can
> add their own WebServices plugins.
>
>        2) Logging the current user in (on_action).
>
>        3) Calling the correct code from a module in the
> Bugzilla/WebServices/ directory (handle()).
>
>        -Max
> --
> http://www.everythingsolved.com/
> Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=saadsj at gmail.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20080630/b5ed9498/attachment.html>

From mkanat at bugzilla.org  Tue Jul  1 05:09:09 2008
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Mon, 30 Jun 2008 22:09:09 -0700
Subject: WebServices: quick code walk through
In-Reply-To: <f597d8f90806302155v6104bad6sdf449e93058e67e1@mail.gmail.com>
References: <f597d8f90806292217w77d33cb9me5f64f5210ac67a0@mail.gmail.com>
	<20080630020639.5d305ef3@es-compy>
	<f597d8f90806302155v6104bad6sdf449e93058e67e1@mail.gmail.com>
Message-ID: <20080630220909.5d2895ba@es-compy>

On Mon, 30 Jun 2008 22:55:04 -0600 "Scott Saad" <saadsj at gmail.com>
wrote:
> I spent some time today looking through the code, starting with the
> xmlrpc.cgi. Your walk through did help lead me in the right
> direction. Thank you for that.

	Great. :-)

> Please bare with me for a bit while I try and familiarize myself with
> the code base and surrounding environment.

	No problem, that's always the way it is with a new project. I
myself am working on another project these days where there's a LOT to
learn, and so I know exactly what you're talking about.

> Sometimes I feel that
> having some way to debug or test the code is a great way to help the
> learning process. Can you recommend ways of doing this? Meaning, can
> a debugger be used, or test environments setup to help step through
> code, etc?

	There's nothing that makes this very easy with raw Perl in the
web server. If you want to see data structures, you can use
Data::Dumper like:

	use Data::Dumper; print Dumper($some_var)

	It's also usable in the templates through the Dumper plugin for
Template Toolkit (documented on the template toolkit site).

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


From paul.craciunoiu at gmail.com  Tue Jul  1 17:40:11 2008
From: paul.craciunoiu at gmail.com (paulc)
Date: Tue, 1 Jul 2008 10:40:11 -0700 (PDT)
Subject: QMO + Bugzilla + Drupal
Message-ID: <6fe4023e-c8a1-41ab-ad27-ab6865cad4e5@r37g2000prm.googlegroups.com>

Hi all,

I'm an intern at Mozilla, trying to set up a Drupal module for QMO
(quality.mozilla.org).
Shortly put, this module needs to gather data from Bugzilla and
generate useful charts that would help the QA team (and hopefully not
just). Some feedback from the kind of charts the QA team wants is
available at
http://wiki.mozilla.org/QA/Community/QMO_Bugzilla
I'll be working on this with Jay Patel, my mentor for the summer.

One idea I've had so far was to parse the XML output of Bugzilla and
store it in a QMO database. Then query that database on each page
display to generate the charts listed above. This works wonderfully if
I can get all the information I need in one query. Easily enough, I
could get the bugs changed for the past 24 hours each day and make
sure that the QMO module stays up to date.

However, some of these charts may require some fields that are not
displayed by default in bug listings, does anyone know a way to get
more (or all) information on bugs, a quicker way than just by parsing
each bug by id, or doing a new query listing? For example, if I'd like
to know when a bug's keywords have changed, when it's been marked as a
regression, etc.

I'm open to any help, suggestions and ideas. This project has just
started and I'm working more on implementing the functionality in the
module itself than getting the content from Bugzilla, so please take a
stab at how I should proceed.

Thanks a bunch!
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla


From lpsolit at gmail.com  Tue Jul  1 17:43:15 2008
From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=)
Date: Tue, 01 Jul 2008 19:43:15 +0200
Subject: WebServices: quick code walk through
In-Reply-To: <20080630220909.5d2895ba@es-compy>
References: <f597d8f90806292217w77d33cb9me5f64f5210ac67a0@mail.gmail.com>	<20080630020639.5d305ef3@es-compy>	<f597d8f90806302155v6104bad6sdf449e93058e67e1@mail.gmail.com> <20080630220909.5d2895ba@es-compy>
Message-ID: <486A6CB3.4090405@gmail.com>

Max Kanat-Alexander a ?crit :
> 	No problem, that's always the way it is with a new project. I
> myself am working on another project these days where there's a LOT to
> learn, and so I know exactly what you're talking about.

Firefox or Thunderbird? Maybe SOAP::Lite? :-D



From lpsolit at gmail.com  Tue Jul  1 19:05:35 2008
From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=)
Date: Tue, 01 Jul 2008 21:05:35 +0200
Subject: QMO + Bugzilla + Drupal
In-Reply-To: <6fe4023e-c8a1-41ab-ad27-ab6865cad4e5@r37g2000prm.googlegroups.com>
References: <6fe4023e-c8a1-41ab-ad27-ab6865cad4e5@r37g2000prm.googlegroups.com>
Message-ID: <486A7FFF.7000106@gmail.com>

paulc a ?crit :
> to know when a bug's keywords have changed, when it's been marked as a
> regression, etc.

You need an API which is not available in Bugzilla 3.0.4 (the version 
used by b.m.o). get_history() is only available in Bugzilla 3.2 RC1 and 
higher. You probably have to wait for b.m.o to upgrade (or parse the 
HTML page).

LpSolit



From paul.craciunoiu at gmail.com  Wed Jul  2 20:47:05 2008
From: paul.craciunoiu at gmail.com (paulc)
Date: Wed, 2 Jul 2008 13:47:05 -0700 (PDT)
Subject: QMO + Bugzilla + Drupal
References: <6fe4023e-c8a1-41ab-ad27-ab6865cad4e5@r37g2000prm.googlegroups.com>
	<mailman.35.1214949144.16855.dev-apps-bugzilla@lists.mozilla.org>
Message-ID: <faabf3fe-4e48-4755-a7cc-f42382ee03f0@i36g2000prf.googlegroups.com>

On Jul 1, 12:05?pm, Fr?d?ric Buclin <lpso... at gmail.com> wrote:
> paulc a ?crit :
>
> > to know when a bug's keywords have changed, when it's been marked as a
> > regression, etc.
>
> You need an API which is not available in Bugzilla 3.0.4 (the version
> used by b.m.o). get_history() is only available in Bugzilla 3.2 RC1 and
> higher. You probably have to wait for b.m.o to upgrade (or parse the
> HTML page).
>
> LpSolit
>
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=dev-apps-bugzi... at lists.mozilla.org>

Thanks for that, I'll try to keep it flexible and open for when the
update comes, it's probably the easiest and best solution with regard
to that kind of history.
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla


From mkanat at bugzilla.org  Wed Jul  2 21:07:19 2008
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Wed, 2 Jul 2008 14:07:19 -0700
Subject: QMO + Bugzilla + Drupal
In-Reply-To: <486A7FFF.7000106@gmail.com>
References: <6fe4023e-c8a1-41ab-ad27-ab6865cad4e5@r37g2000prm.googlegroups.com>
	<486A7FFF.7000106@gmail.com>
Message-ID: <20080702140719.5d169864@es-compy>

On Tue, 01 Jul 2008 21:05:35 +0200 Fr?d?ric Buclin <lpsolit at gmail.com>
wrote:
> get_history() is only available in Bugzilla 3.2 RC1
> and higher. You probably have to wait for b.m.o to upgrade (or parse
> the HTML page).

	Actually, I'm pretty sure get_history is only going to be in
4.0.

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


From saadsj at gmail.com  Wed Jul  2 22:20:16 2008
From: saadsj at gmail.com (Scott Saad)
Date: Wed, 2 Jul 2008 16:20:16 -0600
Subject: (seemingly) simple but useful WebService expansion?
Message-ID: <f597d8f90807021520r570b8000xdeb2733c1864030f@mail.gmail.com>

Hello,

I would like to kick around an idea for the WebServices API. The past few
days I've been familiarizing myself with the code base. I've also been
trying to search the for existing WebService enhancement requests to see if
what I'm proposing is already covered for a future release. If what I'm
about to say happens to already be planned, please forgive me :-).

Use Case:
Developer X would like to create some type of client side application that
uses the WebService API for Bugzilla. Currently, limited bug information
comes back to the client. (i.e. created, changed, alias, summary) when a
call to Bug.get is made. Plus, the developer must somehow know the list of
bug ID's before making this call. The interest really lies in bugs for
particular products and a query for bugs by product would be very helpful.
With this ability, along with expanded bug information, the usability
becomes more in line with the client as the filtering can now be done on the
client side. This is of course opposed to waiting for the ultimate query API
to be ready, where filtering occurs on the server side.

Proposal:
* There already exists a way to get all products. An enhancement to allow
for the querying of bugs by product (i.e. Bug.getAllByProduct) could be
implemented.
* Expand the WebService:Bug class to include a more complete set of fields.
This would mean including data like, status, assigned_to, priority,
severity, etc.
* With this type of call, the ability for clients to consume valuable bug
information and filtering in the manner it sees fit becomes a possibility.

Disclaimer:
I definitely have not thought this all the way through and being new with
internals of the system I wanted to throw the idea across the wire in hopes
of getting feedback. I debated on whether or not to log an enhancement
request for this because I'm not sure if it's in line with the road map. I
think there are definitely plans to expand the API but this might be a
stepping stone to that expansion. In my opinion, the usefulness of the API
goes through the roof with this type of access. It provides real value with
seeminly tiny impact.

Now, I don't really know if enabling something like this is really "tiny",
but with my limited knowledge and exploration, this is my ignorant claim.

Any thoughts/suggestions/clarifcations would be greatly appreciated.

Best regards,
Scott Saad (saadware)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20080702/783625d4/attachment.html>

From mkanat at bugzilla.org  Wed Jul  2 22:31:57 2008
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Wed, 2 Jul 2008 15:31:57 -0700
Subject: (seemingly) simple but useful WebService expansion?
In-Reply-To: <f597d8f90807021520r570b8000xdeb2733c1864030f@mail.gmail.com>
References: <f597d8f90807021520r570b8000xdeb2733c1864030f@mail.gmail.com>
Message-ID: <20080702153157.035c093f@es-compy>

	Hey Scott! Wow, very detailed there. :-) No need to write quite
that much, we're relatively informal--you're free to just say, "Hey, I
think we should add X to Y, sound good?"

	My responses below:

On Wed, 2 Jul 2008 16:20:16 -0600 "Scott Saad" <saadsj at gmail.com> wrote:
> and a query for bugs by product would be very helpful.

	The problem is that I don't want, in the future, two ways to do
the same thing--that can be pretty confusing. Bug.search (or whatever
we're calling it) will get that information for us, so I don't want to
add another way to get it. We can't remove functions once we add
them--that breaks the API--so we have to be careful about what we add.

> * Expand the WebService:Bug class to include a more complete set of
> fields. This would mean including data like, status, assigned_to,
> priority, severity, etc.

	Sure, that'd be good. I already have a patch that does that
somewhere, I might have even attached it to a bug.

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


From autogbler at yahoo.de  Wed Jul  2 22:35:06 2008
From: autogbler at yahoo.de (=?iso-8859-1?Q?ricardo_G=E4bler?=)
Date: Thu, 3 Jul 2008 00:35:06 +0200
Subject: No subject
Message-ID: <001401c8dc93$e92b9570$6402a8c0@nl51wyiup8upiv>


_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla


From autogbler at yahoo.de  Wed Jul  2 22:46:39 2008
From: autogbler at yahoo.de (=?iso-8859-1?Q?ricardo_G=E4bler?=)
Date: Thu, 3 Jul 2008 00:46:39 +0200
Subject: No subject
Message-ID: <00a701c8dc96$402daf00$6402a8c0@nl51wyiup8upiv>


_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla


From autogbler at yahoo.de  Wed Jul  2 22:51:54 2008
From: autogbler at yahoo.de (=?iso-8859-1?Q?ricardo_G=E4bler?=)
Date: Thu, 3 Jul 2008 00:51:54 +0200
Subject: No subject
Message-ID: <00a801c8dc96$40e53f30$6402a8c0@nl51wyiup8upiv>


_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla


From dhanya.shanthi at gmail.com  Thu Jul  3 06:06:33 2008
From: dhanya.shanthi at gmail.com (dhanya)
Date: Wed, 2 Jul 2008 23:06:33 -0700
Subject: QMO + Bugzilla + Drupal
In-Reply-To: <6fe4023e-c8a1-41ab-ad27-ab6865cad4e5@r37g2000prm.googlegroups.com>
References: <6fe4023e-c8a1-41ab-ad27-ab6865cad4e5@r37g2000prm.googlegroups.com>
Message-ID: <TOudnSDCAt7v8fHVnZ2dnUVZ_vGdnZ2d@mozilla.org>


"paulc" <paul.craciunoiu at gmail.com> wrote in message 
news:6fe4023e-c8a1-41ab-ad27-ab6865cad4e5 at r37g2000prm.googlegroups.com...
> Hi all,
>
> I'm an intern at Mozilla, trying to set up a Drupal module for QMO
> (quality.mozilla.org).
> Shortly put, this module needs to gather data from Bugzilla and
> generate useful charts that would help the QA team (and hopefully not
> just). Some feedback from the kind of charts the QA team wants is
> available at
> http://wiki.mozilla.org/QA/Community/QMO_Bugzilla
> I'll be working on this with Jay Patel, my mentor for the summer.
>
> One idea I've had so far was to parse the XML output of Bugzilla and
> store it in a QMO database. Then query that database on each page
> display to generate the charts listed above. This works wonderfully if
> I can get all the information I need in one query. Easily enough, I
> could get the bugs changed for the past 24 hours each day and make
> sure that the QMO module stays up to date.
>
> However, some of these charts may require some fields that are not
> displayed by default in bug listings, does anyone know a way to get
> more (or all) information on bugs, a quicker way than just by parsing
> each bug by id, or doing a new query listing? For example, if I'd like
> to know when a bug's keywords have changed, when it's been marked as a
> regression, etc.
>
> I'm open to any help, suggestions and ideas. This project has just
> started and I'm working more on implementing the functionality in the
> module itself than getting the content from Bugzilla, so please take a
> stab at how I should proceed.
>
> Thanks a bunch! 

_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla


From dhanya.shanthi at gmail.com  Thu Jul  3 06:07:19 2008
From: dhanya.shanthi at gmail.com (dhanya)
Date: Wed, 2 Jul 2008 23:07:19 -0700
Subject: QMO + Bugzilla + Drupal
In-Reply-To: <6fe4023e-c8a1-41ab-ad27-ab6865cad4e5@r37g2000prm.googlegroups.com>
References: <6fe4023e-c8a1-41ab-ad27-ab6865cad4e5@r37g2000prm.googlegroups.com>
Message-ID: <QJudnSbZd9M-8fHVnZ2dnUVZ_gidnZ2d@mozilla.org>


"paulc" <paul.craciunoiu at gmail.com> wrote in message 
news:6fe4023e-c8a1-41ab-ad27-ab6865cad4e5 at r37g2000prm.googlegroups.com...
> Hi all,
>
> I'm an intern at Mozilla, trying to set up a Drupal module for QMO
> (quality.mozilla.org).
> Shortly put, this module needs to gather data from Bugzilla and
> generate useful charts that would help the QA team (and hopefully not
> just). Some feedback from the kind of charts the QA team wants is
> available at
> http://wiki.mozilla.org/QA/Community/QMO_Bugzilla
> I'll be working on this with Jay Patel, my mentor for the summer.
>
> One idea I've had so far was to parse the XML output of Bugzilla and
> store it in a QMO database. Then query that database on each page
> display to generate the charts listed above. This works wonderfully if
> I can get all the information I need in one query. Easily enough, I
> could get the bugs changed for the past 24 hours each day and make
> sure that the QMO module stays up to date.
>
> However, some of these charts may require some fields that are not
> displayed by default in bug listings, does anyone know a way to get
> more (or all) information on bugs, a quicker way than just by parsing
> each bug by id, or doing a new query listing? For example, if I'd like
> to know when a bug's keywords have changed, when it's been marked as a
> regression, etc.
>
> I'm open to any help, suggestions and ideas. This project has just
> started and I'm working more on implementing the functionality in the
> module itself than getting the content from Bugzilla, so please take a
> stab at how I should proceed.
>
> Thanks a bunch! 

_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla


From saadsj at gmail.com  Thu Jul  3 17:38:02 2008
From: saadsj at gmail.com (Scott Saad)
Date: Thu, 3 Jul 2008 11:38:02 -0600
Subject: (seemingly) simple but useful WebService expansion?
In-Reply-To: <20080702153157.035c093f@es-compy>
References: <f597d8f90807021520r570b8000xdeb2733c1864030f@mail.gmail.com>
	 <20080702153157.035c093f@es-compy>
Message-ID: <f597d8f90807031038v14e1e775j5431d2737e8a12f0@mail.gmail.com>

Sorry about the verbosity on that one, will definitely keep it short and
sweet in the future. :-)

I've been following the conversations at
https://bugzilla.mozilla.org/show_bug.cgi?id=398281:

I understand not wanting to provide more than one way of getting at bug
information. What concerns me is the possibility that the concept of
Bug.search may be overkill. Is there a need to provide an interface that
mimics bugzilla's search? I know from a bugzilla developer's standpoint it's
the natural approach... the more powerful the better. However, what do the
potential users of the API really want? Do they need all that power? Or
would a function for each use case suffice? ie...

   Bug.GetByUserId
   Bug.GetByProductId
   Bug.GetByStatus
   Bug.GetByPriority

or the overall encompassing call: Bug.GetByParams( UserId, ProductId,
Status, Priority ).

With an approach like this would it solve the majority use cases? Again, I
realize that a super powerful search feels great. Could it be overkill? I
say this not really knowing the user base so I could be missing a huge part
of the picture here.

Thoughts?
Scott

On Wed, Jul 2, 2008 at 4:31 PM, Max Kanat-Alexander <mkanat at bugzilla.org>
wrote:

>        Hey Scott! Wow, very detailed there. :-) No need to write quite
> that much, we're relatively informal--you're free to just say, "Hey, I
> think we should add X to Y, sound good?"
>
>        My responses below:
>
> On Wed, 2 Jul 2008 16:20:16 -0600 "Scott Saad" <saadsj at gmail.com> wrote:
> > and a query for bugs by product would be very helpful.
>
>         The problem is that I don't want, in the future, two ways to do
> the same thing--that can be pretty confusing. Bug.search (or whatever
> we're calling it) will get that information for us, so I don't want to
> add another way to get it. We can't remove functions once we add
> them--that breaks the API--so we have to be careful about what we add.
>
> > * Expand the WebService:Bug class to include a more complete set of
> > fields. This would mean including data like, status, assigned_to,
> > priority, severity, etc.
>
>         Sure, that'd be good. I already have a patch that does that
> somewhere, I might have even attached it to a bug.
>
>        -Max
> --
> http://www.everythingsolved.com/
> Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=saadsj at gmail.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20080703/c605a600/attachment.html>

From mkanat at bugzilla.org  Thu Jul  3 19:33:52 2008
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Thu, 3 Jul 2008 12:33:52 -0700
Subject: (seemingly) simple but useful WebService expansion?
In-Reply-To: <f597d8f90807031038v14e1e775j5431d2737e8a12f0@mail.gmail.com>
References: <f597d8f90807021520r570b8000xdeb2733c1864030f@mail.gmail.com>
	<20080702153157.035c093f@es-compy>
	<f597d8f90807031038v14e1e775j5431d2737e8a12f0@mail.gmail.com>
Message-ID: <20080703123352.2a4d7096@es-compy>

On Thu, 3 Jul 2008 11:38:02 -0600 "Scott Saad" <saadsj at gmail.com> wrote:
> Sorry about the verbosity on that one, will definitely keep it short
> and sweet in the future. :-)
> 
> I've been following the conversations at
> https://bugzilla.mozilla.org/show_bug.cgi?id=398281:
> 
> I understand not wanting to provide more than one way of getting at
> bug information. What concerns me is the possibility that the concept
> of Bug.search may be overkill. [snip]

	Hmm. Well, one of the concerns with these sorts of interfaces
is being able to do as much as possible in one call, because there can
be a lot of latency in a single call (particularly for installations
that aren't running under mod_perl).

	Also, the basic case will look pretty simple:

	Bug.search({ match => { product => 'TestProduct' } })

	In normal API design I'd be all with you on the
one-function-one-task design (and in fact that's the way I originally
wanted to design the interface), but because this is a web service, we
need to make our individual functions fairly powerful to be useful to
the clients consuming them (from my experience talking to those
clients). Also, operations have to be atomic (particularly important
with the latency issue) which is only possible in our case with single,
powerful functions.

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


From saadsj at gmail.com  Thu Jul  3 20:33:51 2008
From: saadsj at gmail.com (Scott Saad)
Date: Thu, 3 Jul 2008 14:33:51 -0600
Subject: (seemingly) simple but useful WebService expansion?
In-Reply-To: <20080703123352.2a4d7096@es-compy>
References: <f597d8f90807021520r570b8000xdeb2733c1864030f@mail.gmail.com>
	 <20080702153157.035c093f@es-compy>
	 <f597d8f90807031038v14e1e775j5431d2737e8a12f0@mail.gmail.com>
	 <20080703123352.2a4d7096@es-compy>
Message-ID: <f597d8f90807031333k3b1bdd36y1b47c978130b580e@mail.gmail.com>

OK. I definitely have a more clear understanding of the needs now. Thanks
for take the time to explain. I hope you weren't annoyed too much with my
questions.

After reading more on bug 398281, it seems like this functionality is geared
for a 4.0 target but I'm unclear on the current status. Are there patches
available where things are partially implemented? Is it something I can
contribute to in order to help move things forward?

Thanks,
Scott

On Thu, Jul 3, 2008 at 1:33 PM, Max Kanat-Alexander <mkanat at bugzilla.org>
wrote:

> On Thu, 3 Jul 2008 11:38:02 -0600 "Scott Saad" <saadsj at gmail.com> wrote:
> > Sorry about the verbosity on that one, will definitely keep it short
> > and sweet in the future. :-)
> >
> > I've been following the conversations at
> > https://bugzilla.mozilla.org/show_bug.cgi?id=398281:
> >
> > I understand not wanting to provide more than one way of getting at
> > bug information. What concerns me is the possibility that the concept
> > of Bug.search may be overkill. [snip]
>
>        Hmm. Well, one of the concerns with these sorts of interfaces
> is being able to do as much as possible in one call, because there can
> be a lot of latency in a single call (particularly for installations
> that aren't running under mod_perl).
>
>        Also, the basic case will look pretty simple:
>
>        Bug.search({ match => { product => 'TestProduct' } })
>
>        In normal API design I'd be all with you on the
> one-function-one-task design (and in fact that's the way I originally
> wanted to design the interface), but because this is a web service, we
> need to make our individual functions fairly powerful to be useful to
> the clients consuming them (from my experience talking to those
> clients). Also, operations have to be atomic (particularly important
> with the latency issue) which is only possible in our case with single,
> powerful functions.
>
>        -Max
> --
> http://www.everythingsolved.com/
> Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=saadsj at gmail.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20080703/8972608a/attachment.html>

From mkanat at bugzilla.org  Thu Jul  3 21:47:45 2008
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Thu, 3 Jul 2008 14:47:45 -0700
Subject: (seemingly) simple but useful WebService expansion?
In-Reply-To: <f597d8f90807031333k3b1bdd36y1b47c978130b580e@mail.gmail.com>
References: <f597d8f90807021520r570b8000xdeb2733c1864030f@mail.gmail.com>
	<20080702153157.035c093f@es-compy>
	<f597d8f90807031038v14e1e775j5431d2737e8a12f0@mail.gmail.com>
	<20080703123352.2a4d7096@es-compy>
	<f597d8f90807031333k3b1bdd36y1b47c978130b580e@mail.gmail.com>
Message-ID: <20080703144745.1d66b2e0@es-compy>

On Thu, 3 Jul 2008 14:33:51 -0600 "Scott Saad" <saadsj at gmail.com> wrote:
> OK. I definitely have a more clear understanding of the needs now.
> Thanks for take the time to explain. I hope you weren't annoyed too
> much with my questions.

	Hey Scott. No, I wasn't annoyed at all. They were all very
well-reasoned questions.

> After reading more on bug 398281, it seems like this functionality is
> geared for a 4.0 target but I'm unclear on the current status. Are
> there patches available where things are partially implemented? Is it
> something I can contribute to in order to help move things forward?

	You can ask me about it in IRC if you want, I'm mkanat there.

	I think there's a patch pending review, or I'm waiting for
somebody to put up something that's closer to the simple API I wanted.
(I'm not looking at the bug right now, just saying what I remember off
the top of my head.) If there's a patch pending review, you're free to
look it over and give your suggestions (but prefix them with the fact
that you're not an official reviewer), and otherwise you're free to
write something. :-)

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


From lpsolit at gmail.com  Fri Jul  4 09:00:25 2008
From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=)
Date: Fri, 04 Jul 2008 11:00:25 +0200
Subject: (seemingly) simple but useful WebService expansion?
In-Reply-To: <20080703144745.1d66b2e0@es-compy>
References: <f597d8f90807021520r570b8000xdeb2733c1864030f@mail.gmail.com>	<20080702153157.035c093f@es-compy>	<f597d8f90807031038v14e1e775j5431d2737e8a12f0@mail.gmail.com>	<20080703123352.2a4d7096@es-compy>	<f597d8f90807031333k3b1bdd36y1b47c978130b580e@mail.gmail.com> <20080703144745.1d66b2e0@es-compy>
Message-ID: <486DE6A9.3070005@gmail.com>

Max Kanat-Alexander a ?crit :
> 	I think there's a patch pending review, or I'm waiting for
> somebody to put up something that's closer to the simple API I wanted.
> (I'm not looking at the bug right now, just saying what I remember off
> the top of my head.)

There are several patches attached, but all with r-, which means one can 
read the review comments and take them into account for a new patch.

LpSolit



From autogbler at yahoo.de  Sun Jul  6 21:03:15 2008
From: autogbler at yahoo.de (=?iso-8859-1?Q?ricardo_G=E4bler?=)
Date: Sun, 6 Jul 2008 23:03:15 +0200
Subject: No subject
Message-ID: <004c01c8dfab$b7eb6c40$6402a8c0@nl51wyiup8upiv>


_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla


From autogbler at yahoo.de  Sun Jul  6 21:03:19 2008
From: autogbler at yahoo.de (=?iso-8859-1?Q?ricardo_G=E4bler?=)
Date: Sun, 6 Jul 2008 23:03:19 +0200
Subject: No subject
Message-ID: <004d01c8dfac$7df97ad0$6402a8c0@nl51wyiup8upiv>


_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla


From bugreport at peshkin.net  Tue Jul  8 17:16:40 2008
From: bugreport at peshkin.net (Joel Peshkin)
Date: Tue, 08 Jul 2008 10:16:40 -0700
Subject: Contrib/  Bugzilla Stripping Tool
Message-ID: <4873A0F8.5000407@peshkin.net>

Hi All:

   I'm just in the process of splitting of a set of products that have 
been sold to another company so that there is a copy of the original 
company's Bugzilla containing only the subset of products being sold.

   At the moment, the approach is to
   1) Make a copy
   2) Rename all the products that do NOT go with the new company to 
start with "BYE_"
   3) Run a script full of mysql commands that systematically delete the 
rows of all the tables that are associated with those products' bugs' 
attachment's data, then products' bugs' attachments, then products' 
bugs' longesc, etc......

   I'm doing this for 2.22.*'s schema.  

   I am wondering if this is something that should be made into a more 
general capability and kept up to date as the schema evolves.   If so, I 
would probably use a mechanism like "closed for bug entry" instead of 
renaming the products to indicate which ones should go away. Any thoughts?

-Joel



From mkanat at bugzilla.org  Tue Jul  8 18:31:05 2008
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Tue, 8 Jul 2008 11:31:05 -0700
Subject: Contrib/  Bugzilla Stripping Tool
In-Reply-To: <4873A0F8.5000407@peshkin.net>
References: <4873A0F8.5000407@peshkin.net>
Message-ID: <20080708113105.60d57aaf@es-compy>

On Tue, 08 Jul 2008 10:16:40 -0700 Joel Peshkin <bugreport at peshkin.net>
wrote:
> Any thoughts?

	In 4.0 we'll have foreign keys, which will make that all a lot
easier. You should be able to just delete the product row and have
things go away--though some things you'd have to trace manually.
However, thanks to the FKs you should be able to do that by tracing
through the schema without ever having to update the script again in
the future.

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


From rupert at handfordonline.plus.com  Thu Jul 10 07:47:45 2008
From: rupert at handfordonline.plus.com (rupert at handfordonline.plus.com)
Date: Thu, 10 Jul 2008 08:47:45 +0100 (BST)
Subject: Self-Introduction: Rupert Anthony Handford
Message-ID: <10181.87.112.94.238.1215676065.squirrel@webmail.plus.net>

Name: Rupert Anthony Handford

IRC: N/A at present

Location: Grimsby, United Kingdon. GMT

Profession: IT Developer/Support

Assist with:

I am very keen to assist in any area that you feel would be most appropriate.
I have 14 years experience in programming various languages (Perl, PHP,
ASP, BAsic, Cobol) so I guess I would like to contribute to the code base
if possible.

Background:

21 Years background in the IT environment.
Currently runnng a Suse Linux platform.
Have the attitude that there is nothing you cant do on a computer, it's
just a question of how.
Most web based history is on Intranets or just for personal education.
I would love to contribute to your project so that the hours I spend here
typing away are for the good of all and not just for my entertainment.

I hook forward to hearing from you soon.



From bugzilla at colinogilvie.co.uk  Sun Jul 13 17:17:58 2008
From: bugzilla at colinogilvie.co.uk (Colin Ogilvie)
Date: Sun, 13 Jul 2008 18:17:58 +0100
Subject: Documentation
In-Reply-To: <4865B657.3050704@bugzilla.org>
References: <48652108.2080006@colinogilvie.co.uk> <4865B657.3050704@bugzilla.org>
Message-ID: <487A38C6.4010409@colinogilvie.co.uk>

David Miller wrote:
> XMLTO_Documentation_Branch works for me.

I've started work on this today, and have made some initial checkins for 
https://bugzilla.mozilla.org/show_bug.cgi?id=423496 (all the details are 
on the bug) and by process of this, 2 of the 3 dependant bugs will also 
be resolved if this was committed as is.

Unfortunately, I'm still looking at the PDF stuff as it's still 
producing a load of rubbish to STDERR :(

Colin


From justdave at bugzilla.org  Sun Jul 13 21:39:49 2008
From: justdave at bugzilla.org (David Miller)
Date: Sun, 13 Jul 2008 17:39:49 -0400
Subject: Documentation
In-Reply-To: <487A38C6.4010409@colinogilvie.co.uk>
References: <48652108.2080006@colinogilvie.co.uk> <4865B657.3050704@bugzilla.org> <487A38C6.4010409@colinogilvie.co.uk>
Message-ID: <487A7625.3020500@bugzilla.org>

Colin Ogilvie wrote on 7/13/08 1:17 PM:
> David Miller wrote:
>> XMLTO_Documentation_Branch works for me.
> 
> I've started work on this today, and have made some initial checkins for
> https://bugzilla.mozilla.org/show_bug.cgi?id=423496 (all the details are
> on the bug) and by process of this, 2 of the 3 dependant bugs will also
> be resolved if this was committed as is.
> 
> Unfortunately, I'm still looking at the PDF stuff as it's still
> producing a load of rubbish to STDERR :(

While you're at it, the HTML generation is hanging periodically on the
website.  Seems to be related to it needing to retrieve DTD files off
oasis-open.org in order to build (despite having copies of those files
locally on the machine) and oasis-open.org is rate-limiting us because
we're pulling too much at once (trying to build 3 copies of the docs -
twice for HTML and once for PDF - times 4 to 8 versions of bugzilla that
we have docs on the website for).

Finding a way to make it use the local SGML/XML docbook catalog instead
of retrieving the files off the web might be useful.

In trying to debug this so far I've gotten the impression that if you
declare PUBLIC entity and specify a URL for it, it'll use the URL,
period.  It only looks it up in the catalog if the URL isn't supplied.
I can't find any command-line switches for jade to override that either.
 I haven't tested that theory by removing the URLs yet though.

-- 
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  Sun Jul 13 21:48:30 2008
From: justdave at bugzilla.org (David Miller)
Date: Sun, 13 Jul 2008 17:48:30 -0400
Subject: Self-Introduction: Rupert Anthony Handford
In-Reply-To: <10181.87.112.94.238.1215676065.squirrel@webmail.plus.net>
References: <10181.87.112.94.238.1215676065.squirrel@webmail.plus.net>
Message-ID: <487A782E.4000102@bugzilla.org>

rupert at handfordonline.plus.com wrote on 7/10/08 3:47 AM:
> Name: Rupert Anthony Handford

> I would love to contribute to your project so that the hours I spend here
> typing away are for the good of all and not just for my entertainment.

Welcome!  We'd be happy to have your help.

It's really hard to know what to ask for help with...  What people
really wind up being good at doesn't always line up with what they've
done in the past and we want you to have fun helping, too. :)

There's a bunch of things listed at http://www.bugzilla.org/contribute/

If you've recently installed Bugzilla or been administrating one, the
documentation is one place that really needs help.  Even just pointing
out things that the documentation is missing, even if you leave it for
someone else to write. (Just file bugs on it in the Documentation
component).

If coding is your thing, there's links where to find good bugs to work
on and so forth on http://wiki.mozilla.org/Bugzilla:Developers (which is
probably where you found the request to post here).

Just participating in the discussions here is a good way to stay
involved, too.

-- 
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  Sun Jul 13 22:14:39 2008
From: justdave at bugzilla.org (David Miller)
Date: Sun, 13 Jul 2008 18:14:39 -0400
Subject: Documentation
In-Reply-To: <487A7625.3020500@bugzilla.org>
References: <48652108.2080006@colinogilvie.co.uk> <4865B657.3050704@bugzilla.org> <487A38C6.4010409@colinogilvie.co.uk> <487A7625.3020500@bugzilla.org>
Message-ID: <487A7E4F.2090908@bugzilla.org>

David Miller wrote on 7/13/08 5:39 PM:
> Finding a way to make it use the local SGML/XML docbook catalog instead
> of retrieving the files off the web might be useful.
> 
> In trying to debug this so far I've gotten the impression that if you
> declare PUBLIC entity and specify a URL for it, it'll use the URL,
> period.  It only looks it up in the catalog if the URL isn't supplied.
> I can't find any command-line switches for jade to override that either.
> I haven't tested that theory by removing the URLs yet though.

OK, I just tried this, and that theory is indeed correct.  If I remove
the URL entirely (not even a blank param for it), then it uses the local
files specified by the SGML_CATALOG_FILES environment variable.  If the
URL is there, it hits oasis-open.org to grab all of them.  Just removing
the URL from the 3rd line of Bugzilla-Guide.xml completely eliminated
all network access during the docs build, and the docs still build fine.
(well, except for this stupid warning that happens a bazillion times
with or without the URL:
jade:/usr/share/sgml/docbook/xml-dtd-4.1.2-1.0-30.1/ent/iso-cyr1.ent:6:16:E:
"X0430" is not a function name
)

--- en/xml/Bugzilla-Guide.xml	20 May 2008 20:00:52 -0000	1.79
+++ en/xml/Bugzilla-Guide.xml	13 Jul 2008 21:59:50 -0000
@@ -1,6 +1,5 @@
 <?xml version="1.0"?>
-<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
-
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" [
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" [
     <!ENTITY % myents SYSTEM "bugzilla.ent">
     %myents;



-- 
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  Mon Jul 14 02:03:18 2008
From: justdave at bugzilla.org (David Miller)
Date: Sun, 13 Jul 2008 22:03:18 -0400
Subject: Contrib/  Bugzilla Stripping Tool
In-Reply-To: <4873A0F8.5000407@peshkin.net>
References: <4873A0F8.5000407@peshkin.net>
Message-ID: <487AB3E6.508@bugzilla.org>

Joel Peshkin wrote on 7/8/08 1:16 PM:

>   I'm just in the process of splitting of a set of products that have
> been sold to another company so that there is a copy of the original
> company's Bugzilla containing only the subset of products being sold.
> 
>   At the moment, the approach is to
>   1) Make a copy
>   2) Rename all the products that do NOT go with the new company to
> start with "BYE_"
>   3) Run a script full of mysql commands that systematically delete the
> rows of all the tables that are associated with those products' bugs'
> attachment's data, then products' bugs' attachments, then products'
> bugs' longesc, etc......
> 
>   I'm doing this for 2.22.*'s schema. 
>   I am wondering if this is something that should be made into a more
> general capability and kept up to date as the schema evolves.   If so, I
> would probably use a mechanism like "closed for bug entry" instead of
> renaming the products to indicate which ones should go away. Any thoughts?

We have something similar we've been using at Mozilla to produce
sanitized copies of the database that only include publicly-visible data
to give to researchers to avoid them having to pull xml versions of
every bug in the system to reconstruct it all.  Our version removes all
bugs that are in groups as well as insidergroup stuff and things in
hidden products.

It was originally a bunch of SQL but I ended up converting it to Perl so
I could point it at a copy of Bugzilla and let it use the built-in code
for deleting various things (which takes into account the foreign keys
and so forth).

It's on https://bugzilla.mozilla.org/show_bug.cgi?id=421025

-- 
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  Tue Jul 15 00:55:26 2008
From: justdave at bugzilla.org (David Miller)
Date: Mon, 14 Jul 2008 20:55:26 -0400
Subject: Bugzilla flyer for OSCON
Message-ID: <487BF57E.702@bugzilla.org>

We had some brief talk on IRC a couple weeks ago about updating the
Bugzilla flyer to use at OSCON, but it doesn't seem to have made it to
the mailing list, and I don't know if anything was done.  OSCON is about
a week away and I'd like to get something put together far enough in
advance (like the next day or two) to avoid having to do a last minute
rush order again like we did last year. :)

Last year's flyer is at http://www.justdave.net/BugzillaFlyer.pdf if you
want to see what it looks like, and the source is at
http://www.justdave.net/BugzillaFlyer.odg (OpenOffice Draw format) if
you want to play with it.  Anyone have suggestions for changes to it?
Or should we just update the factual data to reflect the changes since
last year and leave the format alone?

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


From mkanat at bugzilla.org  Tue Jul 15 02:18:18 2008
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Mon, 14 Jul 2008 19:18:18 -0700
Subject: Bugzilla flyer for OSCON
In-Reply-To: <487BF57E.702@bugzilla.org>
References: <487BF57E.702@bugzilla.org>
Message-ID: <20080714191818.394d6714@es-compy>

On Mon, 14 Jul 2008 20:55:26 -0400 David Miller <justdave at bugzilla.org>
wrote:
> Anyone have suggestions for changes to it?
> Or should we just update the factual data to reflect the changes since
> last year and leave the format alone?

	I think the format's pretty good. And actually, pretty much all
the factual data is still the same, too. Maybe we should update the
number of languages available, if that's not right anymore.

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


From justdave at bugzilla.org  Tue Jul 15 02:43:32 2008
From: justdave at bugzilla.org (David Miller)
Date: Mon, 14 Jul 2008 22:43:32 -0400
Subject: Bugzilla flyer for OSCON
In-Reply-To: <20080714191818.394d6714@es-compy>
References: <487BF57E.702@bugzilla.org> <20080714191818.394d6714@es-compy>
Message-ID: <487C0ED4.2070609@bugzilla.org>

Max Kanat-Alexander wrote on 7/14/08 10:18 PM:
> On Mon, 14 Jul 2008 20:55:26 -0400 David Miller <justdave at bugzilla.org>
> wrote:
>> Anyone have suggestions for changes to it?
>> Or should we just update the factual data to reflect the changes since
>> last year and leave the format alone?
> 
> 	I think the format's pretty good. And actually, pretty much all
> the factual data is still the same, too. Maybe we should update the
> number of languages available, if that's not right anymore.

And the databases (Oracle is actually in and not "landing soon" now, right?)

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


From mkanat at bugzilla.org  Tue Jul 15 06:28:20 2008
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Mon, 14 Jul 2008 23:28:20 -0700
Subject: Bugzilla flyer for OSCON
In-Reply-To: <487C0ED4.2070609@bugzilla.org>
References: <487BF57E.702@bugzilla.org>
	<20080714191818.394d6714@es-compy>
	<487C0ED4.2070609@bugzilla.org>
Message-ID: <20080714232820.1f62da84@es-compy>

On Mon, 14 Jul 2008 22:43:32 -0400 David Miller <justdave at bugzilla.org>
wrote:
> And the databases (Oracle is actually in and not "landing soon" now,
> right?)

	Yeah, Oracle is here, though experimental.

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


From bd at bc-bd.org  Tue Jul 15 15:59:22 2008
From: bd at bc-bd.org (bd at bc-bd.org)
Date: Tue, 15 Jul 2008 17:59:22 +0200
Subject: Self-Introduction: Stefan =?iso-8859-1?Q?V?=
	=?iso-8859-1?Q?=F6lkel?=
Message-ID: <20080715155922.GJ3749@hexenkessel.bc>

Name: Stefan V?lkel
IRC: -
Country: Germany

I have been playing with Bugzilla's XML-RPC interface because I want to create a
couple of reports from it.

I found out that it is missing some features I am going to need. Since others
may profit from my changes I want to get them upstream.

Regarding my past, I am working with Linux since roughly 12 years, I have worked
as a Kernel Developer, System Engineer, Administrator, ...

I have written a couple of irssi scripts, a wordpress plugin, half a million
shell scripts (at least it feels like half a million) and I maintain two
packages for debian.

regards

	Stefan
-- 
Linux is obsolete
		-- Andrew Tanenbaum


From craig5 at pobox.com  Tue Jul 15 22:31:21 2008
From: craig5 at pobox.com (Craig)
Date: Tue, 15 Jul 2008 15:31:21 -0700
Subject: API to change milestones
Message-ID: <487D2539.2010900@pobox.com>

I need a way to change (add and delete) milestones via a CLI app. (Most 
likely it will be in perl, but that isn't definite.)

I looked at Bugzilla::WebService::Product, but all of the 
routines/methods are marked as not stable.

What is the "best way" to update milestones for a specific product 
programatically?

Adding it directly to the DB works just fine for me, but I wanted to do 
it using whatever method is "approved". (Makes upgrades easier. :> )

Any thoughts would be appreciated.

TIA!
Craig


From michael.j.tosh at lmco.com  Wed Jul 16 13:09:29 2008
From: michael.j.tosh at lmco.com (Tosh, Michael J)
Date: Wed, 16 Jul 2008 09:09:29 -0400
Subject: API to change milestones
In-Reply-To: <487D2539.2010900@pobox.com>
References: <487D2539.2010900@pobox.com>
Message-ID: <FDB5599B9D4E934C8CFA6C9097D4C9F10CBED69A@emss10m05.us.lmco.com>

Quoting Craig:
> I need a way to change (add and delete) milestones via a CLI app.
> (Most likely it will be in Perl, but that isn't definite.)
> 
> I looked at Bugzilla::WebService::Product, but all of the
> routines/methods are marked as not stable.
> 
> What is the "best way" to update milestones for a specific product
> programatically?
> 
> Adding it directly to the DB works just fine for me, but I wanted to
> do it using whatever method is "approved". (Makes upgrades easier. :>
> ) 

cp editmilestones.cgi editmilestones.pl
Then check each reference to $cgi->params() and read an argument or
<STDIN> instead.

(It would be pretty neat to run:
 "echo delete \n myproduct \n mymilestone \n |editmilestones.pl")

sub prompt_for_field {
    my $field = shift;
    my $value;
    while ($value eq "") {
        print "Enter a value for $field: ";
        chomp($value = <>);
    }
    return $value;
}
my $product_name = prompt_for_field("Product");
my $milestone_name = prompt_for_field("Target Milestone");

Editmilestones.cgi is only 360 or so lines and MUCH of it is comments
and whitespace.  Be sure to submit it as a contrib script for the rest
of us to share! ;-)

(using this script to start with is good because it already has the
Bugzilla structure built in with validation and Bugzilla objects and
much of the hard work is done.)


From paul.craciunoiu at gmail.com  Wed Jul 16 17:05:07 2008
From: paul.craciunoiu at gmail.com (paulc)
Date: Wed, 16 Jul 2008 10:05:07 -0700 (PDT)
Subject: =?ISO-8859-1?Q?Re=3A_Self=2DIntroduction=3A_Stefan_V=F6lkel?=
References: <mailman.371.1216139081.9472.dev-apps-bugzilla@lists.mozilla.org>
Message-ID: <3515b150-deb1-48ee-b026-435846ecc043@y21g2000hsf.googlegroups.com>

On Jul 15, 8:59?am, b... at bc-bd.org wrote:
> Name: Stefan V?lkel
> IRC: -
> Country: Germany
>
> I have been playing with Bugzilla's XML-RPC interface because I want to create a
> couple of reports from it.
>
> I found out that it is missing some features I am going to need. Since others
> may profit from my changes I want to get them upstream.
>
> Regarding my past, I am working with Linux since roughly 12 years, I have worked
> as a Kernel Developer, System Engineer, Administrator, ...
>
> I have written a couple of irssi scripts, a wordpress plugin, half a million
> shell scripts (at least it feels like half a million) and I maintain two
> packages for debian.
>
> regards
>
> ? ? ? ? Stefan
> --
> Linux is obsolete
> ? ? ? ? ? ? ? ? -- Andrew Tanenbaum
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=dev-apps-bugzi... at lists.mozilla.org>

Hi Stefan, glad to meet you!

It sounds like you might be working on something similar to what I'm
trying to do.
See thread here: http://groups.google.com/group/mozilla.dev.apps.bugzilla/browse_thread/thread/a1794cbccdd3f6f2
And a screenshot of the (pre-pre-pre-alpha :) ) Drupal module here:
http://wittyletter.com/upload/qmo_bugs_1.png
The charts are really random data so ignore them, but let me know if
the idea is something you may want to help on.

I've been hired to work on this for the Mozilla QA team anyway.
Hopefully in a few weeks it will be a full working module available on
drupal.org.

Best,
Paul Craciunoiu
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla


From craig5 at pobox.com  Wed Jul 16 23:39:47 2008
From: craig5 at pobox.com (Craig)
Date: Wed, 16 Jul 2008 16:39:47 -0700
Subject: API to change milestones
In-Reply-To: <FDB5599B9D4E934C8CFA6C9097D4C9F10CBED69A@emss10m05.us.lmco.com>
References: <487D2539.2010900@pobox.com> <FDB5599B9D4E934C8CFA6C9097D4C9F10CBED69A@emss10m05.us.lmco.com>
Message-ID: <487E86C3.8010603@pobox.com>

Tosh, Michael J wrote:
> cp editmilestones.cgi editmilestones.pl
> Then check each reference to $cgi->params() and read an argument or
> <STDIN> instead.

Fair enough.

One small issue concerns the login. This is a script that will be run 
from another script and the entire thing is probably going to be 
automated. So, requiring a login/pw is a problem. I was thinking that 
the perl script could look for env var with the desired login to use. 
(Basic idea is to create a generic account for all "automated processes.")

As far as security, I figured that if someone has access to the scripts, 
then they probably have access to "localconfig", which means they can 
cause a lot more damage. Is this a reasonable assumption? (I realize 
that the permissions CAN be different, but I don't know how common that is.)

> (It would be pretty neat to run:
>  "echo delete \n myproduct \n mymilestone \n |editmilestones.pl")

For *my particular case*, it would probably be something like
	editmilestones.pl --add product new-milestone

("editmilestones.pl product" wuld simply give a list of the current 
milestones.)

But, I am more than open to other ideas.

> Editmilestones.cgi is only 360 or so lines and MUCH of it is comments

Ya, it seems pretty straight forward.

> and whitespace.  Be sure to submit it as a contrib script for the rest
> of us to share! ;-)

Of course. :)

> (using this script to start with is good because it already has the
> Bugzilla structure built in with validation and Bugzilla objects and
> much of the hard work is done.)

Definitely. For a newbie to the code, dealing with things like tokens 
was really more than I waned to bite off right now. :)

I'll post the script when I'm done.

Thanx for the help/ideas.

Craig


From michael.j.tosh at lmco.com  Thu Jul 17 16:22:22 2008
From: michael.j.tosh at lmco.com (Tosh, Michael J)
Date: Thu, 17 Jul 2008 12:22:22 -0400
Subject: API to change milestones
In-Reply-To: <487E86C3.8010603@pobox.com>
References: <487D2539.2010900@pobox.com> <FDB5599B9D4E934C8CFA6C9097D4C9F10CBED69A@emss10m05.us.lmco.com>
 <487E86C3.8010603@pobox.com>
Message-ID: <FDB5599B9D4E934C8CFA6C9097D4C9F10CBED6BD@emss10m05.us.lmco.com>

Quoting Craig:
> One small issue concerns the login. This is a script that will be run
> from another script and the entire thing is probably going to be
> automated. So, requiring a login/pw is a problem. I was thinking that
> the Perl script could look for env var with the desired login to use.
> (Basic idea is to create a generic account for all "automated
> processes.") 

I'd suggest using ~/.netrc.

machine <name or url>
login <email or userid>
password <password>

You could even authenticate against the extern_id in the profiles table
as another option.
 
> As far as security, I figured that if someone has access to the
> scripts, then they probably have access to "localconfig", which means
> they can 
> cause a lot more damage. Is this a reasonable assumption? (I realize
> that the permissions CAN be different, but I don't know how common
> that is.) 

You may want to write a very simple c/c++ program that calls your
script.  That c program could have a sticky bit set so that it can be
run as another user under the owner's permissions.  Then the user won't
have read access to localconfig, but the script could.


From autogbler at yahoo.de  Tue Jul 15 18:13:39 2008
From: autogbler at yahoo.de (=?iso-8859-1?Q?Ricardo_G=E4bler?=)
Date: Tue, 15 Jul 2008 20:13:39 +0200
Subject: dev-apps-bugzilla Digest, Vol 31, Issue 4
References: <mailman.1363.1216139081.9471.dev-apps-bugzilla@lists.mozilla.org>
Message-ID: <BFE823BDEC114087B5A0001AB40DC946@s2p9f4ymmim58a>

dev-apps-bugzilla mailing list submissions to


----- Original Message ----- 
From: <dev-apps-bugzilla-request at lists.mozilla.org>
To: <dev-apps-bugzilla at lists.mozilla.org>
Sent: Tuesday, July 15, 2008 6:24 PM
Subject: dev-apps-bugzilla Digest, Vol 31, Issue 4


> Send dev-apps-bugzilla mailing list submissions to
> dev-apps-bugzilla at lists.mozilla.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.mozilla.org/listinfo/dev-apps-bugzilla
> or, via email, send a message with subject or body 'help' to
> dev-apps-bugzilla-request at lists.mozilla.org
>
> You can reach the person managing the list at
> dev-apps-bugzilla-owner at lists.mozilla.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of dev-apps-bugzilla digest..."
>
>
> Today's Topics:
>
>   1. Re: Documentation (David Miller)
>   2. Re: Self-Introduction: Rupert Anthony Handford (David Miller)
>   3. Re: Documentation (David Miller)
>   4. Re: Contrib/  Bugzilla Stripping Tool (David Miller)
>   5. Bugzilla flyer for OSCON (David Miller)
>   6. Re: Bugzilla flyer for OSCON (Max Kanat-Alexander)
>   7. Re: Bugzilla flyer for OSCON (David Miller)
>   8. Re: Bugzilla flyer for OSCON (Max Kanat-Alexander)
>   9. Self-Introduction: Stefan V?lkel (bd at bc-bd.org)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 13 Jul 2008 17:39:49 -0400
> From: David Miller <justdave at bugzilla.org>
> Subject: Re: Documentation
> To: developers at bugzilla.org
> Message-ID: <487A7625.3020500 at bugzilla.org>
> Content-Type: text/plain; charset=UTF-8
>
> Colin Ogilvie wrote on 7/13/08 1:17 PM:
>> David Miller wrote:
>>> XMLTO_Documentation_Branch works for me.
>>
>> I've started work on this today, and have made some initial checkins for
>> https://bugzilla.mozilla.org/show_bug.cgi?id=423496 (all the details are
>> on the bug) and by process of this, 2 of the 3 dependant bugs will also
>> be resolved if this was committed as is.
>>
>> Unfortunately, I'm still looking at the PDF stuff as it's still
>> producing a load of rubbish to STDERR :(
>
> While you're at it, the HTML generation is hanging periodically on the
> website.  Seems to be related to it needing to retrieve DTD files off
> oasis-open.org in order to build (despite having copies of those files
> locally on the machine) and oasis-open.org is rate-limiting us because
> we're pulling too much at once (trying to build 3 copies of the docs -
> twice for HTML and once for PDF - times 4 to 8 versions of bugzilla that
> we have docs on the website for).
>
> Finding a way to make it use the local SGML/XML docbook catalog instead
> of retrieving the files off the web might be useful.
>
> In trying to debug this so far I've gotten the impression that if you
> declare PUBLIC entity and specify a URL for it, it'll use the URL,
> period.  It only looks it up in the catalog if the URL isn't supplied.
> I can't find any command-line switches for jade to override that either.
> I haven't tested that theory by removing the URLs yet though.
>
> -- 
> Dave Miller                                   http://www.justdave.net/
> System Administrator, Mozilla Corporation      http://www.mozilla.com/
> Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=dev-apps-bugzilla at lists.mozilla.org>
>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 13 Jul 2008 17:48:30 -0400
> From: David Miller <justdave at bugzilla.org>
> Subject: Re: Self-Introduction: Rupert Anthony Handford
> To: developers at bugzilla.org
> Message-ID: <487A782E.4000102 at bugzilla.org>
> Content-Type: text/plain; charset=UTF-8
>
> rupert at handfordonline.plus.com wrote on 7/10/08 3:47 AM:
>> Name: Rupert Anthony Handford
>
>> I would love to contribute to your project so that the hours I spend here
>> typing away are for the good of all and not just for my entertainment.
>
> Welcome!  We'd be happy to have your help.
>
> It's really hard to know what to ask for help with...  What people
> really wind up being good at doesn't always line up with what they've
> done in the past and we want you to have fun helping, too. :)
>
> There's a bunch of things listed at http://www.bugzilla.org/contribute/
>
> If you've recently installed Bugzilla or been administrating one, the
> documentation is one place that really needs help.  Even just pointing
> out things that the documentation is missing, even if you leave it for
> someone else to write. (Just file bugs on it in the Documentation
> component).
>
> If coding is your thing, there's links where to find good bugs to work
> on and so forth on http://wiki.mozilla.org/Bugzilla:Developers (which is
> probably where you found the request to post here).
>
> Just participating in the discussions here is a good way to stay
> involved, too.
>
> -- 
> Dave Miller                                   http://www.justdave.net/
> System Administrator, Mozilla Corporation      http://www.mozilla.com/
> Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=dev-apps-bugzilla at lists.mozilla.org>
>
>
> ------------------------------
>
> Message: 3
> Date: Sun, 13 Jul 2008 18:14:39 -0400
> From: David Miller <justdave at bugzilla.org>
> Subject: Re: Documentation
> To: developers at bugzilla.org
> Message-ID: <487A7E4F.2090908 at bugzilla.org>
> Content-Type: text/plain; charset=UTF-8
>
> David Miller wrote on 7/13/08 5:39 PM:
>> Finding a way to make it use the local SGML/XML docbook catalog instead
>> of retrieving the files off the web might be useful.
>>
>> In trying to debug this so far I've gotten the impression that if you
>> declare PUBLIC entity and specify a URL for it, it'll use the URL,
>> period.  It only looks it up in the catalog if the URL isn't supplied.
>> I can't find any command-line switches for jade to override that either.
>> I haven't tested that theory by removing the URLs yet though.
>
> OK, I just tried this, and that theory is indeed correct.  If I remove
> the URL entirely (not even a blank param for it), then it uses the local
> files specified by the SGML_CATALOG_FILES environment variable.  If the
> URL is there, it hits oasis-open.org to grab all of them.  Just removing
> the URL from the 3rd line of Bugzilla-Guide.xml completely eliminated
> all network access during the docs build, and the docs still build fine.
> (well, except for this stupid warning that happens a bazillion times
> with or without the URL:
> jade:/usr/share/sgml/docbook/xml-dtd-4.1.2-1.0-30.1/ent/iso-cyr1.ent:6:16:E:
> "X0430" is not a function name
> )
>
> --- en/xml/Bugzilla-Guide.xml 20 May 2008 20:00:52 -0000 1.79
> +++ en/xml/Bugzilla-Guide.xml 13 Jul 2008 21:59:50 -0000
> @@ -1,6 +1,5 @@
> <?xml version="1.0"?>
> -<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
> -
> "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" [
> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" [
>     <!ENTITY % myents SYSTEM "bugzilla.ent">
>     %myents;
>
>
>
> -- 
> Dave Miller                                   http://www.justdave.net/
> System Administrator, Mozilla Corporation      http://www.mozilla.com/
> Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=dev-apps-bugzilla at lists.mozilla.org>
>
>
> ------------------------------
>
> Message: 4
> Date: Sun, 13 Jul 2008 22:03:18 -0400
> From: David Miller <justdave at bugzilla.org>
> Subject: Re: Contrib/  Bugzilla Stripping Tool
> To: developers at bugzilla.org
> Message-ID: <487AB3E6.508 at bugzilla.org>
> Content-Type: text/plain; charset=UTF-8
>
> Joel Peshkin wrote on 7/8/08 1:16 PM:
>
>>   I'm just in the process of splitting of a set of products that have
>> been sold to another company so that there is a copy of the original
>> company's Bugzilla containing only the subset of products being sold.
>>
>>   At the moment, the approach is to
>>   1) Make a copy
>>   2) Rename all the products that do NOT go with the new company to
>> start with "BYE_"
>>   3) Run a script full of mysql commands that systematically delete the
>> rows of all the tables that are associated with those products' bugs'
>> attachment's data, then products' bugs' attachments, then products'
>> bugs' longesc, etc......
>>
>>   I'm doing this for 2.22.*'s schema.
>>   I am wondering if this is something that should be made into a more
>> general capability and kept up to date as the schema evolves.   If so, I
>> would probably use a mechanism like "closed for bug entry" instead of
>> renaming the products to indicate which ones should go away. Any 
>> thoughts?
>
> We have something similar we've been using at Mozilla to produce
> sanitized copies of the database that only include publicly-visible data
> to give to researchers to avoid them having to pull xml versions of
> every bug in the system to reconstruct it all.  Our version removes all
> bugs that are in groups as well as insidergroup stuff and things in
> hidden products.
>
> It was originally a bunch of SQL but I ended up converting it to Perl so
> I could point it at a copy of Bugzilla and let it use the built-in code
> for deleting various things (which takes into account the foreign keys
> and so forth).
>
> It's on https://bugzilla.mozilla.org/show_bug.cgi?id=421025
>
> -- 
> Dave Miller                                   http://www.justdave.net/
> System Administrator, Mozilla Corporation      http://www.mozilla.com/
> Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=dev-apps-bugzilla at lists.mozilla.org>
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 14 Jul 2008 20:55:26 -0400
> From: David Miller <justdave at bugzilla.org>
> Subject: Bugzilla flyer for OSCON
> To: developers at bugzilla.org
> Message-ID: <487BF57E.702 at bugzilla.org>
> Content-Type: text/plain; charset=UTF-8
>
> We had some brief talk on IRC a couple weeks ago about updating the
> Bugzilla flyer to use at OSCON, but it doesn't seem to have made it to
> the mailing list, and I don't know if anything was done.  OSCON is about
> a week away and I'd like to get something put together far enough in
> advance (like the next day or two) to avoid having to do a last minute
> rush order again like we did last year. :)
>
> Last year's flyer is at http://www.justdave.net/BugzillaFlyer.pdf if you
> want to see what it looks like, and the source is at
> http://www.justdave.net/BugzillaFlyer.odg (OpenOffice Draw format) if
> you want to play with it.  Anyone have suggestions for changes to it?
> Or should we just update the factual data to reflect the changes since
> last year and leave the format alone?
>
> -- 
> Dave Miller                                   http://www.justdave.net/
> System Administrator, Mozilla Corporation      http://www.mozilla.com/
> Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=dev-apps-bugzilla at lists.mozilla.org>
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 14 Jul 2008 19:18:18 -0700
> From: Max Kanat-Alexander <mkanat at bugzilla.org>
> Subject: Re: Bugzilla flyer for OSCON
> To: developers at bugzilla.org
> Message-ID: <20080714191818.394d6714 at es-compy>
> Content-Type: text/plain; charset=US-ASCII
>
> On Mon, 14 Jul 2008 20:55:26 -0400 David Miller <justdave at bugzilla.org>
> wrote:
>> Anyone have suggestions for changes to it?
>> Or should we just update the factual data to reflect the changes since
>> last year and leave the format alone?
>
> I think the format's pretty good. And actually, pretty much all
> the factual data is still the same, too. Maybe we should update the
> number of languages available, if that's not right anymore.
>
> -Max
> -- 
> http://www.everythingsolved.com/
> Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=dev-apps-bugzilla at lists.mozilla.org>
>
>
> ------------------------------
>
> Message: 7
> Date: Mon, 14 Jul 2008 22:43:32 -0400
> From: David Miller <justdave at bugzilla.org>
> Subject: Re: Bugzilla flyer for OSCON
> To: developers at bugzilla.org
> Message-ID: <487C0ED4.2070609 at bugzilla.org>
> Content-Type: text/plain; charset=UTF-8
>
> Max Kanat-Alexander wrote on 7/14/08 10:18 PM:
>> On Mon, 14 Jul 2008 20:55:26 -0400 David Miller <justdave at bugzilla.org>
>> wrote:
>>> Anyone have suggestions for changes to it?
>>> Or should we just update the factual data to reflect the changes since
>>> last year and leave the format alone?
>>
>> I think the format's pretty good. And actually, pretty much all
>> the factual data is still the same, too. Maybe we should update the
>> number of languages available, if that's not right anymore.
>
> And the databases (Oracle is actually in and not "landing soon" now, 
> right?)
>
> -- 
> Dave Miller                                   http://www.justdave.net/
> System Administrator, Mozilla Corporation      http://www.mozilla.com/
> Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=dev-apps-bugzilla at lists.mozilla.org>
>
>
> ------------------------------
>
> Message: 8
> Date: Mon, 14 Jul 2008 23:28:20 -0700
> From: Max Kanat-Alexander <mkanat at bugzilla.org>
> Subject: Re: Bugzilla flyer for OSCON
> To: developers at bugzilla.org
> Message-ID: <20080714232820.1f62da84 at es-compy>
> Content-Type: text/plain; charset=US-ASCII
>
> On Mon, 14 Jul 2008 22:43:32 -0400 David Miller <justdave at bugzilla.org>
> wrote:
>> And the databases (Oracle is actually in and not "landing soon" now,
>> right?)
>
> Yeah, Oracle is here, though experimental.
>
> -Max
> -- 
> http://www.everythingsolved.com/
> Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=dev-apps-bugzilla at lists.mozilla.org>
>
>
> ------------------------------
>
> Message: 9
> Date: Tue, 15 Jul 2008 17:59:22 +0200
> From: bd at bc-bd.org
> Subject: Self-Introduction: Stefan V?lkel
> To: developers at bugzilla.org
> Message-ID: <20080715155922.GJ3749 at hexenkessel.bc>
> Content-Type: text/plain; charset=iso-8859-1
>
> Name: Stefan V?lkel
> IRC: -
> Country: Germany
>
> I have been playing with Bugzilla's XML-RPC interface because I want to 
> create a
> couple of reports from it.
>
> I found out that it is missing some features I am going to need. Since 
> others
> may profit from my changes I want to get them upstream.
>
> Regarding my past, I am working with Linux since roughly 12 years, I have 
> worked
> as a Kernel Developer, System Engineer, Administrator, ...
>
> I have written a couple of irssi scripts, a wordpress plugin, half a 
> million
> shell scripts (at least it feels like half a million) and I maintain two
> packages for debian.
>
> regards
>
> Stefan
> -- 
> Linux is obsolete
> -- Andrew Tanenbaum
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=dev-apps-bugzilla at lists.mozilla.org>
>
>
> ------------------------------
>
> _______________________________________________
> dev-apps-bugzilla mailing list
> dev-apps-bugzilla at lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-bugzilla
>
>
> End of dev-apps-bugzilla Digest, Vol 31, Issue 4
> ************************************************ 


_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla


From autogbler at yahoo.de  Mon Jul 14 02:13:54 2008
From: autogbler at yahoo.de (=?iso-8859-1?Q?Ricardo_G=E4bler?=)
Date: Mon, 14 Jul 2008 04:13:54 +0200
Subject: dev-apps-bugzilla mailing list submissions 
Message-ID: <C145C568CC564834957FF30CC973C4F8@s2p9f4ymmim58a>

dev-apps-bugzilla mailing list submissions 
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla


From autogbler at yahoo.de  Wed Jul 16 00:18:13 2008
From: autogbler at yahoo.de (=?iso-8859-1?Q?Ricardo_G=E4bler?=)
Date: Wed, 16 Jul 2008 02:18:13 +0200
Subject: dev-apps-bugzilla mailing list submissions to
Message-ID: <EB1104169A3A434989C4230B4CBCA327@s2p9f4ymmim58a>

dev-apps-bugzilla mailing list submissions to
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla


From autogbler at yahoo.de  Fri Jul 18 00:30:11 2008
From: autogbler at yahoo.de (=?iso-8859-1?Q?Ricardo_G=E4bler?=)
Date: Fri, 18 Jul 2008 02:30:11 +0200
Subject: dev-apps-bugzilla mailing list submissions
Message-ID: <4C895580A5A34713AB97274F00FA73B3@s2p9f4ymmim58a>

dev-apps-bugzilla mailing list submissions
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla


From rreinurm at gmail.com  Fri Jul 18 11:13:45 2008
From: rreinurm at gmail.com (Renno Reinurm)
Date: Fri, 18 Jul 2008 04:13:45 -0700 (PDT)
Subject: Bugzilla identification
Message-ID: <4db8cbb6-9c06-4a14-85dd-da7bd91ad384@v21g2000pro.googlegroups.com>

Hi!
I had problems with Bugzilla identification. Currently unique identity
is users email address. I had situation where email is not good option
at all.

I'm using Kerberos authentication and LDAP (MS AD) for authorization.
If user is put into the Bugzilla users group in LDAP, then he/she can
access Bugzilla. If user goes to Bugzilla page, he/she will
automatically get new account according to mail attribute in LDAP if
it hasn't existed before.

But if users mail attribute has changed, then he/she will
automatically get new account or administrator has to change user
mail.

I think better way would be to use unique user attribute from LDAP for
user identification like saMAccountname from AD. And if user login to
Bugzilla, then every time will be checked if he/she mail address is
still same or needs it synchronize.

My problem was that every user got new email address in AD, what I
discovered some time later and I had to write a script to give
original account new email address.
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla


From craig5 at pobox.com  Fri Jul 18 22:14:26 2008
From: craig5 at pobox.com (Craig)
Date: Fri, 18 Jul 2008 15:14:26 -0700
Subject: self-intro: Craig Sebenik
Message-ID: <488115C2.40202@pobox.com>

Name: Craig Sebenik
IRC: --
Location: San Mateo, CA
Profession: Systems Engr (half way between SW dev and "IT")
Company: 4info

 >>> What do you want to help out with?

I've just recently started playing with the "internals". I would love to 
see most (all?) of the admin functions that are available thru the GUI 
also be available via CLI. I am making a number of changes to our 
install. We are staging the changes on a "test" install. Making the same 
set of changes in "prod" as I am making in the "test" install is going 
to be *tedious*, to say the least. I would prefer to just write a shell 
script.

Also, several months ago, I proposed using autoconf, but met with
some resistance. *I* think using "./configure; make install" would be 
beneficial, but there is plenty of other stuff to do.

Some other random stuff:
   - move all of data/params into the DB (???)
   - more consistent use of "fielddefs".
	It seems like some "field titles" are hard coded into the
	templates... but, I could be wrong.
   - move the help pages/data into the DB
   - there's more, but it's escaping me at the moment


 >>> Historical qualifications
 >>> What other technical projects have you worked on in the past?

Made one patch to Apache. :) But, that was a long time ago.

Previous companies (*cough* NetApp *cough*) weren't all that keen on 
contributing "back to the community". So, most of the code I worked on 
is not associated with any open source projects.

As far as "corp projects", it has ranged from simple stuff (sysadmin 
tools) to semi-large web apps. This includes integrating with 3rd party 
apps (ERP, CRM, <insert corporate TLA here>), SSO, WebLogic, MySQL, 
Oracle, etc. Mostly in Perl and Java. (Did write a significant piece in 
C with Apache's filter mechanism.)


 >>> What level and type of computer skills do you have?

I would *like* say my skills are at a pretty high level, but I guess 
that depends on your perspective. Most apropos; my perl skills are very 
good. (I don't mess around with the perl internals, but I like to think 
my perl is pretty strong.) I have written semi-large apps (~10k lines) 
all in "OO perl".


 >>> What other skills do you have that might be applicable?
 >>> 	User interface design, other so-called soft skills (people
 >>>	skills), etc.

I am pretty anal about documentation, but not all that great at it. ;)



From spamsux at forgetit.org  Fri Jul 18 23:08:32 2008
From: spamsux at forgetit.org (Steve Wendt)
Date: Fri, 18 Jul 2008 16:08:32 -0700
Subject: self-intro: Craig Sebenik
In-Reply-To: <hO2dnWOSg7J4vBzVnZ2dnUVZ_oPinZ2d@mozilla.org>
References: <mailman.738.1216421084.9472.dev-apps-bugzilla@lists.mozilla.org>
	<hO2dnWOSg7J4vBzVnZ2dnUVZ_oPinZ2d@mozilla.org>
Message-ID: <hO2dnWKSg7LsvxzVnZ2dnUVZ_oPinZ2d@mozilla.org>

On 7/18/2008 4:06 PM, Steve Wendt wrote:

>>   - move all of data/params into the DB (???)
> 
> How do you determine the database configuration then?

Sorry, I was confusing it with localconfig (!)
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla


From spamsux at forgetit.org  Fri Jul 18 23:06:13 2008
From: spamsux at forgetit.org (Steve Wendt)
Date: Fri, 18 Jul 2008 16:06:13 -0700
Subject: self-intro: Craig Sebenik
In-Reply-To: <mailman.738.1216421084.9472.dev-apps-bugzilla@lists.mozilla.org>
References: <mailman.738.1216421084.9472.dev-apps-bugzilla@lists.mozilla.org>
Message-ID: <hO2dnWOSg7J4vBzVnZ2dnUVZ_oPinZ2d@mozilla.org>

On 7/18/2008 3:14 PM, Craig wrote:

> Also, several months ago, I proposed using autoconf, but met with
> some resistance. *I* think using "./configure; make install" would be 
> beneficial, but there is plenty of other stuff to do.

There's little to no benefit to that for scripted code, and it adds an 
extra requirement.

>   - move all of data/params into the DB (???)

How do you determine the database configuration then?

>   - more consistent use of "fielddefs".
>     It seems like some "field titles" are hard coded into the
>     templates... but, I could be wrong.

I think this is in an ongoing process of being fixed.  Others here know 
better than I, I'm sure.

>   - move the help pages/data into the DB

It's much nicer (and easier) to link to online resources, that are 
updated independently...
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla


From mkanat at bugzilla.org  Sat Jul 19 00:01:23 2008
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Fri, 18 Jul 2008 17:01:23 -0700
Subject: Bugzilla identification
In-Reply-To: <4db8cbb6-9c06-4a14-85dd-da7bd91ad384@v21g2000pro.googlegroups.com>
References: <4db8cbb6-9c06-4a14-85dd-da7bd91ad384@v21g2000pro.googlegroups.com>
Message-ID: <20080718170123.236e05c0@es-compy>

On Fri, 18 Jul 2008 04:13:45 -0700 (PDT) Renno Reinurm
<rreinurm at gmail.com> wrote:
> I think better way would be to use unique user attribute from LDAP for
> user identification like saMAccountname from AD.

	Bugzilla actually should already be doing that. I might have
only fixed it for 3.2, but it should be storing the LDAP ID in the
extern_id column in the profiles table.

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


From mkanat at bugzilla.org  Sat Jul 19 00:04:19 2008
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Fri, 18 Jul 2008 17:04:19 -0700
Subject: self-intro: Craig Sebenik
In-Reply-To: <488115C2.40202@pobox.com>
References: <488115C2.40202@pobox.com>
Message-ID: <20080718170419.5cce2ae7@es-compy>

On Fri, 18 Jul 2008 15:14:26 -0700 Craig <craig5 at pobox.com> wrote:
>    - move all of data/params into the DB (???)

	I've thought about doing that. I think it has pros and cons,
but it would probably be nice to have most of it in there. We could
possibly have some way of specifying whether we use the file backend or
the DB backend for certain params.

>    - more consistent use of "fielddefs".
> 	It seems like some "field titles" are hard coded into the
> 	templates... but, I could be wrong.

	Yes, you're right. More consistent use of field_descs is really
what we want.

>    - move the help pages/data into the DB

	We generally don't want strings in the DB, it prevents
localization.

> I have written semi-large apps (~10k lines) all in "OO perl".

	Sweet! That's what we do, so you've come to the right place. :-)

> I am pretty anal about documentation, but not all that great at it. ;)

	Oh, that's really good, though--we need people to do
documentation, either API or user/admin docs. If you're not good at it,
we'll give you reviews until you get better. :-)

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


From craig5 at pobox.com  Sat Jul 19 00:06:26 2008
From: craig5 at pobox.com (Craig)
Date: Fri, 18 Jul 2008 17:06:26 -0700
Subject: self-intro: Craig Sebenik
In-Reply-To: <hO2dnWOSg7J4vBzVnZ2dnUVZ_oPinZ2d@mozilla.org>
References: <mailman.738.1216421084.9472.dev-apps-bugzilla@lists.mozilla.org> <hO2dnWOSg7J4vBzVnZ2dnUVZ_oPinZ2d@mozilla.org>
Message-ID: <48813002.4040500@pobox.com>

Steve Wendt wrote:
> On 7/18/2008 3:14 PM, Craig wrote:
> 
>> Also, several months ago, I proposed using autoconf, but met with
>> some resistance. *I* think using "./configure; make install" would be 
>> beneficial, but there is plenty of other stuff to do.
> 
> There's little to no benefit to that for scripted code, and it adds an 
> extra requirement.

I understand that. For installing on unix, there is almost no additional 
requirement. (I can't commit to "no additional requirement", but I am 
pretty sure that autoconf just generates a shell script. Which is 
probably going to be ok for 99.9% of unix systems. If I'm wrong, please 
let me know.) However, for development, adding things to the "install 
process" would be non-trivial. However, all of that can be made less 
painful with some scripts.

I see that adding there is little benefit in adding "./configure" to the 
current install process. But, I would argue that the current layout is 
not the best. Another *possible* way to lay it would be a more standard:
	html
	etc
	lib
	docs
	share (eg: share/templates)

Eg. it doesn't make a lot of sense to have a README sitting in the HTML 
directory. But, it also doesn't hurt anything, either. However, if you 
happen to forget to change httpd.conf to "AllowOverride", then someone 
could look at "localconfig" (as well as the rest of the .pl and .pm 
files). Yes, if this happens, that means the person that installed it 
made a mistake. But, mistakes happen.

I do realize how much work it would be to move everything into sub-dirs, 
but it really is a better layout for the long-term.

There would be some beneficial side-effects. Eg. if the perl modules 
were actually put into "/usr/lib/perl/site_perl/..." (or whatever), then 
it would be easier for end-users to write scripts. (This may be a "con"...)

Please don't misunderstand... I am not saying that I think the current 
method is totally "bad". I am just saying that there is another way that 
has a different set of pros and cons. However, the impact to the 
developers is far from 0.


>>   - more consistent use of "fielddefs".
>>     It seems like some "field titles" are hard coded into the
>>     templates... but, I could be wrong.
> 
> I think this is in an ongoing process of being fixed.  Others here know 
> better than I, I'm sure.

That's what I thought. After messing around with the code, it looks like 
it is an "in progress" thing. I am more than willing to help out with that.

>>   - move the help pages/data into the DB
> 
> It's much nicer (and easier) to link to online resources, that are 
> updated independently...


And it's 2 things you need to update. I recently had to update some of 
the help docs and it was a little confusing. There are the static help 
pages; template/en/default/pages/fields.html.tmpl, and the "roll overs" 
(eg. advanced search); template/en/default/search/search-help.html.tmpl.

Also, you have limited functionality with simply linking to a static 
file. One possible alternative would be a "popup window" for help 
instead of linking to a whole different page. (After all, if you really 
want help, going to another page and then hitting "back" is not always 
the desired user-experience.)

These are just some thoughts. I don't want to change things just to 
change them, I really think there are use cases that would show the 
benefits. I'd be happy to give a more thorough argument for the changes 
once I g become more familiar with the code itself. I am sure that some 
things will *seem* like they need to be changed, but once you understand 
why things are done a certain way, you see why it is so difficult to 
make some changes...

Craig


From mkanat at bugzilla.org  Sat Jul 19 00:12:59 2008
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Fri, 18 Jul 2008 17:12:59 -0700
Subject: self-intro: Craig Sebenik
In-Reply-To: <48813002.4040500@pobox.com>
References: <mailman.738.1216421084.9472.dev-apps-bugzilla@lists.mozilla.org>
	<hO2dnWOSg7J4vBzVnZ2dnUVZ_oPinZ2d@mozilla.org>
	<48813002.4040500@pobox.com>
Message-ID: <20080718171259.7e132892@es-compy>

On Fri, 18 Jul 2008 17:06:26 -0700 Craig <craig5 at pobox.com> wrote:
> >> Also, several months ago, I proposed using autoconf, but met with
> >> some resistance. *I* think using "./configure; make install" would
> >> be beneficial, but there is plenty of other stuff to do.

	We had a project to do that, we abandoned it as we found that
our current method was much easier and that using autoconf had no
advantages. I think you'll find the combination of checksetup.pl and
the Bugzilla::Install modules to be much easier for both us and the
end-user, given enough time to see the difference between them and
autoconf.

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


From craig5 at pobox.com  Sat Jul 19 00:18:03 2008
From: craig5 at pobox.com (Craig)
Date: Fri, 18 Jul 2008 17:18:03 -0700
Subject: self-intro: Craig Sebenik
In-Reply-To: <20080718170419.5cce2ae7@es-compy>
References: <488115C2.40202@pobox.com> <20080718170419.5cce2ae7@es-compy>
Message-ID: <488132BB.8040102@pobox.com>

Max Kanat-Alexander wrote:
> On Fri, 18 Jul 2008 15:14:26 -0700 Craig <craig5 at pobox.com> wrote:
>>    - move all of data/params into the DB (???)
> 
> 	I've thought about doing that. I think it has pros and cons,
> but it would probably be nice to have most of it in there. We could
> possibly have some way of specifying whether we use the file backend or
> the DB backend for certain params.

I was thinking that if combined with more CLI controls, then moving away 
from static files becomes easier. After all, if you can still edit (and 
view) the commands via the CLI, isn't that the same thing.

>>    - move the help pages/data into the DB
> 
> 	We generally don't want strings in the DB, it prevents
> localization.

Couldn't that *help* localization?

If you had a column that defined the language, then you could simply put 
the necessary translation in a separate row. Assuming you had an admin 
app, you could provide a simple table to show which things have been 
translated.

For example, let's suppose you had the following in the DB:
field	lang	help_msg
-----	----	------------
var1	en-us	Some help thing
var2	en-us	More help
var1	de	(help in German)
var2	fr	(help in French)

Then admin page would show something like
	US English	German		French
	----------	-------		-------
var1	OK		OK		MISSING
var2	OK		MISSING		OK


That would be a far amount of effort with questionable benefits. I think 
it makes sense and provides more functionality, but the cost could very 
well out-weight the benefits.


>> I have written semi-large apps (~10k lines) all in "OO perl".
> 
> 	Sweet! That's what we do, so you've come to the right place. :-)

That brings up a question... In the past, most of my web apps have had 
really simple CGIs and almost all of the logic in the perl modules. So, 
my CGI would look something like:

#!/usr/bin/perl
use strict;
use warnings;
use Some::Package;
my $pkg = Some::Package->new().
$pkg->main();

Then, essentially, all of the logic is in one place. This also make it 
easier to provide an API because you don't have to worry about



From autogbler at yahoo.de  Sat Jul 19 00:22:26 2008
From: autogbler at yahoo.de (=?iso-8859-1?Q?Ricardo_G=E4bler?=)
Date: Sat, 19 Jul 2008 02:22:26 +0200
Subject: dev-apps-bugzilla mailing list submissions
References: <4C895580A5A34713AB97274F00FA73B3@s2p9f4ymmim58a>
Message-ID: <92F0B6CF5664432C83414E594B39DDE8@s2p9f4ymmim58a>


----- Original Message ----- 
From: "Ricardo G?bler" <autogbler at yahoo.de>
To: <dev-apps-bugzilla at lists.mozilla.org>
Sent: Friday, July 18, 2008 2:30 AM
Subject: dev-apps-bugzilla mailing list submissions


> dev-apps-bugzilla mailing list submissions
> _______________________________________________
> dev-apps-bugzilla mailing list
> dev-apps-bugzilla at lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-bugzilla
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=autogbler at yahoo.de> 




From craig5 at pobox.com  Sat Jul 19 00:23:23 2008
From: craig5 at pobox.com (Craig)
Date: Fri, 18 Jul 2008 17:23:23 -0700
Subject: file layout/structure (Was: self-intro: Craig Sebenik)
In-Reply-To: <20080718171259.7e132892@es-compy>
References: <mailman.738.1216421084.9472.dev-apps-bugzilla@lists.mozilla.org> <hO2dnWOSg7J4vBzVnZ2dnUVZ_oPinZ2d@mozilla.org> <48813002.4040500@pobox.com> <20080718171259.7e132892@es-compy>
Message-ID: <488133FB.5080401@pobox.com>

Max Kanat-Alexander wrote:
> On Fri, 18 Jul 2008 17:06:26 -0700 Craig <craig5 at pobox.com> wrote:
>>>> Also, several months ago, I proposed using autoconf, but met with
>>>> some resistance. *I* think using "./configure; make install" would
>>>> be beneficial, but there is plenty of other stuff to do.
> 
> 	We had a project to do that, we abandoned it as we found that
> our current method was much easier and that using autoconf had no
> advantages. I think you'll find the combination of checksetup.pl and
> the Bugzilla::Install modules to be much easier for both us and the
> end-user, given enough time to see the difference between them and
> autoconf.

OK. That is totally reasonable.

In a previous email, I had mentioned breaking up the current file 
structure. I.e. instead of everything being in "html", there would be 
separate config, lib, etc. directories.

Any thoughts on that?

This is totally separate from changing the install process. I am simply 
wondering about changing the layout. As I said, there are some security 
reasons for removing some files from the "html" dir.



From mkanat at bugzilla.org  Sat Jul 19 00:32:51 2008
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Fri, 18 Jul 2008 17:32:51 -0700
Subject: file layout/structure (Was: self-intro: Craig Sebenik)
In-Reply-To: <488133FB.5080401@pobox.com>
References: <mailman.738.1216421084.9472.dev-apps-bugzilla@lists.mozilla.org>
	<hO2dnWOSg7J4vBzVnZ2dnUVZ_oPinZ2d@mozilla.org>
	<48813002.4040500@pobox.com>
	<20080718171259.7e132892@es-compy>
	<488133FB.5080401@pobox.com>
Message-ID: <20080718173251.78772998@es-compy>

On Fri, 18 Jul 2008 17:23:23 -0700 Craig <craig5 at pobox.com> wrote:
> In a previous email, I had mentioned breaking up the current file 
> structure. I.e. instead of everything being in "html", there would be 
> separate config, lib, etc. directories.
> 
> Any thoughts on that?

	I think that sort of thing is what I'd like to make *possible*
with things like Bugzilla::Constants::bz_locations(), but not
necessarily do right out of the box.

	There are possibly some things that could be moved out of the
main directory and into a bin/ subdirectory or something, but my goal
is for Bugzilla to be as easy to install as possible, at the moment. If
anything obscures where things are, I'd be against it. However, if
reorganization makes things clearer without any loss of functionality,
I'd be for it.

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


From mkanat at bugzilla.org  Sat Jul 19 00:36:50 2008
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Fri, 18 Jul 2008 17:36:50 -0700
Subject: self-intro: Craig Sebenik
In-Reply-To: <488132BB.8040102@pobox.com>
References: <488115C2.40202@pobox.com>
	<20080718170419.5cce2ae7@es-compy>
	<488132BB.8040102@pobox.com>
Message-ID: <20080718173650.5b65623e@es-compy>

On Fri, 18 Jul 2008 17:18:03 -0700 Craig <craig5 at pobox.com> wrote:
> I was thinking that if combined with more CLI controls, then moving
> away from static files becomes easier. After all, if you can still
> edit (and view) the commands via the CLI, isn't that the same thing.

	Well, I'm not sure we want more CLI controls, that's would add
a fair bit of code complexity to help only a small portion of our
users, who are the type of people who are probably already smart enough
to just use our XML-RPC interface to create their own CLI controls.

	But yes, a lot of those params should probably be in the DB. I
just need a concrete example that really proves *why* that's the case.
After all, right now, "it ain't broken."


> >>    - move the help pages/data into the DB
> > 
> > 	We generally don't want strings in the DB, it prevents
> > localization.
> 
> Couldn't that *help* localization?
> [snip]

	Not without a fair bit of additional code and query complexity
that I'd like to avoid as much as possible.

	The best way to do localization would be gettext (or really,
Locale::Maketext) and that's what I'd like to focus our efforts on, if
we're going to go in some other direction for localization.

> That would be a far amount of effort with questionable benefits. I
> think it makes sense and provides more functionality, but the cost
> could very well out-weight the benefits.

	Yeah, we have a bug where we discuss it, somewhere.

> That brings up a question... In the past, most of my web apps have
> had really simple CGIs and almost all of the logic in the perl
> modules. [snip]

	We're moving more in that direction. If you think of our CGIs
as "controllers" and our modules as the "model" in the MVC sense, then
I'd like to get more of the logic inside the model and out of the
controllers. But I wouldn't want to remove it *all* and just have it
call a single function. I want a flexible model and then the
controllers can use it as they please.

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


From autogbler at yahoo.de  Sat Jul 19 01:45:13 2008
From: autogbler at yahoo.de (=?iso-8859-1?Q?Ricardo_G=E4bler?=)
Date: Sat, 19 Jul 2008 03:45:13 +0200
Subject: dev-apps-bugzilla mailing list submissions
References: <4C895580A5A34713AB97274F00FA73B3@s2p9f4ymmim58a> <92F0B6CF5664432C83414E594B39DDE8@s2p9f4ymmim58a>
Message-ID: <536EAC97D70E4ADD85E5DF51225E08AA@s2p9f4ymmim58a>


----- Original Message ----- 
From: "Ricardo G?bler" <autogbler at yahoo.de>
To: <developers at bugzilla.org>
Sent: Saturday, July 19, 2008 2:22 AM
Subject: Re: dev-apps-bugzilla mailing list submissions


>
> ----- Original Message ----- 
> From: "Ricardo G?bler" <autogbler at yahoo.de>
> To: <dev-apps-bugzilla at lists.mozilla.org>
> Sent: Friday, July 18, 2008 2:30 AM
> Subject: dev-apps-bugzilla mailing list submissions
>
>
>> dev-apps-bugzilla mailing list submissions
>> _______________________________________________
>> dev-apps-bugzilla mailing list
>> dev-apps-bugzilla at lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-apps-bugzilla
>> -
>> To view or change your list settings, click here:
>> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=autogbler at yahoo.de>
>
>
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=autogbler at yahoo.de> 




From jochen.wiedmann at gmail.com  Sat Jul 19 09:18:43 2008
From: jochen.wiedmann at gmail.com (Jochen Wiedmann)
Date: Sat, 19 Jul 2008 11:18:43 +0200
Subject: Bugzilla identification
In-Reply-To: <20080718170123.236e05c0@es-compy>
References: <4db8cbb6-9c06-4a14-85dd-da7bd91ad384@v21g2000pro.googlegroups.com>
	 <20080718170123.236e05c0@es-compy>
Message-ID: <e75283b10807190218i4e8003a5y1c856f30a5deb1af@mail.gmail.com>

On Sat, Jul 19, 2008 at 2:01 AM, Max Kanat-Alexander
<mkanat at bugzilla.org> wrote:

>        Bugzilla actually should already be doing that. I might have
> only fixed it for 3.2, but it should be storing the LDAP ID in the
> extern_id column in the profiles table.

Might this be a reason to take some of the code from

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

For example, display and editing of the extern_id should make sense in
such an environment as well.


Jochen


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

 -- (Terry Pratchett, Thief of Time)


From |3dariel.ch at msa.hinet.net  Sat Jul 19 10:40:55 2008
From: |3dariel.ch at msa.hinet.net (Laverne Varner)
Date: Sat, 19 Jul 2008 12:40:55 +0200
Subject: Dating Marina 15
Message-ID: <01c8e99c$af94e580$3185a54e@|3dariel.ch>

--------------------------------
Marina 21 yrs old 
Horoscope: Virgo
Last activity:  July 18, 2008 
Looking For Fetish, 
Relationship Type: Sex Marriage 
Female 
Atlanta
-----------------------------------------

Meet woman and Looking For Fun 

http://udifilagimo.narod.ru

-----------------------------------------





























________________________________________________________

delite your email from my  list It can take about 2 days
If you get mail agian please send once more:
impeemenf[@] gmail[dot] com



pen-wipers, smelling-bottles, 205230

_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla


From craig5 at pobox.com  Mon Jul 14 22:48:59 2008
From: craig5 at pobox.com (Craig)
Date: Mon, 14 Jul 2008 15:48:59 -0700
Subject: modify milestone for multiple products
Message-ID: <487BD7DB.6030101@pobox.com>

Hi.

I'd like to be able to add the same milestone to multiple products. I 
briefly looked at Bugzilla::WebService::Product, but all of the routines 
are marked as "unstable". What is the best programmatic way to add 
milestones? (Is adding directly to the milestones table ok?)

More info:
	Bugzilla version 3.02 with approx 20 products

Any thoughts would be appreciated.

TIA!
Craig


From autogbler at yahoo.de  Sun Jul 20 14:34:00 2008
From: autogbler at yahoo.de (=?UTF-8?Q?Ricardo_G=C3=A4bler?=)
Date: Sun, 20 Jul 2008 16:34:00 +0200
Subject: Bugzilla identification
References: <4db8cbb6-9c06-4a14-85dd-da7bd91ad384@v21g2000pro.googlegroups.com> <20080718170123.236e05c0@es-compy> <e75283b10807190218i4e8003a5y1c856f30a5deb1af@mail.gmail.com>
Message-ID: <EA794E561FD6488C8CFE3F93D2E15BEA@s2p9f4ymmim58a>


----- Original Message ----- 
From: "Jochen Wiedmann" <jochen.wiedmann at gmail.com>
To: <developers at bugzilla.org>
Sent: Saturday, July 19, 2008 11:18 AM
Subject: Re: Bugzilla identification


> On Sat, Jul 19, 2008 at 2:01 AM, Max Kanat-Alexander
> <mkanat at bugzilla.org> wrote:
> 
>>        Bugzilla actually should already be doing that. I might have
>> only fixed it for 3.2, but it should be storing the LDAP ID in the
>> extern_id column in the profiles table.
> 
> Might this be a reason to take some of the code from
> 
>    https://bugzilla.mozilla.org/show_bug.cgi?id=392482
> 
> For example, display and editing of the extern_id should make sense in
> such an environment as well.
> 
> 
> Jochen
> 
> 
> -- 
> Look, that's why there's rules, understand? So that you think before
> you break 'em.
> 
> -- (Terry Pratchett, Thief of Time)
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=autogbler at yahoo.de>



From colemanblue at hotmail.com  Mon Jul 21 04:12:59 2008
From: colemanblue at hotmail.com (Nancy)
Date: Sun, 20 Jul 2008 21:12:59 -0700
Subject: test message
Message-ID: <VK2dnVNuI8FOkRnVnZ2dnUVZ_g-dnZ2d@mozilla.org>

Hi, 

This is a test message 
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla


From colemanblue at hotmail.com  Mon Jul 21 04:41:34 2008
From: colemanblue at hotmail.com (Nancy)
Date: Sun, 20 Jul 2008 21:41:34 -0700
Subject: API to change milestones
References: <mailman.411.1216161143.9472.dev-apps-bugzilla@lists.mozilla.org>
Message-ID: <lYWdnbcl0c4WjhnVnZ2dnUVZ_o7inZ2d@mozilla.org>



"Craig" <craig5 at pobox.com> wrote in message 
news:mailman.411.1216161143.9472.dev-apps-bugzilla at lists.mozilla.org...
> I need a way to change (add and delete) milestones via a CLI app. (Most 
> likely it will be in perl, but that isn't definite.)
>
> I looked at Bugzilla::WebService::Product, but all of the routines/methods 
> are marked as not stable.
>
> What is the "best way" to update milestones for a specific product 
> programatically?
>
> Adding it directly to the DB works just fine for me, but I wanted to do it 
> using whatever method is "approved". (Makes upgrades easier. :> )
>
> Any thoughts would be appreciated.
>
> TIA!
> Craig
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=dev-apps-bugzilla at lists.mozilla.org> 

_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla


From craig5 at pobox.com  Mon Jul 21 06:29:25 2008
From: craig5 at pobox.com (Craig)
Date: Sun, 20 Jul 2008 23:29:25 -0700
Subject: CLI  and parms in DB  ( WAS: Re: self-intro: Craig Sebenik)
In-Reply-To: <20080718173650.5b65623e@es-compy>
References: <488115C2.40202@pobox.com> <20080718170419.5cce2ae7@es-compy> <488132BB.8040102@pobox.com> <20080718173650.5b65623e@es-compy>
Message-ID: <48842CC5.8050002@pobox.com>

Max Kanat-Alexander wrote:
> On Fri, 18 Jul 2008 17:18:03 -0700 Craig <craig5 at pobox.com> wrote:
>> I was thinking that if combined with more CLI controls, then moving
>> away from static files becomes easier. After all, if you can still
>> edit (and view) the commands via the CLI, isn't that the same thing.
> 
> 	Well, I'm not sure we want more CLI controls, that's would add
> a fair bit of code complexity to help only a small portion of our
> users, who are the type of people who are probably already smart enough
> to just use our XML-RPC interface to create their own CLI controls.

Ok, so it's not "CLI" per se that you object to, it's supporting more 
complexity in the code. As I mentioned, *I* need a CLI so that I can 
automate all of the administrative changes. But, I have no requirement 
for how its done. It seems to me that a CLI that utilizes the XML-RPC 
layer would meet everyone's needs. Correct?


> 	But yes, a lot of those params should probably be in the DB. I
> just need a concrete example that really proves *why* that's the case.
> After all, right now, "it ain't broken."

Ok, that's resonable. The simple fact is that right now, you have to 
back up 2 different "things" for the bugzilla app: the database and the 
filesystem. The data in the DB is far more critical than the stuff in 
the filesystem. Granted losing the FS would mean any customizations 
would be lost. One problem at a time. :)

By putting all of the params data into the DB it centralizes the data. 
And since bugzilla is highly dependent on the DB anyway, moving more 
data into the DB wouldn't seem to be a major problem.

I have no idea how it would affect performance though. After looking 
around it looks like the apps need access to do some auth checking (as 
an exmaple). Which obviously means there needs to be a call into the DB 
relatively early, like maybe during "Bugzilla.pm" initialization???

I really think this is worthwhile to explore... but, it may turn out to 
be difficult to do. Or, at the very least, it could mean making a LOT fo 
changes...

Thoughts?



> I'd like to get more of the logic inside the model and out of the
> controllers. But I wouldn't want to remove it *all* and just have it
> call a single function. I want a flexible model and then the
> controllers can use it as they please.

Can you better define what you would like where? I realize that isn't 
necessarily an easy question, but if we have *some* definition of where 
to put what logic, it would be easier to start making changes.


From mkanat at bugzilla.org  Mon Jul 21 07:13:59 2008
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Mon, 21 Jul 2008 00:13:59 -0700
Subject: CLI  and parms in DB  ( WAS: Re: self-intro: Craig Sebenik)
In-Reply-To: <48842CC5.8050002@pobox.com>
References: <488115C2.40202@pobox.com>
	<20080718170419.5cce2ae7@es-compy>
	<488132BB.8040102@pobox.com>
	<20080718173650.5b65623e@es-compy>
	<48842CC5.8050002@pobox.com>
Message-ID: <20080721001359.44470d30@es-lappy>

On Sun, 20 Jul 2008 23:29:25 -0700 Craig <craig5 at pobox.com> wrote:
> Ok, so it's not "CLI" per se that you object to, it's supporting more 
> complexity in the code. As I mentioned, *I* need a CLI so that I can 
> automate all of the administrative changes. But, I have no
> requirement for how its done. It seems to me that a CLI that utilizes
> the XML-RPC layer would meet everyone's needs. Correct?

	Sure. Or actually, if you want to develop and have a CLI as an
addon, I'd be happy to accept the functionality that you need for a CLI
in Bugzilla, provided that it's in the direction of a generally-useful
API.

> Ok, that's resonable. The simple fact is that right now, you have to 
> back up 2 different "things" for the bugzilla app: the database and
> the filesystem. The data in the DB is far more critical than the
> stuff in the filesystem. Granted losing the FS would mean any
> customizations would be lost. One problem at a time. :)

	True. However, there are some params that would likely always
have to live outside the database. I'm pretty sure that utf8 is one of
those params, since we have to know it before we connect to the DB.

> I have no idea how it would affect performance though. After looking 
> around it looks like the apps need access to do some auth checking
> (as an exmaple). Which obviously means there needs to be a call into
> the DB relatively early, like maybe during "Bugzilla.pm"
> initialization???

	Yes, that brings up another problem, is working it all out in
checksetup for the dependencies on what can happen when.

	But performance isn't an issue, we'd just read all the params
every page call and cache them.

> I really think this is worthwhile to explore... but, it may turn out
> to be difficult to do. Or, at the very least, it could mean making a
> LOT fo changes...

	Yeah, worthwhile to explore, definitely, as long as it can be
done incrementally somehow.

> Can you better define what you would like where? I realize that isn't 
> necessarily an easy question, but if we have *some* definition of
> where to put what logic, it would be easier to start making changes.

	Well, think of it in the standard OO sense of
objects--accessors & mutators and all that. Manipulation of the
accessors and mutators should generally be in the scripts (the
controller), but the mutators and so forth should be in the objects.

	In particular, I'd like to avoid having any SQL whatsoever in
the controllers.

	-Max


From dmarshal at yahoo-inc.com  Mon Jul 21 16:49:05 2008
From: dmarshal at yahoo-inc.com (David Marshall)
Date: Mon, 21 Jul 2008 09:49:05 -0700
Subject: self-intro: Craig Sebenik
In-Reply-To: <20080718173650.5b65623e@es-compy>
Message-ID: <C4AA0C11.19155%dmarshal@yahoo-inc.com>




On 7/18/08 5:36 PM, "Max Kanat-Alexander" <mkanat at bugzilla.org> wrote:

> On Fri, 18 Jul 2008 17:18:03 -0700 Craig <craig5 at pobox.com> wrote:
>> I was thinking that if combined with more CLI controls, then moving
>> away from static files becomes easier. After all, if you can still
>> edit (and view) the commands via the CLI, isn't that the same thing.
> 
> Well, I'm not sure we want more CLI controls, that's would add
> a fair bit of code complexity to help only a small portion of our
> users, who are the type of people who are probably already smart enough
> to just use our XML-RPC interface to create their own CLI controls.
> 

We've been adding our own web services to our 2.22.X Bugzilla, and we have
both a reference CLI application for using them, as well as a number of
users writing their own CLI applications.  It's definitely the way to go.



From colemanblue at hotmail.com  Thu Jul 24 09:26:52 2008
From: colemanblue at hotmail.com (Nancy Coleman)
Date: Thu, 24 Jul 2008 14:56:52 +0530
Subject: test message
References: <VK2dnVNuI8FOkRnVnZ2dnUVZ_g-dnZ2d@mozilla.org>
Message-ID: <U6udnTfEOPEg1xXVnZ2dnUVZ_t_inZ2d@mozilla.org>

thanks

"Nancy" <colemanblue at hotmail.com> wrote in message 
news:VK2dnVNuI8FOkRnVnZ2dnUVZ_g-dnZ2d at mozilla.org...
> Hi,
> This is a test message 

_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla


From nagend_n at hotmail.com  Thu Jul 24 09:26:12 2008
From: nagend_n at hotmail.com (Nagendran)
Date: Thu, 24 Jul 2008 02:26:12 -0700
Subject: test message
References: <VK2dnVNuI8FOkRnVnZ2dnUVZ_g-dnZ2d@mozilla.org>
Message-ID: <FJSdnS2TLexd1xXVnZ2dnUVZ_hjinZ2d@mozilla.org>


thanks
"Nancy" <colemanblue at hotmail.com> wrote in message 
news:VK2dnVNuI8FOkRnVnZ2dnUVZ_g-dnZ2d at mozilla.org...
> Hi,
> This is a test message 

_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla


From shruthi_1987 at hotmail.com  Thu Jul 24 09:38:50 2008
From: shruthi_1987 at hotmail.com (shruthi)
Date: Thu, 24 Jul 2008 15:08:50 +0530
Subject: test message
References: <VK2dnVNuI8FOkRnVnZ2dnUVZ_g-dnZ2d@mozilla.org>
Message-ID: <LrSdnTHXdYAo0BXVnZ2dnUVZ_oHinZ2d@mozilla.org>

hi

"Nancy" <colemanblue at hotmail.com> wrote in message 
news:VK2dnVNuI8FOkRnVnZ2dnUVZ_g-dnZ2d at mozilla.org...
> Hi,
> This is a test message 

_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla


From lpsolit at gmail.com  Thu Jul 24 10:00:29 2008
From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=)
Date: Thu, 24 Jul 2008 12:00:29 +0200
Subject: Self-Introduction: Rupert Anthony Handford
In-Reply-To: <487A782E.4000102@bugzilla.org>
References: <10181.87.112.94.238.1215676065.squirrel@webmail.plus.net> <487A782E.4000102@bugzilla.org>
Message-ID: <488852BD.2040607@gmail.com>

David Miller a ?crit :
> It's really hard to know what to ask for help with...  What people
> really wind up being good at doesn't always line up with what they've
> done in the past and we want you to have fun helping, too. :)

Also, how well do you know Bugzilla? Is there any part of it you would 
like to improve?


LpSolit


From lpsolit at gmail.com  Thu Jul 24 10:05:52 2008
From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=)
Date: Thu, 24 Jul 2008 12:05:52 +0200
Subject: Contrib/  Bugzilla Stripping Tool
In-Reply-To: <4873A0F8.5000407@peshkin.net>
References: <4873A0F8.5000407@peshkin.net>
Message-ID: <48885400.6020905@gmail.com>

Joel Peshkin a ?crit :
>   3) Run a script full of mysql commands

Why not simply deleting products from the UI? It knows what to do with 
related data.

LpSolit



From lpsolit at gmail.com  Thu Jul 24 10:50:06 2008
From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=)
Date: Thu, 24 Jul 2008 12:50:06 +0200
Subject: self-intro: Craig Sebenik
In-Reply-To: <488132BB.8040102@pobox.com>
References: <488115C2.40202@pobox.com> <20080718170419.5cce2ae7@es-compy> <488132BB.8040102@pobox.com>
Message-ID: <48885E5E.8050902@gmail.com>

Craig a ?crit :
>>>    - move all of data/params into the DB (???)

I'm currently against this idea. I have two use cases in mind right now:

1) When moving your Bugzilla installation to a new web server, you have 
to edit urlbase and sslbase first, to point to the new server. If you 
forget to do this on time, Bugzilla redirects you to the old web server 
and you can never update these parameters from the UI. In this case, 
it's much easier to edit data/params with a text editor than to type SQL 
commands.

2) When Bugzilla is down (e.g. for maintenance), you still want the 
content of the shutdownhtml parameter to be displayed, even if the DB 
server is down, see https://bugzilla.mozilla.org/show_bug.cgi?id=398075. 
This parameter must then be kept outside the DB.

And having parameters in two different places is a bad idea, offers no 
benefit and increases complexity.



>>>    - move the help pages/data into the DB
>>
>>     We generally don't want strings in the DB, it prevents
>> localization.
> 
> Couldn't that *help* localization?

No, we don't want to interact with the DB when doing l10n. The DB is not 
the right place to add human readable text.


LpSolit


From craig5 at pobox.com  Thu Jul 24 22:09:54 2008
From: craig5 at pobox.com (Craig)
Date: Thu, 24 Jul 2008 15:09:54 -0700
Subject: self-intro: Craig Sebenik
In-Reply-To: <48885E5E.8050902@gmail.com>
References: <488115C2.40202@pobox.com> <20080718170419.5cce2ae7@es-compy> <488132BB.8040102@pobox.com> <48885E5E.8050902@gmail.com>
Message-ID: <4888FDB2.4070005@pobox.com>

Fr?d?ric Buclin wrote:
> Craig a ?crit :
>>>>    - move all of data/params into the DB (???)
> 
> I'm currently against this idea. I have two use cases in mind right now:
> 
> 1) When moving your Bugzilla installation to a new web server, you have 
> to edit urlbase and sslbase first, to point to the new server. If you 
> forget to do this on time, Bugzilla redirects you to the old web server 
> and you can never update these parameters from the UI. In this case, 
> it's much easier to edit data/params with a text editor than to type SQL 
> commands.

Ok. What if there was a CLI to update the necessary values? This isn't 
an ideal situation...

> 2) When Bugzilla is down (e.g. for maintenance), you still want the 
> content of the shutdownhtml parameter to be displayed, even if the DB 
> server is down, see https://bugzilla.mozilla.org/show_bug.cgi?id=398075. 
> This parameter must then be kept outside the DB.

Good point. (I forgot about this parameter.) One could argue that this 
is, essentially, a "database connection parameter". If it's true, then 
ignore the rest of the DB settings.


> And having parameters in two different places is a bad idea, offers no 
> benefit and increases complexity.

Totally agree! If the data/params cannot be moved into the DB, can we 
move "setting" and "setting_value" out of the DB and into data/params?

=========================

Ok, let me back up a little. My basic problem is that there is some data 
in the DB and some other in the filesystem. This is a bit of a pain to 
backup. (How we backup the DB is significantly different than any kind 
of filesystem backups.) Also, with some data in the files, doing 
upgrades are more difficult than they have to be (IMHO). If the "config" 
was outside of the "app home", then this wouldn't be so bad. But, we 
can't just download a new version, drop it in, run "checksetup.pl" and 
everything is up. *Ideally*, all of the data and config would be in one 
place. When I was new to bz, I had to upgrade an existing install and 
forgot data/params. Admittedly, we can't prevent any/all stupids 
mistakes. Just trying to make the upgrade process easier. I thought that 
moving the params into the DB was going to be a simple thing, since 
several are already in there. It sounds like it's going to create more 
problems than solve...



> No, we don't want to interact with the DB when doing l10n. The DB is not 
> the right place to add human readable text.

Fair enough. I had an issue when trying to add a "custom field". I read 
the page about customizing bz and it mentioned that you should "co-opt" 
a field before creating a "custom field". We used "rep_platform". We 
changed the row in fielddefs, but then had to change 2 files to update 
various help pages:
	template/en/default/search/search-help.html.tmpl
	template/en/default/pages/fields.html.tmpl

It was a little tedious. At the very least, the admin pages should allow 
one to update those values. I was merely thinking that by putting it in 
the DB it would be easier to manage. But, the truth is that I jsut am 
looking for an easier way to update all necessary pieces of data when 
changing a field.

Craig



From lpsolit at gmail.com  Thu Jul 24 22:23:02 2008
From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=)
Date: Fri, 25 Jul 2008 00:23:02 +0200
Subject: self-intro: Craig Sebenik
In-Reply-To: <4888FDB2.4070005@pobox.com>
References: <488115C2.40202@pobox.com> <20080718170419.5cce2ae7@es-compy> <488132BB.8040102@pobox.com> <48885E5E.8050902@gmail.com> <4888FDB2.4070005@pobox.com>
Message-ID: <488900C6.70806@gmail.com>

Craig a ?crit :
> Totally agree! If the data/params cannot be moved into the DB, can we 
> move "setting" and "setting_value" out of the DB and into data/params?

No reason to do this. Those settings never change and are set by 
checksetup.pl. They are not something you can edit.

Moreover, when doing an upgrade, you have to copy the whole data/ 
directory, not only data/params. Old charts have data in data/mining/ 
and local attachments are stored in data/attachments/. You need them 
when upgrading and so you have to backup data/ anyway.


LpSolit


From colemanblue at hotmail.com  Fri Jul 25 07:15:57 2008
From: colemanblue at hotmail.com (Nancy)
Date: Fri, 25 Jul 2008 00:15:57 -0700
Subject: test message
References: <VK2dnVNuI8FOkRnVnZ2dnUVZ_g-dnZ2d@mozilla.org>
Message-ID: <sMidnSdfKYMu4BTVnZ2dnUVZ_uLinZ2d@mozilla.org>

Hi all,

I need to ask about the tabbed browsing options in Mozilla.

"Nancy" <colemanblue at hotmail.com> wrote in message 
news:VK2dnVNuI8FOkRnVnZ2dnUVZ_g-dnZ2d at mozilla.org...
> Hi,
> This is a test message 

_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla


From colemanblue at hotmail.com  Fri Jul 25 07:24:20 2008
From: colemanblue at hotmail.com (Nancy)
Date: Fri, 25 Jul 2008 00:24:20 -0700
Subject: One-click site information
Message-ID: <3POdnVV977A44hTVnZ2dnUVZ_r7inZ2d@mozilla.org>

Hi, 

Could anyone explain what one-click site information is? 
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla


From colemanblue at hotmail.com  Fri Jul 25 07:24:58 2008
From: colemanblue at hotmail.com (Nancy)
Date: Fri, 25 Jul 2008 00:24:58 -0700
Subject: News servers
Message-ID: <hKednfa9O65R4hTVnZ2dnUVZ_oHinZ2d@mozilla.org>

Hi, 

How useful are news servers? 
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla


From colemanblue at hotmail.com  Fri Jul 25 07:21:50 2008
From: colemanblue at hotmail.com (Nancy)
Date: Fri, 25 Jul 2008 00:21:50 -0700
Subject: Add-ons feature in Mozilla
Message-ID: <lZSdnRUYc_2N4hTVnZ2dnUVZ_sbinZ2d@mozilla.org>

Hi, 

The new add-ons in Mozilla are quite useful. 
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla


From colemanblue at hotmail.com  Fri Jul 25 07:16:55 2008
From: colemanblue at hotmail.com (Nancy)
Date: Fri, 25 Jul 2008 00:16:55 -0700
Subject: Tabbed browsing
Message-ID: <DYydnSK1Ncp04BTVnZ2dnUVZ_oPinZ2d@mozilla.org>

Hi all, 
Could anyone explain the tabbed browsing feature in Mozilla?

Regards,
Nancy

 
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla


From colemanblue at hotmail.com  Fri Jul 25 08:24:30 2008
From: colemanblue at hotmail.com (Nancy)
Date: Fri, 25 Jul 2008 01:24:30 -0700
Subject: The Options dialog box
Message-ID: <KJqdneXJg4FdEBTVnZ2dnUVZ_uCdnZ2d@mozilla.org>

Hi, 
The Options dialog box has many useful options. 
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla


From colemanblue at hotmail.com  Fri Jul 25 08:27:44 2008
From: colemanblue at hotmail.com (Nancy)
Date: Fri, 25 Jul 2008 01:27:44 -0700
Subject: Windows Live Mail
Message-ID: <z7GdnY5ZhP8cExTVnZ2dnUVZ_g-dnZ2d@mozilla.org>

Hi, 

Does Windows live Mail perform in the XP OS? 
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla


From colemanblue at hotmail.com  Fri Jul 25 08:31:44 2008
From: colemanblue at hotmail.com (Nancy)
Date: Fri, 25 Jul 2008 01:31:44 -0700
Subject: Phishing options
Message-ID: <J_2dnc4HUvvuEhTVnZ2dnUVZ_oninZ2d@mozilla.org>

Hi, 

Please tell me clearly what phishing options are. 
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla


From justdave at bugzilla.org  Fri Jul 25 11:44:18 2008
From: justdave at bugzilla.org (David Miller)
Date: Fri, 25 Jul 2008 04:44:18 -0700
Subject: test message
In-Reply-To: <sMidnSdfKYMu4BTVnZ2dnUVZ_uLinZ2d@mozilla.org>
References: <VK2dnVNuI8FOkRnVnZ2dnUVZ_g-dnZ2d@mozilla.org>
	<sMidnSdfKYMu4BTVnZ2dnUVZ_uLinZ2d@mozilla.org>
Message-ID: <4889BC92.7080205@bugzilla.org>

Nancy wrote on 7/25/08 12:15 AM:

> I need to ask about the tabbed browsing options in Mozilla.

Sorry for a somewhat abrupt answer, but you're posting to the wrong
newsgroup for that.  This group is for development discussion about
Bugzilla (which is a program that runs on a web server, not a browser),
you want to use mozilla.support.firefox for questions like yours.

-- 
Dave Miller                                   http://www.justdave.net/
System Administrator, Mozilla Corporation      http://www.mozilla.com/
Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla


From bugzilla at displague.com  Fri Jul 25 13:07:42 2008
From: bugzilla at displague.com (Marques Johansson)
Date: Fri, 25 Jul 2008 09:07:42 -0400
Subject: Phishing options
In-Reply-To: <J_2dnc4HUvvuEhTVnZ2dnUVZ_oninZ2d@mozilla.org>
References: <J_2dnc4HUvvuEhTVnZ2dnUVZ_oninZ2d@mozilla.org>
Message-ID: <527759310807250607q55d1f7a6l4b0de7ab808ce402@mail.gmail.com>

Me thinks Nancy won't pass a Turing test. Possibly harvesting email
addresses from replies while gathering AI replies to automated questions for
the sake of creating better SPAM?


On Fri, Jul 25, 2008 at 4:31 AM, Nancy <colemanblue at hotmail.com> wrote:

> Hi,
>
> Please tell me clearly what phishing options are.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20080725/412db5ea/attachment.html>

From gerv at mozilla.org  Fri Jul 25 22:51:03 2008
From: gerv at mozilla.org (Gervase Markham)
Date: Fri, 25 Jul 2008 15:51:03 -0700
Subject: Simpler Bugzilla
Message-ID: <qoGdnepflokGFRfVnZ2dnUVZ_rHinZ2d@mozilla.org>

I had someone complaining to me recently that Bugzilla's UI was too 
complicated. I said that some people needed all those fields; he replied 
that still, there was no need to show them by default.

Is it worth us considering whether we want to make default Bugzilla use 
fewer fields? Are there some switchable ones turned on by default that 
we could turn off? Or can we put a few more hard-coded ones inside [% IF 
%] blocks to make them switchable?

Also, chatting with Myk over lunch, a couple of things that would make 
installation simpler:

- We could support and ship with SQLite. I suspect it would be all that 
90% of installations needed, and removes the need to set up and 
configure MySQL or PgSQL.

- We could ship with a simple Perl webserver or lighttpd, which removes 
the need to set up and configure Apache. We don't use many advanced 
webserver features; as long as it obeys .htaccess files, we should be fine.

With these two features, installing Bugzilla would be a case of:

- Download and unpack
- Run the module install script
- Do first-run config in the GUI like your SMTP server name
- Done.

Not even any localconfig, as far as I can see.

What do people think?

Gerv


_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla


From guy.pyrzak at gmail.com  Sat Jul 26 02:34:07 2008
From: guy.pyrzak at gmail.com (Guy Pyrzak)
Date: Fri, 25 Jul 2008 19:34:07 -0700
Subject: Simpler Bugzilla
In-Reply-To: <qoGdnepflokGFRfVnZ2dnUVZ_rHinZ2d@mozilla.org>
References: <qoGdnepflokGFRfVnZ2dnUVZ_rHinZ2d@mozilla.org>
Message-ID: <df4dec6f0807251934m5f88efb9x9f84f465bceb9dea@mail.gmail.com>

I agree 100% with both points, fewer fields and easier install. That's a big
problem with bugzilla and why many people don't want to use it. Some folks
could care less about the default fields that we give. In the end i think
the only fields that should appear by default are the ones bugzilla needs to
function.

However, part of this conversion also has to be making it easier to use
custom fields as well since people will invariably use those to create
fields that they need.

As far as easier shipping, I'd like to think the LAMP framework is kind
standard, however, talking to people in the chat rooms the P in lamp tends
to stand for PHP not perl and that's where people get tripped up.

I do think that overall the UI for Bugzilla could be simplified so that the
advanced features are there but they don't get in the way so much. I've had
this discussion with max a few times.

I'm not convinced that having bugzilla ship with mysql-lite and a perl will
fix the problem, but it is an interesting idea.

-Guy


On Fri, Jul 25, 2008 at 3:51 PM, Gervase Markham <gerv at mozilla.org> wrote:

> I had someone complaining to me recently that Bugzilla's UI was too
> complicated. I said that some people needed all those fields; he replied
> that still, there was no need to show them by default.
>
> Is it worth us considering whether we want to make default Bugzilla use
> fewer fields? Are there some switchable ones turned on by default that
> we could turn off? Or can we put a few more hard-coded ones inside [% IF
> %] blocks to make them switchable?
>
> Also, chatting with Myk over lunch, a couple of things that would make
> installation simpler:
>
> - We could support and ship with SQLite. I suspect it would be all that
> 90% of installations needed, and removes the need to set up and
> configure MySQL or PgSQL.
>
> - We could ship with a simple Perl webserver or lighttpd, which removes
> the need to set up and configure Apache. We don't use many advanced
> webserver features; as long as it obeys .htaccess files, we should be fine.
>
> With these two features, installing Bugzilla would be a case of:
>
> - Download and unpack
> - Run the module install script
> - Do first-run config in the GUI like your SMTP server name
> - Done.
>
> Not even any localconfig, as far as I can see.
>
> What do people think?
>
> Gerv
>
>
> _______________________________________________
> dev-apps-bugzilla mailing list
> dev-apps-bugzilla at lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-bugzilla
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=guy.pyrzak at gmail.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20080725/bd288ab3/attachment.html>

From lpsolit at gmail.com  Sat Jul 26 10:40:09 2008
From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=)
Date: Sat, 26 Jul 2008 12:40:09 +0200
Subject: Simpler Bugzilla
In-Reply-To: <qoGdnepflokGFRfVnZ2dnUVZ_rHinZ2d@mozilla.org>
References: <qoGdnepflokGFRfVnZ2dnUVZ_rHinZ2d@mozilla.org>
Message-ID: <488AFF09.30001@gmail.com>

Gervase Markham a ?crit :
> - We could support and ship with SQLite. I suspect it would be all that 
> 90% of installations needed, and removes the need to set up and 
> configure MySQL or PgSQL.
> 
> - We could ship with a simple Perl webserver or lighttpd, which removes 
> the need to set up and configure Apache.


I'm not sure installing MySQL and Apache is such a big deal, even on 
Windows. The first time I had to install both on Windows, I could do it 
without any problem. Their respective executables (.exe) are easy enough 
to use to do it in a few minutes. Also, the most difficult part to 
install is Perl, not the other two above, IMO.

Related bugs and discussions:

- SQLite: https://bugzilla.mozilla.org/show_bug.cgi?id=337776
- lighttpd: https://bugzilla.mozilla.org/show_bug.cgi?id=415529

Now a few questions:
- does SQLite support UTF8 and transactions?
- does lighttpd support mod_perl?


About the UI, there is nothing new here. We already had this discussion 
several times on IRC, especially with mkanat and pyrzak (and again no 
later than yesterday, with pyrzak). We have several ideas in mind; just 
waiting to have the time to implement them.

LpSolit


From shimono at mozilla.gr.jp  Sat Jul 26 11:06:49 2008
From: shimono at mozilla.gr.jp (Atsushi Shimono)
Date: Sat, 26 Jul 2008 20:06:49 +0900
Subject: Simpler Bugzilla
In-Reply-To: <488AFF09.30001@gmail.com>
References: <qoGdnepflokGFRfVnZ2dnUVZ_rHinZ2d@mozilla.org>
	 <488AFF09.30001@gmail.com>
Message-ID: <e7835ac80807260406h4f118a45u9e9d4de02e783e10@mail.gmail.com>

  hi, LpSolit

On Sat, Jul 26, 2008 at 7:40 PM, Fr?d?ric Buclin <lpsolit at gmail.com> wrote:
> Now a few questions:
> - does SQLite support UTF8 and transactions?

  utf8 might be yes. (Unicode supported)
  transactions, yes. with thread-safe but re-build is needed at some binary
distributions.

> - does lighttpd support mod_perl?

  i don't know about mod_perl, but i think it supports FastCGI.

  regards,
-- 
Atsushi Shimono - shimono at mozilla.gr.jp
 http://www.mozilla.gr.jp/~shimono/blog/
 Mozilla-Gumi : Japanese Mozilla Users Group / System Administrator


From lpsolit at gmail.com  Sat Jul 26 11:19:03 2008
From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=)
Date: Sat, 26 Jul 2008 13:19:03 +0200
Subject: Simpler Bugzilla
In-Reply-To: <e7835ac80807260406h4f118a45u9e9d4de02e783e10@mail.gmail.com>
References: <qoGdnepflokGFRfVnZ2dnUVZ_rHinZ2d@mozilla.org>	 <488AFF09.30001@gmail.com> <e7835ac80807260406h4f118a45u9e9d4de02e783e10@mail.gmail.com>
Message-ID: <488B0827.9040906@gmail.com>

Atsushi Shimono a ?crit :
>> - does SQLite support UTF8 and transactions?
> 
>   utf8 might be yes. (Unicode supported)
>   transactions, yes. with thread-safe but re-build is needed at some binary
> distributions.

I just visited http://www.sqlite.org/omitted.html which says foreign 
keys are not supported. This is a problem as our code now assumes these 
constraints to be enforced, especially on deletion.


LpSolit


From after.fallout at gmail.com  Sat Jul 26 16:25:13 2008
From: after.fallout at gmail.com (Bill Barry)
Date: Sat, 26 Jul 2008 10:25:13 -0600
Subject: Simpler Bugzilla
In-Reply-To: <488B0827.9040906@gmail.com>
References: <qoGdnepflokGFRfVnZ2dnUVZ_rHinZ2d@mozilla.org>	 <488AFF09.30001@gmail.com> <e7835ac80807260406h4f118a45u9e9d4de02e783e10@mail.gmail.com> <488B0827.9040906@gmail.com>
Message-ID: <488B4FE9.6010307@gmail.com>

Fr?d?ric Buclin wrote:
>
> I just visited http://www.sqlite.org/omitted.html which says foreign 
> keys are not supported. This is a problem as our code now assumes 
> these constraints to be enforced, especially on deletion.
Foreign keys can be mocked using triggers.

The biggest problem with supporting sqlite is its concurrency model. 
Multiple connections can read at the same time, but only one connection 
can connect to the entire database (the whole db is write locked) when 
writing. That severely limits the number of concurrent users of Bugzilla.

A better path for Bugzilla might be to work towards a completely 
abstracted migration/installation database library (DBMI? *note). Once 
that is done, it would be able to support any database where a migration 
implementation (DBMD?) exists and a DBD implementation exists

note:
As a disclaimer, I have no idea how migrations are working in bugzilla 
at the moment, nor have I searched in Bugzilla for anything like this. I 
have only done rudimentary searching on cpan and come up with 
DBIx::Migrations::Directory, but I don't think that is a good solution 
as it requires sql scripts for each migration for each supported 
database. I was thinking something more along the lines of migrator.net 
(http://code.google.com/p/migratordotnet/) which abstracts away the sql 
that runs in order to support multiple databases with a single migration 
script.


From jochen.wiedmann at gmail.com  Sat Jul 26 18:00:07 2008
From: jochen.wiedmann at gmail.com (Jochen Wiedmann)
Date: Sat, 26 Jul 2008 20:00:07 +0200
Subject: Simpler Bugzilla
In-Reply-To: <qoGdnepflokGFRfVnZ2dnUVZ_rHinZ2d@mozilla.org>
References: <qoGdnepflokGFRfVnZ2dnUVZ_rHinZ2d@mozilla.org>
Message-ID: <e75283b10807261100k54007d00j24ec0bc16611266d@mail.gmail.com>

On Sat, Jul 26, 2008 at 12:51 AM, Gervase Markham <gerv at mozilla.org> wrote:

> Is it worth us considering whether we want to make default Bugzilla use
> fewer fields? Are there some switchable ones turned on by default that
> we could turn off? Or can we put a few more hard-coded ones inside [% IF
> %] blocks to make them switchable?

I know that in particular the search UI is/was deterrent for a lot of
users. The "simple search" was a great help, but the "advanced search"
could do with renaming to "expert search" and the addition of someting
in between. Apart from the search, I only heard complaints about the
bug editing UI, but the primary candidates for removal there are
already configurable via parameters.


> - We could support and ship with SQLite. I suspect it would be all that
> 90% of installations needed, and removes the need to set up and
> configure MySQL or PgSQL.

That would sure be nice. OTOH, it might make upgrades more difficult.
And, apart from that, I do personally believe that the most important
problem is not the setup but the myriad of Perl modules. The changes
in the email system for 3.0 haven't been exactly helpful there. I do
not know so much about Perl than I used to do, in particular, I do not
know whether there is an equivalent to the Java jar files today, but
an included delivery of the required/optional modules would help.
Perhaps in a separate directory, where you can very easily switch them
off, and perhaps including the Pure-Perl modules only.


> - We could ship with a simple Perl webserver or lighttpd, which removes
> the need to set up and configure Apache. We don't use many advanced
> webserver features; as long as it obeys .htaccess files, we should be fine.

I do not know how the reality on the user lists look alike, but
personally I never considered that as painful.


> With these two features, installing Bugzilla would be a case of:
>
> - Download and unpack
> - Run the module install script
> - Do first-run config in the GUI like your SMTP server name
> - Done.
>
> Not even any localconfig, as far as I can see.
>
> What do people think?

About the localconfig: I am always impressed by the setup of systems
like typo3, drupal, egroupware, mediawiki: The system detects whether
it is a first time installation (usually because some config file is
missing) and provides a UI for the first time installation. I would
recommend to think in that direction instead.

Of course, a complete distribution would be nice, but I think it is
realistic for Windows only. Apart from that, that's something you can
leave to interesting individuals and not necessarily a task for the
whole community.


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  Sun Jul 27 01:31:19 2008
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Sat, 26 Jul 2008 18:31:19 -0700
Subject: Simpler Bugzilla
In-Reply-To: <488B4FE9.6010307@gmail.com>
References: <qoGdnepflokGFRfVnZ2dnUVZ_rHinZ2d@mozilla.org>
	<488AFF09.30001@gmail.com>
	<e7835ac80807260406h4f118a45u9e9d4de02e783e10@mail.gmail.com>
	<488B0827.9040906@gmail.com>
	<488B4FE9.6010307@gmail.com>
Message-ID: <20080726183119.25dab440@es-lappy>

On Sat, 26 Jul 2008 10:25:13 -0600 Bill Barry <after.fallout at gmail.com>
wrote:
> The biggest problem with supporting sqlite is its concurrency model. 
> Multiple connections can read at the same time, but only one
> connection can connect to the entire database (the whole db is write
> locked) when writing. That severely limits the number of concurrent
> users of Bugzilla.

	That's fine. We wouldn't expect large installs to use SQLite,
we would tell them to use a real DB server.

> A better path for Bugzilla might be to work towards a completely 
> abstracted migration/installation database library (DBMI? *note).

	SQL::Translator, I have a bug filed about it somewhere.

	-Max


From mkanat at bugzilla.org  Sun Jul 27 01:36:24 2008
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Sat, 26 Jul 2008 18:36:24 -0700
Subject: Simpler Bugzilla
In-Reply-To: <e75283b10807261100k54007d00j24ec0bc16611266d@mail.gmail.com>
References: <qoGdnepflokGFRfVnZ2dnUVZ_rHinZ2d@mozilla.org>
	<e75283b10807261100k54007d00j24ec0bc16611266d@mail.gmail.com>
Message-ID: <20080726183624.5c008bf8@es-lappy>

On Sat, 26 Jul 2008 20:00:07 +0200 "Jochen Wiedmann"
<jochen.wiedmann at gmail.com> wrote:
> I know that in particular the search UI is/was deterrent for a lot of
> users. The "simple search" was a great help, but the "advanced search"
> could do with renaming to "expert search" and the addition of someting
> in between. Apart from the search, I only heard complaints about the
> bug editing UI, but the primary candidates for removal there are
> already configurable via parameters.

	I think search would be greatly improved by making it work a
bit like iTunes (or Rhythmbox, which I'm used to) filters, where you
have a limited list of fields in one drop-down, and then a second box
for the "operator" (which could also be a more limited list than we
have in the Boolean Charts) and then a text box for the criteria.

	In a sense, like a Boolean Charts but simplified. Also, for
<select> fields (like product, component, etc), the "text box" could
become a drop-down that only contains valid choices.

> That would sure be nice. OTOH, it might make upgrades more difficult.

	No, I know how to make upgrades fully possible with
SQLLite--they'll just be slow. But that's fine, we expect SQLite to be
easy, not fast.

> And, apart from that, I do personally believe that the most important
> problem is not the setup but the myriad of Perl modules. 

	See install-module.pl in the 3.2 branch.

> About the localconfig: I am always impressed by the setup of systems
> like typo3, drupal, egroupware, mediawiki:

	All not written in Perl...

> The system detects whether
> it is a first time installation (usually because some config file is
> missing) and provides a UI for the first time installation. I would
> recommend to think in that direction instead.

	I worked on this for a while, and I decided that it didn't
actually have any benefit for our users over checksetup.pl, at least
not enough benefit to justify the added complexity.

	However, we could quiz people for the essential localconfig
data, instead of making them edit the file, on a new install.

> Of course, a complete distribution would be nice, but I think it is
> realistic for Windows only. Apart from that, that's something you can
> leave to interesting individuals and not necessarily a task for the
> whole community.

	I think the best solution for non-Windows is the VM images that
people distribute that already have Bugzilla working on them.

	-Max


From mkanat at bugzilla.org  Sun Jul 27 01:36:49 2008
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Sat, 26 Jul 2008 18:36:49 -0700
Subject: Simpler Bugzilla
In-Reply-To: <qoGdnepflokGFRfVnZ2dnUVZ_rHinZ2d@mozilla.org>
References: <qoGdnepflokGFRfVnZ2dnUVZ_rHinZ2d@mozilla.org>
Message-ID: <20080726183649.797ca96f@es-lappy>

On Fri, 25 Jul 2008 15:51:03 -0700 Gervase Markham <gerv at mozilla.org>
wrote:
> I had someone complaining to me recently that Bugzilla's UI was too 
> complicated. I said that some people needed all those fields; he
> replied that still, there was no need to show them by default.

	Sometimes more fields actually makes life simpler, because it
allows better data organization.

	We've improved the UI for 3.2, also.

> Is it worth us considering whether we want to make default Bugzilla
> use fewer fields? Are there some switchable ones turned on by default
> that we could turn off? Or can we put a few more hard-coded ones
> inside [% IF %] blocks to make them switchable?

	We have bugs for this, I'm pretty sure.

	op_sys and platform should be made into custom fields and
should be moved into a plugin (so that they can maintain their magic
"auto-select what the browser tells us" functionality).

> - We could support and ship with SQLite. I suspect it would be all
> that 90% of installations needed, and removes the need to set up and 
> configure MySQL or PgSQL.

	Yes, there's a bug for that and I was working on it.

> - We could ship with a simple Perl webserver or lighttpd, which
> removes the need to set up and configure Apache. We don't use many
> advanced webserver features; as long as it obeys .htaccess files, we
> should be fine.

	"Obeys .htaccess files" is the tricky (or perhaps impossible)
part there.

	-Max


From eseyman at linagora.com  Mon Jul 28 07:01:50 2008
From: eseyman at linagora.com (Emmanuel Seyman)
Date: Mon, 28 Jul 2008 09:01:50 +0200
Subject: Simpler Bugzilla
In-Reply-To: <qoGdnepflokGFRfVnZ2dnUVZ_rHinZ2d@mozilla.org>
References: <qoGdnepflokGFRfVnZ2dnUVZ_rHinZ2d@mozilla.org>
Message-ID: <20080728070150.GA6915@lora.maison.lan>

* Gervase Markham [26/07/2008 04:15] :
>
> Is it worth us considering whether we want to make default Bugzilla use 
> fewer fields? Are there some switchable ones turned on by default that 
> we could turn off? Or can we put a few more hard-coded ones inside [% IF 
> %] blocks to make them switchable?

Just so that we're on the same wavelength, the switchable fields are:

bugaliases
classification
qacontact
statuswhiteboard
targetmilestone
votes (enabled by default in 3.0)

Gerv, did the person you were talking to tell you which fields
he had in mind?

Emmanuel
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla


From Steve.Roscio at hp.com  Mon Jul 28 14:48:12 2008
From: Steve.Roscio at hp.com (Roscio, Steve)
Date: Mon, 28 Jul 2008 14:48:12 +0000
Subject: Phishing options
In-Reply-To: <527759310807250607q55d1f7a6l4b0de7ab808ce402@mail.gmail.com>
References: <J_2dnc4HUvvuEhTVnZ2dnUVZ_oninZ2d@mozilla.org>
 <527759310807250607q55d1f7a6l4b0de7ab808ce402@mail.gmail.com>
Message-ID: <81DC3A589F7C274A9D3D960BBD0F0B0C315036D029@GVW0670EXC.americas.hpqcorp.net>

Yeah, I suspect that too.  Many decades ago I wrote a program called ?Alicia? who sounds very much like our Nancy here.

From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] On Behalf Of Marques Johansson
Sent: Friday, July 25, 2008 7:08 AM
To: developers at bugzilla.org
Subject: Re: Phishing options

Me thinks Nancy won't pass a Turing test. Possibly harvesting email addresses from replies while gathering AI replies to automated questions for the sake of creating better SPAM?

On Fri, Jul 25, 2008 at 4:31 AM, Nancy <colemanblue at hotmail.com<mailto:colemanblue at hotmail.com>> wrote:
Hi,

Please tell me clearly what phishing options are.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20080728/364fe469/attachment.html>

From colemanblue at hotmail.com  Tue Jul 29 11:43:43 2008
From: colemanblue at hotmail.com (Nancy)
Date: Tue, 29 Jul 2008 04:43:43 -0700
Subject: test message
References: <VK2dnVNuI8FOkRnVnZ2dnUVZ_g-dnZ2d@mozilla.org>
Message-ID: <koKdndNax7vgnxLVnZ2dnUVZ_oLinZ2d@mozilla.org>

I had already sent a test message last week

"Nancy" <colemanblue at hotmail.com> wrote in message 
news:VK2dnVNuI8FOkRnVnZ2dnUVZ_g-dnZ2d at mozilla.org...
> Hi,
> This is a test message 

_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla


From bugzilla at displague.com  Tue Jul 29 12:33:32 2008
From: bugzilla at displague.com (Marques Johansson)
Date: Tue, 29 Jul 2008 08:33:32 -0400
Subject: test message
In-Reply-To: <koKdndNax7vgnxLVnZ2dnUVZ_oLinZ2d@mozilla.org>
References: <VK2dnVNuI8FOkRnVnZ2dnUVZ_g-dnZ2d@mozilla.org>
	 <koKdndNax7vgnxLVnZ2dnUVZ_oLinZ2d@mozilla.org>
Message-ID: <527759310807290533le00d1a3ke5c2d7fa7ddc64b9@mail.gmail.com>

A stateful conversation seeding spam bot?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20080729/cf58b2bc/attachment.html>

From shimono at mozilla.gr.jp  Tue Jul 29 19:04:40 2008
From: shimono at mozilla.gr.jp (Atsushi Shimono)
Date: Wed, 30 Jul 2008 04:04:40 +0900
Subject: self-intro: Craig Sebenik
In-Reply-To: <48885E5E.8050902@gmail.com>
References: <488115C2.40202@pobox.com> <20080718170419.5cce2ae7@es-compy> <488132BB.8040102@pobox.com> <48885E5E.8050902@gmail.com>
Message-ID: <488F69C8.40902@mozilla.gr.jp>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

  hi, all

Fr?d?ric Buclin wrote:
>>>>    - move the help pages/data into the DB
>>>
>>>     We generally don't want strings in the DB, it prevents
>>> localization.
>>
>> Couldn't that *help* localization?
> 
> No, we don't want to interact with the DB when doing l10n. The DB is not
> the right place to add human readable text.

  It isn't helpful for user to insert the localized strings for user
definedable values, such as custom bug field values or statuses, into
the DB?
  Of cource, for localizors' view we desire not to insert them into DB (?),
but for users' view it might be easy to edit them from administration pages
rather than from editing templates directly.
  If users have languages like more than two, everytime they edit the
field values, they are in need to edit the templates.


  thanx.
- --
Atsushi Shimono
 Dept. Astronomy, Kyoto Univ
 Kyoto3DII Project / Okayama 3.8m New Telescope Project
 mail : shimono @ kusastro.kyoto-u.ac.jp / gmail.com
 skype : shimono_univ (w/cam; @univ), shimono_mobile (note pc)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEAREKAAYFAkiPaccACgkQBygbhFUCKWbJeQCbBvoYK89xqXzZFEvZQOqDPDOk
JGkAnAu8fZ3Ijicmm9aDw9jubQ764OvJ
=OJ1W
-----END PGP SIGNATURE-----


From gerv at mozilla.org  Thu Jul 31 04:48:10 2008
From: gerv at mozilla.org (Gervase Markham)
Date: Wed, 30 Jul 2008 21:48:10 -0700
Subject: Simpler Bugzilla
In-Reply-To: <mailman.1522.1217072090.9472.dev-apps-bugzilla@lists.mozilla.org>
References: <qoGdnepflokGFRfVnZ2dnUVZ_rHinZ2d@mozilla.org>
	<mailman.1522.1217072090.9472.dev-apps-bugzilla@lists.mozilla.org>
Message-ID: <BsqdnaoLypSR2QzVnZ2dnUVZ_jKdnZ2d@mozilla.org>

Fr?d?ric Buclin wrote:
> I'm not sure installing MySQL and Apache is such a big deal, even on
> Windows. 

They may not be, but sometimes a long list of requirements is enough to
put people off. It would be interesting to see if we could get hard data
on what people found most difficult.

> Related bugs and discussions:
> 
> - SQLite: https://bugzilla.mozilla.org/show_bug.cgi?id=337776
> - lighttpd: https://bugzilla.mozilla.org/show_bug.cgi?id=415529
> 
> Now a few questions:
> - does SQLite support UTF8 and transactions?

UTF8, I'm sure. Mozilla uses it, and it's fully internationalizable.
Transactions, yes: http://www.sqlite.org/lang_transaction.html

> - does lighttpd support mod_perl?

Probably not, but most people don't need it. If you want mod_perl,
install Apache.

Gerv
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla

From gerv at mozilla.org  Thu Jul 31 04:53:03 2008
From: gerv at mozilla.org (Gervase Markham)
Date: Wed, 30 Jul 2008 21:53:03 -0700
Subject: Simpler Bugzilla
In-Reply-To: <mailman.1559.1217122633.9472.dev-apps-bugzilla@lists.mozilla.org>
References: <qoGdnepflokGFRfVnZ2dnUVZ_rHinZ2d@mozilla.org>
	<mailman.1559.1217122633.9472.dev-apps-bugzilla@lists.mozilla.org>
Message-ID: <wO-dnUqc-5Os2AzVnZ2dnUVZ_qPinZ2d@mozilla.org>

Max Kanat-Alexander wrote:
> 	Sometimes more fields actually makes life simpler, because it
> allows better data organization.

I think Joel's piece about custom fields addresses that view. I assume
you've read it; what do you think of it?

> 	Yes, there's a bug for that and I was working on it.

Cool! :-)

Gerv
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla


From gerv at mozilla.org  Thu Jul 31 04:53:43 2008
From: gerv at mozilla.org (Gervase Markham)
Date: Wed, 30 Jul 2008 21:53:43 -0700
Subject: Simpler Bugzilla
In-Reply-To: <mailman.1598.1217228530.9472.dev-apps-bugzilla@lists.mozilla.org>
References: <qoGdnepflokGFRfVnZ2dnUVZ_rHinZ2d@mozilla.org>
	<mailman.1598.1217228530.9472.dev-apps-bugzilla@lists.mozilla.org>
Message-ID: <wO-dnUWc-5PF2AzVnZ2dnUVZ_qPinZ2d@mozilla.org>

Emmanuel Seyman wrote:
> Gerv, did the person you were talking to tell you which fields
> he had in mind?

Nope. But perhaps we could look at what we provide that Trac doesn't,
and use that as a starting point for discussion :-)

Gerv
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla


From mkanat at bugzilla.org  Thu Jul 31 05:15:32 2008
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Wed, 30 Jul 2008 22:15:32 -0700
Subject: Simpler Bugzilla
In-Reply-To: <wO-dnUqc-5Os2AzVnZ2dnUVZ_qPinZ2d@mozilla.org>
References: <qoGdnepflokGFRfVnZ2dnUVZ_rHinZ2d@mozilla.org>
	<mailman.1559.1217122633.9472.dev-apps-bugzilla@lists.mozilla.org>
	<wO-dnUqc-5Os2AzVnZ2dnUVZ_qPinZ2d@mozilla.org>
Message-ID: <20080730221532.100d2830@es-compy>

On Wed, 30 Jul 2008 21:53:03 -0700 Gervase Markham <gerv at mozilla.org>
wrote:
> Max Kanat-Alexander wrote:
> > 	Sometimes more fields actually makes life simpler, because
> > it allows better data organization.
> 
> I think Joel's piece about custom fields addresses that view. I assume
> you've read it; what do you think of it?

	It's sort of a sliding scale. Allowing people to add any field
they want can make a bug-tracker too complex. Having too few built-in
fields can also make a bug-tracker too difficult to use.

	The ideal is to figure out the exact data model that's needed
and present it in the most user-friendly fashion.

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