From lpsolit at gmail.com  Mon Oct  2 08:32:31 2006
From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=)
Date: Mon, 02 Oct 2006 10:32:31 +0200
Subject: Bugzilla meeting tomorrow
Message-ID: <4520CE9F.6050803@gmail.com>

We have another Bugzilla meeting tomorrow, Tuesday Oct. 3rd at 18:00 GMT
(11:00 PDT, 20:00 CEST) in the #bugzilla-meeting channel on IRC. As
usual, this meeting is public; anyone can attend.

The agenda is available at http://wiki.mozilla.org/Bugzilla:Meetings


See you tomorrow,

LpSolit


From derekbellnersmith at yahoo.com  Mon Oct  2 17:12:58 2006
From: derekbellnersmith at yahoo.com (Derek B. Smith)
Date: Mon, 2 Oct 2006 10:12:58 -0700 (PDT)
Subject: login not working
In-Reply-To: <451D3D65.6010904@mozilla.org>
Message-ID: <20061002171258.22417.qmail@web42408.mail.scd.yahoo.com>

My confusion as I original signed up for an account to
this list unknowingly the bugzilla.mozilla.org was a
different list.

I just signed up...thx anyway
derek
--- Gervase Markham <gerv at mozilla.org> wrote:

> Derek B. Smith wrote:
> > Trying to log in to grab some tasks, but after
> failing
> > I reset my passwd then I "accepted" the passwd
> change,
> > then I received email saying password change was
> > successfuly, but I cannot login as it is telling
> me
> > invlaid user-id or password?
> > 
> > userid=derekbellnersmith at yahoo.com
> > 
> > can anyone hlpe plz?
> 
> Which Bugzilla installation are you using? I can't
> find anyone with that
> email address on bugzilla.mozilla.org.
> 
> Gerv
> -
> To view or change your list settings, click here:
>
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=derekbellnersmith at yahoo.com>
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From ukh_dtl at yahoo.com  Tue Oct  3 14:02:14 2006
From: ukh_dtl at yahoo.com (ukhas jean)
Date: Tue, 3 Oct 2006 07:02:14 -0700 (PDT)
Subject: query on "process_cgi"
Message-ID: <20061003140214.97392.qmail@web31703.mail.mud.yahoo.com>

Hello All,
   
  I was working on process_bug.cgi. Can anyone tell me why "makeexact" value is used??
   
  Any advise/help/suggestions are welcome!!!
   
  Regards,
  Ukhas

 		
---------------------------------
Do you Yahoo!?
 Everyone is raving about the  all-new Yahoo! Mail.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20061003/c5190078/attachment.html>

From justdave at bugzilla.org  Wed Oct  4 02:51:39 2006
From: justdave at bugzilla.org (David Miller)
Date: Tue, 03 Oct 2006 22:51:39 -0400
Subject: query on "process_cgi"
In-Reply-To: <20061003140214.97392.qmail@web31703.mail.mud.yahoo.com>
References: <20061003140214.97392.qmail@web31703.mail.mud.yahoo.com>
Message-ID: <452321BB.1050401@bugzilla.org>

ukhas jean wrote on 10/3/06 10:02 AM:

> I was working on process_bug.cgi. Can anyone tell me why "makeexact"
> value is used??

I don't have it open in front of me right at the moment, but I believe
that's used in the case of the submission coming from the "change
several bugs at once" form for fields that can have multiple values such
as keywords.  The context is to "add these keywords to all of these
bugs", "remove these keywords from all of these bugs", or "make the
keyword list on all of these bugs exactly this list".

-- 
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 ukh_dtl at yahoo.com  Wed Oct  4 05:21:10 2006
From: ukh_dtl at yahoo.com (ukhas jean)
Date: Tue, 3 Oct 2006 22:21:10 -0700 (PDT)
Subject: query on "process_cgi"
In-Reply-To: <452321BB.1050401@bugzilla.org>
Message-ID: <20061004052110.81365.qmail@web31705.mail.mud.yahoo.com>

Hello Dave et al,
   
  Thanks ... i think i understand the logic behind it now ... one more question ... 
  Y is this SQL query required ?? i cant figure y deletion of keywords have to take place ... ??
  Following is snippet of code from process_bug.cgi:-
     
     my $changed = 0;
        if ($keywordaction eq "makeexact") {
   SendSQL("DELETE FROM keywords WHERE bug_id = $id");
      $changed = 1;
        }
   
   
  Best,
  Ukh
  
David Miller <justdave at bugzilla.org> wrote:
  ukhas jean wrote on 10/3/06 10:02 AM:

> I was working on process_bug.cgi. Can anyone tell me why "makeexact"
> value is used??

I don't have it open in front of me right at the moment, but I believe
that's used in the case of the submission coming from the "change
several bugs at once" form for fields that can have multiple values such
as keywords. The context is to "add these keywords to all of these
bugs", "remove these keywords from all of these bugs", or "make the
keyword list on all of these bugs exactly this list".

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



 		
---------------------------------
Get your email and more, right on the  new Yahoo.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20061003/0afe9b97/attachment.html>

From justdave at bugzilla.org  Wed Oct  4 06:18:25 2006
From: justdave at bugzilla.org (David Miller)
Date: Wed, 04 Oct 2006 02:18:25 -0400
Subject: query on "process_cgi"
In-Reply-To: <20061004052110.81365.qmail@web31705.mail.mud.yahoo.com>
References: <20061004052110.81365.qmail@web31705.mail.mud.yahoo.com>
Message-ID: <45235231.2090409@bugzilla.org>

ukhas jean wrote on 10/4/06 1:21 AM:
> Hello Dave et al,
>  
> Thanks ... i think i understand the logic behind it now ... one more
> question ... 
> Y is this SQL query required ?? i cant figure y deletion of keywords
> have to take place ... ??
> Following is snippet of code from process_bug.cgi:-
>   
>    my $changed = 0;
>         if ($keywordaction eq "makeexact") {
>    SendSQL("DELETE FROM keywords WHERE bug_id = $id");
>       $changed = 1;
>         }

Because if you're making it exactly that list, then none of the existing
keywords need to be on that bug (well, maybe some of them might, but
it's easier to delete and re-add than to figure out which ones).  So it
deletes the entire existing list before adding the new ones.

-- 
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 ukh_dtl at yahoo.com  Wed Oct  4 07:31:38 2006
From: ukh_dtl at yahoo.com (ukhas jean)
Date: Wed, 4 Oct 2006 00:31:38 -0700 (PDT)
Subject: query on "process_cgi"
In-Reply-To: <45235231.2090409@bugzilla.org>
Message-ID: <20061004073138.48522.qmail@web31703.mail.mud.yahoo.com>

Dave,
   
  Thats sounds cool ... hmm ... but how is the script keeping track of the records it is deleting??
   
  Ukh

David Miller <justdave at bugzilla.org> wrote:
  ukhas jean wrote on 10/4/06 1:21 AM:
> Hello Dave et al,
> 
> Thanks ... i think i understand the logic behind it now ... one more
> question ... 
> Y is this SQL query required ?? i cant figure y deletion of keywords
> have to take place ... ??
> Following is snippet of code from process_bug.cgi:-
> 
> my $changed = 0;
> if ($keywordaction eq "makeexact") {
> SendSQL("DELETE FROM keywords WHERE bug_id = $id");
> $changed = 1;
> }

Because if you're making it exactly that list, then none of the existing
keywords need to be on that bug (well, maybe some of them might, but
it's easier to delete and re-add than to figure out which ones). So it
deletes the entire existing list before adding the new ones.

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



 		
---------------------------------
Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls.  Great rates starting at 1?/min.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20061004/8e75d965/attachment.html>

From mkanat at bugzilla.org  Wed Oct  4 08:48:55 2006
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Wed, 04 Oct 2006 01:48:55 -0700
Subject: query on "process_cgi"
In-Reply-To: <20061004073138.48522.qmail@web31703.mail.mud.yahoo.com>
References: <20061004073138.48522.qmail@web31703.mail.mud.yahoo.com>
Message-ID: <1159951736.2445.8.camel@localhost.localdomain>

On Wed, 2006-10-04 at 00:31 -0700, ukhas jean wrote:
> Thats sounds cool ... hmm ... but how is the script keeping track of
> the records it is deleting??

	Hey Ukh. I think at this point the best way to get your questions
answered is to come into IRC. You can see the details here:

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

	-Max

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



From justdave at bugzilla.org  Wed Oct  4 10:39:22 2006
From: justdave at bugzilla.org (David Miller)
Date: Wed, 04 Oct 2006 06:39:22 -0400
Subject: query on "process_cgi"
In-Reply-To: <20061004073138.48522.qmail@web31703.mail.mud.yahoo.com>
References: <20061004073138.48522.qmail@web31703.mail.mud.yahoo.com>
Message-ID: <45238F5A.5020701@bugzilla.org>

ukhas jean wrote on 10/4/06 3:31 AM:

> Thats sounds cool ... hmm ... but how is the script keeping track of the
> records it is deleting??

If you mean so that it can put them in the activity log as having been
removed, process_bug takes before and after snapshots of the bug and
compares them in order to make that entry.

-- 
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  Thu Oct  5 07:18:19 2006
From: justdave at bugzilla.org (David Miller)
Date: Thu, 05 Oct 2006 03:18:19 -0400
Subject: bugzilla.org website CVS repository moving
In-Reply-To: <451CB30A.4090403@bugzilla.org>
References: <451CB30A.4090403@bugzilla.org>
Message-ID: <4524B1BB.5030802@bugzilla.org>

David Miller wrote on 9/29/06 1:45 AM:
> Some of you are already aware, but just to make sure everyone knows,
> we're in the process of moving the bugzilla.org website out of
> mozilla-org/html/projects/bugzilla/ into bugzilla-org/ on the cvs
> server, in order to allow us to use a more flexible site build system.
> The CVS file copies in order to preserve history on the files was
> performed this afternoon.  We'll be switching over the live site to pull
> from the new repo as soon as we get it building correctly.  I'll post
> again when that happens.
> 
> In the mean time, remember that if you change anything on the website,
> you need to make the same change in both repos until we complete the
> switchover.
> 
> The source data for the installation list is the main thing that's in a
> different spot in the new repo.  It's now in the lib/ directory at the
> top-level (outside of what's essentially the docroot).

I just flipped the switch on the production webserver.  You can now
safely completely ignore the old projects/bugzilla repo and only edit
pages on the new one now.

-- 
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 bugzilla at colinogilvie.co.uk  Thu Oct  5 08:06:59 2006
From: bugzilla at colinogilvie.co.uk (Colin Ogilvie)
Date: Thu, 05 Oct 2006 09:06:59 +0100
Subject: bugzilla.org website CVS repository moving
Message-ID: <454684f94426008345c993d8ffb2049b@webmail.plus.net>

On Thu Oct  5  8:18 , David Miller <justdave at bugzilla.org> sent:
>I just flipped the switch on the production webserver.  You can now
>safely completely ignore the old projects/bugzilla repo and only edit
>pages on the new one now.

How does this affect changes being checked in to the site - does it automatically
pull them and build the site still, or does it behave like mozilla.com and
require server ops to push it?

Colin


From justdave at bugzilla.org  Fri Oct  6 05:58:32 2006
From: justdave at bugzilla.org (David Miller)
Date: Fri, 06 Oct 2006 01:58:32 -0400
Subject: bugzilla.org website CVS repository moving
In-Reply-To: <454684f94426008345c993d8ffb2049b@webmail.plus.net>
References: <454684f94426008345c993d8ffb2049b@webmail.plus.net>
Message-ID: <4525F088.8000703@bugzilla.org>

Colin Ogilvie wrote on 10/5/06 4:06 AM:
> On Thu Oct  5  8:18 , David Miller <justdave at bugzilla.org> sent:
>> I just flipped the switch on the production webserver.  You can now
>> safely completely ignore the old projects/bugzilla repo and only edit
>> pages on the new one now.
> 
> How does this affect changes being checked in to the site - does it automatically
> pull them and build the site still, or does it behave like mozilla.com and
> require server ops to push it?

It still automatically pulls every 10 minutes.  It's behind a caching
proxy though, so depending on when you hit it, the changes might take
longer to show up.  But it's been that way for the last couple months
already anyway.

-- 
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  Fri Oct  6 08:27:00 2006
From: justdave at bugzilla.org (David Miller)
Date: Fri, 06 Oct 2006 04:27:00 -0400
Subject: Moving the mailing lists
Message-ID: <45261354.4020009@bugzilla.org>

For those who don't know, the mail processing and mailing list hosting
for bugzilla.org is hosted at Syndicomm, which is where I've had all of
my personal domains hosted for the last several years.  The Bugzilla
website got moved to mozilla.org servers a year and a half ago, but the
mail processing never did, mainly because of the difficulty of trying to
move the list server (and that there wasn't a machine to put it on
easily at Mozilla).  Well, now we have machines at Mozilla that it can
be put on, and the issue is being forced anyway, as the hosting side of
Syndicomm's business is getting shut down on December 1st, so we have
until then to move out.

I think we should probably take this opportunity to move the developers
list to the mozilla.dev.apps.bugzilla newsgroup/mailing list.  We can
make the old address continue to work (it's easy to remember :) and have
it deliver there.

For the rest of the lists, we can set them up on the new mail server.
The next question of course, is Majordomo2 vs Mailman.  Mailman is
easier to install because RHEL packages it.  Majordomo2 is still only
available as source.  A year or two ago when asked this question I'd be
fighting to keep Majordomo2.  But my Mailman experience at the time was
Mailman 2.0, and most of the things I liked about Mj2 that Mailman was
lacking got added to Mailman in 2.1.  The list is currently hosted on
Majordomo2, so it theoretically wouldn't be *that* hard to move
everything intact if we kept using it.

The list archives aren't directly compatible between Mj2 and Mailman.
Both store the messages in mbox files for the archives, but the metadata
and indexing is done differently.  So moving the archives to Mailman
might be "interesting".  Although I'd be surprised if there aren't
scripts out there somewhere to have mailman reindex a bare mbox file.

The other issue is IMAP accounts.  There's a couple of you with IMAP
accounts on bugzilla.org.  I'll be pestering you soon about where to
send your mail if you're one of them.  We aren't going to be able to
host those at Mozilla unless you're an employee.

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


From lpsolit at gmail.com  Fri Oct  6 18:35:19 2006
From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=)
Date: Fri, 06 Oct 2006 20:35:19 +0200
Subject: QA status
Message-ID: <4526A1E7.4050607@gmail.com>

Just in case you are curious to know how QA tests are going and how far
we are, have a look at this URL:

http://landfill.bugzilla.org/bugzillaqa/tr_list_runs.cgi?plan_id=3

We won't release anything as long as all progress bars are not all 100%
green.


LpSolit


From myk at mozilla.org  Fri Oct  6 20:40:29 2006
From: myk at mozilla.org (Myk Melez)
Date: Fri, 06 Oct 2006 13:40:29 -0700
Subject: Moving the mailing lists
In-Reply-To: <45261354.4020009@bugzilla.org>
References: <45261354.4020009@bugzilla.org>
Message-ID: <4526BF3D.6010803@mozilla.org>

David Miller wrote:
> The list archives aren't directly compatible between Mj2 and Mailman.
> Both store the messages in mbox files for the archives, but the metadata
> and indexing is done differently.  So moving the archives to Mailman
> might be "interesting".  Although I'd be surprised if there aren't
> scripts out there somewhere to have mailman reindex a bare mbox file.
>   
I think there might even be such scripts in the mailman package.

-myk



From mkanat at bugzilla.org  Sat Oct  7 10:56:46 2006
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Sat, 07 Oct 2006 03:56:46 -0700
Subject: Nominating things for the 3.2 roadmap
Message-ID: <1160218606.2351.10.camel@es-lappy>

	Hey hey. So I was just mentioning to LpSolit, we can nominate things to
show up on the 3.2 roadmap by putting "[roadmap: 3.2]" in their status
whiteboard.

	That doesn't mean they *will* be on the roadmap. It just means that in
two months or so when we write the roadmap, we'll have a list to go
through.

	Don't discuss it here, just nominate things and we'll discuss them in a
month or two.

	-Max
-- 
http://www.everythingsolved.com/
Everything Solved: Competent, Friendly Bugzilla and Linux Services



From vladd at bugzilla.org  Sat Oct  7 18:18:43 2006
From: vladd at bugzilla.org (Vlad Dascalu)
Date: Sat, 07 Oct 2006 21:18:43 +0300
Subject: Nominating things for the 3.2 roadmap
In-Reply-To: <1160218606.2351.10.camel@es-lappy>
References: <1160218606.2351.10.camel@es-lappy>
Message-ID: <4527EF83.4090700@bugzilla.org>

I wanted to share the Linux "roadmap" thing, maybe it's useful for 
Bugzilla (or not).

According to Linus, Linux is "evolution", not "inteligent design". The 
way Linux expandes is governed by its contributors. They have a 2-week 
window in which they merge all the features that got coded during the 
previous freeze, and after that it's stabilization, and release. And 
after that it starts all over again.

There's no roadmap in the Linux world from this point of view.

Well, ok, there are lots of roadmaps in the Linux world. Each company 
that depends on a specific device driver for the Linux OS has a roadmap 
regarding the schedule of getting the driver into the kernel, and stuff 
like that. But there is no "central", "approved" roadmap, because the 
only way to put a thing in the Linux roadmap is to work hard enough and 
be responsive enough in order to "carry" the patch in the Linus' tree.

I do welcome any kind of coordonation in a project, but I think 
roadmaps, if mis-managed, can have a detrimental effect.

I've welcomed the Bugzilla 3.0 roadmap when it appeared, but I think 
we're starting to push roadmap management too far, with possible 
detriments to our developers and engineers. We're way too early in 3.2 
lifecycle in order to "nominate" things. Developers that want to 
nominate something should start working on that feature, or getting it 
reviewed/feedbacked. But even that is too early (bitrotten is a fact).

If we want to have things on the radar, we can use a lot of mechanisms 
already available (priority, target milestones, blocking flags)...

I think the Linux model has a lot of impact in motivating developers to 
get stuff done. I, like Linus, prefer "evolution" to "inteligent 
design", and too much roadmap management can be detrimental.

It's just my personal opinion, and I probably won't have the time to 
reply to the replies, so consider it a useful insight :). Bugzilla has 
become a 2-man game (LpSolit and mkanat), with Marc, RSZ, Colin and 
others digging in occasionally. Compared to the state of things when I 
was around, the top contributors are a lot more active, but the team is 
somewhat smaller. I think it would be cool if we could manage to keep 
the activity of top-contributors, while at the same time encourage new 
devels to kick in. I do think roadmap over-management can hurt the new guys.

Vlad

Max Kanat-Alexander wrote:
> 	Hey hey. So I was just mentioning to LpSolit, we can nominate things to
> show up on the 3.2 roadmap by putting "[roadmap: 3.2]" in their status
> whiteboard.
>
> 	That doesn't mean they *will* be on the roadmap. It just means that in
> two months or so when we write the roadmap, we'll have a list to go
> through.
>
> 	Don't discuss it here, just nominate things and we'll discuss them in a
> month or two.
>
> 	-Max
>   



From pedro.lamarao at intersix.com.br  Tue Oct 10 12:41:03 2006
From: pedro.lamarao at intersix.com.br (=?ISO-8859-1?Q?Pedro_Lamar=E3o?=)
Date: Tue, 10 Oct 2006 09:41:03 -0300
Subject: Nominating things for the 3.2 roadmap
In-Reply-To: <4527EF83.4090700@bugzilla.org>
References: <1160218606.2351.10.camel@es-lappy> <4527EF83.4090700@bugzilla.org>
Message-ID: <452B94DF.4030800@intersix.com.br>

Vlad Dascalu escreveu:
> I wanted to share the Linux "roadmap" thing, maybe it's useful for 
> Bugzilla (or not).
>
> According to Linus, Linux is "evolution", not "inteligent design". The 
> way Linux expandes is governed by its contributors. They have a 2-week 
> window in which they merge all the features that got coded during the 
> previous freeze, and after that it's stabilization, and release. And 
> after that it starts all over again.
>
> There's no roadmap in the Linux world from this point of view.
>
> Well, ok, there are lots of roadmaps in the Linux world. Each company 
> that depends on a specific device driver for the Linux OS has a 
> roadmap regarding the schedule of getting the driver into the kernel, 
> and stuff like that. But there is no "central", "approved" roadmap, 
> because the only way to put a thing in the Linux roadmap is to work 
> hard enough and be responsive enough in order to "carry" the patch in 
> the Linus' tree.
>
> I do welcome any kind of coordonation in a project, but I think 
> roadmaps, if mis-managed, can have a detrimental effect.

Mis-done things always hurt.

But compare the "Linux model" with the current "GCC model":

http://gcc.gnu.org/wiki/GCC_4.3_Release_Planning

-- 
Pedro Lamar?o
Desenvolvimento

Intersix Technologies S.A.
SP: (55 11 3803-9300)
RJ: (55 21 3852-3240)
www.intersix.com.br

Your Security is our Business



From justdave at bugzilla.org  Tue Oct 10 17:01:32 2006
From: justdave at bugzilla.org (David Miller)
Date: Tue, 10 Oct 2006 13:01:32 -0400
Subject: Time for Landfill to move again
Message-ID: <452BD1EC.5040306@bugzilla.org>

For those that didn't already hear
(http://www.sethbindernagel.com/mozilla/?p=25), the Bugzilla project has
received a new VMWare ESX 3.0.1 server via the Mozilla Corporation's
Community Giving program.

The existing landfill server is going to get p2v'd into a VM running on
that box (which will give it additional CPU and RAM in the process), and
we'll be able to add additional VMs for tinderbox clients and so forth,
to be able to keep the tinderboxes from killing the CPU on the
development box while you're working on developing stuff. :)

The box has arrived, and Mozilla's IT is ready to run the p2v on
landfill whenever we're ready.  The question now is, when are we ready?
 I told him probably next week after our 2.23.2 QA cycle is done, but I
figured I'd ask to make sure.  If we can handle a couple hours of
downtime, anytime's good.

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


From mkanat at bugzilla.org  Wed Oct 11 08:57:13 2006
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Wed, 11 Oct 2006 01:57:13 -0700
Subject: Time for Landfill to move again
In-Reply-To: <452BD1EC.5040306@bugzilla.org>
References: <452BD1EC.5040306@bugzilla.org>
Message-ID: <1160557034.7190.4.camel@localhost.localdomain>

On Tue, 2006-10-10 at 13:01 -0400, David Miller wrote:
> The box has arrived, and Mozilla's IT is ready to run the p2v on
> landfill whenever we're ready.  The question now is, when are we ready?

	I think we could do it today (Wednesday). LpSolit is away, and we can
probably do it while _maki is asleep (or not doing QA). And they're the
only two people doing QA.

	Unless there are any objections, of course.

	I'll probably email mrz around 12pm or so, to have him take it down and
copy it over into the VM. I haven't asked him how long it will take,
just justdave said it could take a few hours, so the machine is likely
to be down for most of the afternoon.

	Just so everybody knows, the IP address of the machine will change.

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



From lpsolit at gmail.com  Wed Oct 11 16:38:46 2006
From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=)
Date: Wed, 11 Oct 2006 18:38:46 +0200
Subject: Time for Landfill to move again
In-Reply-To: <1160557034.7190.4.camel@localhost.localdomain>
References: <452BD1EC.5040306@bugzilla.org> <1160557034.7190.4.camel@localhost.localdomain>
Message-ID: <452D1E16.8000402@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> 	I think we could do it today (Wednesday). LpSolit is away, and we can
> probably do it while _maki is asleep (or not doing QA). And they're the
> only two people doing QA.
> 
> 	Unless there are any objections, of course.


There is an objection, from me!

I'm back now, and we plan to work hard on finishing QA tests today and
tomorrow (Friday on the latest). And in case you didn't notice, I did
some QA tests remotely while I was away. And I also noticed that
ghendricks did some while I was away too.

We are doing QA stuff twice per year, it's a non-sense to shutdown
landfill while we need it the most. Next week is soon enough. I don't
want to hear that landfill will be down for a longer period due to
unexpected problems. If such problems occur, I much prefer them to
happen while we don't need landfill.

LpSolit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFLR4WuG3TRgecPlsRAqvQAJwKLCvqFeEMFqCggPOj8o+u8TUWOACgkq7d
mlYRIgZlKFg1pw9bTtcNsB8=
=nUBU
-----END PGP SIGNATURE-----


From mkanat at bugzilla.org  Wed Oct 11 19:51:08 2006
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Wed, 11 Oct 2006 12:51:08 -0700
Subject: Time for Landfill to move again
In-Reply-To: <452D1E16.8000402@gmail.com>
References: <452BD1EC.5040306@bugzilla.org>
	 <1160557034.7190.4.camel@localhost.localdomain>
	 <452D1E16.8000402@gmail.com>
Message-ID: <1160596268.2474.0.camel@localhost.localdomain>

On Wed, 2006-10-11 at 18:38 +0200, Fr?d?ric Buclin wrote:
> There is an objection, from me!

	Ah, okay. You're back. :-) We'll do it after we release, then.

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



From vladd at bugzilla.org  Wed Oct 11 20:31:22 2006
From: vladd at bugzilla.org (Vlad Dascalu)
Date: Wed, 11 Oct 2006 23:31:22 +0300
Subject: Time for Landfill to move again
In-Reply-To: <1160596268.2474.0.camel@localhost.localdomain>
References: <452BD1EC.5040306@bugzilla.org>	 <1160557034.7190.4.camel@localhost.localdomain>	 <452D1E16.8000402@gmail.com> <1160596268.2474.0.camel@localhost.localdomain>
Message-ID: <452D549A.6050506@bugzilla.org>

Max Kanat-Alexander wrote:
> We'll do it after we release, then.
>   
D'oh :)


From myk at mozilla.org  Wed Oct 11 23:27:18 2006
From: myk at mozilla.org (Myk Melez)
Date: Wed, 11 Oct 2006 16:27:18 -0700
Subject: REST + microformats as a Bugzilla API
Message-ID: <452D7DD6.2010207@mozilla.org>


The enduring popularity of REST, coupled with the growing popularity of 
microformats, suggests to me that the most developer-, user-, and web- 
friendly way for us to build an API for Bugzilla is to integrate it with 
the app's existing user-focused mechanisms for requesting and retrieving 
information.

In other words, use REST for RPC, and return data-only responses when 
appropriate, but structure our HTML responses with embedded metadata (? 
la microformats) so clients can cleanly extract data from them.

Thoughts?

-myk



From mkanat at bugzilla.org  Wed Oct 11 23:56:44 2006
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Wed, 11 Oct 2006 16:56:44 -0700
Subject: REST + microformats as a Bugzilla API
In-Reply-To: <452D7DD6.2010207@mozilla.org>
References: <452D7DD6.2010207@mozilla.org>
Message-ID: <1160611004.2474.24.camel@localhost.localdomain>

On Wed, 2006-10-11 at 16:27 -0700, Myk Melez wrote:
> The enduring popularity of REST, coupled with the growing popularity of 
> microformats, suggests to me that the most developer-, user-, and web- 
> friendly way for us to build an API for Bugzilla is to integrate it with 
> the app's existing user-focused mechanisms for requesting and retrieving 
> information.
> 
> In other words, use REST for RPC, and return data-only responses when 
> appropriate, but structure our HTML responses with embedded metadata (? 
> la microformats) so clients can cleanly extract data from them.
> 
> Thoughts?

	I like having our XML-RPC API separate, because it's a lot easier to
keep it stable.

	We already have some semi-REST mechanisms, like the XML representation
of a bug.

	I like XML-RPC because it's easier to interact with it programmatically
from somewhere else--XML-RPC is a standard, so there are modules in all
languages to parse it.

	If we just have our own REST system, clients have to know exactly how
our particular system works. We also lose the functionality that our
XML-RPC server modules give us on the side of creating well-crafted
responses.

	Perhaps we could implement a sort of REST URL interface to our XML-RPC
API, which might make life easier for JavaScript developers and other
people who don't have an easily-accessible XML-RPC client package.

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



From ukh_dtl at yahoo.com  Fri Oct 13 05:02:29 2006
From: ukh_dtl at yahoo.com (ukhas jean)
Date: Thu, 12 Oct 2006 22:02:29 -0700 (PDT)
Subject: Regarding  templates.
Message-ID: <20061013050229.66481.qmail@web31712.mail.mud.yahoo.com>

Hi all ...
   
   In order to add a control ... is it mandatory to use the .tmpl file?? for eg. i wanted to add a control (an HTML select) to bug_form.pl ... so is it necessary to edit the bugform_redhat.tmpl file as well??
   
  Best,
  Ukh

 				
---------------------------------
Get your own web address for just $1.99/1st yr. We'll help. Yahoo! Small Business.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20061012/4a81ce06/attachment.html>

From mkanat at bugzilla.org  Fri Oct 13 05:13:03 2006
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Thu, 12 Oct 2006 22:13:03 -0700
Subject: Regarding  templates.
In-Reply-To: <20061013050229.66481.qmail@web31712.mail.mud.yahoo.com>
References: <20061013050229.66481.qmail@web31712.mail.mud.yahoo.com>
Message-ID: <1160716383.2368.3.camel@es-lappy>

On Thu, 2006-10-12 at 22:02 -0700, ukhas jean wrote:
>  In order to add a control ... is it mandatory to use the .tmpl file??
> for eg. i wanted to add a control (an HTML select) to bug_form.pl ...
> so is it necessary to edit the bugform_redhat.tmpl file as well??

	Hi Ukh. Is this for upstream development, or for a local customization?

	For a local customization, you should ask on the support-bugzilla
mailing list, which you can see information about here:

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

	-Max

-- 
http://www.everythingsolved.com/
Everything Solved: Competent, Friendly Bugzilla and Linux Services



From lpsolit at gmail.com  Sat Oct 14 16:30:25 2006
From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=)
Date: Sat, 14 Oct 2006 18:30:25 +0200
Subject: Minutes of the Bugzilla meeting + News about the new releases
Message-ID: <453110A1.8060008@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The minutes of our last Bugzilla meeting are finally here:
http://wiki.mozilla.org/Bugzilla:Meetings:2006-10-03

Note that we will meet again next Tuesday (3 days from now) in
#bugzilla-meeting. The discussion will probably be about the new
releases (going to be out tonight) and about what we need to do in the
next few weeks to prepare 3.0 RC1. You are free to attend, as usual.

About the releases, note that I closed the trunk for checkins a few
hours ago in order to prepare 2.23.3, 2.22.1, 2.20.3 and 2.18.6.
Branches were already closed several days ago when we started QA
testing. I'm going to check in the 21(!) security patches in the coming
few hours and mkanat will update the website (bugzilla.org) and create
the tarballs right after that. When the tarballs will be ready, we will
open the trunk and branches again.


LpSolit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFMRChuG3TRgecPlsRAiipAJ405D3oCbR0e/kHtE3Hmtt85LwyKQCeILsw
ALColi7CwrtnmOBTte7GY5c=
=H3/n
-----END PGP SIGNATURE-----


From mkanat at bugzilla.org  Sun Oct 15 10:11:45 2006
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Sun, 15 Oct 2006 03:11:45 -0700
Subject: Releases Done, Trunk Open
Message-ID: <1160907105.2465.20.camel@es-lappy>

	Hey hey. So, the releases are all done and released.

	So, I assume this means the trunk is open for checkins and approvals.

	Remember that we now have two weeks until we freeze.

	The freeze date will be the end of Sunday, October 29. (So, we'll be
frozen on Monday, October 30.)

	-Max
-- 
http://www.everythingsolved.com/
Everything Solved: Competent, Friendly Bugzilla and Linux Services



From jochen.wiedmann at gmail.com  Sun Oct 15 13:39:10 2006
From: jochen.wiedmann at gmail.com (Jochen Wiedmann)
Date: Sun, 15 Oct 2006 15:39:10 +0200
Subject: Releases Done, Trunk Open
In-Reply-To: <1160907105.2465.20.camel@es-lappy>
References: <1160907105.2465.20.camel@es-lappy>
Message-ID: <e75283b10610150639q6e1d1252p8c3247246095b0be@mail.gmail.com>

On 10/15/06, Max Kanat-Alexander <mkanat at bugzilla.org> wrote:

>         Hey hey. So, the releases are all done and released.

Good work, thank you!

OT question, as I was just about to check the state of germzilla in
relation to the new releases: Does anyone know what happened to
wurblzap.net? The NS records are all gone.

Thanks,

Jochen

-- 
My wife Mary and I have been married for forty-seven years and not
once have we had an argument serious enough to consider divorce;
murder, yes, but divorce, never.
(Jack Benny)


From bugzilla at colinogilvie.co.uk  Sun Oct 15 16:19:00 2006
From: bugzilla at colinogilvie.co.uk (Colin Ogilvie)
Date: Sun, 15 Oct 2006 17:19:00 +0100
Subject: Documentation for Bugzilla 3.0
Message-ID: <200610151719.01009.bugzilla@colinogilvie.co.uk>

Hi

Over the last few releases, new features have been added to Bugzilla, but 
there has sometimes been very little documentation written for them.

If you are either the author of one of these new features, or simply a user of 
them, please help bring the documentation up to speed for that feature... it 
would be great to be able to ship Bugzilla 3.0 with some documentation for 
the majority of features.

The biggest way to help is by writing documentation ? even just as a text file 
attached to a bug without any XML formatting etc. around it would be a good 
start ? someone else that knows the docbook format could then convert it to 
the format we require for the guide.

You could also take a look at the open documentation bugs 
(http://tinyurl.com/ye39qb) and see if you are able to write documentation 
for any of them.

Colin

-- 
Colin Ogilvie
bugzilla at colinogilvie.co.uk



From gerv at mozilla.org  Mon Oct 16 11:30:32 2006
From: gerv at mozilla.org (Gervase Markham)
Date: Mon, 16 Oct 2006 12:30:32 +0100
Subject: Documentation for Bugzilla 3.0
In-Reply-To: <200610151719.01009.bugzilla@colinogilvie.co.uk>
References: <200610151719.01009.bugzilla@colinogilvie.co.uk>
Message-ID: <45336D58.8090800@mozilla.org>

Colin Ogilvie wrote:
> Over the last few releases, new features have been added to Bugzilla, but 
> there has sometimes been very little documentation written for them.

Are you able to say which releases, or even better which features? :-)

Gerv


From bugzilla at colinogilvie.co.uk  Mon Oct 16 11:56:50 2006
From: bugzilla at colinogilvie.co.uk (Colin Ogilvie)
Date: Mon, 16 Oct 2006 12:56:50 +0100
Subject: Documentation for Bugzilla 3.0
Message-ID: <cae74fbee0cb35f07e4b0ddcf90c4fb1@webmail.plus.net>

On Mon Oct 16 12:30 , Gervase Markham <gerv at mozilla.org> sent:
>Are you able to say which releases, or even better which features? :-)

Not off the top of my head, no. The open bugs are probably a better idea, but
there's things that have gone in to 3.0 that don't have documentation or
reference in the manual.

I hope to try and have a look and see at some point this week, if other things
allow for it.

Colin


From justdave at bugzilla.org  Mon Oct 16 18:56:44 2006
From: justdave at bugzilla.org (David Miller)
Date: Mon, 16 Oct 2006 14:56:44 -0400
Subject: Time for Landfill to move again
In-Reply-To: <1160596268.2474.0.camel@localhost.localdomain>
References: <452BD1EC.5040306@bugzilla.org>	 <1160557034.7190.4.camel@localhost.localdomain>	 <452D1E16.8000402@gmail.com> <1160596268.2474.0.camel@localhost.localdomain>
Message-ID: <4533D5EC.9050802@bugzilla.org>

Max Kanat-Alexander wrote on 10/11/06 3:51 PM:
> On Wed, 2006-10-11 at 18:38 +0200, Fr?d?ric Buclin wrote:
>> There is an objection, from me!
> 
> 	Ah, okay. You're back. :-) We'll do it after we release, then.

OK, we released.  Unless there's further objections, we're going to
image the existing landfill into the VM tomorrow (Tuesday) during PDT
business hours.

-- 
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  Mon Oct 16 20:02:50 2006
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Mon, 16 Oct 2006 13:02:50 -0700
Subject: Time for Landfill to move again
In-Reply-To: <4533D5EC.9050802@bugzilla.org>
References: <452BD1EC.5040306@bugzilla.org>
	 <1160557034.7190.4.camel@localhost.localdomain>
	 <452D1E16.8000402@gmail.com>
	 <1160596268.2474.0.camel@localhost.localdomain>
	 <4533D5EC.9050802@bugzilla.org>
Message-ID: <1161028971.2366.4.camel@es-lappy>

On Mon, 2006-10-16 at 14:56 -0400, David Miller wrote:
> OK, we released.  Unless there's further objections, we're going to
> image the existing landfill into the VM tomorrow (Tuesday) during PDT
> business hours.

	That's fine with me.

	-Max
-- 
http://www.everythingsolved.com/
Everything Solved: Competent, Friendly Bugzilla and Linux Services



From kmaksimov at naumen.ru  Mon Oct 16 11:57:19 2006
From: kmaksimov at naumen.ru (Kirill A Maksimov)
Date: Mon, 16 Oct 2006 17:57:19 +0600
Subject: web services
Message-ID: <4533739F.7010201@naumen.ru>

Hello,

I've written my own service in Bugzilla/WebServices/Bug.pm

sub create_bug {

    my $self = shift;

    Bugzilla->login;    

    $b = Bugzilla::Bug -> create ({'bug_severity' => 'enhancement',

    'component' => 'TestComponent',

    'creation_ts' => '2006.04.18 14:46',

    'op_sys' => 'Linux',

    'priority' => 'P2' ,

    'product' => 'TestProduct',

    'rep_platform' => 'PC',

    'short_desc' => 'abc',

    'version' => 'other',

    });    

    return $b;    

}


I've received a fault:

xmlrpclib.Fault: <Fault Server: 'Undefined subroutine &Component::check_component called at Bugzilla/Bug.pm line 560.\n'>


What's wrong?

-- 
Thanks for assistance,
Kirill A Maksimov, Naumen



From mkanat at bugzilla.org  Tue Oct 17 01:25:27 2006
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Mon, 16 Oct 2006 18:25:27 -0700
Subject: web services
In-Reply-To: <4533739F.7010201@naumen.ru>
References: <4533739F.7010201@naumen.ru>
Message-ID: <1161048327.2926.3.camel@es-lappy>

On Mon, 2006-10-16 at 17:57 +0600, Kirill A Maksimov wrote:
> I've written my own service in Bugzilla/WebServices/Bug.pm

	For local customizations, the best place to ask questions is the
bugzilla-support list, which you can see details on here:

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

	There's no need to create your own create_bug subroutine--3.0 will have
one. There's even a patch that exists now in Bugzilla that you could
apply to a 2.23.3, for this functionality. Just search for "create" and
"webservice."

	-Max
-- 
http://www.everythingsolved.com/
Everything Solved: Competent, Friendly Bugzilla and Linux Services



From myk at mozilla.org  Tue Oct 17 01:50:17 2006
From: myk at mozilla.org (Myk Melez)
Date: Mon, 16 Oct 2006 18:50:17 -0700
Subject: REST + microformats as a Bugzilla API
In-Reply-To: <1160611004.2474.24.camel@localhost.localdomain>
References: <452D7DD6.2010207@mozilla.org> <1160611004.2474.24.camel@localhost.localdomain>
Message-ID: <453436D9.4010903@mozilla.org>

Max Kanat-Alexander wrote:
> I like having our XML-RPC API separate, because it's a lot easier to
> keep it stable.
>   
Sure, understood.  In any case, I'm not particularly concerned with 
whether or not to keep XML-RPC.

The piece I'm mostly interested in is the way we design our HTML 
responses.  I think it would be productive for us to structure them with 
embedded metadata so clients which want to use them to programmatically 
access data can do so.

-myk



From mkanat at bugzilla.org  Tue Oct 17 05:32:51 2006
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Mon, 16 Oct 2006 22:32:51 -0700
Subject: REST + microformats as a Bugzilla API
In-Reply-To: <453436D9.4010903@mozilla.org>
References: <452D7DD6.2010207@mozilla.org>
	 <1160611004.2474.24.camel@localhost.localdomain>
	 <453436D9.4010903@mozilla.org>
Message-ID: <1161063172.2794.1.camel@es-lappy>

On Mon, 2006-10-16 at 18:50 -0700, Myk Melez wrote:
> The piece I'm mostly interested in is the way we design our HTML 
> responses.  I think it would be productive for us to structure them with 
> embedded metadata so clients which want to use them to programmatically 
> access data can do so.

	Sure, I think it's something we can consider. It could be cool and
useful.

	Usually I like to have some consumer who wants something, before we
implement it. For example, we have *lots* of people who have wanted the
XML-RPC interface for a long time, so that gives us a good idea of how
to implement it, because they'll say "Oh, it really needs to do THIS."

	It would be interesting to know who our REST clients would be, and we
could give them what they'd be most interested in.

	-Max
-- 
http://www.everythingsolved.com/
Everything Solved: Competent, Friendly Bugzilla and Linux Services



From jochen.wiedmann at gmail.com  Tue Oct 17 06:45:03 2006
From: jochen.wiedmann at gmail.com (Jochen Wiedmann)
Date: Tue, 17 Oct 2006 08:45:03 +0200
Subject: REST + microformats as a Bugzilla API
In-Reply-To: <1161063172.2794.1.camel@es-lappy>
References: <452D7DD6.2010207@mozilla.org>
	 <1160611004.2474.24.camel@localhost.localdomain>
	 <453436D9.4010903@mozilla.org> <1161063172.2794.1.camel@es-lappy>
Message-ID: <e75283b10610162345v3facc165q646b50c6365dbfec@mail.gmail.com>

On 10/17/06, Max Kanat-Alexander <mkanat at bugzilla.org> wrote:

>         Usually I like to have some consumer who wants something, before we
> implement it. For example, we have *lots* of people who have wanted the
> XML-RPC interface for a long time, so that gives us a good idea of how
> to implement it, because they'll say "Oh, it really needs to do THIS."
>
>         It would be interesting to know who our REST clients would be, and we
> could give them what they'd be most interested in.

I believe the discussion only demonstrates that the web services
interface should be (and possibly is?) designed in a manner that
allows to separate transport and logic. Assuming that the XML-RPC
interface takes as input mainly scalar variables (like those created
from an HTML form), then it should be one or two hours work to add a
REST interface, should that be required.

Also note, that a REST interface is clearly less powerful than a fully
blown SOAP interface or an XML-RPC interface. In particular, the
latter allow to transmit hashes, arrays, and nested data structures.
May be we don't need that now, but why forfeit the possibility without
a good reason?

Jochen


-- 
My wife Mary and I have been married for forty-seven years and not
once have we had an argument serious enough to consider divorce;
murder, yes, but divorce, never.
(Jack Benny)


From mkanat at bugzilla.org  Tue Oct 17 06:58:57 2006
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Mon, 16 Oct 2006 23:58:57 -0700
Subject: Inbound Email
Message-ID: <1161068337.2794.23.camel@es-lappy>

	Hey hey. So, we have an inbound email interface that's standardly part
of Bugzilla, now. You can see its documentation here:

	http://www.bugzilla.org/docs/tip/html/api/email_in.html

	This interface can create and update bugs.

	The syntax of emails may change before the actual release of Bugzilla
3.0.

	The old contrib/bug_email interface is going away.

	-Max
-- 
http://www.everythingsolved.com/
Everything Solved: Competent, Friendly Bugzilla and Linux Services



From gerv at mozilla.org  Tue Oct 17 09:09:36 2006
From: gerv at mozilla.org (Gervase Markham)
Date: Tue, 17 Oct 2006 10:09:36 +0100
Subject: REST + microformats as a Bugzilla API
In-Reply-To: <453436D9.4010903@mozilla.org>
References: <452D7DD6.2010207@mozilla.org> <1160611004.2474.24.camel@localhost.localdomain> <453436D9.4010903@mozilla.org>
Message-ID: <45349DD0.4010800@mozilla.org>

Myk Melez wrote:
> The piece I'm mostly interested in is the way we design our HTML 
> responses.  I think it would be productive for us to structure them with 
> embedded metadata so clients which want to use them to programmatically 
> access data can do so.

My concern here is that, by doing this, we create another interface 
which we have to keep stable. That means we reduce our flexibility to 
change the interface based on usability or other feedback, or as web 
standards evolve. Say we wanted to switch show_bug to entirely semantic 
markup. What if someone was depending on the fact that we used a table 
in order to navigate to the node they wanted?

Additionally, because the metadata is embedded in a browser-viewable 
HTML response, it's also not completely clear what the interface 
actually is. One client may choose to access the attachment list using 
the equivalent of getElementsByClassName("attachment"), another may 
choose getElementsById("attachments").childNodes() or something like 
that. Unless we plan to document the supported methods for extracting 
the data?

It would certainly be useful to have some concrete use cases, along with 
a reason why our current web services interface is inappropriate in each 
case.

Gerv



From dwilliss at microimages.com  Tue Oct 17 15:46:35 2006
From: dwilliss at microimages.com (Dave Williss)
Date: Tue, 17 Oct 2006 10:46:35 -0500
Subject: REST + microformats as a Bugzilla API
In-Reply-To: <1161063172.2794.1.camel@es-lappy>
References: <452D7DD6.2010207@mozilla.org>	 <1160611004.2474.24.camel@localhost.localdomain>	 <453436D9.4010903@mozilla.org> <1161063172.2794.1.camel@es-lappy>
Message-ID: <4534FADB.5080701@microimages.com>



Max Kanat-Alexander wrote:
>
> 	It would be interesting to know who our REST clients would be, and we
> could give them what they'd be most interested in.
>
> 	-Max
>   

This is something I would like to be able to use here.  We have an 
automated testing system here that we wrote ourselves. It keeps all it's 
state information in a MySQL database.  Through its web interface, a 
programmer of QA person can see what tests are failing and determine 
what bugs to write up.  When they write up the bug, they enter the 
bugzilla id on the page for that test, and mark the test as disabled so 
they don't keep getting bugged about it.

Every hour, the test system does a query of the Bugzilla database to see 
if any of the bugs it's blocking on are "RESOLVED FIXED" and re-enables 
any tests on those bugs.

It also checks for any tests which have bugzilla ids attached to them 
which are now passing and if it finds any, does the following..

    # INSERT CODE HERE -- Mark the bug as VERIFIED in Bugzilla.

Having a REST or SOAP XML-RPC interface would allow me to insert that 
code there :-)



From mkanat at bugzilla.org  Tue Oct 17 17:37:01 2006
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Tue, 17 Oct 2006 10:37:01 -0700
Subject: REST + microformats as a Bugzilla API
In-Reply-To: <4534FADB.5080701@microimages.com>
References: <452D7DD6.2010207@mozilla.org>
	 <1160611004.2474.24.camel@localhost.localdomain>
	 <453436D9.4010903@mozilla.org> <1161063172.2794.1.camel@es-lappy>
	 <4534FADB.5080701@microimages.com>
Message-ID: <1161106621.2372.0.camel@es-lappy>

On Tue, 2006-10-17 at 10:46 -0500, Dave Williss wrote:
> Having a REST or SOAP XML-RPC interface would allow me to insert that 
> code there :-)

	We have an XML-RPC interface, for 3.0. What we're discussing is whether
or not we also need a REST interface. It sounds like your use case would
be happier with the standard XML-RPC interface than a REST interface,
most likely.

	-Max
-- 
http://www.everythingsolved.com/
Everything Solved: Competent, Friendly Bugzilla and Linux Services



From myk at mozilla.org  Tue Oct 17 21:30:43 2006
From: myk at mozilla.org (Myk Melez)
Date: Tue, 17 Oct 2006 14:30:43 -0700
Subject: REST + microformats as a Bugzilla API
In-Reply-To: <1161063172.2794.1.camel@es-lappy>
References: <452D7DD6.2010207@mozilla.org>	 <1160611004.2474.24.camel@localhost.localdomain>	 <453436D9.4010903@mozilla.org> <1161063172.2794.1.camel@es-lappy>
Message-ID: <45354B83.7050006@mozilla.org>

Max Kanat-Alexander wrote:

> 	We have an XML-RPC interface, for 3.0. What we're discussing is whether
> or not we also need a REST interface.
I'd rephrase this a bit to say that we also have a REST interface, and 
what we're discussing is whether to treat it as an interface for clients 
in addition to users.

> 	Usually I like to have some consumer who wants something, before we
> implement it. For example, we have *lots* of people who have wanted the
> XML-RPC interface for a long time, so that gives us a good idea of how
> to implement it, because they'll say "Oh, it really needs to do THIS."
>
> 	It would be interesting to know who our REST clients would be, and we
> could give them what they'd be most interested in.
>   
I agree that we're better off with concrete use cases.  Here's one:

Some engineers at Mozilla (mconnor in particular) use microsummaries to 
keep track of bug counts.  They bookmark bug lists and use a 
microsummary generator to make the label of the bookmark include the 
number of bugs in the list.

The generator updates the bug count periodically by executing a query 
via our REST API (i.e. it requests a URL), downloading the resulting bug 
list, and extracting the bug count from it.

But bug counts are hard to extract from bug lists, because they aren't 
labeled as such.  They are merely inserted as raw text into the HTML 
which comprises a bug list.  They aren't even surrounded by a generic 
element like a DIV or a SPAN to distinguish them from surrounding 
whitespace, and the actual number isn't separated from its "bugs found" 
label.

So instead of extracting a specific node, the generator has to identify 
some other node, travel along a path from that node to the text node 
containing the bug count, and then extract the number from that node.

And since we don't treat the count as data that should be 
programmatically accessible, we're liable to change its location from 
version to version, breaking the existing mechanism for extracting it.

If we treated our REST API as an interface for clients and our HTML as 
structured data, on the other hand, ? la microformats, then we might 
surround the bug count with a span identifying it:

<span id="bz_bug_count">41</span> bugs found

And then the generator would be able to extract the number by simply 
referencing the specific node in which it was found.

This doesn't tie our hands against future changes.  We could still move 
this information around in the document.  We could even change the tag 
we use to mark up the number (advising developers to key off the ID only 
and not the tag+ID combination).

All this does is make it possible to extract the information we already 
provide as data, and to do so in a way which is safe against future 
modifications to the HTML in which it is embedded.

-myk



From gerv at mozilla.org  Wed Oct 18 18:47:37 2006
From: gerv at mozilla.org (Gervase Markham)
Date: Wed, 18 Oct 2006 19:47:37 +0100
Subject: REST + microformats as a Bugzilla API
In-Reply-To: <45354B83.7050006@mozilla.org>
References: <452D7DD6.2010207@mozilla.org>	 <1160611004.2474.24.camel@localhost.localdomain>	 <453436D9.4010903@mozilla.org> <1161063172.2794.1.camel@es-lappy> <45354B83.7050006@mozilla.org>
Message-ID: <453676C9.1000001@mozilla.org>

Myk Melez wrote:
> This doesn't tie our hands against future changes.  We could still move 
> this information around in the document.  We could even change the tag 
> we use to mark up the number (advising developers to key off the ID only 
> and not the tag+ID combination).

As long as we keep stuff to this sort of level (i.e. we don't tie our 
hands about tag choice or structure), and as long as we document each ID 
we add for this purpose (in the relevant template header and in whatever 
public "here's our API" document we have), I'd be happy with it.

Gerv




From myk at mozilla.org  Wed Oct 18 19:18:42 2006
From: myk at mozilla.org (Myk Melez)
Date: Wed, 18 Oct 2006 12:18:42 -0700
Subject: REST + microformats as a Bugzilla API
In-Reply-To: <453676C9.1000001@mozilla.org>
References: <452D7DD6.2010207@mozilla.org>	 <1160611004.2474.24.camel@localhost.localdomain>	 <453436D9.4010903@mozilla.org> <1161063172.2794.1.camel@es-lappy> <45354B83.7050006@mozilla.org> <453676C9.1000001@mozilla.org>
Message-ID: <45367E12.3000503@mozilla.org>

Gervase Markham wrote:
> As long as we keep stuff to this sort of level (i.e. we don't tie our 
> hands about tag choice or structure),
I think we should follow the lead of the microformats project, using 
actual microformats 
<http://microformats.org/wiki/Main_Page#Design_Patterns>, microformats 
design patterns 
<http://microformats.org/wiki/Main_Page#Design_Patterns>, or homegrown 
formats/patterns as appropriate.

Note that this might imply tag choice or structure in some cases.  But 
even if it does, that doesn't mean it ties our hands, since we can 
decide to change an API.  We should judge each case individually instead 
of deciding in advance what we can and cannot do.

> and as long as we document each ID we add for this purpose (in the 
> relevant template header and in whatever public "here's our API" 
> document we have)
I don't think we should make this an official API that we require our 
developers to document just yet.

Rather, I think we should just keep structured data in mind when writing 
(and revising) our HTML output, just as we already keep stylability in 
mind.  And since the two overlap to a significant degree, so this 
doesn't require much change.

-myk

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

From gerv at mozilla.org  Thu Oct 19 07:09:12 2006
From: gerv at mozilla.org (Gervase Markham)
Date: Thu, 19 Oct 2006 08:09:12 +0100
Subject: REST + microformats as a Bugzilla API
In-Reply-To: <45367E12.3000503@mozilla.org>
References: <452D7DD6.2010207@mozilla.org>	 <1160611004.2474.24.camel@localhost.localdomain>	 <453436D9.4010903@mozilla.org> <1161063172.2794.1.camel@es-lappy> <45354B83.7050006@mozilla.org> <453676C9.1000001@mozilla.org> <45367E12.3000503@mozilla.org>
Message-ID: <45372498.5010302@mozilla.org>

Myk Melez wrote:
> I don't think we should make this an official API that we require our 
> developers to document just yet.

Well, then we need to make it clear to anyone who uses it (mconnor in 
your example) that it might break at any time.

Gerv



From myk at mozilla.org  Thu Oct 19 09:25:50 2006
From: myk at mozilla.org (Myk Melez)
Date: Thu, 19 Oct 2006 02:25:50 -0700
Subject: REST + microformats as a Bugzilla API
In-Reply-To: <45372498.5010302@mozilla.org>
References: <452D7DD6.2010207@mozilla.org>	 <1160611004.2474.24.camel@localhost.localdomain>	 <453436D9.4010903@mozilla.org> <1161063172.2794.1.camel@es-lappy> <45354B83.7050006@mozilla.org> <453676C9.1000001@mozilla.org> <45367E12.3000503@mozilla.org> <45372498.5010302@mozilla.org>
Message-ID: <4537449E.8010306@mozilla.org>

Gervase Markham wrote:
> Myk Melez wrote:
>> I don't think we should make this an official API that we require our 
>> developers to document just yet.
>
> Well, then we need to make it clear to anyone who uses it (mconnor in 
> your example) that it might break at any time.
I agree.  Once we're further down the road of structured data, and we 
have more use cases to help us understand its value, we can better make 
a decision about the degree to which we want to support it as a stable API.

-myk



From lpsolit at gmail.com  Thu Oct 19 15:22:24 2006
From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=)
Date: Thu, 19 Oct 2006 17:22:24 +0200
Subject: Releases Done, Trunk Open
In-Reply-To: <e75283b10610150639q6e1d1252p8c3247246095b0be@mail.gmail.com>
References: <1160907105.2465.20.camel@es-lappy> <e75283b10610150639q6e1d1252p8c3247246095b0be@mail.gmail.com>
Message-ID: <45379830.6010805@gmail.com>

> OT question, as I was just about to check the state of germzilla in
> relation to the new releases: Does anyone know what happened to
> wurblzap.net? The NS records are all gone.

Marc said his website was down due to a problem with his provider. He
told me to redirect you to support-bugzilla at bugzilla.org where he will
be happy to reply to you. CC'ing Marc too.


LpSolit


From lpsolit at gmail.com  Thu Oct 19 15:27:16 2006
From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=)
Date: Thu, 19 Oct 2006 17:27:16 +0200
Subject: Documentation for Bugzilla 3.0
In-Reply-To: <45336D58.8090800@mozilla.org>
References: <200610151719.01009.bugzilla@colinogilvie.co.uk> <45336D58.8090800@mozilla.org>
Message-ID: <45379954.7070307@gmail.com>

> Are you able to say which releases, or even better which features? :-)

Which features? Very easy:

https://bugzilla.mozilla.org/request.cgi?action=queue&product=Bugzilla&type=documentation&group=type


LpSolit



From kevin.benton at amd.com  Thu Oct 19 19:34:52 2006
From: kevin.benton at amd.com (Benton, Kevin)
Date: Thu, 19 Oct 2006 12:34:52 -0700
Subject: Inbound Email
Message-ID: <D85E06673A2DFF44B221CF78D1CBB11BB549F5@SSVLEXMB1.amd.com>

> 	Hey hey. So, we have an inbound email interface that's
standardly
> part
> of Bugzilla, now. You can see its documentation here:
> 
> 	http://www.bugzilla.org/docs/tip/html/api/email_in.html
> 
> 	This interface can create and update bugs.
> 
> 	The syntax of emails may change before the actual release of
> Bugzilla
> 3.0.
> 
> 	The old contrib/bug_email interface is going away.

Is there a way in this interface to specifically reject attachments or
at least to specify one or more regexes of addresses where they're
allowed to come from?  Some are worried about inbound email not being
virus-checked properly and want to prevent the potential for spammed
worms.

---
Kevin Benton
Senior Software Developer
Advanced Micro Devices (AMD)
3665 John F Kennedy Parkway
Building 1 Suite 206
Fort Collins, CO  80525

The opinions stated in this communication do not necessarily reflect the
view of Advanced Micro Devices and have not been reviewed by management.
This communication may contain sensitive and/or confidential and/or
proprietary information.  Distribution of such information is strictly
prohibited without prior consent of Advanced Micro Devices.  This
communication is for the intended recipient(s) only.  If you have
received this communication in error, please notify the sender, then
destroy any remaining copies of this communication.





From mkanat at bugzilla.org  Thu Oct 19 20:22:15 2006
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Thu, 19 Oct 2006 13:22:15 -0700
Subject: Inbound Email
In-Reply-To: <D85E06673A2DFF44B221CF78D1CBB11BB549F5@SSVLEXMB1.amd.com>
References: <D85E06673A2DFF44B221CF78D1CBB11BB549F5@SSVLEXMB1.amd.com>
Message-ID: <1161289335.2539.7.camel@max>

On Thu, 2006-10-19 at 12:34 -0700, Benton, Kevin wrote:
> Is there a way in this interface to specifically reject attachments or
> at least to specify one or more regexes of addresses where they're
> allowed to come from?  Some are worried about inbound email not being
> virus-checked properly and want to prevent the potential for spammed
> worms.

	Well, the current interface rejects all attachments, because I haven't
implemented attachment support yet. :-) (Although I will for 3.0.)

	After we have attachment support, you could file a bug requesting that
functionality.

	As far as virus-checking goes, I highly recommend that all system
administrators have virus-checkers in their MTAs, of course.

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



From mkanat at bugzilla.org  Thu Oct 19 20:24:42 2006
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Thu, 19 Oct 2006 13:24:42 -0700
Subject: API Docs Easily Accessible from bugzilla.org
Message-ID: <1161289482.2539.10.camel@max>

	Just so everybody knows, the API (POD) docs are now easily accessible
from www.bugzilla.org. You can see the link in the "Developer Resources"
section. Also, here's the direct link:

	http://www.bugzilla.org/docs/tip/html/api/

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



From micklweiss at gmx.net  Fri Oct 20 02:27:44 2006
From: micklweiss at gmx.net (Mick Weiss)
Date: Thu, 19 Oct 2006 22:27:44 -0400
Subject: cvs web?
In-Reply-To: <444AF2DA.3050304@bugzilla.org>
References: <43AA1639.6000007@gmx.net> <43AA19DD.5070605@peshkin.net> <43AA46A5.3070109@gmx.net> <444AF2DA.3050304@bugzilla.org>
Message-ID: <45383420.6020800@gmx.net>

Heh, thanks - I'm also catching up on some "old mail" :-)

- Mick


David Miller wrote:
> Mick Weiss wrote on 12/22/05 1:24 AM:
>> Joel Peshkin wrote:
>>
>>> Mick Weiss wrote:
>>>
>>>> I was just on the download site again, and I noticed that there is
>>>> no way to browse cvs from the web:
>>>> http://www.bugzilla.org/download/#cvs
>>>>
>>>> Is it not possible, or not listed on the site? I always find this
>>>> to be very useful :-)
>>>>
>>> Not exactly, but....
>>> http://lxr.mozilla.org/mozilla/source/webtools/bugzilla/
>>> http://bonsai.mozilla.org/rview.cgi?dir=mozilla/webtools/bugzilla&cvsroot=/cvsroot
>>
>>
>> Wouldn't that be worth adding to http://www.bugzilla.org/download/#cvs ?
>
> OK, this is done now.  I'm way behind catching up on some old mail :)
>



From gerv at mozilla.org  Fri Oct 20 15:51:20 2006
From: gerv at mozilla.org (Gervase Markham)
Date: Fri, 20 Oct 2006 16:51:20 +0100
Subject: Inbound Email
In-Reply-To: <1161068337.2794.23.camel@es-lappy>
References: <1161068337.2794.23.camel@es-lappy>
Message-ID: <4538F078.4030403@mozilla.org>

Max Kanat-Alexander wrote:
> 	Hey hey. So, we have an inbound email interface that's standardly part
> of Bugzilla, now. You can see its documentation here:
> 
> 	http://www.bugzilla.org/docs/tip/html/api/email_in.html

"The @ labels can be any valid field name in Bugzilla that can be set on 
enter_bug.cgi. For the list of field names, see the fielddefs table in 
the database."

Any chance of some sensible, limited aliasing here, to remove some of 
the historical warts from our field names? For example:

"summary" for "short_desc"
"platform" for "rep_platform"
"url" for "bug_file_loc"
"status" for "bug_status"
"severity" for "bug_severity"

No-one is going to know to use "bug_file_loc" for URL, for example...

Gerv


From mkanat at bugzilla.org  Fri Oct 20 19:47:03 2006
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Fri, 20 Oct 2006 12:47:03 -0700
Subject: Inbound Email
In-Reply-To: <4538F078.4030403@mozilla.org>
References: <1161068337.2794.23.camel@es-lappy>
	 <4538F078.4030403@mozilla.org>
Message-ID: <1161373623.2479.0.camel@max>

On Fri, 2006-10-20 at 16:51 +0100, Gervase Markham wrote:
> Any chance of some sensible, limited aliasing here, to remove some of 
> the historical warts from our field names? For example:
> 
> "summary" for "short_desc"
> "platform" for "rep_platform"
> "url" for "bug_file_loc"
> "status" for "bug_status"
> "severity" for "bug_severity"
> 
> No-one is going to know to use "bug_file_loc" for URL, for example...

	Yeah, I think that's a good idea. I'm doing the same thing for the
XML-RPC interface, so we could do that.

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



From myk at melez.com  Sun Oct 22 03:24:11 2006
From: myk at melez.com (Myk Melez)
Date: Sat, 21 Oct 2006 20:24:11 -0700
Subject: [Fwd: Re: [Sysadmin] upgrades made]
Message-ID: <453AE45B.3040505@melez.com>

FYI, mozdev on Bugzilla upgrades...

-------- Original Message --------
Subject: 	Re: [Sysadmin] upgrades made
Date: 	Fri, 20 Oct 2006 14:29:29 -0700 (PDT)
From: 	David Boswell <davidwboswell at yahoo.com>
Reply-To: 	sysadmin at mozdev.org
To: 	sysadmin at mozdev.org



> Regarding the upgrade of bugzilla I sent a mail yesterday to 
> sysadmin at mozdev.org. Has anyone already tested the new instance on 
> http://bugzilla.vebzom.org ...?

I did some clicking around on stage and things looked fine.  Bugzilla
upgrades in the past have tended to go smoothly.  In fact, we're not
usually even aware of the upgrades because it has been automatically
updated monthly and things haven't tended to break when this has
happened.

David


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

From lpsolit at gmail.com  Sun Oct 29 20:05:33 2006
From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=)
Date: Sun, 29 Oct 2006 21:05:33 +0100
Subject: Bugzilla meeting on Tuesday, October 31st, 2006
Message-ID: <4545098D.50907@gmail.com>

We will have our 20th Bugzilla meeting this Tuesday, October 31st, 2006
at 18:00 GMT (11:00 PDT, 20:00 CEST) in the #bugzilla-meeting channel.

We will know a bit more about progress towards Bugzilla 3.0 RC1. There
are still 13 unfixed blockers and some enhancement bugs we would like to
see implemented for 3.0. More information on Tuesday.


LpSolit


From gerv at mozilla.org  Mon Oct 30 15:40:25 2006
From: gerv at mozilla.org (Gervase Markham)
Date: Mon, 30 Oct 2006 15:40:25 +0000
Subject: Bugzilla meeting on Tuesday, October 31st, 2006
In-Reply-To: <4545098D.50907@gmail.com>
References: <4545098D.50907@gmail.com>
Message-ID: <45461CE9.1050407@mozilla.org>

Fr?d?ric Buclin wrote:
> We will have our 20th Bugzilla meeting this Tuesday, October 31st, 2006
> at 18:00 GMT (11:00 PDT, 20:00 CEST) in the #bugzilla-meeting channel.

Now we are no longer using Daylight Savings Time, 18:00 GMT is 10:00 PDT 
and, I believe, 19:00 CEST. Could you clarify exactly what time the 
meeting is?

Gerv



From lpsolit at gmail.com  Mon Oct 30 16:27:59 2006
From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=)
Date: Mon, 30 Oct 2006 17:27:59 +0100
Subject: Bugzilla meeting on Tuesday, October 31st, 2006
In-Reply-To: <45461CE9.1050407@mozilla.org>
References: <4545098D.50907@gmail.com> <45461CE9.1050407@mozilla.org>
Message-ID: <4546280F.4010108@gmail.com>

> Now we are no longer using Daylight Savings Time, 18:00 GMT is 10:00 PDT
> and, I believe, 19:00 CEST. Could you clarify exactly what time the
> meeting is?


Argh, right! The meeting will take place at 19:00 GMT, i.e. 20:00 CET
and 11:00 PST.

I always said this daylight savings time was a stupid and useless invention!

Thanks for catching that, gerv. :)


LpSolit


From mkanat at bugzilla.org  Tue Oct 31 22:49:39 2006
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Tue, 31 Oct 2006 14:49:39 -0800
Subject: Trunk In Soft Freeze
Message-ID: <1162334979.2609.6.camel@max>

	Hey hey. So the trunk is now "soft" frozen.

	This means that any enhancement that *currently* has a patch on it,
where that patch is awaiting review, can still be checked in, until
November 14.

	However, no new patches will be accepted for enhancements, unless those
enhancements are marked as blockers.

	On November 14, we freeze "hard," which means that we won't accept any
enhancements at all until after Bugzilla 3.0rc1.

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