From mkanat at bugzilla.org  Mon Feb  1 03:10:53 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Sun, 31 Jan 2010 19:10:53 -0800
Subject: Releases Done, Moving to Bzr, CVS Checkins on Hold
Message-ID: <4B66463D.8080100@bugzilla.org>

	The pending releases have just been done, and the bzr server is set up
and ready, so we'll be moving to bzr very soon. CVS checkins are on hold
permanently, starting now. :-) Once bzr is up and ready (probably within
the next two days) I'll let you guys know all about it and what to do
with it.

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


From mkanat at bugzilla.org  Tue Feb  2 01:09:23 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Mon, 01 Feb 2010 17:09:23 -0800
Subject: We've Switched to Bzr!
Message-ID: <4B677B43.9010406@bugzilla.org>

	Hey folks! So, we've officially now switched away from CVS and on to
Bazaar (bzr). For people who just want to check out and do diffs, CVS
still works and will be kept in sync with bzr. However, all commits will
be done to bzr.

	Here's a good introduction to bzr for users familiar with CVS:

	http://doc.bazaar.canonical.com/migration/en/survival/bzr-for-cvs-users.html

	You can browse the server here:

	http://bzr.mozilla.org/

	------------
	Checking Out
	------------

	To do a read-only checkout of the trunk, you can do:

	bzr co bzr://bzr.mozilla.org/bugzilla/trunk

	Or if for some reason you can't access port 4155 on that machine, you
can do:

	bzr co http://bzr.mozilla.org/bugzilla/trunk

	(Note that right now, the bzr:// server actually isn't working--it
should be up by Tuesday or Wednesday.)

	If you're going to want to check in to the repository using your
checkout, you should do:

	bzr co bzr+ssh://user at domain.com@bzr.mozilla.org/bugzilla/trunk

	Where "user at domain.com" is your username in the Mozilla LDAP. (It's the
same as the email address of your CVS account.)

	----
	Tags
	----

	All of the releases are tagged, similarly to how they were in CVS.
However, the tags are named like "bugzilla-3.3.1" for the 3.3.1 release,
and so on. You can see the whole list of tags in a branch like this:

	bzr tags bzr://bzr.mozilla.org/bugzilla/trunk

	You can check out a tag like:

	bzr co -r tag:bugzilla-3.3.1 bzr://bzr.mozilla.org/bugzilla/trunk
bugzilla-3.3.1

	----------
	Committing
	----------

	In order to commit you must have bzr 1.17 or later. 2.0 or later is
ideal, as it will be faster.

	I believe that anybody who could commit to Bugzilla CVS should be able
to commit to Bugzilla Bzr, but if you can't for some reason, let me know
and I will work it out with Mozilla IT.

	In order to commit, you must use "bzr whoami" at least once on your
machine before the first time you commit. Please include both your full
name and your email address in whoami--this is important for how commit
info is displayed in the web view of the repository, and I'd like to
keep that as consistent as possible. A sample whoami command would look
like:

	bzr whoami 'Max Kanat-Alexander <mkanat at bugzilla.org>'

	The email address that you set in "whoami" must match your Mozilla LDAP
account.

	To commit, you should do something like this in your checkout:

	bzr commit --author='Some Other User <somebody at else.com>' --fixes
mozilla:123456

	You only need to specify the --author argument if you are not the
author of the patch you are checking in. PLEASE specify both the full
name and email address of the author, and PLEASE remember to specify
--author when you're checking in somebody else's patch. Loggerhead (the
web view of the repository) actually shows that user as the author of
the patch, and it's nice to keep it consistent.

	--fixes allows bzr to store information about which bug is being fixed.
In order to use it, you have to edit $HOME/.bazaar/bazaar.conf and add
this line at the end of the file:

	bugzilla_mozilla_url = https://bugzilla.mozilla.org

	It's very important to specify --fixes, because that's what allows
loggerhead (the web view of the repository) to show a link to a bug.
Hopefully eventually this data will be used in more places in loggerhead
and in other tools that bzr uses.

	Since we have --author, and because the author is prominently displayed
both by "bzr log" and by Loggerhead, it's not necessary to include
"Patch By" in the checkin comment anymore. I've been writing checkin
comments like this, now:

Bug 543459: Speed up the new duplicates.cgi
r=LpSolit, a=LpSolit

	Commits CANNOT be changed after they are committed to the repository,
in bzr, so please make sure that you are correctly specifying --author,
--fixes, and the checkin comment.

	After you commit, you should basically do the same thing we did with
CVS, which is to paste the "bzr commit" output into a comment. You don't
need to specify what branch you're committing against, though, because
the bzr output actually contains that information. You can see an
example comment here:

	https://bugzilla.mozilla.org/show_bug.cgi?id=514970#c16

	If you have any questions about committing, feel free to ask me before
you commit--it's important to get it right, because we can't change
what's in the repository once it's there.

	-----------
	CVS and Bzr
	-----------	

	One of the nice things about the new server is that there's no lag
between the "read-only" bzr, and the "committable" bzr. The instant you
commit, your commits can be checked-out using bzr://, and they will
immediately appear in loggerhead.

	CVS, though, will be about 15 to 20 minutes behind bzr.

	For now, all our build and release tools will continue to use CVS,
though they will probably be slowly migrated over to using bzr.

	------------------------
	The Old bzr.bugzilla.org
	------------------------

	I have fully disabled the old bzr.bugzilla.org. If you were using
checkouts from the old bzr.bugzilla.org, in order to merge or update
from bzr.mozilla.org, you will have to upgrade your local bzr checkout
to a "rich root". If you're using a modern version of bzr, the best
thing to do is to change to the directory of your bzr checkout and do:

	bzr upgrade --2a

	However, that only works as of bzr 1.16. If you're using an earlier
version, you should probably just do:

	bzr upgrade --1.9-rich-root

	Which works as of bzr 1.9. If by some chance you're using a version
older than 1.9, you'll have to do:

	bzr upgrade --rich-root

	I imagine this will most affect people who were doing QA. The QA
repository has moved to:

	bzr://bzr.bugzilla.org/bugzilla/qa/

	-------------
	How We Did It
	-------------

	Anybody who's interested in how we did the migration and how the
bzr-to-cvs script is working should check out the bug that tracked the
whole experience of setting up the bzr server, and contains all all the
scripts you'd need to duplicate our setup:

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

	The bzr-to-cvs script is in our bzr repository. Note that nobody else
in the Bugzilla Project should be running this for Bugzilla. I have it
set up and running, and it is syncing data for us. I am providing the
link purely for people who are interested in creating a similar setup
for their project:

	http://bzr.mozilla.org/bzr-plugins/bzr-to-cvs/files

	----
	Wiki
	----

	Most (or all) of this information will be on the Wiki at some point,
but I wanted to get it out there in this email for now.

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


From mkanat at bugzilla.org  Tue Feb  2 01:31:04 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Mon, 01 Feb 2010 17:31:04 -0800
Subject: Branched for 3.6
Message-ID: <4B678058.7070506@bugzilla.org>

	Okay, we've branched for 3.6.

	In bzr, the 3.6 branch is at:

	http://bzr.mozilla.org/bugzilla/3.6

	In CVS, it's BUGZILLA-3_6-BRANCH.

	The trunk is open for checkins again, for 3.8.

	Checkins on the 3.6 branch require approval3.6 to be set.

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


From Callek at gmail.com  Tue Feb  2 04:51:48 2010
From: Callek at gmail.com (Justin Wood (Callek))
Date: Mon, 01 Feb 2010 23:51:48 -0500
Subject: Branched for 3.6
In-Reply-To: <mailman.3677.1265074292.4112.dev-apps-bugzilla@lists.mozilla.org>
References: <mailman.3677.1265074292.4112.dev-apps-bugzilla@lists.mozilla.org>
Message-ID: <xI2dnTBeuq35MvrWnZ2dnUVZ_oVi4p2d@mozilla.org>

On 2/1/2010 8:31 PM, Max Kanat-Alexander wrote:
> 	Okay, we've branched for 3.6.
>
> 	In bzr, the 3.6 branch is at:  ...
>
> 	In CVS, it's BUGZILLA-3_6-BRANCH.

Just for clarity; 3.6 approved landings should be in bzr or cvs?

[not that *I* have any though]

-- 
~Justin Wood (Callek)
_______________________________________________
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  Tue Feb  2 06:12:51 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Mon, 01 Feb 2010 22:12:51 -0800
Subject: Branched for 3.6
In-Reply-To: <xI2dnTBeuq35MvrWnZ2dnUVZ_oVi4p2d@mozilla.org>
References: <mailman.3677.1265074292.4112.dev-apps-bugzilla@lists.mozilla.org> <xI2dnTBeuq35MvrWnZ2dnUVZ_oVi4p2d@mozilla.org>
Message-ID: <4B67C263.8040709@bugzilla.org>

On 02/01/2010 08:51 PM, Justin Wood (Callek) wrote:
> Just for clarity; 3.6 approved landings should be in bzr or cvs?

	All landings on every branch go to bzr. There will be no more manual
checkins to CVS for any branch.

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


From lpsolit at gmail.com  Tue Feb  2 08:41:11 2010
From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=)
Date: Tue, 02 Feb 2010 09:41:11 +0100
Subject: We've Switched to Bzr!
In-Reply-To: <4B677B43.9010406@bugzilla.org>
References: <4B677B43.9010406@bugzilla.org>
Message-ID: <4B67E527.5010300@gmail.com>

Le 02. 02. 10 02:09, Max Kanat-Alexander a ?crit :
> 	--fixes allows bzr to store information about which bug is being fixed.
> In order to use it, you have to edit $HOME/.bazaar/bazaar.conf and add
> this line at the end of the file:
> 
> 	bugzilla_mozilla_url = https://bugzilla.mozilla.org

What's the magic line to point to
http://landfill.bugzilla.org/bugzillaqa/ for Selenium and WS test scripts?

LpSolit


From mkanat at bugzilla.org  Tue Feb  2 16:11:38 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Tue, 02 Feb 2010 08:11:38 -0800
Subject: We've Switched to Bzr!
In-Reply-To: <4B67E527.5010300@gmail.com>
References: <4B677B43.9010406@bugzilla.org> <4B67E527.5010300@gmail.com>
Message-ID: <4B684EBA.6010902@bugzilla.org>

On 02/02/2010 12:41 AM, Fr?d?ric Buclin wrote:
> What's the magic line to point to
> http://landfill.bugzilla.org/bugzillaqa/ for Selenium and WS test scripts?

	I suppose you could use something like:

	bugzilla_qa_url = http://landfill.bugzilla.org/bugzillaqa

	And then you'd do --fixes qa:1234

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


From gerv at mozilla.org  Tue Feb  2 16:52:56 2010
From: gerv at mozilla.org (Gervase Markham)
Date: Tue, 02 Feb 2010 16:52:56 +0000
Subject: We've Switched to Bzr!
In-Reply-To: <mailman.3674.1265072995.4112.dev-apps-bugzilla@lists.mozilla.org>
References: <mailman.3674.1265072995.4112.dev-apps-bugzilla@lists.mozilla.org>
Message-ID: <oIydnejOIab3xfXWnZ2dnUVZ_sSdnZ2d@mozilla.org>

On 02/02/10 01:09, Max Kanat-Alexander wrote:
> 	If you're going to want to check in to the repository using your
> checkout, you should do:
> 
> 	bzr co bzr+ssh://user at domain.com@bzr.mozilla.org/bugzilla/trunk
> 
> 	Where "user at domain.com" is your username in the Mozilla LDAP. (It's the
> same as the email address of your CVS account.)

A few clarificatory points:

- Your Mozilla LDAP username is not necessarily the same as your CVS
account name. (My LDAP username is gerv at mozilla.org; my CVS account name
is gerv%gerv.net). Particularly if you have multiple SCM accounts with
different addresses associated with them. If you have an Hg username, I
believe it'll be that one.

- As Max's example shows, the account name needs an @ sign, not the %
you are used to using when using CVS. You can escape the @ as %40 if you
like but it's not required.

- You can avoid having to specify the login name on each URL by adding
the following 2 lines to your ~/.ssh/config:

Host bzr.mozilla.org
  User <ldapusername at mydomain.example>

Then you can just do:

bzr co bzr+ssh://bzr.mozilla.org/bugzilla/trunk

- If you put the name of a directory on the end of that command line,
it'll check out into that directory. It's like svn in this respect.

Hope that helps :-)

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


From eblack at higherone.com  Tue Feb  2 17:02:38 2010
From: eblack at higherone.com (Eric Black)
Date: Tue, 2 Feb 2010 12:02:38 -0500
Subject: We've Switched to Bzr!
In-Reply-To: <4B677B43.9010406@bugzilla.org>
References: <4B677B43.9010406@bugzilla.org>
Message-ID: <4F91EB003F5C784084736E717AB5AFCA1A00495577@mail02.higherone.com>


>        Here's a good introduction to bzr for users familiar with CVS:
>
>        http://doc.bazaar.canonical.com/migration/en/survival/bzr-for-cvs-users.html


Should or can we still create patches the same way as we did against cvs before?


From mkanat at bugzilla.org  Tue Feb  2 17:26:53 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Tue, 02 Feb 2010 09:26:53 -0800
Subject: We've Switched to Bzr!
In-Reply-To: <4F91EB003F5C784084736E717AB5AFCA1A00495577@mail02.higherone.com>
References: <4B677B43.9010406@bugzilla.org> <4F91EB003F5C784084736E717AB5AFCA1A00495577@mail02.higherone.com>
Message-ID: <4B68605D.4020308@bugzilla.org>

On 02/02/2010 09:02 AM, Eric Black wrote:
> Should or can we still create patches the same way as we did against cvs before?

	Yeah. You can actually still create patches against CVS if you want, if
you're just posting them for review and not checking them in yourself.

	If you want to use bzr, making a bzr patch is just:

	bzr diff > some-name.diff

	You don't have to specify -Nu or anything like you did for CVS. You can
even do "bzr add" to add new files so that they'll show up in your diff,
even if you don't have write access to the bzr repository.

	One difference is that bzr supports moving and renaming of files, so
instead of doing "bzr rm" and "bzr add" to change the name of a file,
you'd want to make sure that you used "bzr mv".

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


From Callek at gmail.com  Wed Feb  3 04:37:39 2010
From: Callek at gmail.com (Justin Wood (Callek))
Date: Tue, 02 Feb 2010 23:37:39 -0500
Subject: We've Switched to Bzr!
In-Reply-To: <mailman.3674.1265072995.4112.dev-apps-bugzilla@lists.mozilla.org>
References: <mailman.3674.1265072995.4112.dev-apps-bugzilla@lists.mozilla.org>
Message-ID: <7KKdneyT6tUOYPXWnZ2dnUVZ_uWdnZ2d@mozilla.org>

On 2/1/2010 8:09 PM, Max Kanat-Alexander wrote:
> 	--fixes allows bzr to store information about which bug is being fixed.
> In order to use it, you have to edit $HOME/.bazaar/bazaar.conf and add
> this line at the end of the file:

FYI from bzr docs:

Configuration files are located in $HOME/.bazaar on Linux/Unix and 
C:\Documents and Settings\<username>\Application Data\Bazaar\2.0 on Windows.

bzr is not (yet) installed as an MSYS binary so it is not using the 
$HOME location here.

-- 
~Justin Wood (Callek)
_______________________________________________
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  Fri Feb  5 08:59:52 2010
From: gerv at mozilla.org (Gervase Markham)
Date: Fri, 05 Feb 2010 09:59:52 +0100
Subject: Bugzilla for Humans
Message-ID: <NZidnUCGm-CUQ_bWnZ2dnUVZ_oWdnZ2d@mozilla.org>

Johnath has just posted a video he made which is an introduction to
Bugzilla:
http://blog.johnath.com/2010/02/04/bugzilla-for-humans/

If you are a Bugzilla developer, there is nothing in there you don't
know. However, I suggest it is required watching, because the way it is
narrated gives a very valuable perspective on how Mozilla people, and
users in general, feel about the process of interacting with Bugzilla. I
think there are lessons there for all of us.

It's less than 20 minutes long. Do watch the open video version :-)

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  Fri Feb  5 12:01:31 2010
From: gerv at mozilla.org (Gervase Markham)
Date: Fri, 05 Feb 2010 13:01:31 +0100
Subject: Bug Relationships
In-Reply-To: <mailman.2246.1263592515.4112.dev-apps-bugzilla@lists.mozilla.org>
References: <ZNOdnZt5bJG4_dbWnZ2dnUVZ_o-dnZ2d@mozilla.org>	<mailman.1859.1263245390.4112.dev-apps-bugzilla@lists.mozilla.org>	<etOdnWEKCeeif83WnZ2dnUVZ_v2dnZ2d@mozilla.org>
	<mailman.2246.1263592515.4112.dev-apps-bugzilla@lists.mozilla.org>
Message-ID: <V7SdnQq9JqsAlfHWnZ2dnUVZ_jadnZ2d@mozilla.org>

On 15/01/10 22:54, Max Kanat-Alexander wrote:
> 	No, this would be overkill; there aren't going to be more than a few
> relationship custom fields on the average Bugzilla, if there's even one.

I am suggesting we use this for all bug-to-bug relationships, so there
are at least 3 in default Bugzilla - depends, blocks and see also. I can
imagine some more useful ones without much effort - e.g.
regressed/caused-by.

The more specific you can be about the relationship, the better. With
something as generic as "see also", you have to go and read the other
bug to work out why it's related and if you care. If the relationship
has a name, you may be able to decide up front that it's not relevant to
you. So enabling people to add the specific relationships their
organization cares about, without the number of fields on the bug
increasing, seems like a worthy goal.

> 	Each relationship will be its own field, just like Depends On and
> Blocks are, now.

And my suggestion is that this additional complexity does not serve the
user well.

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  Fri Feb  5 12:01:39 2010
From: gerv at mozilla.org (Gervase Markham)
Date: Fri, 05 Feb 2010 13:01:39 +0100
Subject: Bug Relationships
In-Reply-To: <mailman.2248.1263592630.4112.dev-apps-bugzilla@lists.mozilla.org>
References: <ZNOdnZt5bJG4_dbWnZ2dnUVZ_o-dnZ2d@mozilla.org>	<mailman.1859.1263245390.4112.dev-apps-bugzilla@lists.mozilla.org>	<nr6dnfPFsJbExdHWnZ2dnUVZ_uNi4p2d@mozilla.org>
	<mailman.2248.1263592630.4112.dev-apps-bugzilla@lists.mozilla.org>
Message-ID: <hYGdnRnwCL05lfHWnZ2dnUVZ_o2dnZ2d@mozilla.org>

On 15/01/10 22:56, Max Kanat-Alexander wrote:
> 	Let's wait and see how the full and complete implementation of See Also
> turns out. The goal is to keep it as simple as possible, to interact
> with as many different possible trackers as possible, and to have the
> maximum useful functionality based on that simplicity. Right now I want
> to do that by making it a fully-mutual relationship, not a dual-one-way
> relationship like Depends On and Blocks are. 

Can you explain the difference between fully-mutual and dual-one-way?

My design included both "asymmetrical" relationships like depends
on/blocks and "symmetrical" relationships like "related" or "see also".
Is that the difference you are referring to?

I really think it does not improve the problem of Bugzilla's complexity
to have a different UI for

- relating bugs to other bugs in the same Bugzilla in one particular way
(depends on/blocks)
- relating bugs to other bugs in the same Bugzilla in other ways (custom
fields taking Bug IDs)
- relating bugs to other bugs in other bug systems (See Also)

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


From ahdevans at gmail.com  Fri Feb  5 17:02:55 2010
From: ahdevans at gmail.com (Aaron Evans)
Date: Fri, 5 Feb 2010 09:02:55 -0800
Subject: Bug Relationships
In-Reply-To: <V7SdnQq9JqsAlfHWnZ2dnUVZ_jadnZ2d@mozilla.org>
References: <ZNOdnZt5bJG4_dbWnZ2dnUVZ_o-dnZ2d@mozilla.org>
	 <mailman.1859.1263245390.4112.dev-apps-bugzilla@lists.mozilla.org>
	 <etOdnWEKCeeif83WnZ2dnUVZ_v2dnZ2d@mozilla.org>
	 <mailman.2246.1263592515.4112.dev-apps-bugzilla@lists.mozilla.org>
	 <V7SdnQq9JqsAlfHWnZ2dnUVZ_jadnZ2d@mozilla.org>
Message-ID: <36fce4891002050902v4515671fucf1ef20a9be3e84@mail.gmail.com>

On Fri, Feb 5, 2010 at 4:01 AM, Gervase Markham <gerv at mozilla.org> wrote:

> On 15/01/10 22:54, Max Kanat-Alexander wrote:
> >       No, this would be overkill; there aren't going to be more than a
> few
> > relationship custom fields on the average Bugzilla, if there's even one.
>
> I am suggesting we use this for all bug-to-bug relationships, so there
> are at least 3 in default Bugzilla - depends, blocks and see also. I can
> imagine some more useful ones without much effort - e.g.
> regressed/caused-by.
>
> The more specific you can be about the relationship, the better. With
> something as generic as "see also", you have to go and read the other
> bug to work out why it's related and if you care. If the relationship
> has a name, you may be able to decide up front that it's not relevant to
> you. So enabling people to add the specific relationships their
> organization cares about, without the number of fields on the bug
> increasing, seems like a worthy goal.
>
> >       Each relationship will be its own field, just like Depends On and
> > Blocks are, now.
>

And my suggestion is that this additional complexity does not serve the
> user well.
>
> Gerv
> _____
>

What about a generic relationship type?  So that the property is
"is-related-to" and for each relationship there could be a
relationship-type.  That allows for an open-ended system, but with
reasonable defaults.  A few specific relation-categories could describe the
permutations, such as one-to-one, parent-child, etc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20100205/16139adf/attachment.html>

From guy.pyrzak at gmail.com  Fri Feb  5 17:26:40 2010
From: guy.pyrzak at gmail.com (Guy Pyrzak)
Date: Fri, 5 Feb 2010 09:26:40 -0800
Subject: Bug Relationships
In-Reply-To: <36fce4891002050902v4515671fucf1ef20a9be3e84@mail.gmail.com>
References: <ZNOdnZt5bJG4_dbWnZ2dnUVZ_o-dnZ2d@mozilla.org>
	 <mailman.1859.1263245390.4112.dev-apps-bugzilla@lists.mozilla.org>
	 <etOdnWEKCeeif83WnZ2dnUVZ_v2dnZ2d@mozilla.org>
	 <mailman.2246.1263592515.4112.dev-apps-bugzilla@lists.mozilla.org>
	 <V7SdnQq9JqsAlfHWnZ2dnUVZ_jadnZ2d@mozilla.org>
	 <36fce4891002050902v4515671fucf1ef20a9be3e84@mail.gmail.com>
Message-ID: <df4dec6f1002050926v3e68bb06w4844c269d2a6fd60@mail.gmail.com>

Sorry to be a buzz kill, but maybe this discussion should be happening on
the bug?

-Guy

On Fri, Feb 5, 2010 at 9:02 AM, Aaron Evans <ahdevans at gmail.com> wrote:

>
> On Fri, Feb 5, 2010 at 4:01 AM, Gervase Markham <gerv at mozilla.org> wrote:
>
>> On 15/01/10 22:54, Max Kanat-Alexander wrote:
>> >       No, this would be overkill; there aren't going to be more than a
>> few
>> > relationship custom fields on the average Bugzilla, if there's even one.
>>
>> I am suggesting we use this for all bug-to-bug relationships, so there
>> are at least 3 in default Bugzilla - depends, blocks and see also. I can
>> imagine some more useful ones without much effort - e.g.
>> regressed/caused-by.
>>
>> The more specific you can be about the relationship, the better. With
>> something as generic as "see also", you have to go and read the other
>> bug to work out why it's related and if you care. If the relationship
>> has a name, you may be able to decide up front that it's not relevant to
>> you. So enabling people to add the specific relationships their
>> organization cares about, without the number of fields on the bug
>> increasing, seems like a worthy goal.
>>
>> >       Each relationship will be its own field, just like Depends On and
>> > Blocks are, now.
>>
>
> And my suggestion is that this additional complexity does not serve the
>> user well.
>>
>> Gerv
>> _____
>>
>
> What about a generic relationship type?  So that the property is
> "is-related-to" and for each relationship there could be a
> relationship-type.  That allows for an open-ended system, but with
> reasonable defaults.  A few specific relation-categories could describe the
> permutations, such as one-to-one, parent-child, etc.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20100205/0932b764/attachment.html>

From jjclark1982 at gmail.com  Fri Feb  5 18:02:25 2010
From: jjclark1982 at gmail.com (Jesse J. Clark)
Date: Fri, 5 Feb 2010 10:02:25 -0800
Subject: Bug Relationships
In-Reply-To: <df4dec6f1002050926v3e68bb06w4844c269d2a6fd60@mail.gmail.com>
References: <ZNOdnZt5bJG4_dbWnZ2dnUVZ_o-dnZ2d@mozilla.org> <mailman.1859.1263245390.4112.dev-apps-bugzilla@lists.mozilla.org> <etOdnWEKCeeif83WnZ2dnUVZ_v2dnZ2d@mozilla.org> <mailman.2246.1263592515.4112.dev-apps-bugzilla@lists.mozilla.org> <V7SdnQq9JqsAlfHWnZ2dnUVZ_jadnZ2d@mozilla.org> <36fce4891002050902v4515671fucf1ef20a9be3e84@mail.gmail.com> <df4dec6f1002050926v3e68bb06w4844c269d2a6fd60@mail.gmail.com>
Message-ID: <EC164523-B751-47DA-8DD9-48BABB1AB7E6@gmail.com>


On Feb 5, 2010, at 9:26 AM, Guy Pyrzak wrote:

> Sorry to be a buzz kill, but maybe this discussion should be happening on the bug?
> 
> -Guy
> 

Bug 251556 is one piece of the puzzle, but it's nice to have this discussion of how to move forward with bug link fields. Here is how I imagine we could progress toward Gerv's design:

- Relationship trees. Bug 539131
- Reverse Editability. This gets into a lot of permissions issues, some of which we have worked out in PRACA.
- Multiplicability. Should be similar to FIELD_TYPE_MULTI_SELECT.
- Migration of non-custom link fields
- Combined relationship editing widget


This still doesn't address Max's plans for fully-mutual relationships between separate bug trackers.

From mkanat at bugzilla.org  Tue Feb  9 00:01:26 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Mon, 08 Feb 2010 16:01:26 -0800
Subject: TraceParser: An Extension for Bugzilla 3.6
Message-ID: <4B70A5D6.4040700@bugzilla.org>

	Hey folks. I wrote an extension that parses stack traces and does
useful things with them, for Bugzilla:

	https://launchpad.net/bugzilla-traceparser

	The features and installation procedure are described on that page.

	It's currently only compatible with the very latest development code of
3.6 (or the trunk code). It won't work with 3.5.3.

	In addition to being useful and neat, I thought it might be an
interesting example of a functional extension that I wrote myself (since
I wrote the Extensions system). It uses almost all the major features of
the Extensions system.

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


From lpsolit at gmail.com  Wed Feb 10 11:43:05 2010
From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=)
Date: Wed, 10 Feb 2010 12:43:05 +0100
Subject: Bugzilla meeting next Tuesday, February 16, 2010
Message-ID: <4B729BC9.6080006@gmail.com>

Hello all,

Our next Bugzilla meeting will take place next Tuesday, February 16,
2010, at 11:00 PDT (19:00 GMT, 20:00 CET) in the #bugzilla-meeting
channel on IRC (irc.mozilla.org). Everyone is free to attend, as usual.

Happy Saint Valentine,

LpSolit


From lpsolit at gmail.com  Wed Feb 10 11:52:41 2010
From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=)
Date: Wed, 10 Feb 2010 12:52:41 +0100
Subject: QA scripts now work with Bugzilla 3.6
Message-ID: <4B729E09.8080902@gmail.com>

Just a quick note to let you know that I finished updating all our
Selenium and WebService scripts to work with Bugzilla 3.6. Those who are
interested can get more information here:

https://wiki.mozilla.org/Bugzilla:QA

and the scripts are available here:

http://bzr.mozilla.org/bugzilla/qa/

What I found while porting them to 3.6 is that several WebServices
methods do not work at all in Bugzilla 3.5.3. The problems have already
been fixed and will be available in Bugzilla 3.5.4/3.6rc1, see bug
544506 and bug 544615.

We can now focus on adding new tests to the 3.6 branch. Help welcome!

LpSolit


From szabgab at gmail.com  Wed Feb 10 13:34:10 2010
From: szabgab at gmail.com (Gabor Szabo)
Date: Wed, 10 Feb 2010 15:34:10 +0200
Subject: post FOSDEM
Message-ID: <d8a74af11002100534x23a23505jc8feae66d6c5c5fa@mail.gmail.com>

Hi Gervase  and everyone else on the list,

Gervase,
it was nice meeting you on FOSDEM and thanks for the short overview
of where Bugzilla stands.

Unfortunately there was no Bugzilla related action on FOSDEM but I have
not gave up trying to have more cooperation between the Bugzilla
developers and the Perl community but I need your help as well.

So where do you people think the Perl community could help Bugzilla?

Gabor


From benjamin at smedbergs.us  Wed Feb 10 15:21:13 2010
From: benjamin at smedbergs.us (Benjamin Smedberg)
Date: Wed, 10 Feb 2010 10:21:13 -0500
Subject: Fwd: REST APIs, and Tags
In-Reply-To: <lJ-dnTp28csNE5PWnZ2dnUVZ_hmdnZ2d@mozilla.org>
References: <lJ-dnTp28csNE5PWnZ2dnUVZ_hmdnZ2d@mozilla.org>
Message-ID: <yZidndn6Ks90U-_WnZ2dnUVZ_i2dnZ2d@mozilla.org>

On 11/26/09 9:19 AM, Gervase Markham wrote:

> It would be great to start a discussion on our future plans for this
> sort of thing. For example, can we merge keywords and what we now call
> tags into one tag implementation (incorporating both public and private
> tags) which has these desirable properties?

I was just made aware of this thread, and wanted to post my thoughts and 
experiences from using the google code bugtracker.

The google code bug tracker tracks basically all metadata using "labels". 
The project administrator can administer a predefined set of labels, and 
also any project member (roughly equivalent to editbugs in 
bugzilla.mozilla.org) can label bugs with other values if they wish.

Labels are not simple text tags, then can have two-part values, for example:

Type-Defect
Type-Enhancement
Type-Task

Priority-Critical
Priority-High

Milestone-1
Milestone-2.3.3

The project administrator may specify that you may only have one label of 
Type-* Priority-* or Milestone-*

In search results, you can sort bugs by the labels.

I tend to think that if bugzilla.mozilla.org had these types of labels, we 
would use them for almost every field: replace 
OS/priority/keywords/version/platform/importance/severity/TM/all the 
flags/all the multi-state flags, and use predefined labels for all of this 
metadata. We might even decide to get rid of component and use labels for 
that as well.

Currently google code doesn't have really fine-grained controls to control 
labels so that "any user can set blocking1.9.2-nominated" but "only a 
special group can set blocking-1.9.2-alpha", but that's mainly because they 
don't have access control groups at all.

The remaining question, then, is how to manage 'unadministrated' labels. As 
this thread shows, there are two different categories:

* allow "normal" users to publicly organize bugs. I think that at 
bugzilla.mozilla.org at least, we'd want to restrict the organization of 
some labels (the core ones) to project administrators (perhaps whoever has 
editkeywords now). But anyone with editbugs would be able to create their 
own taxonomy, for example I'd like to create a multi-state label:

Lorentz-nominated
Lorentz-notblocking
Lorentz-blockingalpha
Lorentz-blockingbeta

* allow users to privately organize bugs. There are two possible reasons for 
this:

1) the user wants to keep the labels secret
2) the user doesn't want to burden everyone's UI with their own private 
annotations.

Frankly #1 doesn't seem that important. I wonder if, in the UI, we could 
just allow each user to claim labelspace based on some username/loginname, 
e.g. I could claim bsmedberg-* labelspace as my personal area, and those 
labels 1) wouldn't appear in the UI by default 2) only I could set those labels.

--BDS
_______________________________________________
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  Wed Feb 10 17:12:57 2010
From: gerv at mozilla.org (Gervase Markham)
Date: Wed, 10 Feb 2010 17:12:57 +0000
Subject: Fwd: REST APIs, and Tags
In-Reply-To: <yZidndn6Ks90U-_WnZ2dnUVZ_i2dnZ2d@mozilla.org>
References: <lJ-dnTp28csNE5PWnZ2dnUVZ_hmdnZ2d@mozilla.org>
	<yZidndn6Ks90U-_WnZ2dnUVZ_i2dnZ2d@mozilla.org>
Message-ID: <9qednfhflNqGdO_WnZ2dnUVZ_jCdnZ2d@mozilla.org>

On 10/02/10 15:21, Benjamin Smedberg wrote:
> Labels are not simple text tags, then can have two-part values, for
> example:
> 
> Type-Defect
> Type-Enhancement
> Type-Task

I think that's interesting, although using a hyphen seems nasty :-/ I'd
personally prefer a colon, and that fits with QuickSearch syntax. I
guess we'd have to see how much we wanted to be compatible with their
system.

> * allow "normal" users to publicly organize bugs. I think that at
> bugzilla.mozilla.org at least, we'd want to restrict the organization of
> some labels (the core ones) to project administrators (perhaps whoever
> has editkeywords now). But anyone with editbugs would be able to create
> their own taxonomy, for example I'd like to create a multi-state label:
> 
> Lorentz-nominated
> Lorentz-notblocking
> Lorentz-blockingalpha
> Lorentz-blockingbeta
> Frankly #1 doesn't seem that important. I wonder if, in the UI, we could
> just allow each user to claim labelspace based on some
> username/loginname, e.g. I could claim bsmedberg-* labelspace as my
> personal area, and those labels 1) wouldn't appear in the UI by default
> 2) only I could set those labels.

The other alternative is just to have two fields - public and private.
That avoids the ugly prefixes. If you specifically requested a list of
"all labels on a bug" it would show you them, grouped by the user who
set them.

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 Feb 11 12:32:36 2010
From: gerv at mozilla.org (Gervase Markham)
Date: Thu, 11 Feb 2010 12:32:36 +0000
Subject: Bug Relationships
In-Reply-To: <mailman.3997.1265389406.4112.dev-apps-bugzilla@lists.mozilla.org>
References: <ZNOdnZt5bJG4_dbWnZ2dnUVZ_o-dnZ2d@mozilla.org>	<mailman.1859.1263245390.4112.dev-apps-bugzilla@lists.mozilla.org>	<etOdnWEKCeeif83WnZ2dnUVZ_v2dnZ2d@mozilla.org>	<mailman.2246.1263592515.4112.dev-apps-bugzilla@lists.mozilla.org>	<V7SdnQq9JqsAlfHWnZ2dnUVZ_jadnZ2d@mozilla.org>
	<mailman.3997.1265389406.4112.dev-apps-bugzilla@lists.mozilla.org>
Message-ID: <WcidnWLFppx5Ze7WnZ2dnUVZ_gZi4p2d@mozilla.org>

On 05/02/10 17:02, Aaron Evans wrote:
> What about a generic relationship type?  So that the property is
> "is-related-to" and for each relationship there could be a
> relationship-type.  That allows for an open-ended system, but with
> reasonable defaults.  A few specific relation-categories could describe the
> permutations, such as one-to-one, parent-child, etc.

As far as I understand your suggestion, I think you are suggesting what
I am suggesting...

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 Feb 11 12:32:01 2010
From: gerv at mozilla.org (Gervase Markham)
Date: Thu, 11 Feb 2010 12:32:01 +0000
Subject: post FOSDEM
In-Reply-To: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>
Message-ID: <WcidnWPFppxcZe7WnZ2dnUVZ_gZi4p2d@mozilla.org>

On 10/02/10 13:34, Gabor Szabo wrote:
> So where do you people think the Perl community could help Bugzilla?

Hi Gabor,

It was great to meet you at FOSDEM too.

IMO, the Bugzilla community is most in need of additional developers.
Where in the Perl community might we ask to see if anyone is interested
in lending a hand?

Other than that, did you have any ideas about how we could collaborate
better?

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  Wed Feb 10 21:44:13 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Wed, 10 Feb 2010 13:44:13 -0800
Subject: post FOSDEM
In-Reply-To: <d8a74af11002100534x23a23505jc8feae66d6c5c5fa@mail.gmail.com>
References: <d8a74af11002100534x23a23505jc8feae66d6c5c5fa@mail.gmail.com>
Message-ID: <4B7328AD.40908@bugzilla.org>

On 02/10/2010 05:34 AM, Gabor Szabo wrote:
> So where do you people think the Perl community could help Bugzilla?

	Hmm, if you could send some developers our way, that would certainly be
helpful! :-) We're very helpful to people who are relatively-new Perl
coders, and we have a pretty good introductory system for getting into
coding on Bugzilla, so you're welcome to advertise Bugzilla as a Perl
project that's friendly to relatively-new developers. (Though they do
have to be able to read and write Object-Oriented Perl.)

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


From gerv at mozilla.org  Wed Feb 10 17:19:27 2010
From: gerv at mozilla.org (Gervase Markham)
Date: Wed, 10 Feb 2010 17:19:27 +0000
Subject: Fwd: REST APIs, and Tags
In-Reply-To: <mailman.4377.1265818185.4112.dev-apps-bugzilla@lists.mozilla.org>
References: <lJ-dnTp28csNE5PWnZ2dnUVZ_hmdnZ2d@mozilla.org>	<yZidndn6Ks90U-_WnZ2dnUVZ_i2dnZ2d@mozilla.org>
	<mailman.4377.1265818185.4112.dev-apps-bugzilla@lists.mozilla.org>
Message-ID: <Tc6dnaPvS4E9d-_WnZ2dnUVZ_uSdnZ2d@mozilla.org>

On 10/02/10 16:09, Fr?d?ric Buclin wrote:
> <troll>
>   You could as well stop using Bugzilla and use Excel instead.
> </troll>
> 
> Using labels for everything is unmanageable, and would make it very hard
> to track bugs efficiently, especially when used in some complex queries.
> You want a UI with less fields, but you are making bug tracking more
> difficult, which makes the simpler UI useless.

Given that Ben has noted that exactly the system he suggests is in use
by a bug tracker which tracks bugs for some 250,000 projects[0], I think
that asserting such a system would be "unmanageable" is contradicted by
the evidence.

We might argue that we are not technically capable of building such a
system. But we can't argue that it would be unusable if we did.

Remember also that the fact that a "field" used tags on the back end
doesn't mean that the only permitted UI is a giant "tags" textbox. If
particular fields are particularly important, you can break them out in
the UI. E.g. one could certainly implement e.g. "OS" as a drop-down
listbox while still having it implemented on the back end using a tags
system.

Gerv

[0] http://googleblog.blogspot.com/2009/12/meaning-of-open.html
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla

From benjamin at smedbergs.us  Wed Feb 10 16:24:41 2010
From: benjamin at smedbergs.us (Benjamin Smedberg)
Date: Wed, 10 Feb 2010 11:24:41 -0500
Subject: Fwd: REST APIs, and Tags
In-Reply-To: <mailman.4377.1265818185.4112.dev-apps-bugzilla@lists.mozilla.org>
References: <lJ-dnTp28csNE5PWnZ2dnUVZ_hmdnZ2d@mozilla.org>	<yZidndn6Ks90U-_WnZ2dnUVZ_i2dnZ2d@mozilla.org>
	<mailman.4377.1265818185.4112.dev-apps-bugzilla@lists.mozilla.org>
Message-ID: <dbudnelwoblUQO_WnZ2dnUVZ_tudnZ2d@mozilla.org>

On 2/10/10 11:09 AM, Fr?d?ric Buclin wrote:

> Using labels for everything is unmanageable, and would make it very hard
> to track bugs efficiently, especially when used in some complex queries.
> You want a UI with less fields, but you are making bug tracking more
> difficult, which makes the simpler UI useless.

Could you be specific? I'm not trying to troll here, but I'd like to 
understand what complex queries are actually effective today and would not 
be if most of our metadata was optional.

In bugzilla.mozilla.org, having required metadata, which is either guessed 
or asked from the bug submitter, makes the overall quality of the metadata 
pretty poor. Nobody knows or can agree on what the "OS" field means. Many 
fields such as priority only make sense in the context of the bug already 
having been triaged and/or assigned to an owner. The severity field has 
meaning, but other than "blocker" "crash" and "enhancement" the severity 
values are pretty meaningless.

--BDS
_______________________________________________
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  Wed Feb 10 16:09:20 2010
From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=)
Date: Wed, 10 Feb 2010 17:09:20 +0100
Subject: Fwd: REST APIs, and Tags
In-Reply-To: <yZidndn6Ks90U-_WnZ2dnUVZ_i2dnZ2d@mozilla.org>
References: <lJ-dnTp28csNE5PWnZ2dnUVZ_hmdnZ2d@mozilla.org>
	<yZidndn6Ks90U-_WnZ2dnUVZ_i2dnZ2d@mozilla.org>
Message-ID: <4B72DA30.1070206@gmail.com>

Le 10. 02. 10 16:21, Benjamin Smedberg a ?crit :
> I tend to think that if bugzilla.mozilla.org had these types of labels,
> we would use them for almost every field: replace
> OS/priority/keywords/version/platform/importance/severity/TM/all the
> flags/all the multi-state flags, and use predefined labels for all of
> this metadata. We might even decide to get rid of component and use
> labels for that as well.

<troll>
  You could as well stop using Bugzilla and use Excel instead.
</troll>

Using labels for everything is unmanageable, and would make it very hard
to track bugs efficiently, especially when used in some complex queries.
You want a UI with less fields, but you are making bug tracking more
difficult, which makes the simpler UI useless.

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


From nbezzala at yahoo.com  Thu Feb 11 13:23:45 2010
From: nbezzala at yahoo.com (Nitish Bezzala)
Date: Thu, 11 Feb 2010 05:23:45 -0800 (PST)
Subject: post FOSDEM
In-Reply-To: <WcidnWPFppxcZe7WnZ2dnUVZ_gZi4p2d@mozilla.org>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org> <WcidnWPFppxcZe7WnZ2dnUVZ_gZi4p2d@mozilla.org>
Message-ID: <97784.55432.qm@web114014.mail.gq1.yahoo.com>

Hi Gabor,


Can you please tell us what you think attracted so many developers to Padre? 
Maybe, we'll be able to borrow some ideas from you...

Thanks,
Nitish


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

From lpsolit at gmail.com  Thu Feb 11 13:32:29 2010
From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=)
Date: Thu, 11 Feb 2010 14:32:29 +0100
Subject: Fwd: REST APIs, and Tags
In-Reply-To: <dbudnelwoblUQO_WnZ2dnUVZ_tudnZ2d@mozilla.org>
References: <lJ-dnTp28csNE5PWnZ2dnUVZ_hmdnZ2d@mozilla.org>	<yZidndn6Ks90U-_WnZ2dnUVZ_i2dnZ2d@mozilla.org>	<mailman.4377.1265818185.4112.dev-apps-bugzilla@lists.mozilla.org> <dbudnelwoblUQO_WnZ2dnUVZ_tudnZ2d@mozilla.org>
Message-ID: <4B7406ED.6020003@gmail.com>

Le 10. 02. 10 17:24, Benjamin Smedberg a ?crit :
> Could you be specific? I'm not trying to troll here, but I'd like to
> understand what complex queries are actually effective today and would
> not be if most of our metadata was optional.

Hum, yesterday I had an obvious example in mind when typing this, but I
cannot remember it exactly right now. It had to do with flags, where you
could query for bugs which have a flag, but not with some status (e.g.
exclude all approval flags which are not approval+). Sorry Benjamin if
you had the impression I was being rude yesterday. :)

My two main worries are 1) that it's harder to remember the exact syntax
of each label/tag. With our current design, you have each field
separately, with a list of values you can choose from. That's not prone
to errors. With labels/tags, you have to remember the exact syntax of a
label (type componnent:Attachments instead of component-Attachment, and
you are lost, and it will take you ages to find what's wrong with your
query or why a bug isn't listed, because it has a wrongly typed label).
Also, 2) with our current design, I know exactly where to look at for a
given information, because a field is always at the exact same place in
a bug report. With tags, I fear my eyes have to scan the whole list of
tags all the time to know if such or such attribute is present. Doing a
lot of triage myself, it's a real pain if I cannot anticipate where to
look at. Also, how do you display information in buglists, if everything
are tags?

Gerv, I'm not saying Google is wrong and Bugzilla is the right way to
display or use metadata. I'm saying that you cannot use labels
everywhere and all the time. And by looking at the Google bug tracker, I
see that a tag of the form foo-bar is nothing more than the foo field
with the bar value, displayed "as tags". But I don't see them as being
real tags, just another way to display data in the UI. This explains how
they manage to still display the information in buglists. So it's rather
a UI thing than a real rethink of the whole way Bugzilla works.

I hope I'm clearer.

LpSolit


From mkanat at bugzilla.org  Thu Feb 11 16:08:09 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Thu, 11 Feb 2010 08:08:09 -0800
Subject: Fwd: REST APIs, and Tags
In-Reply-To: <yZidndn6Ks90U-_WnZ2dnUVZ_i2dnZ2d@mozilla.org>
References: <lJ-dnTp28csNE5PWnZ2dnUVZ_hmdnZ2d@mozilla.org> <yZidndn6Ks90U-_WnZ2dnUVZ_i2dnZ2d@mozilla.org>
Message-ID: <4B742B69.90409@bugzilla.org>

On 02/10/2010 07:21 AM, Benjamin Smedberg wrote:
> I was just made aware of this thread, and wanted to post my thoughts and
> experiences from using the google code bugtracker.
> [snip]

	I've used it too, and I think it's very nice for setting up small
projects. The problem at Mozilla is that Firefox and the other major
products are enormous projects, and with an enormous project comes a
much higher required level of control and organization. Even Bugzilla
itself is a project larger than the vast majority of Google Code projects.

	The purpose of a bug tracker is, basically, to help people store and
organize bug reports.

	I suspect (though I don't know) that the Go and Chromium teams may be
finding that what the Google Code issue tracker currently offers isn't
enough to store and organize bug reports well-enough for a large project
with a certain number of contributors. Or maybe they have enough of a
paid triage team to cope with the organizational problems that the
system is causing.

	The approach that Bugzilla takes is that having a large, fixed UI is
actually more efficient for experienced users, because it allows them to
make changes and see information quickly. It is sometimes overwhelming
for new users, but to some degree or another that's OK if it helps new
users file better bug reports, and discourages the filing of unfixable
bug reports. The filing of poor bug reports and organizing the massive
influx are far more significant problems in a very large open source
project than the simplicity of using the bug-tracker, though simplicity
can and should still be worked for.

	Here's what I think is the best way to have discussions about Bugzilla:

	1) Set out some goal that applies to the current userbase.
	2) Determine the best way to meet that goal as an overall architectural
plan.

	#1 I usually like to think of as being phrased as a particular problem.
The more overarching (but specific) the problem's statement, usually the
better we can look at how to fix it. If it's too general or too
nitpicky, then we just get into the details instead of the architecture.

	If the goal applies to only one part of the userbase, then

	For #2, I think that Benjamin's suggestion here is a great
example--this is an overall architectural suggestion that would move
things in some different direction.

	Unfortunately, I think that this particular architecture, as an
underlying system for all of Bugzilla, wouldn't meet the goals of our
current userbase. It might be useful in a more limited sense as a
tagging system, but if we limit it to that, then we have to ask
ourselves "why not just use keywords?". Well, one response to that is,
"Because this allows a field-like organization of data." Then if we have
both fixed fields and tags, we get into a confusion of "when should I
use fixed fields, and when should I use tags?" which, architecturally
from a backend perspective, tends to lead us to always using tags. The
reason that I don't want to do that is that it requires a knowledge of
what the tag names are and what all their values are (which is not very
good for a huge distributed team that includes novice bug reporters and
triagers), as opposed to fields, which just show up automatically and
have all their values displayed.

	My general philosophy on major architectural changes is this:

	Bugzilla works. It may be something that people complain about, but
currently, it mostly does its job. The areas where it *doesn't* do its
job are what we should focus on, stated as specific problems in the form
of "Bugzilla is preventing me from storing and organizing bug reports
because...". Then we can come up with various ways to deal with those
specific problems until we find one that we think is most ideal, and
implement that most-ideal solution. (Note that often, "most ideal" means
"is flexible enough to handle the needs of our varying userbase".)

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


From mkanat at bugzilla.org  Thu Feb 11 17:12:37 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Thu, 11 Feb 2010 09:12:37 -0800
Subject: Bugzilla: Philosophy
Message-ID: <4B743A85.3090204@bugzilla.org>

	In responding to the tags thread today, I realized that we as a Project
have a lot of principles that we've operated on for years but have never
written down. Here's the "Bugzilla Philosophy" as it were:

	https://wiki.mozilla.org/Bugzilla:Philosophy

	I don't claim that those are the ideal principles, or what our
principles *should* be. The page currently just reflects what our
principles *are*.

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


From benjamin at smedbergs.us  Thu Feb 11 18:26:45 2010
From: benjamin at smedbergs.us (Benjamin Smedberg)
Date: Thu, 11 Feb 2010 13:26:45 -0500
Subject: Fwd: REST APIs, and Tags
In-Reply-To: <mailman.4482.1265904519.4112.dev-apps-bugzilla@lists.mozilla.org>
References: <lJ-dnTp28csNE5PWnZ2dnUVZ_hmdnZ2d@mozilla.org>	<yZidndn6Ks90U-_WnZ2dnUVZ_i2dnZ2d@mozilla.org>
	<mailman.4482.1265904519.4112.dev-apps-bugzilla@lists.mozilla.org>
Message-ID: <DLOdnbzZ_Y171unWnZ2dnUVZ_hudnZ2d@mozilla.org>

On 2/11/10 11:08 AM, Max Kanat-Alexander wrote:

> 	The purpose of a bug tracker is, basically, to help people store and
> organize bug reports.

Actually, I think this is a problematic purpose statement. The purpose of 
the bug tracker is to make it possible/easier to fix the incoming reports.

Some organization will help the overall goal of getting bugs fixed, but 
right now I think we categorize a lot of bugs which simply then get stored 
and ignored. In some cases I think we'd be better off with less 
classification/organization of bugs and better *communication* of the bugs. 
The primary use of bugzilla is a communication tool.

> 	#1 I usually like to think of as being phrased as a particular problem.
> The more overarching (but specific) the problem's statement, usually the
> better we can look at how to fix it. If it's too general or too
> nitpicky, then we just get into the details instead of the architecture.

OK, I'll attempt! Note that this is primarily about bugzilla.mozilla.org.

PROBLEM STATEMENT A:

bugzilla.mozilla.org currently works acceptably well if you are an everyday 
user who is completely hooked into the project. But if you are an occasional 
user, or new to the project, filing a bug is itself a painful activity, and 
seeing bugs stored-and-ignored is disheartening. I believe that many web 
developers and other skilled people who could aid the project are being 
driven away by the difficulty of filing bugs and the perception (and 
possible reality) that our bug tracker is a black hole.

The goal of this process should be to 1) give the bug enough details so that 
it can be fixed 2) communicate to developers and the bug reporter how 
important the bug is and when it might be fixed.

THEORY:

I believe that problem is partly caused by this: when we get an incoming bug 
report, the primary goal of triage seems to be to get all the bug metadata 
"correct". We make sure it has the right 
Product/Component/OS/hardware/version. We add keywords, sometimes many 
keywords. In the well-done cases we make sure there are good steps to 
reproduce, or even a testcase.

All this activity masks the real problem, which is having some qualified 
module owner/peer/delegate decide how important the bug is and whether/who 
shold fix it. The only cases in which we actively make bug decisions 
currently is when we are triaging bugs which are nominated to block some 
release. This means that new bugs which are filed without blocking 
nominations (the default situation most filers) are simply ignored.

SOLUTION?:

For now I'll mostly omit proposed solutions: gerv and mconnor have proposed 
various solutions for READY states and bug workflow which I think are partly 
heading in the right direction, but I think that imposing additional 
"process" without fixing the "communication problem" won't actually improve 
bugzilla.

I believe that the problem of required metadata can and should be solved 
with keywords/tags/labels/whateveryoucall it. Most of the time the data 
isn't important and we shouldn't bother with it. When it is important, 
optional labels are going to have much better accuracy.

PROBLEM STATEMENT B:

Advanced users and project leads need to be able to organize bugs better. I 
am leading the "Electrolysis" project to do multi-process plugins and tabs 
in Mozilla/Firefox. I need the ability to categorize and organize bugs which 
are relevant to this effort. I have tried various solutions, including a 
wiki page external to bugzilla and tracking bugs with dependencies.

My requirements are:
* to allow interested QAfolk/developers to nominate bugs
* to allow me to classify a set of bugs according to how serious they are 
and which milestone they should be fixed in

This problem is basically solved by multi-state flags, except that it's not 
just me: the accessibility team, the JS team, etc are all running similar 
projects and would like project-specific classifications. Having 30 
multi-state flags down the right side of the bugzilla UI doesn't scale.

PROPOSED SOLUTION:

Project-specific labels which autocomplete for the various projects and have 
configuration values as google code does. I don't particularly care whether 
they use the existing multi-state flag backend data storage system... this 
is mainly a question of UI.

--BDS
_______________________________________________
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 Feb 11 18:48:00 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Thu, 11 Feb 2010 10:48:00 -0800
Subject: Fwd: REST APIs, and Tags
In-Reply-To: <DLOdnbzZ_Y171unWnZ2dnUVZ_hudnZ2d@mozilla.org>
References: <lJ-dnTp28csNE5PWnZ2dnUVZ_hmdnZ2d@mozilla.org>	<yZidndn6Ks90U-_WnZ2dnUVZ_i2dnZ2d@mozilla.org>	<mailman.4482.1265904519.4112.dev-apps-bugzilla@lists.mozilla.org> <DLOdnbzZ_Y171unWnZ2dnUVZ_hudnZ2d@mozilla.org>
Message-ID: <4B7450E0.5020309@bugzilla.org>

On 02/11/2010 10:26 AM, Benjamin Smedberg wrote:
> Actually, I think this is a problematic purpose statement. The purpose
> of the bug tracker is to make it possible/easier to fix the incoming
> reports.

	Oh, that's an interesting thought. (Not that we haven't been doing
that, just that it's an interesting thing to think about the purpose
that way.)

> [snip] filing a bug is itself a
> painful activity, and seeing bugs stored-and-ignored is disheartening.

	The problem statement is good, but those are two separate problems that
probably have separate solutions.

	Also, by the way, if you stopped presenting new users with the Bugzilla
Helper and just used the default Simple Form in Bugzilla 3.4, I suspect
that filing a bug would become a far less painful experience.

> I
> believe that many web developers and other skilled people who could aid
> the project are being driven away by the difficulty of filing bugs and
> the perception (and possible reality) that our bug tracker is a black hole.

	Okay, as far as filing bugs goes, I think the current problem is more
that there are too many bugs filed, not that there aren't enough people
filing bugs. So the black hole problem is probably more significant.

> The goal of this process should be to 1) give the bug enough details so
> that it can be fixed 2) communicate to developers and the bug reporter
> how important the bug is and when it might be fixed.

	That sounds pretty reasonable. :-)

> All this activity masks the real problem, which is having some qualified
> module owner/peer/delegate decide how important the bug is and
> whether/who should fix it.

	Yeah, that's actually what I've thought about the situation, myself,
for years.

> For now I'll mostly omit proposed solutions: gerv and mconnor have
> proposed various solutions for READY states and bug workflow which I
> think are partly heading in the right direction, but I think that
> imposing additional "process" without fixing the "communication problem"
> won't actually improve bugzilla.

	Yeah, I agree. I believe my most last suggestion in this area was that
Mozilla should hire several full-time bug triagers.

> I believe that the problem of required metadata can and should be solved
> with keywords/tags/labels/whateveryoucall it. Most of the time the data
> isn't important and we shouldn't bother with it. When it is important,
> optional labels are going to have much better accuracy.

	Hmm. I do agree that there are a lot of cases where certain data just
isn't very important, particularly Platform/OS. Translating those into
tags might be reasonable, but I worry that then we'd shift the burden of
setting them properly *entirely* onto developers instead of how it is
now, where it's just *mostly* on developers (or the fields are ignored).

> PROBLEM STATEMENT B:
> 
> Advanced users and project leads need to be able to organize bugs
> better. [snip]

	Agreed.

> This problem is basically solved by multi-state flags, except that it's
> not just me: the accessibility team, the JS team, etc are all running
> similar projects and would like project-specific classifications. Having
> 30 multi-state flags down the right side of the bugzilla UI doesn't scale.

	Hmm....

> Project-specific labels which autocomplete for the various projects and
> have configuration values as google code does. I don't particularly care
> whether they use the existing multi-state flag backend data storage
> system... this is mainly a question of UI.

	Okay, I see this a little better now.

	A simple solution that would retain the current UI might be to only add
one of those "multi-state flags" (which are a hack on custom fields
that's specific to bmo) if they are somehow specifically set by the user
(so, say, a link like "add a flag" that pops up a <select> that lets you
choose a flag to add).

	It's also possible that bmo could use a Bugzilla Extension or some
external system for Project Management.

	By the way, thanks for these excellent problem statements, they're
really good.

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


From lpsolit at gmail.com  Thu Feb 11 19:01:52 2010
From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=)
Date: Thu, 11 Feb 2010 20:01:52 +0100
Subject: Fwd: REST APIs, and Tags
In-Reply-To: <DLOdnbzZ_Y171unWnZ2dnUVZ_hudnZ2d@mozilla.org>
References: <lJ-dnTp28csNE5PWnZ2dnUVZ_hmdnZ2d@mozilla.org>	<yZidndn6Ks90U-_WnZ2dnUVZ_i2dnZ2d@mozilla.org>	<mailman.4482.1265904519.4112.dev-apps-bugzilla@lists.mozilla.org> <DLOdnbzZ_Y171unWnZ2dnUVZ_hudnZ2d@mozilla.org>
Message-ID: <4B745420.1080808@gmail.com>

Le 11. 02. 10 19:26, Benjamin Smedberg a ?crit :
> right now I think we categorize a lot of bugs which simply then get
> stored and ignored.

You can have the best UI you want, bugs you don't care about will
*always* be ignored. As discussed in mozilla.dev.planning and in bug
545284, you can already track incoming bugs. You can also use saved
searches as Atom feeds to track incoming bugs. So you have all you need
to track newcomers.


> bugs. The primary use of bugzilla is a communication tool.

Right, but you seem to intentionally ignore some communication channels,
see above.


> everyday user who is completely hooked into the project. But if you are
> an occasional user, or new to the project, filing a bug is itself a
> painful activity

As said in mozilla.dev.planning, new users have the guided form to
report bugs, or the normal form with advanced fields hidden by default.
I don't see what's hard here.


> believe that many web developers and other skilled people who could aid
> the project are being driven away by the difficulty of filing bugs and
> the perception (and possible reality) that our bug tracker is a black hole.

The perception of being a black hole is because people tend to ignore
what comes into Firefox:General and Core:General. What prevents all
module owners to watch the QA contact of *:General for new bugs only
(you know how to do this), and pay attention to bugs which seem to
belong to your modules? On one side, you complain about getting too much
bugmail, and on the other one, you complain to not get enough bugmail,
making you miss some bugs.

I will give you an example, keeping in mind that Bugzilla (the project)
is by far not as large as Firefox: when a new bug is reported, a quick
look at it lets us pretty easily say if the bug seems severe, a possible
dupe, a RFE, etc... We quickly set some fields and it should then be in
everyone's radar who is interested by such or such bugs.


> I believe that problem is partly caused by this: when we get an incoming
> bug report, the primary goal of triage seems to be to get all the bug
> metadata "correct".

Well, if that's what your triage teams are doing, then the failure is at
this level, not at the Bugzilla level. Simply ignore metadata you don't
care about. I don't understand your will to set data you don't care
about. Just ignore them and focus on what is important to fix the bug!


> All this activity masks the real problem, which is having some qualified
> module owner/peer/delegate decide how important the bug is and
> whether/who shold fix it.

Either the module owner watches incoming bugs, or triagers CC them.


 The only cases in which we actively make bug
> decisions currently is when we are triaging bugs which are nominated to
> block some release.

That's because you watch flags having "blocking?". If you weren't
watching them, you would miss them too. So watch what you need to watch.
If you need help to have a working saved search to track incoming bugs,
just tell; we can help here. And once it's built, you can even share it
with other members of your team.


> For now I'll mostly omit proposed solutions: gerv and mconnor have
> proposed various solutions for READY states and bug workflow which I
> think are partly heading in the right direction

IMO, an additional bug status doesn't fix anything. You move the problem
from UNCO/NEW to NEW/READY.


> I believe that the problem of required metadata

We don't *require* metadata, besides the component. You can ignore the
OS/Platform fields if they are unimportant to you. Why again do you pay
attention to them if they are meaningless for your team??

> plugins and tabs in Mozilla/Firefox. I need the ability to categorize
> and organize bugs which are relevant to this effort.

Use the priority field. Use the target milestone field. Mark them as
blocking some meta bug. And be sure they are in the correct component.
What else cannot you do with that?


> * to allow interested QAfolk/developers to nominate bugs

We use the status whiteboard for that, in combination with CC'ing the
module owner who can take the decision.


> * to allow me to classify a set of bugs according to how serious they
> are and which milestone they should be fixed in

Severity + target milestone fields.


LpSolit


From szabgab at gmail.com  Thu Feb 11 19:40:47 2010
From: szabgab at gmail.com (Gabor Szabo)
Date: Thu, 11 Feb 2010 21:40:47 +0200
Subject: How to get involved - where is the source code?
Message-ID: <d8a74af11002111140t3d05dbbar734477197b2f8cfa@mail.gmail.com>

I though I'll try to take a look at the Bugzilla codebase in
order to see how can I be involved and here is what I found:

http://www.bugzilla.org/  has a link "Contribute!" which is great.
It leads to http://www.bugzilla.org/contribute/ that has a link "Code".
Clicking on that link I get to a page
https://wiki.mozilla.org/Bugzilla:Developers
that starts by telling me to introduce myself on the list.
I'd probably put that later but that's a less important issue.
The problem is this:

4. Check out the latest Bugzilla code from CVS.

Reading the mailing list I recall that Bugzilla has moved to Bazar
so this confused me very much. Should I still use the CVS or Bazar?
If the latter, can someone please update the explanations?

regards
  Gabor


From lpsolit at gmail.com  Thu Feb 11 19:43:20 2010
From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=)
Date: Thu, 11 Feb 2010 20:43:20 +0100
Subject: How to get involved - where is the source code?
In-Reply-To: <d8a74af11002111140t3d05dbbar734477197b2f8cfa@mail.gmail.com>
References: <d8a74af11002111140t3d05dbbar734477197b2f8cfa@mail.gmail.com>
Message-ID: <4B745DD8.8020407@gmail.com>

Le 11. 02. 10 20:40, Gabor Szabo a ?crit :
> Reading the mailing list I recall that Bugzilla has moved to Bazar
> so this confused me very much. Should I still use the CVS or Bazar?
> If the latter, can someone please update the explanations?

You can still use CVS. Bzr is only required for those having checkin privs.

LpSolit


From szabgab at gmail.com  Thu Feb 11 20:56:28 2010
From: szabgab at gmail.com (Gabor Szabo)
Date: Thu, 11 Feb 2010 22:56:28 +0200
Subject: How to get involved - where is the source code?
In-Reply-To: <4B745DD8.8020407@gmail.com>
References: <d8a74af11002111140t3d05dbbar734477197b2f8cfa@mail.gmail.com>
	 <4B745DD8.8020407@gmail.com>
Message-ID: <d8a74af11002111256j2cb15f02sb98fd8ef5ecafc47@mail.gmail.com>

2010/2/11 Fr?d?ric Buclin <lpsolit at gmail.com>:
> Le 11. 02. 10 20:40, Gabor Szabo a ?crit :
>> Reading the mailing list I recall that Bugzilla has moved to Bazar
>> so this confused me very much. Should I still use the CVS or Bazar?
>> If the latter, can someone please update the explanations?
>
> You can still use CVS. Bzr is only required for those having checkin privs.

Thanks, though actually I was hoping that I won't need to touch CVS :-)

Gabor


From lpsolit at gmail.com  Thu Feb 11 21:01:16 2010
From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=)
Date: Thu, 11 Feb 2010 22:01:16 +0100
Subject: How to get involved - where is the source code?
In-Reply-To: <d8a74af11002111256j2cb15f02sb98fd8ef5ecafc47@mail.gmail.com>
References: <d8a74af11002111140t3d05dbbar734477197b2f8cfa@mail.gmail.com>	 <4B745DD8.8020407@gmail.com> <d8a74af11002111256j2cb15f02sb98fd8ef5ecafc47@mail.gmail.com>
Message-ID: <4B74701C.7030003@gmail.com>

Le 11. 02. 10 21:56, Gabor Szabo a ?crit :
> Thanks, though actually I was hoping that I won't need to touch CVS :-)

Ah, if you prefer to use bzr, that's fine too. Just get the code from:

bzr co bzr://bzr.mozilla.org/bugzilla/trunk


LpSolit


From mkanat at bugzilla.org  Thu Feb 11 21:21:43 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Thu, 11 Feb 2010 13:21:43 -0800
Subject: How to get involved - where is the source code?
In-Reply-To: <d8a74af11002111140t3d05dbbar734477197b2f8cfa@mail.gmail.com>
References: <d8a74af11002111140t3d05dbbar734477197b2f8cfa@mail.gmail.com>
Message-ID: <4B7474E7.8090202@bugzilla.org>

On 02/11/2010 11:40 AM, Gabor Szabo wrote:
> Reading the mailing list I recall that Bugzilla has moved to Bazar
> so this confused me very much. Should I still use the CVS or Bazar?
> If the latter, can someone please update the explanations?

	The explanations do need to be updated; that will happen soon.

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


From szabgab at gmail.com  Thu Feb 11 21:33:43 2010
From: szabgab at gmail.com (Gabor Szabo)
Date: Thu, 11 Feb 2010 23:33:43 +0200
Subject: cannot run tests when using PERL5LIB (e.g. when using local::lib)
Message-ID: <d8a74af11002111333g76634b1crfcafbc85fcf16554@mail.gmail.com>

When trying to run ./runtests.pl the test t/001compile.t blows up as I am using
local::lib and I have PERL5LIB configured to locate the privately installed
modules.

This patch fixes it.
Does it look reasonable?


=== modified file 't/001compile.t'
--- t/001compile.t	2009-11-18 07:01:40 +0000
+++ t/001compile.t	2010-02-11 21:24:22 +0000
@@ -59,8 +59,12 @@
         $T = "T";
     }

+    my $libs = '';
+    if ($ENV{PERL5LIB}) {
+       $libs = join " ", map { "-I$_" } split /:/, $ENV{PERL5LIB};
+    }
     my $perl = qq{"$^X"};
-    my $output = `$perl -wc$T $file 2>&1`;
+    my $output = `$perl $libs -wc$T $file 2>&1`;
     chomp($output);
     my $return_val = $?;
     $output =~ s/^\Q$file\E syntax OK$//ms;


From mkanat at bugzilla.org  Thu Feb 11 21:37:59 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Thu, 11 Feb 2010 13:37:59 -0800
Subject: cannot run tests when using PERL5LIB (e.g. when using local::lib)
In-Reply-To: <d8a74af11002111333g76634b1crfcafbc85fcf16554@mail.gmail.com>
References: <d8a74af11002111333g76634b1crfcafbc85fcf16554@mail.gmail.com>
Message-ID: <4B7478B7.9000402@bugzilla.org>

On 02/11/2010 01:33 PM, Gabor Szabo wrote:
> When trying to run ./runtests.pl the test t/001compile.t blows up as I am using
> local::lib and I have PERL5LIB configured to locate the privately installed
> modules.
> 
> This patch fixes it.
> Does it look reasonable?

	Hmm, why doesn't PERL5LIB get passed to the backticks?

	You can just use prove on the tests, too, it works OK.

	Also, you can use install-module.pl to install modules locally in
Bugzilla's lib dir if you want, too, and that wouldn't require PERL5LIB.

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


From szabgab at gmail.com  Thu Feb 11 21:52:35 2010
From: szabgab at gmail.com (Gabor Szabo)
Date: Thu, 11 Feb 2010 23:52:35 +0200
Subject: cannot run tests when using PERL5LIB (e.g. when using local::lib)
In-Reply-To: <4B7478B7.9000402@bugzilla.org>
References: <d8a74af11002111333g76634b1crfcafbc85fcf16554@mail.gmail.com>
	 <4B7478B7.9000402@bugzilla.org>
Message-ID: <d8a74af11002111352g3374e32dle5d6e701f4b4a1c1@mail.gmail.com>

On Thu, Feb 11, 2010 at 11:37 PM, Max Kanat-Alexander
<mkanat at bugzilla.org> wrote:
> On 02/11/2010 01:33 PM, Gabor Szabo wrote:
>> When trying to run ./runtests.pl the test t/001compile.t blows up as I am using
>> local::lib and I have PERL5LIB configured to locate the privately installed
>> modules.
>>
>> This patch fixes it.
>> Does it look reasonable?
>
> ? ? ? ?Hmm, why doesn't PERL5LIB get passed to the backticks?

because of -T

>
> ? ? ? ?You can just use prove on the tests, too, it works OK.

I guess it would suffer from the same problem.


> ? ? ? ?Also, you can use install-module.pl to install modules locally in
> Bugzilla's lib dir if you want, too, and that wouldn't require PERL5LIB.

I see, I'll check that, though I'd prefer to use the standard(ish)
installation methods.

Gabor


From szabgab at gmail.com  Thu Feb 11 21:59:51 2010
From: szabgab at gmail.com (Gabor Szabo)
Date: Thu, 11 Feb 2010 23:59:51 +0200
Subject: cannot run tests when using PERL5LIB (e.g. when using local::lib)
In-Reply-To: <d8a74af11002111352g3374e32dle5d6e701f4b4a1c1@mail.gmail.com>
References: <d8a74af11002111333g76634b1crfcafbc85fcf16554@mail.gmail.com>
	 <4B7478B7.9000402@bugzilla.org>
	 <d8a74af11002111352g3374e32dle5d6e701f4b4a1c1@mail.gmail.com>
Message-ID: <d8a74af11002111359g5ff2c574wa5d16dd2be63d171@mail.gmail.com>

On Thu, Feb 11, 2010 at 11:52 PM, Gabor Szabo <szabgab at gmail.com> wrote:
> On Thu, Feb 11, 2010 at 11:37 PM, Max Kanat-Alexander
> <mkanat at bugzilla.org> wrote:
>> On 02/11/2010 01:33 PM, Gabor Szabo wrote:
>>> When trying to run ./runtests.pl the test t/001compile.t blows up as I am using
>>> local::lib and I have PERL5LIB configured to locate the privately installed
>>> modules.
>>>
>>> This patch fixes it.
>>> Does it look reasonable?
>>
>> ? ? ? ?Hmm, why doesn't PERL5LIB get passed to the backticks?
>
> because of -T
>
>>
>> ? ? ? ?You can just use prove on the tests, too, it works OK.
>
> I guess it would suffer from the same problem.
>
>
>> ? ? ? ?Also, you can use install-module.pl to install modules locally in
>> Bugzilla's lib dir if you want, too, and that wouldn't require PERL5LIB.
>
> I see, I'll check that, though I'd prefer to use the standard(ish)
> installation methods.

I tried this. Part of the output looks like this:

  ABW/Template-GD-2.66.tar.gz
  /usr/bin/make -- OK
Skipping test because of notest pragma
Running make install
Installing /home/gabor/perl5/lib/perl5/Template/Plugin/GD.pm
Installing /home/gabor/perl5/lib/perl5/Template/Plugin/GD/Constants.pm
...
Installing /home/gabor/work/bugzilla/lib/man/man3/Template::Plugin::GD::Graph::points.3pm
Installing /home/gabor/work/bugzilla/lib/man/man3/Template::Plugin::GD::Graph::linespoints.3pm


So it is still installing the code in the same directory I would
install (only the man pages are installed
in under bugzilla) and that will still require the PERL5LIB I have.

Gabor


From szabgab at gmail.com  Thu Feb 11 22:22:28 2010
From: szabgab at gmail.com (Gabor Szabo)
Date: Fri, 12 Feb 2010 00:22:28 +0200
Subject: post FOSDEM
In-Reply-To: <97784.55432.qm@web114014.mail.gq1.yahoo.com>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>
	 <WcidnWPFppxcZe7WnZ2dnUVZ_gZi4p2d@mozilla.org>
	 <97784.55432.qm@web114014.mail.gq1.yahoo.com>
Message-ID: <d8a74af11002111422k21e6c47eqda30746a08713dc4@mail.gmail.com>

On Thu, Feb 11, 2010 at 3:23 PM, Nitish Bezzala <nbezzala at yahoo.com> wrote:
> Hi Gabor,
>
> Can you please tell us what you think attracted so many developers to Padre?
> Maybe, we'll be able to borrow some ideas from you...
> Thanks,
> Nitish

I basically just got lucky that I started a project that seemed to be
interesting to some developers but as this happened now I try to play
the expert on the subject.

Also I think it is much easier to make people enthusiastic about a new
project than an existing project that has been in use for more than 10
years.

So please take my suggestions with the appropriate grain of salt.

Anyway, I think the main issue was *publicity* and my earlier
involvement in the Perl community helped in that. I gave a talk about
it on FOSDEM last week but managed to use more time than allocated so
I skipped the most 2-3 import slides which said:

Publicity:
- blog about your project
- talk about it on YAPCs, Perl Workshops, Perl Monger meetings, wherever you can
- encourage other developers and users to blog about it and talk about it.

Create positive feeling towards your project.

Regarding Bugzilla:

I still recall this blog entry:
http://avatraxiom.livejournal.com/58084.html and the discussion it
created on http://use.perl.org/~TeeJay/journal/33269

Maybe it is just me and no one of the other use.perl.org readers think
the same but I am still not sure if the Bugzilla team likes the fact
that it is written in Perl or that you hate every inch of it?

IMHO this image need to be changed if you'd like to attract people to
work on Bugzilla.

For one thing if the Bugzilla web site (and the product itself) was
proudly saying that it is based on Perl (with logo, link to
www.perl.org) that would certainly start creating some warm feelings
in the community.
That would also help drive more people in the direction of Perl.
(e.g. see how every mailman installation has the Python icon even
here: http://mail.pm.org/mailman/listinfo/ )

Also - again IMHO - Bugzilla needs to send the message of using
*modern tools* in its development. (e.g. CVS  still being the
recommended way to fetch the source code is NOT sending this
messages). While I think Git would have been a more attractive vcs for
many perl developers I think Bazar is also good in being modern.
(And I am still using SVN for most of my stuff.)

Make it familiar to CPAN authors and people who are used to the CPAN
style stuff.
e.g.
I was happy to see that you are using Test::More but some items I saw
were not as I would expect

the local::lib/PERL5LIB stuff I am trying to patch,
not using Makefile.PL or Build.PL,
not using "standard" CPAN layout:
   modules in    ROOT/lib/
   command line scripts in       ROOT/script
   cgi scripts in some other directory (e.g. I use ROOT/www)

I'll try to allocate some time and look at the project to give you
more unwanted suggestions and maybe even a few patches.

I think if you would like to attract more people from that community
you should start blogging about Bugzilla and how its Perl code works.
What are your main challenges in the code base, what are you going to
do about it. How people could get involved.
I personally will try to see how Bugzilla is tested.


I am not sure if it should be done on http://bugzillaupdate.wordpress.com/
or on some other blog (maybe on http://blogs.perl.org/ ) but I am quite sure
the entires should appear on both http://ironman.enlightenedperl.org/ and on
http://perlsphere.net/ that are read by many people.


I am sorry if this got a bit too long and if it sounds too paternalistic
but the project I started is called Padre, so you might blame it on that ;-)

regards
   Gabor


From mkanat at bugzilla.org  Thu Feb 11 22:47:20 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Thu, 11 Feb 2010 14:47:20 -0800
Subject: cannot run tests when using PERL5LIB (e.g. when using local::lib)
In-Reply-To: <d8a74af11002111352g3374e32dle5d6e701f4b4a1c1@mail.gmail.com>
References: <d8a74af11002111333g76634b1crfcafbc85fcf16554@mail.gmail.com>	 <4B7478B7.9000402@bugzilla.org> <d8a74af11002111352g3374e32dle5d6e701f4b4a1c1@mail.gmail.com>
Message-ID: <4B7488F8.50306@bugzilla.org>

On 02/11/2010 01:52 PM, Gabor Szabo wrote:
>>        Hmm, why doesn't PERL5LIB get passed to the backticks?
> 
> because of -T

	Ah, right. Okay, file a bug and attach your patch and ask for review,
and I'll check it in.

	(The general development process at:

	http://wiki.mozilla.org/Bugzilla:Developers )

>>
>>        You can just use prove on the tests, too, it works OK.
> 
> I guess it would suffer from the same problem.

	Ah, yeah, but you can use -l.

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


From szabgab at gmail.com  Thu Feb 11 23:13:32 2010
From: szabgab at gmail.com (Gabor Szabo)
Date: Fri, 12 Feb 2010 01:13:32 +0200
Subject: cannot run tests when using PERL5LIB (e.g. when using local::lib)
In-Reply-To: <4B7488F8.50306@bugzilla.org>
References: <d8a74af11002111333g76634b1crfcafbc85fcf16554@mail.gmail.com>
	 <4B7478B7.9000402@bugzilla.org>
	 <d8a74af11002111352g3374e32dle5d6e701f4b4a1c1@mail.gmail.com>
	 <4B7488F8.50306@bugzilla.org>
Message-ID: <d8a74af11002111513i4dfd5773s6ae182e1b0828551@mail.gmail.com>

On Fri, Feb 12, 2010 at 12:47 AM, Max Kanat-Alexander
<mkanat at bugzilla.org> wrote:
> On 02/11/2010 01:52 PM, Gabor Szabo wrote:
>>> ? ? ? ?Hmm, why doesn't PERL5LIB get passed to the backticks?
>>
>> because of -T
>
> ? ? ? ?Ah, right. Okay, file a bug and attach your patch and ask for review,
> and I'll check it in.
>
> ? ? ? ?(The general development process at:
>
> ? ? ? ?http://wiki.mozilla.org/Bugzilla:Developers )

done,
https://bugzilla.mozilla.org/show_bug.cgi?id=545762

please let me know if I missed something in the process.


>>>
>>> ? ? ? ?You can just use prove on the tests, too, it works OK.
>>
>> I guess it would suffer from the same problem.
>
> ? ? ? ?Ah, yeah, but you can use -l.

Interesting, I did not know prove also supports -I

Gabor


From szabgab at gmail.com  Fri Feb 12 06:13:36 2010
From: szabgab at gmail.com (Gabor Szabo)
Date: Fri, 12 Feb 2010 08:13:36 +0200
Subject: Test coverage is 18.4%
Message-ID: <d8a74af11002112213p48e5cd5cr4269447ff2fa94f8@mail.gmail.com>

I am not sure if people here are doing this but I was curious about
the test coverage of Bugzilla.
So I created a Makefile with the following content:

test:
	./runtests.pl


and ran the following:

cover -delete
export DEVEL_COVER_OPTIONS="-ignore,perl5lib"
HARNESS_PERL_SWITCHES=-MDevel::Cover make test
cover -report html

According to this,

All tests successful.
Files=12, Tests=4066, 129 wallclock secs ( 0.64 usr  0.06 sys + 122.84
cusr  6.04 csys = 129.58 CPU)

and the total test coverage of Bugzilla is 18.4%

Are there tests other than those in t/*?

Gabor


From gerv at mozilla.org  Fri Feb 12 10:47:51 2010
From: gerv at mozilla.org (Gervase Markham)
Date: Fri, 12 Feb 2010 10:47:51 +0000
Subject: Test coverage is 18.4%
In-Reply-To: <mailman.4584.1265955256.4112.dev-apps-bugzilla@lists.mozilla.org>
References: <mailman.4584.1265955256.4112.dev-apps-bugzilla@lists.mozilla.org>
Message-ID: <3tWdnaqAGJ1KrOjWnZ2dnUVZ_hJi4p2d@mozilla.org>

On 12/02/10 06:13, Gabor Szabo wrote:
> Are there tests other than those in t/*?

Nope.

I don't believe full code coverage has ever been an explicit goal for
our tests. Not that it's not a good thing - clearly it would be! - but
Bugzilla was not developed in a TDD manner. And no-one has yet seen it
as high priority to write the enormous number of tests it would require
to get very high coverage.

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  Fri Feb 12 10:50:41 2010
From: gerv at mozilla.org (Gervase Markham)
Date: Fri, 12 Feb 2010 10:50:41 +0000
Subject: cannot run tests when using PERL5LIB (e.g. when using local::lib)
In-Reply-To: <mailman.4533.1265924321.4112.dev-apps-bugzilla@lists.mozilla.org>
References: <d8a74af11002111333g76634b1crfcafbc85fcf16554@mail.gmail.com>
	<mailman.4533.1265924321.4112.dev-apps-bugzilla@lists.mozilla.org>
Message-ID: <3tWdnaWAGJ0fr-jWnZ2dnUVZ_hL_fwAA@mozilla.org>

On 11/02/10 21:37, Max Kanat-Alexander wrote:
> 	Also, you can use install-module.pl to install modules locally in
> Bugzilla's lib dir if you want, too, and that wouldn't require PERL5LIB.

(I know this issue has now become a bug, but...)

This suggestion worries me slightly. Not because it wouldn't work, but
because I think we are going to have issues working with the wider Perl
community if, when they say "hey, this standard thing doesn't work", we
say "oh, that's OK, you can just do it our way instead".

I'm not saying you meant to be rude, or that you have some
anti-cooperation agenda. And I know you made other comments too - this
wasn't your only response. I just wanted to politely raise the point for
consideration.

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


From byron at glob.com.au  Fri Feb 12 11:01:27 2010
From: byron at glob.com.au (Byron Jones)
Date: Fri, 12 Feb 2010 19:01:27 +0800
Subject: Test coverage is 18.4%
In-Reply-To: <3tWdnaqAGJ1KrOjWnZ2dnUVZ_hJi4p2d@mozilla.org>
References: <mailman.4584.1265955256.4112.dev-apps-bugzilla@lists.mozilla.org> <3tWdnaqAGJ1KrOjWnZ2dnUVZ_hJi4p2d@mozilla.org>
Message-ID: <4B753507.8030605@glob.com.au>

On 12/02/10 06:13, Gabor Szabo wrote:
> Are there tests other than those in t/*?
>    
there's selenium test cases; https://wiki.mozilla.org/Bugzilla:QA





From gerv at mozilla.org  Fri Feb 12 11:53:07 2010
From: gerv at mozilla.org (Gervase Markham)
Date: Fri, 12 Feb 2010 11:53:07 +0000
Subject: Test coverage is 18.4%
In-Reply-To: <mailman.4597.1265972509.4112.dev-apps-bugzilla@lists.mozilla.org>
References: <mailman.4584.1265955256.4112.dev-apps-bugzilla@lists.mozilla.org>	<3tWdnaqAGJ1KrOjWnZ2dnUVZ_hJi4p2d@mozilla.org>
	<mailman.4597.1265972509.4112.dev-apps-bugzilla@lists.mozilla.org>
Message-ID: <reOdndRbwPK53OjWnZ2dnUVZ_h1i4p2d@mozilla.org>

On 12/02/10 11:01, Byron Jones wrote:
> On 12/02/10 06:13, Gabor Szabo wrote:
>> Are there tests other than those in t/*?
>>    
> there's selenium test cases; https://wiki.mozilla.org/Bugzilla:QA

My apologies; I had forgotten about these.

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  Fri Feb 12 12:15:12 2010
From: gerv at mozilla.org (Gervase Markham)
Date: Fri, 12 Feb 2010 12:15:12 +0000
Subject: post FOSDEM
In-Reply-To: <mailman.4542.1265926982.4112.dev-apps-bugzilla@lists.mozilla.org>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>	<WcidnWPFppxcZe7WnZ2dnUVZ_gZi4p2d@mozilla.org>	<97784.55432.qm@web114014.mail.gq1.yahoo.com>
	<mailman.4542.1265926982.4112.dev-apps-bugzilla@lists.mozilla.org>
Message-ID: <ArudnbvuMs7M2-jWnZ2dnUVZ_oKdnZ2d@mozilla.org>

On 11/02/10 22:22, Gabor Szabo wrote:
> Maybe it is just me and no one of the other use.perl.org readers think
> the same but I am still not sure if the Bugzilla team likes the fact
> that it is written in Perl or that you hate every inch of it?

I personally am very happy it's written in Perl.

I have experience using Catalyst for the BzAPI project
(https://wiki.mozilla.org/Bugzilla:REST_API) and I would second the
comments of those who say it is extremely poorly documented. I even
bought the book "The Definitive Guide to Catalyst" and thought I could
take them to the Advertising Standards Authority about both the words
"Definitive" and "Guide". It was terrible.

> For one thing if the Bugzilla web site (and the product itself) was
> proudly saying that it is based on Perl (with logo, link to
> www.perl.org) that would certainly start creating some warm feelings
> in the community.

I'd be happy to see that.

> Also - again IMHO - Bugzilla needs to send the message of using
> *modern tools* in its development. (e.g. CVS  still being the
> recommended way to fetch the source code is NOT sending this
> messages). 

I agree. We have switched to bzr for development, and should be
recommending this to everyone, even anonymous checkers-out.

We use a product called Bugzilla for bug tracking - do you think that's
modern enough?

;-P

> not using Makefile.PL or Build.PL,

Could you explain a bit more about what we would be using them for? We
don't have any compiled bits...

> not using "standard" CPAN layout:
>    modules in    ROOT/lib/
>    command line scripts in       ROOT/script
>    cgi scripts in some other directory (e.g. I use ROOT/www)

Now that we are in a proper SCM, moving files around has suddenly got a
whole lot easier. I guess the issue with switching to this layout is
that everyone upgrading would have to change their Apache configuration.
Wouldn't they?

> I'll try to allocate some time and look at the project to give you
> more unwanted suggestions and maybe even a few patches.

Thank you :-)

> I think if you would like to attract more people from that community
> you should start blogging about Bugzilla and how its Perl code works.
> What are your main challenges in the code base, what are you going to
> do about it. How people could get involved.

Sounds great.

> I am not sure if it should be done on http://bugzillaupdate.wordpress.com/
> or on some other blog (maybe on http://blogs.perl.org/ ) but I am quite sure
> the entires should appear on both http://ironman.enlightenedperl.org/ and on
> http://perlsphere.net/ that are read by many people.

Are those aggregators? I'm sure we could submit the Bugzilla updates
blog to them.

> I am sorry if this got a bit too long and if it sounds too paternalistic
> but the project I started is called Padre, so you might blame it on that ;-)

Everyone's opinion, politely expressed, is welcome.

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  Fri Feb 12 12:23:51 2010
From: gerv at mozilla.org (Gervase Markham)
Date: Fri, 12 Feb 2010 12:23:51 +0000
Subject: Fwd: REST APIs, and Tags
In-Reply-To: <mailman.4471.1265895203.4112.dev-apps-bugzilla@lists.mozilla.org>
References: <lJ-dnTp28csNE5PWnZ2dnUVZ_hmdnZ2d@mozilla.org>	<yZidndn6Ks90U-_WnZ2dnUVZ_i2dnZ2d@mozilla.org>	<mailman.4377.1265818185.4112.dev-apps-bugzilla@lists.mozilla.org>	<dbudnelwoblUQO_WnZ2dnUVZ_tudnZ2d@mozilla.org>
	<mailman.4471.1265895203.4112.dev-apps-bugzilla@lists.mozilla.org>
Message-ID: <I96dneAU6tHF1ejWnZ2dnUVZ_qSdnZ2d@mozilla.org>

On 11/02/10 13:32, Fr?d?ric Buclin wrote:
> My two main worries are 1) that it's harder to remember the exact syntax
> of each label/tag. With our current design, you have each field
> separately, with a list of values you can choose from. That's not prone
> to errors.

I think it is, not just the same sort of "errors".

The difficulty is, those of us with highly organized minds have a
tendency to think that as long as people are provided with the ability
to organize everything perfectly, then things will end up organized
perfectly. Sadly, that isn't the case.

The sort of "errors" you get with the current system are people not
setting a field, or setting it to the wrong value, or setting all the
fields to the right values but the person who is supposed to be finding
the bug to fix it looking for different values instead.

> Also, 2) with our current design, I know exactly where to look at for a
> given information, because a field is always at the exact same place in
> a bug report. With tags, I fear my eyes have to scan the whole list of
> tags all the time to know if such or such attribute is present. 

That's a UI question. A long undifferentiated list is not the only
possible UI for a tag-based system.

But also, your eye is trained to skip past all the fields that e.g. the
Bugzilla project never or rarely uses, such as Platform and OS. However,
these fields increase visual complexity and unapproachability.
Additionally, their global nature means that most of the values are
irrelevant for most of the software tracked in b.m.o.

If Platform and OS information were only present when it was relevant,
that would draw attention to the fact that the bug was platform or
OS-specific.

> Gerv, I'm not saying Google is wrong and Bugzilla is the right way to
> display or use metadata. I'm saying that you cannot use labels
> everywhere and all the time. 

I'm not arguing for "all the time". What I'd really like to see, to
being with, is a first-class tagging implementation. Then people could
decide what to use them for. :-)

> So it's rather
> a UI thing than a real rethink of the whole way Bugzilla works.

Again, I'm not arguing for us to rewrite Bugzilla from the ground up as
the Google bug tracker :-) What I want is for us to implement a proper
tagging system - which takes what we've learned from the status
whiteboard, keywords, flags and custom fields, rolls in what the rest of
the web has learned from their implementations of tagging, applies it to
the Bugzilla context (so e.g. public and private tags) and implements it
in a way which is fast (so a tags table and an integer-based search
backend).

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

From benjamin at smedbergs.us  Fri Feb 12 14:52:31 2010
From: benjamin at smedbergs.us (Benjamin Smedberg)
Date: Fri, 12 Feb 2010 09:52:31 -0500
Subject: Fwd: REST APIs, and Tags
In-Reply-To: <mailman.4514.1265914983.4112.dev-apps-bugzilla@lists.mozilla.org>
References: <lJ-dnTp28csNE5PWnZ2dnUVZ_hmdnZ2d@mozilla.org>	<yZidndn6Ks90U-_WnZ2dnUVZ_i2dnZ2d@mozilla.org>	<mailman.4482.1265904519.4112.dev-apps-bugzilla@lists.mozilla.org>	<DLOdnbzZ_Y171unWnZ2dnUVZ_hudnZ2d@mozilla.org>
	<mailman.4514.1265914983.4112.dev-apps-bugzilla@lists.mozilla.org>
Message-ID: <FI-dnQMPXZSy9ujWnZ2dnUVZ_jqdnZ2d@mozilla.org>

On 2/11/10 2:01 PM, Fr?d?ric Buclin wrote:

> You can have the best UI you want, bugs you don't care about will
> *always* be ignored. As discussed in mozilla.dev.planning and in bug
> 545284, you can already track incoming bugs. You can also use saved
> searches as Atom feeds to track incoming bugs. So you have all you need
> to track newcomers.

As a module owner who tries to respond and react to incoming bug reports, I 
don't disagree that there are ways to track incoming bugs. I do think that 
it would be good to put some energy into making the triage process easier 
and more explicit for those people who are tasked with doing it. That may 
involve going back to the old way of assigning bugs to particular people 
when they are filed, instead of nobody at mozilla.org. Those people will 
probably want a way to separate out bugmail from "bugs which are assigned to 
me in order to get an initial response" and "bugs assigned to me because I'm 
actually fixing them".

We certainly don't have the resources to *fix* every bug that comes in. But 
I think one of our goals in the next bit is to find a way to respond to 
every bug that comes in and make its current state clear. In many cases that 
may be "this is a bug, but it's not important enough for the mozilla 
developer community to fix it".

>> everyday user who is completely hooked into the project. But if you are
>> an occasional user, or new to the project, filing a bug is itself a
>> painful activity
>
> As said in mozilla.dev.planning, new users have the guided form to
> report bugs, or the normal form with advanced fields hidden by default.
> I don't see what's hard here.

The hardest part by far is selecting a component in which to file the bug. 
We have this built-in tension: having lots of little components is good for 
core developers, because they can watch "specialty" components without 
getting overloaded with email. Having a few large components is better for 
almost everyone else. I'd be interested to see if we could figure out a way 
to find the best of both worlds... perhaps hierarchical components so that 
all our layout/content/javascript bugs go in a "Web content" category, with 
subcategories for layout/content/javascript and sub-sub-categories for 
"layout: tables" or "content: XMLHttpRequest" or "javascript: JIT"... I 
don't know the right answer to this problem!

> The perception of being a black hole is because people tend to ignore
> what comes into Firefox:General and Core:General. What prevents all
> module owners to watch the QA contact of *:General for new bugs only
> (you know how to do this), and pay attention to bugs which seem to
> belong to your modules? On one side, you complain about getting too much
> bugmail, and on the other one, you complain to not get enough bugmail,
> making you miss some bugs.

Yes, most of us currently ignore Firefox:General and Core:General. We're 
trying to fix that without destroying everyone's productivity. It may 
involve finding or paying people to help out. The question is though, what 
should these people do? Simply moving the bug to the correct component may 
not be enough: it would be better to explicitly hand it off to a module 
owner at some point who can then decide the priority, comment in the bug, 
and assign it to somebody/nobody depending on how important it is.

> I will give you an example, keeping in mind that Bugzilla (the project)
> is by far not as large as Firefox: when a new bug is reported, a quick
> look at it lets us pretty easily say if the bug seems severe, a possible
> dupe, a RFE, etc... We quickly set some fields and it should then be in
> everyone's radar who is interested by such or such bugs.

At the end of this process is it clear to the original filer what has 
happened? I think many people see the flag changes, don't see any 
substantive comments, and still feel frustrated because they don't know (at 
least in mozilla... perhaps the bugzilla project is clearer!)

> That's because you watch flags having "blocking?". If you weren't
> watching them, you would miss them too. So watch what you need to watch.
> If you need help to have a working saved search to track incoming bugs,
> just tell; we can help here. And once it's built, you can even share it
> with other members of your team.

No, it's not because we "watch" those flags: it's because we have made a 
commitment to actually setting the flag to plus or minus before release. I 
would like a way to do that for every bug... it's almost as if every bug 
starts out with a triage?initial flag, and after it's gone through the 
process it ends up as triage-done, perhaps with trips through triage-ready 
or triage-needtestcase or whatever. Which is perhaps what we should do! I 
don't know yet.

This makes it possible for module owners (or at least the ones who care!) to 
have simple queries for "all the bugs in my module which haven't been 
triaged yet".

> We don't *require* metadata, besides the component. You can ignore the
> OS/Platform fields if they are unimportant to you. Why again do you pay
> attention to them if they are meaningless for your team??

Because they are there, and especially because they confuse new users who 
try to use those fields in the advanced bug search form.

> Use the priority field. Use the target milestone field. Mark them as
> blocking some meta bug. And be sure they are in the correct component.
> What else cannot you do with that?

I cannot accept nominations for 'this might be important, please decide 
whether it blocks alpha1/beta1/final'. I cannot easily create a bug search 
of "everything which directly or indirectly blocks bug 478976 and is 
assigned to nobody@". (I think... I could be wrong, the advanced bug search 
form is sometimes beyond my understanding.)

The problem with the priority field is that it means different things to 
different people. At various times we have used it for:

* each developer prioritizes their own bug list
* priorities are per-component
* priorities plus blocking flags used as a poor-man's multi-state flag

And the TM field feels useless because it doesn't have any of the "lorentz 
submilestones" in it, and people don't want to have a TM field with 150 
entries for each subproject that might want to track things.

And FWIW, the correct component for these bugs is many different things, 
because this is a multi-disciplinary project!

In any case, I probably *could* solve this with status whiteboard 
pseudo-tags. My problem is that these combinations of existing 
flags/keywords would end up with special meaning that was clear to me and to 
a few other core developers, but is completely unclear to most people. It 
feels like  trying to work around limitations in the tool, and my goal was 
to propose extensions to the tool that would help me solve my problems in a 
less haphazard way, and hopefully in a way that was clearer to outside 
participants.

--BDS
_______________________________________________
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  Fri Feb 12 15:49:22 2010
From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=)
Date: Fri, 12 Feb 2010 16:49:22 +0100
Subject: Fwd: REST APIs, and Tags
In-Reply-To: <FI-dnQMPXZSy9ujWnZ2dnUVZ_jqdnZ2d@mozilla.org>
References: <lJ-dnTp28csNE5PWnZ2dnUVZ_hmdnZ2d@mozilla.org>	<yZidndn6Ks90U-_WnZ2dnUVZ_i2dnZ2d@mozilla.org>	<mailman.4482.1265904519.4112.dev-apps-bugzilla@lists.mozilla.org>	<DLOdnbzZ_Y171unWnZ2dnUVZ_hudnZ2d@mozilla.org>	<mailman.4514.1265914983.4112.dev-apps-bugzilla@lists.mozilla.org> <FI-dnQMPXZSy9ujWnZ2dnUVZ_jqdnZ2d@mozilla.org>
Message-ID: <4B757882.7010108@gmail.com>

Le 12. 02. 10 15:52, Benjamin Smedberg a ?crit :
> reports, I don't disagree that there are ways to track incoming bugs. I
> do think that it would be good to put some energy into making the triage
> process easier and more explicit for those people who are tasked with
> doing it.

I agree. Maybe this could be done by sharing some well built saved
searches. For instance, I have a saved search which lists all bugs
younger than 2 days in components I'm interested in. That plus
automatically getting bugmail for newly filed bugs, I never miss one. :)


> The hardest part by far is selecting a component in which to file the
> bug.

As discussed on IRC, the guided form could list only a subset of fake
components, and the backend code (aka post_bug.cgi) would then match
them with real existing components. I guess it doesn't really matter if
a bug isn't filed in the right subcomponent of Layout:* or DOM:* or
Widget:*, and it would be easy for the module owner or peer to set the
exact component the bug belongs to.

> what should these people do? Simply moving the bug to the correct
> component may not be enough

It would be better than nothing, as long as module owners and peers
watch their own components, you would notice the newcomer.


> At the end of this process is it clear to the original filer what has
> happened?

I'm not really worried about whether the process is clear to the
reporter or not. If there are missing information, such as STR, we will
let him know. What is important is that its status is clear to
developers who may potentially fix the bug.


> I would like a way to do that for every bug... it's almost as if every
> bug starts out with a triage?initial flag, and after it's gone through
> the process it ends up as triage-done, perhaps with trips through
> triage-ready or triage-needtestcase or whatever. Which is perhaps what
> we should do! I don't know yet.

Personally, we use the "qawanted" keyword to mean "this bug needs some
attention", either because it doesn't look valid, or because it needs
some more investigation before confirming it or marking it as blocker.

Here, I use the same trick as for new bugs. I watch the default QA
contact of components I'm interested in, and in the email preferences, I
only checked "email me when a new bug is filed" and "email me when a
keyword is added or removed" for the QA contact. We don't use many
keywords for Bugzilla, but in your case you could let Thunderbird triage
incoming bugmail and only keep relevant keywords, thanks to the
X-Bugzilla-Keywords header of bugmail. Instead of a flag, you could use
the "needs-triage" keyword. When you see this keyword in a component you
own, you know this bug is for you. :) And if you didn't pay immediate
attention to them, a saved search "keyword=needs-triage" used as an Atom
field will be a good reminder.


> Because they are there, and especially because they confuse new users
> who try to use those fields in the advanced bug search form.

FYI, we plan to make these two fields optional in Bugzilla 3.8, because
it's a pain even for us. :) Meanwhile, advanced users know they should
just ignore these two fields in their queries (this is a workaround for
now).


> I cannot accept nominations for 'this might be important, please decide
> whether it blocks alpha1/beta1/final'.

Couldn't your team use the needs-triage keyword together with a comment
explaining why the keyword is set? You would get something like:

Some Triager <some.triager at company.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           keywords|                            |needs-triage

--- Comment #7 from Some Triager <some.triager at company.com> 2010-02-11
17:03:28 CET ---
bsmedberd, do you think it should block beta1?


> search of "everything which directly or indirectly blocks bug 478976 and
> is assigned to nobody@".

Yes, you are right, you cannot for indirect blockers. But you can for
direct blockers, which is a start. But I think we should implement this;
I hope this is not too hard. Bug 487864 asks dependencies for
QuickSearch. I will check if we have a separate bug for indirect
dependencies specifically.


> And the TM field feels useless because it doesn't have any of the
> "lorentz submilestones" in it, and people don't want to have a TM field
> with 150 entries for each subproject that might want to track things.

This will become easier once bug 77193 is fixed.


> And FWIW, the correct component for these bugs is many different things,
> because this is a multi-disciplinary project!

Haha, yes, I agree. :)


LpSolit


From lpsolit at gmail.com  Fri Feb 12 15:57:34 2010
From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=)
Date: Fri, 12 Feb 2010 16:57:34 +0100
Subject: Fwd: REST APIs, and Tags
In-Reply-To: <FI-dnQMPXZSy9ujWnZ2dnUVZ_jqdnZ2d@mozilla.org>
References: <lJ-dnTp28csNE5PWnZ2dnUVZ_hmdnZ2d@mozilla.org>	<yZidndn6Ks90U-_WnZ2dnUVZ_i2dnZ2d@mozilla.org>	<mailman.4482.1265904519.4112.dev-apps-bugzilla@lists.mozilla.org>	<DLOdnbzZ_Y171unWnZ2dnUVZ_hudnZ2d@mozilla.org>	<mailman.4514.1265914983.4112.dev-apps-bugzilla@lists.mozilla.org> <FI-dnQMPXZSy9ujWnZ2dnUVZ_jqdnZ2d@mozilla.org>
Message-ID: <4B757A6E.9010801@gmail.com>

Le 12. 02. 10 15:52, Benjamin Smedberg a ?crit :
> I cannot easily create a bug
> search of "everything which directly or indirectly blocks bug 478976 and
> is assigned to nobody@".

Found it: bug 543837.


From benjamin at smedbergs.us  Fri Feb 12 16:04:51 2010
From: benjamin at smedbergs.us (Benjamin Smedberg)
Date: Fri, 12 Feb 2010 11:04:51 -0500
Subject: Fwd: REST APIs, and Tags
In-Reply-To: <mailman.4609.1265989813.4112.dev-apps-bugzilla@lists.mozilla.org>
References: <lJ-dnTp28csNE5PWnZ2dnUVZ_hmdnZ2d@mozilla.org>	<yZidndn6Ks90U-_WnZ2dnUVZ_i2dnZ2d@mozilla.org>	<mailman.4482.1265904519.4112.dev-apps-bugzilla@lists.mozilla.org>	<DLOdnbzZ_Y171unWnZ2dnUVZ_hudnZ2d@mozilla.org>	<mailman.4514.1265914983.4112.dev-apps-bugzilla@lists.mozilla.org>	<FI-dnQMPXZSy9ujWnZ2dnUVZ_jqdnZ2d@mozilla.org>
	<mailman.4609.1265989813.4112.dev-apps-bugzilla@lists.mozilla.org>
Message-ID: <edKdnaDi95G-4ejWnZ2dnUVZ_hKdnZ2d@mozilla.org>

On 2/12/10 10:49 AM, Fr?d?ric Buclin wrote:

> I'm not really worried about whether the process is clear to the
> reporter or not. If there are missing information, such as STR, we will
> let him know. What is important is that its status is clear to
> developers who may potentially fix the bug.

What we are discussion in dev.planning is how it's supremely important (to 
us at least) to make it clear to the original reporter and other people 
cc'ed on the bug what the status is. This will help a lot with web 
developers filing a bug, thinking it has been ignored, and never 
participating again.

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


From szabgab at gmail.com  Fri Feb 12 20:31:06 2010
From: szabgab at gmail.com (Gabor Szabo)
Date: Fri, 12 Feb 2010 22:31:06 +0200
Subject: post FOSDEM
In-Reply-To: <ArudnbvuMs7M2-jWnZ2dnUVZ_oKdnZ2d@mozilla.org>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>
	 <WcidnWPFppxcZe7WnZ2dnUVZ_gZi4p2d@mozilla.org>
	 <97784.55432.qm@web114014.mail.gq1.yahoo.com>
	 <mailman.4542.1265926982.4112.dev-apps-bugzilla@lists.mozilla.org>
	 <ArudnbvuMs7M2-jWnZ2dnUVZ_oKdnZ2d@mozilla.org>
Message-ID: <d8a74af11002121231v24277461o2067c87613e6c08e@mail.gmail.com>

On Fri, Feb 12, 2010 at 2:15 PM, Gervase Markham <gerv at mozilla.org> wrote:
> On 11/02/10 22:22, Gabor Szabo wrote:

> We use a product called Bugzilla for bug tracking - do you think that's
> modern enough?
>
> ;-P

We'll discuss this separately ;-)


>> not using Makefile.PL or Build.PL,
>
> Could you explain a bit more about what we would be using them for? We
> don't have any compiled bits...
>
>> not using "standard" CPAN layout:
>> ? ?modules in ? ?ROOT/lib/
>> ? ?command line scripts in ? ? ? ROOT/script
>> ? ?cgi scripts in some other directory (e.g. I use ROOT/www)
>
> Now that we are in a proper SCM, moving files around has suddenly got a
> whole lot easier. I guess the issue with switching to this layout is
> that everyone upgrading would have to change their Apache configuration.
> Wouldn't they?

I guess yes.

The advantage of the slight reorganization of the layout and the addition of
Makefile.PL or Build.PL is that then Bugzilla could be packaged to be uploaded
to CPAN just as any other CPAN distribution and then you would gain the
various additional features the CPAN ecosystem provides and the mind-share (!)
of the CPAN authors.
e.g. you would automatically get and RT queue.
Err. That might not be so convincing :-)
But you would get the reporting of the CPAN Testers which can be very nice.

With some more work the installation of Bugzilla might be changed so that in
addition to the current way it will also work using

cpan> install Bugzilla

Again, I think this will raise karma of Bugzilla among the CPAN authors.

Of course blogging about the plan, and then about the execution would
further help.

(There is a notion called GrayPAN and BlackPAN - relating to code that
is either open source but not on CPAN or to code that is behind corporate
firewall. Moving Bugzilla from GrayPAN to CPAN would allow it to be
included in various automatic analytical systems)
e.g. see http://ali.as/top100/index.html


>> I am not sure if it should be done on http://bugzillaupdate.wordpress.com/
>> or on some other blog (maybe on http://blogs.perl.org/ ) but I am quite sure
>> the entires should appear on both http://ironman.enlightenedperl.org/ and on
>> http://perlsphere.net/ that are read by many people.
>
> Are those aggregators? I'm sure we could submit the Bugzilla updates
> blog to them.

Yes, http://ironman.enlightenedperl.org/ and  http://perlsphere.net/ are
blog aggregators and especially the former one is now very central to the
core perl readers. Lots of discussion is going on there.


Gabor
ps. Why do the replyes go to both
developers at bugzilla.org and on dev-apps-bugzilla at lists.mozilla.org ?


From mkanat at bugzilla.org  Fri Feb 12 20:51:34 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Fri, 12 Feb 2010 12:51:34 -0800
Subject: cannot run tests when using PERL5LIB (e.g. when using local::lib)
In-Reply-To: <3tWdnaWAGJ0fr-jWnZ2dnUVZ_hL_fwAA@mozilla.org>
References: <d8a74af11002111333g76634b1crfcafbc85fcf16554@mail.gmail.com>	<mailman.4533.1265924321.4112.dev-apps-bugzilla@lists.mozilla.org> <3tWdnaWAGJ0fr-jWnZ2dnUVZ_hL_fwAA@mozilla.org>
Message-ID: <4B75BF56.3010705@bugzilla.org>

On 02/12/2010 02:50 AM, Gervase Markham wrote:
> This suggestion worries me slightly. Not because it wouldn't work, but
> because I think we are going to have issues working with the wider Perl
> community if, when they say "hey, this standard thing doesn't work", we
> say "oh, that's OK, you can just do it our way instead".

	Yeah, that wasn't my intention at all, I was just providing a possible
workaround. And as you noted, I already accepted and committed Gabor's
patch.

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


From szabgab at gmail.com  Fri Feb 12 20:57:00 2010
From: szabgab at gmail.com (Gabor Szabo)
Date: Fri, 12 Feb 2010 22:57:00 +0200
Subject: cannot run tests when using PERL5LIB (e.g. when using local::lib)
In-Reply-To: <4B75BF56.3010705@bugzilla.org>
References: <d8a74af11002111333g76634b1crfcafbc85fcf16554@mail.gmail.com>
	 <mailman.4533.1265924321.4112.dev-apps-bugzilla@lists.mozilla.org>
	 <3tWdnaWAGJ0fr-jWnZ2dnUVZ_hL_fwAA@mozilla.org>
	 <4B75BF56.3010705@bugzilla.org>
Message-ID: <d8a74af11002121257w3b7fefefqf420859cd3d07515@mail.gmail.com>

On Fri, Feb 12, 2010 at 10:51 PM, Max Kanat-Alexander
<mkanat at bugzilla.org> wrote:
> On 02/12/2010 02:50 AM, Gervase Markham wrote:
>> This suggestion worries me slightly. Not because it wouldn't work, but
>> because I think we are going to have issues working with the wider Perl
>> community if, when they say "hey, this standard thing doesn't work", we
>> say "oh, that's OK, you can just do it our way instead".
>
> ? ? ? ?Yeah, that wasn't my intention at all, I was just providing a possible
> workaround. And as you noted, I already accepted and committed Gabor's
> patch.
>

thanks for both of you!

Gabor


From dmarshal at yahoo-inc.com  Fri Feb 12 20:59:19 2010
From: dmarshal at yahoo-inc.com (David Marshall)
Date: Fri, 12 Feb 2010 12:59:19 -0800
Subject: Why Not Y!?
Message-ID: <C79B0127.4005A%dmarshal@yahoo-inc.com>

Hi all,

This is very informal, totally optional (of course), and entirely a matter
of curiosity for me.

Last March, I sent email to this mailing list announcing that Yahoo! was
hiring an additional Bugzilla developer.  I received a number of inquiries,
for which I'm grateful.  To be honest, though, I expected more interest than
I saw.

We're not currently hiring anyone for Bugzilla, and I don't know when/if we
will be next, so this isn't a preface to a similar announcement.

However, I'm interested in why any given person chose not to express any
interest.  For a number of people (some who wrote and some who didn't), it's
not desirable or feasible to move to California.  Others are very happy with
what they're doing and don't want to do something else (like me!).  Some
people don't want to be or cannot be a full-timer at a big company.  That's
all completely understandable.

I'd really like to hear from you if you were looking for a job or were
thinking about it at the time but decided not to express interest in my
posting.  Was there anything about the description or Yahoo! itself that
made you decide against?  Was there anything *not* in the description or
some area in which you think Yahoo! is lacking that made you decide against?

As I said above, this is very informal.  I am just gathering information to
see whether it supports certain hypotheses.  Unless I ask for and receive
your explicit permission to share your remarks (anonymously) with others at
Yahoo!, I'll regard your communication as private between us.

If you would prefer to email me at some other email address, please find me
on #mozwebtools (as dwm), and I'll give you my personal email address.

Thank you very much!



From mkanat at bugzilla.org  Fri Feb 12 21:15:52 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Fri, 12 Feb 2010 13:15:52 -0800
Subject: Fwd: REST APIs, and Tags
In-Reply-To: <edKdnaDi95G-4ejWnZ2dnUVZ_hKdnZ2d@mozilla.org>
References: <lJ-dnTp28csNE5PWnZ2dnUVZ_hmdnZ2d@mozilla.org>	<yZidndn6Ks90U-_WnZ2dnUVZ_i2dnZ2d@mozilla.org>	<mailman.4482.1265904519.4112.dev-apps-bugzilla@lists.mozilla.org>	<DLOdnbzZ_Y171unWnZ2dnUVZ_hudnZ2d@mozilla.org>	<mailman.4514.1265914983.4112.dev-apps-bugzilla@lists.mozilla.org>	<FI-dnQMPXZSy9ujWnZ2dnUVZ_jqdnZ2d@mozilla.org>	<mailman.4609.1265989813.4112.dev-apps-bugzilla@lists.mozilla.org> <edKdnaDi95G-4ejWnZ2dnUVZ_hKdnZ2d@mozilla.org>
Message-ID: <4B75C508.1030804@bugzilla.org>

On 02/12/2010 08:04 AM, Benjamin Smedberg wrote:
> What we are discussion in dev.planning is how it's supremely important
> (to us at least) to make it clear to the original reporter and other
> people cc'ed on the bug what the status is. This will help a lot with
> web developers filing a bug, thinking it has been ignored, and never
> participating again.

	I agree that this is important.

	I'm staying out of this particular branch of this thread, mostly,
though. I think my views on the situation were mostly expressed in my
earlier response to your very-helpful problem statement, and if you have
thoughts on my response, I'd be happy to discuss them with you.

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


From mkanat at bugzilla.org  Fri Feb 12 21:22:28 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Fri, 12 Feb 2010 13:22:28 -0800
Subject: Fwd: REST APIs, and Tags
In-Reply-To: <I96dneAU6tHF1ejWnZ2dnUVZ_qSdnZ2d@mozilla.org>
References: <lJ-dnTp28csNE5PWnZ2dnUVZ_hmdnZ2d@mozilla.org>	<yZidndn6Ks90U-_WnZ2dnUVZ_i2dnZ2d@mozilla.org>	<mailman.4377.1265818185.4112.dev-apps-bugzilla@lists.mozilla.org>	<dbudnelwoblUQO_WnZ2dnUVZ_tudnZ2d@mozilla.org>	<mailman.4471.1265895203.4112.dev-apps-bugzilla@lists.mozilla.org> <I96dneAU6tHF1ejWnZ2dnUVZ_qSdnZ2d@mozilla.org>
Message-ID: <4B75C694.50609@bugzilla.org>

On 02/12/2010 04:23 AM, Gervase Markham wrote:
> What I want is for us to implement a proper
> tagging system - which takes what we've learned from the status
> whiteboard, keywords, flags and custom fields, rolls in what the rest of
> the web has learned from their implementations of tagging, applies it to
> the Bugzilla context (so e.g. public and private tags) and implements it
> in a way which is fast (so a tags table and an integer-based search
> backend).

	Okay, here's what I think:

	* Tags are good.
	* Having global tags, private tags, one fixed list of tags, and totally
unfixed list of tags all together is too complicated. So we need a
solution that starts off with some specific problem statement (like
bsmedberg's, which was great) and demonstrates why a much simpler
implementation than this is an excellent solution for both broad
distributed teams like Mozilla, and in-house corporate shops (who are
the majority of consumers of Bugzilla).

	Further debate on the merits of particular details of the feature
probably isn't going to get us anywhere until we address the above. And
once we address the above, then we can start to have a direction to go
in that can (and eventually will) actually be implemented.

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


From mkanat at bugzilla.org  Fri Feb 12 21:44:58 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Fri, 12 Feb 2010 13:44:58 -0800
Subject: post FOSDEM
In-Reply-To: <d8a74af11002111422k21e6c47eqda30746a08713dc4@mail.gmail.com>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>	 <WcidnWPFppxcZe7WnZ2dnUVZ_gZi4p2d@mozilla.org>	 <97784.55432.qm@web114014.mail.gq1.yahoo.com> <d8a74af11002111422k21e6c47eqda30746a08713dc4@mail.gmail.com>
Message-ID: <4B75CBDA.9080702@bugzilla.org>

On 02/11/2010 02:22 PM, Gabor Szabo wrote:
> Maybe it is just me and no one of the other use.perl.org readers think
> the same but I am still not sure if the Bugzilla team likes the fact
> that it is written in Perl or that you hate every inch of it?

	I think that we talked about this in one of our Bugzilla Meetings, and
basically, Bugzilla is written in Perl, and it's written in Perl no
matter whether each of us loves it or hates it. Perl has some awesome
things about it, and some bad things about it. (By the way, as a side
note, every programmer should have experience writing professionally in
multiple languages, so that they can understand what's good about each
language and what's bad about it--with only single-language experience
it's hard to make such a judgment.)

	It's a programming language, a tool to and end. I don't think it's an
emotional issue, it's just a technical fact that Bugzilla is in Perl.

> Also - again IMHO - Bugzilla needs to send the message of using
> *modern tools* in its development. (e.g. CVS  still being the
> recommended way to fetch the source code is NOT sending this
> messages).

	The switch happened just days ago, and pretty much all the developer
documentation is written by me, in addition to almost all the
administrative details of the project being done by me, in addition to
50% or more of the development of the project being done by me, and I'm
not getting paid for any of it. So yes, I agree that the documentation
needs to be fixed, and it will be done soon.

	However, CVS is still going to be easier for some people than bzr,
because far more people are familiar with CVS. So we'll keep around some
CVS instructions as well.

> the local::lib/PERL5LIB stuff I am trying to patch,

	You're actually the first person ever to mention a problem with it, I
believe. :-) Otherwise we would have fixed it earlier.

> not using Makefile.PL or Build.PL,
> not using "standard" CPAN layout:

	Mmm, I tend to think that, at the moment, installation would actually
become more difficult than it is now, with Module::Install, particularly
on Windows. There have been a few other people who have made this
suggestion when they were new to Bugzilla, but usually as people become
more familiar with the codebase, the community, and Bugzilla's install
process on various platforms, they see that it's better the way that it
is. However, if you can demonstrate to us that in the context of
Bugzilla's userbase and community, that there would be significant
technical advantages to restructuring to a more normal CPAN layout, then
it's something that we could certainly do now, since we're using a VCS
that understands renames. It would be a lot of work and a big change for
us, though, so we'd definitely want to see some strong technical advantages.

> I'll try to allocate some time and look at the project to give you
> more unwanted suggestions and maybe even a few patches.

	Hahahaha. Your suggestions are not unwanted at all, I'm really glad to
have them, personally. :-)

> I am not sure if it should be done on http://bugzillaupdate.wordpress.com/
> or on some other blog (maybe on http://blogs.perl.org/ ) but I am quite sure
> the entires should appear on both http://ironman.enlightenedperl.org/ and on
> http://perlsphere.net/ that are read by many people.

	This is certainly something to think about, and it's cool to have
experienced suggestions from somebody with good experience in the area.

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


From mkanat at bugzilla.org  Fri Feb 12 21:49:51 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Fri, 12 Feb 2010 13:49:51 -0800
Subject: post FOSDEM
In-Reply-To: <d8a74af11002121231v24277461o2067c87613e6c08e@mail.gmail.com>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>	 <WcidnWPFppxcZe7WnZ2dnUVZ_gZi4p2d@mozilla.org>	 <97784.55432.qm@web114014.mail.gq1.yahoo.com>	 <mailman.4542.1265926982.4112.dev-apps-bugzilla@lists.mozilla.org>	 <ArudnbvuMs7M2-jWnZ2dnUVZ_oKdnZ2d@mozilla.org> <d8a74af11002121231v24277461o2067c87613e6c08e@mail.gmail.com>
Message-ID: <4B75CCFF.7080701@bugzilla.org>

On 02/12/2010 12:31 PM, Gabor Szabo wrote:
> The advantage of the slight reorganization of the layout and the addition of
> Makefile.PL or Build.PL is that then Bugzilla could be packaged to be uploaded
> to CPAN just as any other CPAN distribution and then you would gain the
> various additional features the CPAN ecosystem provides and the mind-share (!)
> of the CPAN authors.

	This is true, but currently all of our pages are separate CGI files, so
it's not like other web apps where there's a single .pl file that runs
under FastCGI and can reasonably installed in /usr/sbin/. Also, all of
our static web files are really static files, not handlers called
through a single point of access. The CPAN modules that I'm familiar
with don't provide any decent way of putting everything into a web
space, and with the current Bugzilla layout, all you have to do is untar
the tarball and you're basically good to go, in terms of layout.

> But you would get the reporting of the CPAN Testers which can be very nice.

	That would be good for sure.

	By the way, Bugzilla Extensions (that will be appearing in 3.6) are
designed in such a way that they can be packaged and distributed on CPAN.

> developers at bugzilla.org and on dev-apps-bugzilla at lists.mozilla.org ?

	developers@ was originally a majordomo list. Then we moved to using a
newsgroup with a gateway, but we wanted to keep the primary address as
developers at bugzilla.org.

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


From mkanat at bugzilla.org  Fri Feb 12 21:54:27 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Fri, 12 Feb 2010 13:54:27 -0800
Subject: Test coverage is 18.4%
In-Reply-To: <d8a74af11002112213p48e5cd5cr4269447ff2fa94f8@mail.gmail.com>
References: <d8a74af11002112213p48e5cd5cr4269447ff2fa94f8@mail.gmail.com>
Message-ID: <4B75CE13.3020705@bugzilla.org>

On 02/11/2010 10:13 PM, Gabor Szabo wrote:
> and the total test coverage of Bugzilla is 18.4%

	Yeah, just to say again what others have said, this is a problem, for sure.

> Are there tests other than those in t/*?

	There are the Selenium tests that Byron pointed out--those are our main
method of QA at the moment.

	The nice part about the Selenium tests is that they make sure that the
actual UI and the JavaScript in Bugzilla works. That is, we wouldn't
really have "full coverage" unless we tested those as well.

	Having unit tests for every single method and function in Bugzilla
would be great, though. The fact is, the lack of TDD in our development
process is one of the things that makes the review process so difficult.
But the number of tests that we'd have to write to truly have full
coverage is also something that's nearly overwhelming for us, because we
just don't have the current manpower to do it.

	If somebody wanted to work on getting Bugzilla fully unit-tested, I'd
be behind it 100% of the way. (Note that to get really full coverage on
the Perl code, we'd have to move all the .cgi code into Controller
modules, but that's something that I've want to do  anyway.)

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


From ahdevans at gmail.com  Fri Feb 12 22:05:52 2010
From: ahdevans at gmail.com (Aaron Evans)
Date: Fri, 12 Feb 2010 14:05:52 -0800
Subject: Test coverage is 18.4%
In-Reply-To: <4B75CE13.3020705@bugzilla.org>
References: <d8a74af11002112213p48e5cd5cr4269447ff2fa94f8@mail.gmail.com>
	 <4B75CE13.3020705@bugzilla.org>
Message-ID: <36fce4891002121405ocdb7d1odf73ebc6eebb894b@mail.gmail.com>

The biggest problem I've found trying to go back and fill in unit tests is
you can either cover the obvious things that won't break unless there are
API changes, but the type of stuff that more often breaks can't often be
deduced from the code (not to mention you can't find existing bugs when the
implementation is your spec.

On Fri, Feb 12, 2010 at 1:54 PM, Max Kanat-Alexander <mkanat at bugzilla.org>wrote:

> On 02/11/2010 10:13 PM, Gabor Szabo wrote:
> > and the total test coverage of Bugzilla is 18.4%
>
>         Yeah, just to say again what others have said, this is a problem,
> for sure.
>
> > Are there tests other than those in t/*?
>
>         There are the Selenium tests that Byron pointed out--those are our
> main
> method of QA at the moment.
>
>        The nice part about the Selenium tests is that they make sure that
> the
> actual UI and the JavaScript in Bugzilla works. That is, we wouldn't
> really have "full coverage" unless we tested those as well.
>
>        Having unit tests for every single method and function in Bugzilla
> would be great, though. The fact is, the lack of TDD in our development
> process is one of the things that makes the review process so difficult.
> But the number of tests that we'd have to write to truly have full
> coverage is also something that's nearly overwhelming for us, because we
> just don't have the current manpower to do it.
>
>        If somebody wanted to work on getting Bugzilla fully unit-tested,
> I'd
> be behind it 100% of the way. (Note that to get really full coverage on
> the Perl code, we'd have to move all the .cgi code into Controller
> modules, but that's something that I've want to do  anyway.)
>
>        -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=ahdevans at gmail.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20100212/a3268efe/attachment.html>

From dmarshal at yahoo-inc.com  Fri Feb 12 22:04:41 2010
From: dmarshal at yahoo-inc.com (David Marshall)
Date: Fri, 12 Feb 2010 14:04:41 -0800
Subject: Test coverage is 18.4%
In-Reply-To: <4B75CE13.3020705@bugzilla.org>
Message-ID: <C79B1079.40079%dmarshal@yahoo-inc.com>




On 2/12/10 1:54 PM, "Max Kanat-Alexander" <mkanat at bugzilla.org> wrote:

> On 02/11/2010 10:13 PM, Gabor Szabo wrote:
>> and the total test coverage of Bugzilla is 18.4%
> 
> Yeah, just to say again what others have said, this is a problem, for sure.
> 

I don't think it's a problem at all, because the t/* tests were never, as
far as I am aware, intended to be testing for coverage.  I'm rather
surprised that the number is as high as 18.4%!

At Yahoo!, where we've been putting a lot of effort into continuous
integration, I use t/* as a "commit test" - committing to the repository
triggers an automatic run of t/*.  The idea is to do a quick check that a
commit hasn't horked anything - the Perl compiles, etc.

We also have a home-grown test suite that we use as a "smoke test" - a
nightly test that interacts with Bugzilla through apache and a working
database.  It takes about twenty minutes to run at present.  That's what I
want to have 100% coverage.  Currently, we're at about 60% or so.

We have our own Selenium tests written as well, but I haven't included them
in our continuous integration implementation.



From mkanat at bugzilla.org  Fri Feb 12 22:37:37 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Fri, 12 Feb 2010 14:37:37 -0800
Subject: Results of Community Research
In-Reply-To: <4B55A7AF.2040803@mozilla.org>
References: <mailman.2477.1263867262.4112.dev-apps-bugzilla@lists.mozilla.org> <4B55A7AF.2040803@mozilla.org>
Message-ID: <4B75D831.8080005@bugzilla.org>

	Okay, I'm finally getting back to these emails! :-) See my responses
inline below:

On 01/19/2010 04:38 AM, Gervase Markham wrote:
> Would it be worth instead doing some sort of three-month rolling average
> (if you've contributed in month X, or X+1, or X-1, you get a tick for
> month X)?

	I think that actually wouldn't be statistically significant, because
the freeze harm was several months long, and the recovery from it was
slow over several months, for each freeze.

> Or perhaps look at attached patches in Bugzilla as well as
> checkin data?

	Yeah, actually, I think that would be definitely worthwhile, at least
to get a sense of whether or not there was some problem with people
attaching patches but them never getting in, if nothing else.

> Did you find it was common for someone to leave the community and
> return? 

	I don't know, but them leaving the community at all is a problem, in
terms of what I was looking into. I mean, I want people to be
participating as much as they possibly can and want to.

> Is the raw data available to look at?

	Yeah, I post it up somewhere, if you think that there's something to be
gained or some other investigation of value to be done with it.

> What are the absolute numbers
> here? Was the peak community size 4, or 40?

	The peak was 25.

> Is the addition or removal
> of a single contributor a significant factor in the numbers?

	No, not really. Also, there is so much data that it's not
month-to-month that matters, but the general trend of the graph, which
is pretty clear.

> I didn't even realise there was a review-requests mailing list. Or, if I
> ever knew it, I've forgotten.

	Yeah, I didn't quite know about it either.

> - The acceptance of a patch which provides partial, useful,
> functionality in pursuit of a larger goal, rather than waiting for the
> submitter to implement the entire feature as envisaged by the team (but
> not by the submitter)

	I used to accept things like this and I no longer do, because what
happens is that we actually end up releasing for years with a
half-implemented feature that causes more problems than it solves. I
spent almost the entire 3.6 development cycle "finishing" features that
should have been complete years ago (even ones that I wrote) and the 3.8
cycle is going to be taken up with a tremendous amount of that as well.

> - The acceptance of a patch which provides useful functionality, even if
> the code would eventually be obsoleted by a rewrite of the feature which
> is wanted but un-resourced and un-scheduled

	That's something that can be accepted, *unless* the rewrite is
something that would actually only take a little more effort. For
example, component-watching is actually only a little bit easier than
everything-watching, and everything-watching might be more useful.
That's a fine line, and it's something that I know that I, at least,
could be pushed on, though, with a rational argument.

> - Within limits, the acceptance of a patch which solves a problem for an
> existing user or set of users, even if the Bugzilla team don't
> particularly like the way it's done, if the team has no plans to solve
> that problem themselves 'the better way'.

	If "the Bugzilla team doesn't like the way it's done", that means that:

	(a) The code is poorly architected
	(b) The feature is implemented in a way that we think is not helpful
enough to justify the code complexity.

	So in those cases, we won't accept patches, but we will provide review
comments and guidance on where to go with them. If the patch author
doesn't want to improve the patch, then we will probably eventually get
to it, but we won't accept a poorly-implemented feature, because that's
a disservice to our users.

> - The documentation build system was byzantine in its complexity, and
>   every time I got a new machine (or even when I didn't) it needed
>   setting up.

	That is so true. We really need to switch to xmlto, but nobody's taken
the time to do that yet. I suspect that that will resolve this issue.

> - The XML markup gave the ability to produce text, HTML and PDF, but it
>   made it very difficult to do things with graphics or layout in order
>   to make the documentation more readable. I had to remember an XML
>   vocabulary not used anywhere else in my online life.

	Yeah, I'm not an enormous fan of that process, either.

> - Documentation was treated like code, with patches having to be
>   prepared and reviewed, rather than like a wiki. Getting fixes in,
>   particularly rewrites and reorganizations, was just too much effort.

	Here's the thing about a Wiki--it requires a significant number of
editors who pay attention to it continuously and carefully. The
Win32Install instructions, which we have on the Wiki, became edited into
unusefulness while LpSolit and I weren't paying attention to them. Right
now we just don't have that many people that I think could effectively
function as technical editors of the documentation if it were on a Wiki.

	Perhaps a trade-off would be keeping the installation instructions in
Docbook, and putting everything else into the Wiki. But then how would
we do localization? Would we still be able to ship documentation with
Bugzilla? (Is that even important?)

> Have you read "The Art of Community" by Jono Bacon, recently published?
> It's fantastic on this sort of thing - well worth a read. I read it
> recently, cover to cover.

	No, I haven't. Do you think it's worth reading the whole book, or do
you think a Cliff's Notes version would help? :-)

>> 	1) Extremely rapid response to review requests. No matter how much
>> review a contributor has to go through, they usually will go through it
>> as long as there aren't LONG DELAYS between the request and the response.
> 
> Definitely. On the main Mozilla side, I've been trying for years to get
> a system in place which tracks this across the project and nags the
> appropriate people. The trick, in that case, is defining "appropriate
> people".

	I could imagine a workable system here, I think. Something like, "After
X days, remind the requestee" and then if no response, "After Y days,
remind the module owner" and then if no response, "After Z days, remind
Somebody Important." Perhaps Somebody Important could be a Community
Manager for Mozilla, or something.

>> 	Some people are hopeless programmers, and they're never going to get
>> better no matter how much you help them or how many reviews you do. For
>> these people, you don't have to imagine nice things to say about them--I
>> don't expect anybody to ever make up stuff that isn't true, just to be
>> nice. If somebody has demonstrated conclusively that they're never going
>> to get any better, or that they're just going to cause trouble one way
>> or another no matter what we do, the best thing you can do is simply
>> personally choose to ignore them, which is a personal decision that you
>> can make for yourself.
> 
> I don't actually agree with that. I think the best thing you can do is
> tell them why their contributions aren't being accepted, and say that
> unfortunately you will not be able to make time in future to review
> their contributions. This is possibly (although by no means certainly)
> more likely to result in hurt feelings than just ignoring them, but it
> is also much more likely that their life will improve as they go and do
> something they are actually good at. You certainly don't have to be rude
> or brusque when telling them, but I think you are doing them greater
> good by telling them.

	Okay, you know what, I agree with you here, that at least as a first
attempt, it's more valuable to confront the individual, if you feel like
you can. I don't think that everybody has the requisite communication
skills (or wants to do this), so if a reviewer wants me or another
person to talk to them about it instead, then we'd be happy to. But if
nobody feels capable of talking to the individual, then another option
is to simply ignore the poor contributors who aren't getting better no
matter how many times they are reminded.

> Also, bad coders might make great support people, or documenters (if
> your documentation system isn't the functional and process equivalent of
> writing code ;-).

	Yeah...I don't think I've ever seen a really poor coder write good
documentation or provide good support, though.

>> 	Look, I understand that sometimes coding and working on a collaborative
>> project with people who have different viewpoints can get REALLY
>> frustrating! I've been an offender in this area just as much as anybody
>> has been! But it's really not OK for us to insult other developers
>> personally just because we're frustrated with them personally.
> 
> I agree with all of what you write. Have you noticed any of this? This
> isn't acceptable in a more broader Mozilla context, as well as in a
> Bugzilla one, and I take it seriously when I find it.

	Well, I think that I notice it more in cases like, "That is a
stupid/ridiculous idea"--that's something that I consider a personal
attack on the individual instead of a constructive method of working
together. In general, I more often see personal insults *veiled* as
"professional disagreements" than I see actual personal insults.

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


From mkanat at bugzilla.org  Fri Feb 12 22:38:40 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Fri, 12 Feb 2010 14:38:40 -0800
Subject: duplicates.cgi
In-Reply-To: <k8qdnW87Bp4djsvWnZ2dnUVZ_txi4p2d@mozilla.org>
References: <k8qdnW87Bp4djsvWnZ2dnUVZ_txi4p2d@mozilla.org>
Message-ID: <4B75D870.2080602@bugzilla.org>

On 01/19/2010 12:18 PM, Wayne Mery wrote:
> Is there a way to make/put the output of duplicates.cgi - eg
> https://bugzilla.mozilla.org/duplicates.cgi?product=MailNews%20Core&product=Thunderbird&format=simple&sortby=delta&reverse=1&maxrows=100&changedsince=28
> - into a real bugzilla query result list of buglist.cgi?

	Yeah, take off format=simple, and then there will be a button "bug
list" on the page.

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


From mkanat at bugzilla.org  Fri Feb 12 22:46:38 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Fri, 12 Feb 2010 14:46:38 -0800
Subject: Results of Community Research
In-Reply-To: <4B557C7D.4060108@gmail.com>
References: <4B55155F.3060007@bugzilla.org> <4B557C7D.4060108@gmail.com>
Message-ID: <4B75DA4E.20104@bugzilla.org>

On 01/19/2010 01:33 AM, Fr?d?ric Buclin wrote:
> I'm a bit surprised that nobody mentioned that 1) we have much less
> visible bugs in our code since the QA team exists (July 2005:
> https://wiki.mozilla.org/Bugzilla:QA), and so it's much less obvious for
> people to fix bugs they don't see unless they look at the code itself.

	That's possible. Some people do get involved by first providing a bug
fix. I think that people stay around to write features, though.

>> 	Now, #2 and #3 above pretty much cover my recommendations on how we
>> should behave toward new community members: be really, abnormally,
>> really, really kind, and don't be mean.
> 
> <troll>I hope this doesn't involve sending flowers to all our
> contributors with a greeting card.</troll> More seriously, "abnormally,
> really, really" sounds excessive to me and is not something I will fall
> into.

	Well, maybe not flowers. :-) I think that it's important to be nicer
than we otherwise might think that we have to be, though. Particularly
when we're all far away from each other and can't fix things through
direct in-person conversation, it's important not to cause upsets
between developers. Also, it's important to be really encouraging and
kind to people, so that they see that this is the type of community that
they want to be involved in. After all, nobody wants to voluntarily be
involved in a community that's abusive to them in any way, even if it's
professionally abusive. On the other hand, people do like to be a part
of a group that's kind of them and where they feel like their
contributions are important, so that's the kind of community I want to
create.

> Please don't do that! reviewers@ and review-requests@ have different
> goals. And I recently unsubscribed from review-requests@ for a reason
> (after being 5 years in this mailing-list). Keep them separate, and just
> email reviewers@ to subscribe to review-requests@ if they want to. I
> don't see why you can/should/would be allowed to force them to read all
> review requests. 

	The fact is, the project started to decline when we separated them, so
I think that we should try to rejoin them for at least a few months and
see if that changes things. This is something that we can *actually do*
to try to improve the size of the community. Do you want to be the only
person doing the majority of the development and reviews for the rest of
your life?

> And if you are the requestee, you already get review requests directly
> anyway.

	Yes, but the point is to get the review requests a broader audience.
Maybe somebody requests review from you, but Gerv also feels like he
can/wants to say something about the patch, and he's able to get to it
before you. It allows all the reviewers to participate together as a
community.
	
	-Max
-- 
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.


From mkanat at bugzilla.org  Fri Feb 12 22:49:45 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Fri, 12 Feb 2010 14:49:45 -0800
Subject: Test coverage is 18.4%
In-Reply-To: <C79B1079.40079%dmarshal@yahoo-inc.com>
References: <C79B1079.40079%dmarshal@yahoo-inc.com>
Message-ID: <4B75DB09.1010905@bugzilla.org>

On 02/12/2010 02:04 PM, David Marshall wrote:
> I don't think it's a problem at all, because the t/* tests were never, as
> far as I am aware, intended to be testing for coverage.  I'm rather
> surprised that the number is as high as 18.4%!

	They probably weren't intended that way, but I'd like to see them be
more so. Test-Driven Development didn't exist as a popular philosophy
(though it should have been realized as simply a sensible thing to
do...) when the tests were originally written, so they probably just
weren't aimed in that direction.

> We also have a home-grown test suite that we use as a "smoke test" - a
> nightly test that interacts with Bugzilla through apache and a working
> database.  It takes about twenty minutes to run at present.  That's what I
> want to have 100% coverage.  Currently, we're at about 60% or so.

	Doesn't that seem like duplicated effort with our own Selenium tests? I
mean, we even had Selenium tests for 2.22, if you wanted to use those.

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


From mkanat at bugzilla.org  Fri Feb 12 22:50:54 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Fri, 12 Feb 2010 14:50:54 -0800
Subject: Test coverage is 18.4%
In-Reply-To: <36fce4891002121405ocdb7d1odf73ebc6eebb894b@mail.gmail.com>
References: <d8a74af11002112213p48e5cd5cr4269447ff2fa94f8@mail.gmail.com>	 <4B75CE13.3020705@bugzilla.org> <36fce4891002121405ocdb7d1odf73ebc6eebb894b@mail.gmail.com>
Message-ID: <4B75DB4E.30709@bugzilla.org>

On 02/12/2010 02:05 PM, Aaron Evans wrote:
> The biggest problem I've found trying to go back and fill in unit tests
> is you can either cover the obvious things that won't break unless there
> are API changes, but the type of stuff that more often breaks can't
> often be deduced from the code (not to mention you can't find existing
> bugs when the implementation is your spec.

	Yeah, true, but I think that using a coverage tool helps a lot with
that, because then at least you can be sure that all code paths are
covered. Perl's testing tools are actually really top-of-the-line stuff,
for the most part, and Devel::Cover is pretty good.

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


From mkanat at bugzilla.org  Sat Feb 13 01:35:34 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Fri, 12 Feb 2010 17:35:34 -0800
Subject: Results of Community Research
In-Reply-To: <4B75D831.8080005@bugzilla.org>
References: <mailman.2477.1263867262.4112.dev-apps-bugzilla@lists.mozilla.org> <4B55A7AF.2040803@mozilla.org> <4B75D831.8080005@bugzilla.org>
Message-ID: <4B7601E6.5080500@bugzilla.org>

On 02/12/2010 02:37 PM, Max Kanat-Alexander wrote:
>> Or perhaps look at attached patches in Bugzilla as well as
>> checkin data?
> 
> 	Yeah, actually, I think that would be definitely worthwhile, at least
> to get a sense of whether or not there was some problem with people
> attaching patches but them never getting in, if nothing else.

	Wow, so this analysis produces some very interesting data!

	I see some definite trends:

	1. From 2002-05 to 2004-01, the number of contributors decreases steadily.
	2. From 2004-01 to about 2005-12, it increases significantly and regularly.
	3. From 2006-01 to about 2007-12, it dives significantly and continuously.
	4. From 2007-12 to 2008-05 it makes a comeback.
	5. From 2008-05 to 2009-07 (which is where my data basically ends) it
stays stable, perhaps a slight rise.

	These trends are actually very similar to the checkin trends, except
that they more clearly show a very specific rise to a peak at the *end*
of 2005, whereas the previous data looked roughly level for most of 2005.

	I then did an analysis of the review flag, excluding review requests
and only checking denied and granted flags. The trends of how many
reviewers we have active at any given time correlate nearly-perfectly to
the curve of how many active contributors we have at any given time.
Also, interestingly, roughly 50% or more of all review flags set are
review+, and the percentage of r+ reviews granted in a month doesn't
correlate to the number of active contributors by any curve. I think it
doesn't matter whether we grant r+ or r-, as long as we grant it quickly
either way.

	Here's the raw data for this analysis:

	http://spreadsheets.google.com/ccc?key=0Ar05y8vgF7BhdDBlb3hJU1BKYWMySDFYdE1oOXlKTWc&hl=en

	The next thing to check would be "average review delay" -- that is, the
average amount of time in a particular month that a patch attacher has
to wait for a review, including standard deviation. That would confirm
my hypothesis from above, though there were probably other factors
involved in how many contributors we had at any given time.

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


From szabgab at gmail.com  Sat Feb 13 15:41:36 2010
From: szabgab at gmail.com (Gabor Szabo)
Date: Sat, 13 Feb 2010 17:41:36 +0200
Subject: post FOSDEM
In-Reply-To: <4B75CBDA.9080702@bugzilla.org>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>
	 <WcidnWPFppxcZe7WnZ2dnUVZ_gZi4p2d@mozilla.org>
	 <97784.55432.qm@web114014.mail.gq1.yahoo.com>
	 <d8a74af11002111422k21e6c47eqda30746a08713dc4@mail.gmail.com>
	 <4B75CBDA.9080702@bugzilla.org>
Message-ID: <d8a74af11002130741l4c67d3adj17e61a34c5b9a537@mail.gmail.com>

On Fri, Feb 12, 2010 at 11:44 PM, Max Kanat-Alexander
<mkanat at bugzilla.org> wrote:
> On 02/11/2010 02:22 PM, Gabor Szabo wrote:
>> Maybe it is just me and no one of the other use.perl.org readers think
>> the same but I am still not sure if the Bugzilla team likes the fact
>> that it is written in Perl or that you hate every inch of it?
>
> ? ? ? ?I think that we talked about this in one of our Bugzilla Meetings, and
> basically, Bugzilla is written in Perl, and it's written in Perl no
> matter whether each of us loves it or hates it.

If you mean the one that I was also involved then yes I remember a statement
similar to this one.

> ? ? ? ?It's a programming language, a tool to and end. I don't think it's an
> emotional issue, it's just a technical fact that Bugzilla is in Perl.

I read this once in a while but then I see many people - maybe different ones,
maybe the same - act as if it was emotional.

Personally I think without emotions most people would not be involved in the
Perl (or any other) community.

>> Also - again IMHO - Bugzilla needs to send the message of using
>> *modern tools* in its development. (e.g. CVS ?still being the
>> recommended way to fetch the source code is NOT sending this
>> messages).
>
> ? ? ? ?The switch happened just days ago, and pretty much all the developer
> documentation is written by me, in addition to almost all the
> administrative details of the project being done by me, in addition to
> 50% or more of the development of the project being done by me, and I'm
> not getting paid for any of it. So yes, I agree that the documentation
> needs to be fixed, and it will be done soon.
>
> ? ? ? ?However, CVS is still going to be easier for some people than bzr,
> because far more people are familiar with CVS. So we'll keep around some
> CVS instructions as well.

Err, I think there was a miscommunication on my part.
I was trying the stress that fact that the move to Bazar is a very
positive step.

Maybe technically it would be easier for many people to use CVS than to
learn the few basic commands Bazar needs to get started but I think the
emotions will quickly kick in. (Even with SVN I keep getting comments that
people are not involved in Padre because they want to use Git)


>> the local::lib/PERL5LIB stuff I am trying to patch,
>
> ? ? ? ?You're actually the first person ever to mention a problem with it, I
> believe. :-) Otherwise we would have fixed it earlier.

Someone has to be the first one for every issue :-)

>> not using Makefile.PL or Build.PL,
>> not using "standard" CPAN layout:
>
> ? ? ? ?Mmm, I tend to think that, at the moment, installation would actually
> become more difficult than it is now,

We could try to build a CPAN distro but explicitly turning off the
"install" target and telling people the installation is still the same
as earlier. That one could be uploaded do CPAN as a developer release
and then we could work out the specific issues with frequent new
developer releases to CPAN that mostly will try to address the
packaging and installation issues.

regards
   Gabor


From mkanat at bugzilla.org  Sat Feb 13 18:38:08 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Sat, 13 Feb 2010 10:38:08 -0800
Subject: post FOSDEM
In-Reply-To: <d8a74af11002130741l4c67d3adj17e61a34c5b9a537@mail.gmail.com>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>	 <WcidnWPFppxcZe7WnZ2dnUVZ_gZi4p2d@mozilla.org>	 <97784.55432.qm@web114014.mail.gq1.yahoo.com>	 <d8a74af11002111422k21e6c47eqda30746a08713dc4@mail.gmail.com>	 <4B75CBDA.9080702@bugzilla.org> <d8a74af11002130741l4c67d3adj17e61a34c5b9a537@mail.gmail.com>
Message-ID: <4B76F190.5000206@bugzilla.org>

On 02/13/2010 07:41 AM, Gabor Szabo wrote:
>>        It's a programming language, a tool to and end. I don't think it's an
>> emotional issue, it's just a technical fact that Bugzilla is in Perl.
> 
> I read this once in a while but then I see many people - maybe different ones,
> maybe the same - act as if it was emotional.
> 
> Personally I think without emotions most people would not be involved in the
> Perl (or any other) community.

	Mmm, I think there are definitely a lot of people who get emotional
about it for sure. But ultimately it is a technical thing-- it's not
really like a painting or a song, where your emotional response and your
artistic sensibilities are *all* that matter, really. Still, I do
understand that people can have an emotional attachment to a programming
language. I don't, although I have spent some time with some members of
the Perl community and I like them quite a bit. :-) There's certainly an
emotional aspect to a community, so I agree with you there. :-)

> Err, I think there was a miscommunication on my part.
> I was trying the stress that fact that the move to Bazar is a very
> positive step.

	Ahh, thanks! :-)

> Maybe technically it would be easier for many people to use CVS than to
> learn the few basic commands Bazar needs to get started but I think the
> emotions will quickly kick in. (Even with SVN I keep getting comments that
> people are not involved in Padre because they want to use Git)

	Well, I think that we'll offer both for a while, so we'll see how
people respond.

> We could try to build a CPAN distro but explicitly turning off the
> "install" target and telling people the installation is still the same
> as earlier. That one could be uploaded do CPAN as a developer release
> and then we could work out the specific issues with frequent new
> developer releases to CPAN that mostly will try to address the
> packaging and installation issues.

	Yeah, but I'm worried that it would just increase our support burden,
which is something that I try to avoid. That is, there would be a lot of
people on the support list and in IRC going "I tried to install Bugzilla
and it didn't work...." and then we'd ask them what they did and they'd
say "I did 'install Bugzilla'....".

	One of the most important things to know about Bugzilla is that the
vast, vast majority of our users know nothing at all about Perl or CPAN,
so they have to always be provided installation options that are
straightforward, simple, and always work, or they run into a lot of
trouble and either decide not to use Bugzilla or decide to come to us
for support.

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


From szabgab at gmail.com  Sat Feb 13 18:55:20 2010
From: szabgab at gmail.com (Gabor Szabo)
Date: Sat, 13 Feb 2010 20:55:20 +0200
Subject: post FOSDEM
In-Reply-To: <4B76F190.5000206@bugzilla.org>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>
	 <WcidnWPFppxcZe7WnZ2dnUVZ_gZi4p2d@mozilla.org>
	 <97784.55432.qm@web114014.mail.gq1.yahoo.com>
	 <d8a74af11002111422k21e6c47eqda30746a08713dc4@mail.gmail.com>
	 <4B75CBDA.9080702@bugzilla.org>
	 <d8a74af11002130741l4c67d3adj17e61a34c5b9a537@mail.gmail.com>
	 <4B76F190.5000206@bugzilla.org>
Message-ID: <d8a74af11002131055l5beca6b3gd8505a2f8fd63efd@mail.gmail.com>

On Sat, Feb 13, 2010 at 8:38 PM, Max Kanat-Alexander
<mkanat at bugzilla.org> wrote:
> On 02/13/2010 07:41 AM, Gabor Szabo wrote:

>> Maybe technically it would be easier for many people to use CVS than to
>> learn the few basic commands Bazar needs to get started but I think the
>> emotions will quickly kick in. (Even with SVN I keep getting comments that
>> people are not involved in Padre because they want to use Git)
>
> ? ? ? ?Well, I think that we'll offer both for a while, so we'll see how
> people respond.

That's the best.

>> We could try to build a CPAN distro but explicitly turning off the
>> "install" target and telling people the installation is still the same
>> as earlier. That one could be uploaded do CPAN as a developer release
>> and then we could work out the specific issues with frequent new
>> developer releases to CPAN that mostly will try to address the
>> packaging and installation issues.
>
> ? ? ? ?Yeah, but I'm worried that it would just increase our support burden,
> which is something that I try to avoid. That is, there would be a lot of
> people on the support list and in IRC going "I tried to install Bugzilla
> and it didn't work...." and then we'd ask them what they did and they'd
> say "I did 'install Bugzilla'....".

As long as the version number on CPAN has an _ underscore in it,
the package is not included in the main index so regular people can not
install it but you can already collect the karma for uploading to CPAN.

Just make it clear in the CPAN upload and the accompanying blog entry
that it is the first experimental upload and full installation from CPAN
was not yet implemented.

> ? ? ? ?One of the most important things to know about Bugzilla is that the
> vast, vast majority of our users know nothing at all about Perl or CPAN,
> so they have to always be provided installation options that are
> straightforward, simple, and always work, or they run into a lot of
> trouble and either decide not to use Bugzilla or decide to come to us
> for support.

Then I guess most of them won't install from CPAN anyway.
Also I think we (let me include myself in this) would like to increase
the number of Perl programmers using Bugzilla as that could lead more
volunteers to code.

Anyway, I'll first try to install Bugzilla so I won't just talk in the air and
then I'll try create the appropriate files and submit as a patch.

Gabor


From szabgab at gmail.com  Sat Feb 13 19:14:35 2010
From: szabgab at gmail.com (Gabor Szabo)
Date: Sat, 13 Feb 2010 21:14:35 +0200
Subject: Test coverage is 18.4%
In-Reply-To: <4B75DB4E.30709@bugzilla.org>
References: <d8a74af11002112213p48e5cd5cr4269447ff2fa94f8@mail.gmail.com>
	 <4B75CE13.3020705@bugzilla.org>
	 <36fce4891002121405ocdb7d1odf73ebc6eebb894b@mail.gmail.com>
	 <4B75DB4E.30709@bugzilla.org>
Message-ID: <d8a74af11002131114q4d3ff1d4w9e48110ae001e86d@mail.gmail.com>

Personally I don't think adding strictly speaking unit tests to already
existing code makes a lot of sense. At least not in the case of a full
blown application.

I'd rather have more Selenium tests or tests that execute the individual
.cgi scripts on the command line.
I never tried to measure coverage of Selenium tests but maybe that
can be done as well.

Then those tests can be included in the t/ directory as well and executed
on condition.

For new code I'd still write the unit tests.

Gabor
ps. In companies I would be happy with 30-40% coverage, it is usually
way lower but on CPAN modules I regularly see 70-80% see a few of
them here: http://szabgab.com/coverage/


From mkanat at bugzilla.org  Sat Feb 13 20:36:16 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Sat, 13 Feb 2010 12:36:16 -0800
Subject: post FOSDEM
In-Reply-To: <d8a74af11002131055l5beca6b3gd8505a2f8fd63efd@mail.gmail.com>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>	 <WcidnWPFppxcZe7WnZ2dnUVZ_gZi4p2d@mozilla.org>	 <97784.55432.qm@web114014.mail.gq1.yahoo.com>	 <d8a74af11002111422k21e6c47eqda30746a08713dc4@mail.gmail.com>	 <4B75CBDA.9080702@bugzilla.org>	 <d8a74af11002130741l4c67d3adj17e61a34c5b9a537@mail.gmail.com>	 <4B76F190.5000206@bugzilla.org> <d8a74af11002131055l5beca6b3gd8505a2f8fd63efd@mail.gmail.com>
Message-ID: <4B770D40.1000800@bugzilla.org>

On 02/13/2010 10:55 AM, Gabor Szabo wrote:
> As long as the version number on CPAN has an _ underscore in it,
> the package is not included in the main index so regular people can not
> install it but you can already collect the karma for uploading to CPAN.
> 
> Just make it clear in the CPAN upload and the accompanying blog entry
> that it is the first experimental upload and full installation from CPAN
> was not yet implemented.

	Okay, if you want to investigate the possibility of making Bugzilla
CPAN-installable and come up with a plan for it, then I'm open to the
possibility. I don't want to put it up on CPAN if we're eventually going
to abandon it there for unfeasability, though--I think that it would be
worse to have an abandoned package there than no package at all.

> Also I think we (let me include myself in this) would like to increase
> the number of Perl programmers using Bugzilla as that could lead more
> volunteers to code.

	Yeah, that's true for sure. :-)

> Anyway, I'll first try to install Bugzilla so I won't just talk in the air and
> then I'll try create the appropriate files and submit as a patch.

	Okay, sounds cool. :-)

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


From mkanat at bugzilla.org  Sat Feb 13 20:53:19 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Sat, 13 Feb 2010 12:53:19 -0800
Subject: Test coverage is 18.4%
In-Reply-To: <d8a74af11002131114q4d3ff1d4w9e48110ae001e86d@mail.gmail.com>
References: <d8a74af11002112213p48e5cd5cr4269447ff2fa94f8@mail.gmail.com>	 <4B75CE13.3020705@bugzilla.org>	 <36fce4891002121405ocdb7d1odf73ebc6eebb894b@mail.gmail.com>	 <4B75DB4E.30709@bugzilla.org> <d8a74af11002131114q4d3ff1d4w9e48110ae001e86d@mail.gmail.com>
Message-ID: <4B77113F.6010300@bugzilla.org>

On 02/13/2010 11:14 AM, Gabor Szabo wrote:
> Personally I don't think adding strictly speaking unit tests to already
> existing code makes a lot of sense. At least not in the case of a full
> blown application.
> 
> I'd rather have more Selenium tests or tests that execute the individual
> .cgi scripts on the command line.
> I never tried to measure coverage of Selenium tests but maybe that
> can be done as well.

	Yeah, I think it might make more sense to focus on the Selenium tests
for now, because we can guarantee that they can actually test the full
application.

	I do actually want unit tests, though. I think it's the lack of
existing unit tests that causes us to not write new ones for stuff that
we check in.

> Then those tests can be included in the t/ directory as well and executed
> on condition.

	Yeah, I was thinking that as well, although at the moment they require
basically an empty database in order to run.

> ps. In companies I would be happy with 30-40% coverage, it is usually
> way lower but on CPAN modules I regularly see 70-80% see a few of
> them here: http://szabgab.com/coverage/

	Yeah, I still like to try for 100% coverage, though. I think that my
current CPAN modules come pretty close, actually, although I just
checked one of them after this discussion and I noticed there are a few
extra code paths I need to test. :-)

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


From szabgab at gmail.com  Sun Feb 14 09:57:04 2010
From: szabgab at gmail.com (Gabor Szabo)
Date: Sun, 14 Feb 2010 11:57:04 +0200
Subject: Test coverage is 18.4%
In-Reply-To: <C79B1079.40079%dmarshal@yahoo-inc.com>
References: <4B75CE13.3020705@bugzilla.org>
	 <C79B1079.40079%dmarshal@yahoo-inc.com>
Message-ID: <d8a74af11002140157n7ddd7986q3234f605d319066@mail.gmail.com>

On Sat, Feb 13, 2010 at 12:04 AM, David Marshall <dmarshal at yahoo-inc.com> wrote:
>
>
>
> On 2/12/10 1:54 PM, "Max Kanat-Alexander" <mkanat at bugzilla.org> wrote:
>
>> On 02/11/2010 10:13 PM, Gabor Szabo wrote:
>>> and the total test coverage of Bugzilla is 18.4%
>>
>> Yeah, just to say again what others have said, this is a problem, for sure.
>>
>
> I don't think it's a problem at all, because the t/* tests were never, as
> far as I am aware, intended to be testing for coverage. ?I'm rather
> surprised that the number is as high as 18.4%!
>
> At Yahoo!, where we've been putting a lot of effort into continuous
> integration, I use t/* as a "commit test" - committing to the repository
> triggers an automatic run of t/*. ?The idea is to do a quick check that a
> commit hasn't horked anything - the Perl compiles, etc.
>
> We also have a home-grown test suite that we use as a "smoke test" - a
> nightly test that interacts with Bugzilla through apache and a working
> database. ?It takes about twenty minutes to run at present. ?That's what I
> want to have 100% coverage. ?Currently, we're at about 60% or so.
>
> We have our own Selenium tests written as well, but I haven't included them
> in our continuous integration implementation.
>

Do I understand correctly that you have your own test suite in Yahoo!
testing Bugzilla?
If so why is it not part of the standard set of test of Bugzilla?


Gabor


From dmarshal at yahoo-inc.com  Sun Feb 14 17:12:51 2010
From: dmarshal at yahoo-inc.com (David Marshall)
Date: Sun, 14 Feb 2010 09:12:51 -0800
Subject: Test coverage is 18.4%
In-Reply-To: <d8a74af11002140157n7ddd7986q3234f605d319066@mail.gmail.com>
Message-ID: <C79D6F13.401C3%dmarshal@yahoo-inc.com>




On 2/14/10 1:57 AM, "Gabor Szabo" <szabgab at gmail.com> wrote:


> 
> Do I understand correctly that you have your own test suite in Yahoo!
> testing Bugzilla?
> If so why is it not part of the standard set of test of Bugzilla?
> 

There are three reasons:

1) the non-Selenium tests use an in-house testing and reporting system
without which they're not very useful.

2) the Selenium tests are written against what is a very heavily customized
UI.

3) I don't have permission to send any changes upstream.  That's unlikely to
change anytime soon.



From szabgab at gmail.com  Sun Feb 14 18:07:57 2010
From: szabgab at gmail.com (Gabor Szabo)
Date: Sun, 14 Feb 2010 20:07:57 +0200
Subject: Test coverage is 18.4%
In-Reply-To: <C79D6F13.401C3%dmarshal@yahoo-inc.com>
References: <d8a74af11002140157n7ddd7986q3234f605d319066@mail.gmail.com>
	 <C79D6F13.401C3%dmarshal@yahoo-inc.com>
Message-ID: <d8a74af11002141007u178b40d2vb5bd60c9487087d7@mail.gmail.com>

On Sun, Feb 14, 2010 at 7:12 PM, David Marshall <dmarshal at yahoo-inc.com> wrote:

> There are three reasons:

thanks for the clarification.

Gabor


From gerv at mozilla.org  Mon Feb 15 11:22:35 2010
From: gerv at mozilla.org (Gervase Markham)
Date: Mon, 15 Feb 2010 11:22:35 +0000
Subject: Test coverage is 18.4%
In-Reply-To: <mailman.4645.1266011693.4112.dev-apps-bugzilla@lists.mozilla.org>
References: <d8a74af11002112213p48e5cd5cr4269447ff2fa94f8@mail.gmail.com>
	<mailman.4645.1266011693.4112.dev-apps-bugzilla@lists.mozilla.org>
Message-ID: <_4idnZSdMrvms-TWnZ2dnUVZ_h1i4p2d@mozilla.org>

On 12/02/10 21:54, Max Kanat-Alexander wrote:
> 	Having unit tests for every single method and function in Bugzilla
> would be great, though. The fact is, the lack of TDD in our development
> process is one of the things that makes the review process so difficult.
> But the number of tests that we'd have to write to truly have full
> coverage is also something that's nearly overwhelming for us, because we
> just don't have the current manpower to do it.

Right. Mozilla has exactly the same problem. The way you deal with it is
to make sure the test frameworks are in place, and there are good docs
on writing and running the tests, and then require tests to accompany
all new patches. Tests accidentally/implicitly test more than they are
aimed at anyway, and this way the coverage percentage will rise
organically. When it gets nearer to 90% than 20%, we can look again at
what's necessary to get 100% coverage, if we still think it's worth it.

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  Mon Feb 15 11:28:06 2010
From: gerv at mozilla.org (Gervase Markham)
Date: Mon, 15 Feb 2010 11:28:06 +0000
Subject: post FOSDEM
In-Reply-To: <mailman.4642.1266011129.4112.dev-apps-bugzilla@lists.mozilla.org>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>		<WcidnWPFppxcZe7WnZ2dnUVZ_gZi4p2d@mozilla.org>		<97784.55432.qm@web114014.mail.gq1.yahoo.com>	<d8a74af11002111422k21e6c47eqda30746a08713dc4@mail.gmail.com>
	<mailman.4642.1266011129.4112.dev-apps-bugzilla@lists.mozilla.org>
Message-ID: <_4idnZedMrtbsuTWnZ2dnUVZ_h1i4p2d@mozilla.org>

On 12/02/10 21:44, Max Kanat-Alexander wrote:
> 	However, CVS is still going to be easier for some people than bzr,
> because far more people are familiar with CVS. So we'll keep around some
> CVS instructions as well.

Is it really true that CVS will be easier for some people?

I see two constituencies:

- Users (that is, admins)
- Hackers

For users, it's just bzr co <url> <directory>, copied and pasted from
the installation web page. I can't see much advantage there. OK, if you
are in Windows, you have to install bzr - but you have to install CVS too.

For hackers, we don't allow them to commit to CVS anyway! So starting
with a CVS checkout just means you have to port your patches over later.

>> I am not sure if it should be done on http://bugzillaupdate.wordpress.com/
>> or on some other blog (maybe on http://blogs.perl.org/ ) but I am quite sure
>> the entires should appear on both http://ironman.enlightenedperl.org/ and on
>> http://perlsphere.net/ that are read by many people.
> 
> 	This is certainly something to think about, and it's cool to have
> experienced suggestions from somebody with good experience in the area.

Bugzilla Update is low enough traffic that I think we should just submit
it to both these aggregators now, without worrying.

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  Mon Feb 15 11:28:36 2010
From: gerv at mozilla.org (Gervase Markham)
Date: Mon, 15 Feb 2010 11:28:36 +0000
Subject: post FOSDEM
In-Reply-To: <mailman.4630.1266006694.4112.dev-apps-bugzilla@lists.mozilla.org>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>	<WcidnWPFppxcZe7WnZ2dnUVZ_gZi4p2d@mozilla.org>	<97784.55432.qm@web114014.mail.gq1.yahoo.com>	<mailman.4542.1265926982.4112.dev-apps-bugzilla@lists.mozilla.org>	<ArudnbvuMs7M2-jWnZ2dnUVZ_oKdnZ2d@mozilla.org>
	<mailman.4630.1266006694.4112.dev-apps-bugzilla@lists.mozilla.org>
Message-ID: <_4idnZadMrt4suTWnZ2dnUVZ_h3_fwAA@mozilla.org>

On 12/02/10 20:31, Gabor Szabo wrote:
> ps. Why do the replyes go to both
> developers at bugzilla.org and on dev-apps-bugzilla at lists.mozilla.org ?

Historical reasons.

Gerv
_______________________________________________
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  Mon Feb 15 11:37:54 2010
From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=)
Date: Mon, 15 Feb 2010 12:37:54 +0100
Subject: post FOSDEM
In-Reply-To: <_4idnZedMrtbsuTWnZ2dnUVZ_h1i4p2d@mozilla.org>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>		<WcidnWPFppxcZe7WnZ2dnUVZ_gZi4p2d@mozilla.org>		<97784.55432.qm@web114014.mail.gq1.yahoo.com>	<d8a74af11002111422k21e6c47eqda30746a08713dc4@mail.gmail.com>	<mailman.4642.1266011129.4112.dev-apps-bugzilla@lists.mozilla.org> <_4idnZedMrtbsuTWnZ2dnUVZ_h1i4p2d@mozilla.org>
Message-ID: <4B793212.3070206@gmail.com>

Le 15. 02. 10 12:28, Gervase Markham a ?crit :
> Is it really true that CVS will be easier for some people?
> 
> For users, it's just bzr co <url> <directory>, copied and pasted from
> the installation web page. I can't see much advantage there. OK, if you
> are in Windows, you have to install bzr - but you have to install CVS too.

There are some external tools or scripts which use CVS. And in the short
term, we have more urgent things to do than updating them to point to
and use bzr. So it still makes sense to keep CVS for now as a mirror,
and consequently CVS instructions.

LpSolit


From bugzilla at colinogilvie.co.uk  Mon Feb 15 11:59:44 2010
From: bugzilla at colinogilvie.co.uk (Colin Ogilvie)
Date: Mon, 15 Feb 2010 11:59:44 +0000
Subject: post FOSDEM
In-Reply-To: <4B793212.3070206@gmail.com>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>		<WcidnWPFppxcZe7WnZ2dnUVZ_gZi4p2d@mozilla.org>		<97784.55432.qm@web114014.mail.gq1.yahoo.com>	<d8a74af11002111422k21e6c47eqda30746a08713dc4@mail.gmail.com>	<mailman.4642.1266011129.4112.dev-apps-bugzilla@lists.mozilla.org> <_4idnZedMrtbsuTWnZ2dnUVZ_h1i4p2d@mozilla.org> <4B793212.3070206@gmail.com>
Message-ID: <4B793730.3020804@colinogilvie.co.uk>

On 15/02/2010 11:37, Fr?d?ric Buclin wrote:
> There are some external tools or scripts which use CVS. And in the 
> short term, we have more urgent things to do than updating them to 
> point to and use bzr. So it still makes sense to keep CVS for now as a 
> mirror, and consequently CVS instructions. 
Surely that means the solution is to then:

- Keep CVS for the scripts.
- Update instructions to use BZR.

Reasoning:
If CVS is staying as a permanent read-only access utility, then it's not 
an issue.
However, if the plan is to ditch CVS such that it's not even 
automatically updated from BZR, then the instructions should be changed 
ASAP so that people don't start using CVS read-only versions, then find 
they need to move it to BZR as that would just annoy them.

I'd also have said that updating the scripts should have been considered 
as part of the CVS -> BZR move...

Colin


From gerv at mozilla.org  Mon Feb 15 12:46:04 2010
From: gerv at mozilla.org (Gervase Markham)
Date: Mon, 15 Feb 2010 12:46:04 +0000
Subject: Bugzilla: Philosophy
In-Reply-To: <mailman.4490.1265908384.4112.dev-apps-bugzilla@lists.mozilla.org>
References: <mailman.4490.1265908384.4112.dev-apps-bugzilla@lists.mozilla.org>
Message-ID: <4B79420C.8030109@mozilla.org>

On 11/02/10 17:12, Max Kanat-Alexander wrote:
> 	I don't claim that those are the ideal principles, or what our
> principles *should* be. The page currently just reflects what our
> principles *are*.

But that leads fairly neatly onto a discussion of what they _should_ be
:-) Here are my suggestions:

https://wiki.mozilla.org/Bugzilla_Talk:Philosophy

Some are the same, but many are different. Thanks to bsmedberg for the
inspiration.

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  Mon Feb 15 13:53:52 2010
From: gerv at mozilla.org (Gervase Markham)
Date: Mon, 15 Feb 2010 13:53:52 +0000
Subject: Bug Relationships
In-Reply-To: <mailman.4001.1265392975.4112.dev-apps-bugzilla@lists.mozilla.org>
References: <ZNOdnZt5bJG4_dbWnZ2dnUVZ_o-dnZ2d@mozilla.org>	<mailman.1859.1263245390.4112.dev-apps-bugzilla@lists.mozilla.org>	<etOdnWEKCeeif83WnZ2dnUVZ_v2dnZ2d@mozilla.org>	<mailman.2246.1263592515.4112.dev-apps-bugzilla@lists.mozilla.org>	<V7SdnQq9JqsAlfHWnZ2dnUVZ_jadnZ2d@mozilla.org>	<36fce4891002050902v4515671fucf1ef20a9be3e84@mail.gmail.com>	<df4dec6f1002050926v3e68bb06w4844c269d2a6fd60@mail.gmail.com>
	<mailman.4001.1265392975.4112.dev-apps-bugzilla@lists.mozilla.org>
Message-ID: <sdKdnVppBe9tzOTWnZ2dnUVZ_vqdnZ2d@mozilla.org>

On 05/02/10 18:02, Jesse J. Clark wrote:
> - Relationship trees. Bug 539131

This doesn't seem like a requirement to me...

> - Reverse Editability. This gets into a lot of permissions issues,
> some of which we have worked out in PRACA.

You mean users of other bug trackers editing our tracker? Again, I don't
see how it's a requirement...

> - Multiplicability. Should be similar to FIELD_TYPE_MULTI_SELECT.

Same with this...

> - Migration of non-custom link fields
> - Combined relationship editing widget

I don't see why we can't do this first. We could prototype the widget
for the existing fields using JS. If we are going to support it
officially, the logic would probably need to be on the back end instead
(if we are still maintaining in 2010 that the Bugzilla UI should work
without JS).

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  Mon Feb 15 14:32:33 2010
From: gerv at mozilla.org (Gervase Markham)
Date: Mon, 15 Feb 2010 14:32:33 +0000
Subject: Fwd: REST APIs, and Tags
In-Reply-To: <mailman.4512.1265914114.4112.dev-apps-bugzilla@lists.mozilla.org>
References: <lJ-dnTp28csNE5PWnZ2dnUVZ_hmdnZ2d@mozilla.org>	<yZidndn6Ks90U-_WnZ2dnUVZ_i2dnZ2d@mozilla.org>	<mailman.4482.1265904519.4112.dev-apps-bugzilla@lists.mozilla.org>	<DLOdnbzZ_Y171unWnZ2dnUVZ_hudnZ2d@mozilla.org>
	<mailman.4512.1265914114.4112.dev-apps-bugzilla@lists.mozilla.org>
Message-ID: <XfGdnavAld2fxuTWnZ2dnUVZ_qudnZ2d@mozilla.org>

On 11/02/10 18:48, Max Kanat-Alexander wrote:
> 	Also, by the way, if you stopped presenting new users with the Bugzilla
> Helper and just used the default Simple Form in Bugzilla 3.4, I suspect
> that filing a bug would become a far less painful experience.

I agree we need to change something here... but does the simple form
encourage or help people to search for existing bugs first? If not, how
could that be incorporated?

> 	Yeah, I agree. I believe my most last suggestion in this area was that
> Mozilla should hire several full-time bug triagers.

That may or may not happen; but it shouldn't stop us looking at ways
that we can change the software to make them less necessary :-)

> 	Hmm. I do agree that there are a lot of cases where certain data just
> isn't very important, particularly Platform/OS. Translating those into
> tags might be reasonable, but I worry that then we'd shift the burden of
> setting them properly *entirely* onto developers instead of how it is
> now, where it's just *mostly* on developers (or the fields are ignored).

How would that be significantly worse? At least the responsibility is
clear in the new world.

>> This problem is basically solved by multi-state flags, except that it's
>> not just me: the accessibility team, the JS team, etc are all running
>> similar projects and would like project-specific classifications. Having
>> 30 multi-state flags down the right side of the bugzilla UI doesn't scale.
> 
> 	Hmm....

Quite :-) Here is the problem Mozilla has been struggling with for
years. We started with keywords, then moved to flags, and have now moved
to custom fields. None are ideal. What we really need is proper branch
support - although (and see my comments in that bug) there's a danger
that you are going to implement it and it won't be suitable either!

> 	A simple solution that would retain the current UI might be to only add
> one of those "multi-state flags" (which are a hack on custom fields
> that's specific to bmo) if they are somehow specifically set by the user
> (so, say, a link like "add a flag" that pops up a <select> that lets you
> choose a flag to add).

A cousin of the UI I'm suggesting for bug relationships, then? ;-)

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  Mon Feb 15 14:43:55 2010
From: gerv at mozilla.org (Gervase Markham)
Date: Mon, 15 Feb 2010 14:43:55 +0000
Subject: Fwd: REST APIs, and Tags
In-Reply-To: <mailman.4514.1265914983.4112.dev-apps-bugzilla@lists.mozilla.org>
References: <lJ-dnTp28csNE5PWnZ2dnUVZ_hmdnZ2d@mozilla.org>	<yZidndn6Ks90U-_WnZ2dnUVZ_i2dnZ2d@mozilla.org>	<mailman.4482.1265904519.4112.dev-apps-bugzilla@lists.mozilla.org>	<DLOdnbzZ_Y171unWnZ2dnUVZ_hudnZ2d@mozilla.org>
	<mailman.4514.1265914983.4112.dev-apps-bugzilla@lists.mozilla.org>
Message-ID: <8PadncL6B6wxwOTWnZ2dnUVZ_qSdnZ2d@mozilla.org>

On 11/02/10 19:01, Fr?d?ric Buclin wrote:
> IMO, an additional bug status doesn't fix anything. You move the problem
> from UNCO/NEW to NEW/READY.

Except that you can't file bugs as READY.

And there is a distinction between "yes, this is definitely a problem"
(-> NEW) and "this bug report is ready to be fixed" (-> READY).

> We don't *require* metadata, besides the component. You can ignore the
> OS/Platform fields if they are unimportant to you. Why again do you pay
> attention to them if they are meaningless for your team??

There is a cost to complexity which you pay even if you try and ignore
all the fields that you don't need.

What if, instead of having custom fields, we had hard-coded an
additional 3 of every custom field type into the default UI? When people
complained, we could have said: "why do you pay attention to them if you
aren't using them?"

>> plugins and tabs in Mozilla/Firefox. I need the ability to categorize
>> and organize bugs which are relevant to this effort.
> 
> Use the priority field. Use the target milestone field. Mark them as
> blocking some meta bug. And be sure they are in the correct component.
> What else cannot you do with that?

Because these fields can only reflect the view and the tracking of a
single person at once. (Well, perhaps multiple people can have meta bugs.)

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  Mon Feb 15 14:43:45 2010
From: gerv at mozilla.org (Gervase Markham)
Date: Mon, 15 Feb 2010 14:43:45 +0000
Subject: Fwd: REST APIs, and Tags
In-Reply-To: <FI-dnQMPXZSy9ujWnZ2dnUVZ_jqdnZ2d@mozilla.org>
References: <lJ-dnTp28csNE5PWnZ2dnUVZ_hmdnZ2d@mozilla.org>	<yZidndn6Ks90U-_WnZ2dnUVZ_i2dnZ2d@mozilla.org>	<mailman.4482.1265904519.4112.dev-apps-bugzilla@lists.mozilla.org>	<DLOdnbzZ_Y171unWnZ2dnUVZ_hudnZ2d@mozilla.org>
	<mailman.4514.1265914983.4112.dev-apps-bugzilla@lists.mozilla.org>
	<FI-dnQMPXZSy9ujWnZ2dnUVZ_jqdnZ2d@mozilla.org>
Message-ID: <8qydnd0SGtA_wOTWnZ2dnUVZ_jydnZ2d@mozilla.org>

On 12/02/10 14:52, Benjamin Smedberg wrote:
> As a module owner who tries to respond and react to incoming bug
> reports, I don't disagree that there are ways to track incoming bugs. I
> do think that it would be good to put some energy into making the triage
> process easier and more explicit for those people who are tasked with
> doing it. That may involve going back to the old way of assigning bugs
> to particular people when they are filed, instead of nobody at mozilla.org.
> Those people will probably want a way to separate out bugmail from "bugs
> which are assigned to me in order to get an initial response" and "bugs
> assigned to me because I'm actually fixing them".

I think this is what Jesse's "Getting Bugs Done" proposal was trying to
achieve - have a person responsible for each step in the process, who is
the assignee at that particular point. The trouble was that defining all
that stuff in the workflow would have been loads of work in itself.

> The hardest part by far is selecting a component in which to file the
> bug. We have this built-in tension: having lots of little components is
> good for core developers, because they can watch "specialty" components
> without getting overloaded with email. Having a few large components is
> better for almost everyone else. I'd be interested to see if we could
> figure out a way to find the best of both worlds... perhaps hierarchical
> components so that all our layout/content/javascript bugs go in a "Web
> content" category, with subcategories for layout/content/javascript and
> sub-sub-categories for "layout: tables" or "content: XMLHttpRequest" or
> "javascript: JIT"... I don't know the right answer to this problem!

When Bugzilla needed a third level of categorization, we ended up adding
one at the top (Classifications) instead of at the bottom. This had
implementation advantages, but it does exacerbate this problem.

One option might be to have a set of triage components rather than just
one per product. So you could have Firefox/Web Content (Triage),
Firefox/User Interface (Triage) and so on. The bug filing UI would
direct bugs into there, and appropriate area owners would farm them out.

> At the end of this process is it clear to the original filer what has
> happened? I think many people see the flag changes, don't see any
> substantive comments, and still feel frustrated because they don't know
> (at least in mozilla... perhaps the bugzilla project is clearer!)

We could perhaps try and change this by encouraging people to comment
when triaging. Ubuntu has various bits of comment boilerplate for this;
it seems impersonal, but perhaps it's better than nothing.

> No, it's not because we "watch" those flags: it's because we have made a
> commitment to actually setting the flag to plus or minus before release.
> I would like a way to do that for every bug... it's almost as if every
> bug starts out with a triage?initial flag,

UNCONFIRMED?

> and after it's gone through
> the process it ends up as triage-done, 

READY?

> perhaps with trips through
> triage-ready or triage-needtestcase or whatever. Which is perhaps what
> we should do! I don't know yet.

We can add more states, or we can use NEW + "testcasewanted" keyword/tag.

> And the TM field feels useless because it doesn't have any of the
> "lorentz submilestones" in it, and people don't want to have a TM field
> with 150 entries for each subproject that might want to track things.

Currently TMs are per-product as a way to try and manage this
complexity. And still, the complexity rears its head - on the main
search page, and even in the current lists for each product which are
very long.

This is where using tags would make things simpler.

Gerv

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


From benjamin at smedbergs.us  Mon Feb 15 14:55:02 2010
From: benjamin at smedbergs.us (Benjamin Smedberg)
Date: Mon, 15 Feb 2010 09:55:02 -0500
Subject: Fwd: REST APIs, and Tags
In-Reply-To: <8PadncL6B6wxwOTWnZ2dnUVZ_qSdnZ2d@mozilla.org>
References: <lJ-dnTp28csNE5PWnZ2dnUVZ_hmdnZ2d@mozilla.org>	<yZidndn6Ks90U-_WnZ2dnUVZ_i2dnZ2d@mozilla.org>	<mailman.4482.1265904519.4112.dev-apps-bugzilla@lists.mozilla.org>	<DLOdnbzZ_Y171unWnZ2dnUVZ_hudnZ2d@mozilla.org>
	<mailman.4514.1265914983.4112.dev-apps-bugzilla@lists.mozilla.org>
	<8PadncL6B6wxwOTWnZ2dnUVZ_qSdnZ2d@mozilla.org>
Message-ID: <hK2dncNCMevb_eTWnZ2dnUVZ_uZi4p2d@mozilla.org>

On 2/15/10 9:43 AM, Gervase Markham wrote:
> On 11/02/10 19:01, Fr?d?ric Buclin wrote:
>> IMO, an additional bug status doesn't fix anything. You move the problem
>> from UNCO/NEW to NEW/READY.
>
> Except that you can't file bugs as READY.
>
> And there is a distinction between "yes, this is definitely a problem"
> (->  NEW) and "this bug report is ready to be fixed" (->  READY).

This gets into b.m.o-specific workflow, but neither of those states 
represents what I'm really interested in as module owner. What I want to 
know is "have I or my peers looked at this bug, assigned it a 
priority/owner, and commented setting expectations"? There are many bugs 
which have good testcases and are "ready to be fixed" which I have not 
prioritized... in fact many of the bugs filed in the XPCOM component *come 
with patches*, and I still would like to triage them.

--BDS


_______________________________________________
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  Mon Feb 15 15:12:35 2010
From: gerv at mozilla.org (Gervase Markham)
Date: Mon, 15 Feb 2010 15:12:35 +0000
Subject: Results of Community Research
In-Reply-To: <mailman.4649.1266014288.4112.dev-apps-bugzilla@lists.mozilla.org>
References: <mailman.2477.1263867262.4112.dev-apps-bugzilla@lists.mozilla.org>	<4B55A7AF.2040803@mozilla.org>
	<mailman.4649.1266014288.4112.dev-apps-bugzilla@lists.mozilla.org>
Message-ID: <kP-dnVBSWJz5-eTWnZ2dnUVZ_rKdnZ2d@mozilla.org>

On 12/02/10 22:37, Max Kanat-Alexander wrote:
>> Did you find it was common for someone to leave the community and
>> return? 
> 
> 	I don't know, but them leaving the community at all is a problem, in
> terms of what I was looking into. I mean, I want people to be
> participating as much as they possibly can and want to.

What I meant was, if your definition of "leave" was "didn't contribute
for a month", then I'm sure I "left" and "rejoined" several times over
the last 10 years. I wanted to suggest that if you saw it was common for
people to "leave" and "rejoin", then perhaps you needed to average over
a longer time.

>> - The acceptance of a patch which provides partial, useful,
>> functionality in pursuit of a larger goal, rather than waiting for the
>> submitter to implement the entire feature as envisaged by the team (but
>> not by the submitter)
> 
> 	I used to accept things like this and I no longer do, because what
> happens is that we actually end up releasing for years with a
> half-implemented feature that causes more problems than it solves. I
> spent almost the entire 3.6 development cycle "finishing" features that
> should have been complete years ago (even ones that I wrote) and the 3.8
> cycle is going to be taken up with a tremendous amount of that as well.

There's a difference between "half-implemented" and "half-implemented" :-)

If something is half-implemented in the sense that "it half-does A",
then I can see what you mean, and you are right to object. But if it's
half-implemented in the sense that "it does A, but it would be great if
it did B too, because really B and A go together, and in an ideal world
Bugzilla would do both A and B", then IMO we should still take it. It's
normally things in the latter category that I object to. For example,
Myk's component watching patch was rejected in favour of fixing a
"generic watching" bug. Five years later, we have neither.

>> - The acceptance of a patch which provides useful functionality, even if
>> the code would eventually be obsoleted by a rewrite of the feature which
>> is wanted but un-resourced and un-scheduled
> 
> 	That's something that can be accepted, *unless* the rewrite is
> something that would actually only take a little more effort. For
> example, component-watching is actually only a little bit easier than
> everything-watching, and everything-watching might be more useful.

Great example - see above! You say it's only a little bit easier - but
five years ago we _had_ a patch for component watching, and we didn't
have one for everything-watching. The patch was turned down, and five
years later we still have neither feature.

I would politely suggest a better rule would be to ask the patch
submitter if they were interested in doing the generic feature. If they
said no, and if no-one else was working on it actively at that exact
moment, take the patch - even if you think generalising it isn't hard at
all. If it's not hard, then someone can do it as a further development :-)

>> - The documentation build system was byzantine in its complexity, and
>>   every time I got a new machine (or even when I didn't) it needed
>>   setting up.
> 
> 	That is so true. We really need to switch to xmlto, but nobody's taken
> the time to do that yet. I suspect that that will resolve this issue.

I'm afraid I don't agree. The success of things like DevMo have been
their easy editability. Manual hacking of XML-based markup is not easy,
even if its compilation becomes easier.

> 	Here's the thing about a Wiki--it requires a significant number of
> editors who pay attention to it continuously and carefully. The
> Win32Install instructions, which we have on the Wiki, became edited into
> unusefulness while LpSolit and I weren't paying attention to them. 

I presume you mean these edits?
https://wiki.mozilla.org/index.php?title=Bugzilla%3AWin32Install&diff=146397&oldid=123138
I think "edited into unusefulness" is an exaggeration.

Of course they were not as well-written as the rest of the document, but
they were clearly a record of someone's experiences doing the
installation and an attempt to make the document more useful. IMO,
reverting the lot without making any effort to see what was useful and
incorporating it was unfortunate.

And you have to set that against useful edits like these:
https://wiki.mozilla.org/index.php?title=Bugzilla%3AWin32Install&diff=174547&oldid=163572

> Right
> now we just don't have that many people that I think could effectively
> function as technical editors of the documentation if it were on a Wiki.

But what you have now is no-one _editing_ the documentation. You just
have people _changing_ it (and not many people doing that either). The
structure hasn't changed for years, and the limitations and complexities
of the authoring and build process mean there are no or few diagrams,
little useful formatting, few tables, and it's very hard to take the
overall view and say "Hmm, that belongs there, and that thing there, and
then we need to edit this bit, and this bit should be a separate page,
and..." because it's all too high-friction.

And when someone does an editing patch like that, it's really hard to
review, and so gets rejected ("come back with something smaller"). That
happened to me a few years ago :-(

Moving to a wiki is not going to be 100% improvement with no downside.
But I think we'd end up with much better, more accurate and more useful
documentation than we have now.

> 	Perhaps a trade-off would be keeping the installation instructions in
> Docbook, and putting everything else into the Wiki. 

I think the installation instructions would benefit just as much, if not
more, from being in a wiki.

> But then how would
> we do localization? 

According to http://www.bugzilla.org/docs/, we haven't had localized
documentation since 2.18. Regardless, we could have a parallel set of
wiki pages just as easily as we could have a parallel set of XML files.

> Would we still be able to ship documentation with
> Bugzilla? (Is that even important?)

I don't myself think it's particularly important, but I've never had to
install Bugzilla in a location where I couldn't access the Internet.
Even machines which are isolated from the net can often be installed by
ssh-ing in from another machine which does have access, or another
machine which can sit next to a laptop which does have access, on which
you can read the docs.

But I'm sure we could ship docs anyway. There's a MediaWiki2HTML Perl
module:
http://www.gerv.net/cgi-bin/mediawiki2html

>> Have you read "The Art of Community" by Jono Bacon, recently published?
>> It's fantastic on this sort of thing - well worth a read. I read it
>> recently, cover to cover.
> 
> 	No, I haven't. Do you think it's worth reading the whole book, or do
> you think a Cliff's Notes version would help? :-)

I'd rather you read the book, because then you can hear it all from
someone other than me! ;-)

>> Definitely. On the main Mozilla side, I've been trying for years to get
>> a system in place which tracks this across the project and nags the
>> appropriate people. The trick, in that case, is defining "appropriate
>> people".
> 
> 	I could imagine a workable system here, I think. Something like, "After
> X days, remind the requestee" and then if no response, "After Y days,
> remind the module owner" and then if no response, "After Z days, remind
> Somebody Important." Perhaps Somebody Important could be a Community
> Manager for Mozilla, or something.

The trick is mapping "I have a bug in product Foo and component Bar"
into "therefore the responsible module owner is Fred Bloggs".
https://spreadsheets.google.com/ccc?key=0AjgkRw6P9EKGcGNSLWhGaXI5eDBQbi1UeFYzajJaYmc&hl=en_GB
is our attempt thusfar.

>> Also, bad coders might make great support people, or documenters (if
>> your documentation system isn't the functional and process equivalent of
>> writing code ;-).
> 
> 	Yeah...I don't think I've ever seen a really poor coder write good
> documentation or provide good support, though.

Lots of people who can't code provide good support. I'm sure various
admins in our newsgroups who help people have fairly rusty Perl skills.
And certainly the Firefox support community can't code. And a good
friend of mine was a mediocre coder, but a kick-ass QA person (although
he eventually went to theological college and is training to be an Old
Testament lecturer).

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  Mon Feb 15 15:14:09 2010
From: gerv at mozilla.org (Gervase Markham)
Date: Mon, 15 Feb 2010 15:14:09 +0000
Subject: post FOSDEM
In-Reply-To: <mailman.4777.1266234028.4112.dev-apps-bugzilla@lists.mozilla.org>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>		<WcidnWPFppxcZe7WnZ2dnUVZ_gZi4p2d@mozilla.org>		<97784.55432.qm@web114014.mail.gq1.yahoo.com>	<d8a74af11002111422k21e6c47eqda30746a08713dc4@mail.gmail.com>	<mailman.4642.1266011129.4112.dev-apps-bugzilla@lists.mozilla.org>	<_4idnZedMrtbsuTWnZ2dnUVZ_h1i4p2d@mozilla.org>
	<mailman.4777.1266234028.4112.dev-apps-bugzilla@lists.mozilla.org>
Message-ID: <kP-dnVNSWJxf-eTWnZ2dnUVZ_rJi4p2d@mozilla.org>

On 15/02/10 11:37, Fr?d?ric Buclin wrote:
> There are some external tools or scripts which use CVS. And in the short
> term, we have more urgent things to do than updating them to point to
> and use bzr. So it still makes sense to keep CVS for now as a mirror,
> and consequently CVS instructions.

How does that "consequently" follow? If we need a CVS mirror for our own
purposes, sure. But why do we need to make people wanting to use
Bugzilla use CVS?

Gerv
_______________________________________________
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  Mon Feb 15 15:19:27 2010
From: bugreport at peshkin.net (Joel Peshkin)
Date: Mon, 15 Feb 2010 07:19:27 -0800
Subject: Test coverage is 18.4%
In-Reply-To: <_4idnZSdMrvms-TWnZ2dnUVZ_h1i4p2d@mozilla.org>
References: <d8a74af11002112213p48e5cd5cr4269447ff2fa94f8@mail.gmail.com>	<mailman.4645.1266011693.4112.dev-apps-bugzilla@lists.mozilla.org> <_4idnZSdMrvms-TWnZ2dnUVZ_h1i4p2d@mozilla.org>
Message-ID: <4B7965FF.6030803@peshkin.net>


The 18.4% number seems to refer to the t/ tests.   I think, if we are 
serious about this, we need to start by creating a mechanism in the t/ 
tests to have it use a test database.  So, you do the following...

perl Makefile.PL --db_server=localhost --db=bztest --db_user=foo 
--db_passwd=bar
make test

and the tests create their own databases, preloading them with data, and 
run.

Naturally, this also means that we need to figure out how to do the 
equivalent of the selenium tests in a way that won't break all of the 
tests every time a trivial change is made in a template.

-Joel



From gerv at mozilla.org  Mon Feb 15 15:29:42 2010
From: gerv at mozilla.org (Gervase Markham)
Date: Mon, 15 Feb 2010 15:29:42 +0000
Subject: Fwd: REST APIs, and Tags
In-Reply-To: <mailman.4638.1266009774.4112.dev-apps-bugzilla@lists.mozilla.org>
References: <lJ-dnTp28csNE5PWnZ2dnUVZ_hmdnZ2d@mozilla.org>	<yZidndn6Ks90U-_WnZ2dnUVZ_i2dnZ2d@mozilla.org>	<mailman.4377.1265818185.4112.dev-apps-bugzilla@lists.mozilla.org>	<dbudnelwoblUQO_WnZ2dnUVZ_tudnZ2d@mozilla.org>	<mailman.4471.1265895203.4112.dev-apps-bugzilla@lists.mozilla.org>	<I96dneAU6tHF1ejWnZ2dnUVZ_qSdnZ2d@mozilla.org>
	<mailman.4638.1266009774.4112.dev-apps-bugzilla@lists.mozilla.org>
Message-ID: <DoadnWV4sbX69eTWnZ2dnUVZ_o2dnZ2d@mozilla.org>

On 12/02/10 21:22, Max Kanat-Alexander wrote:
> On 02/12/2010 04:23 AM, Gervase Markham wrote:
> 	* Tags are good.
> 	* Having global tags, private tags, one fixed list of tags, and totally
> unfixed list of tags all together is too complicated.

I think you are sort of right - but who is proposing that anyway?

The design of a basic tagging system is now fairly well established by
other web applications. There are a few variables (space-separated or
comma-separated?) but it's mostly there.

- Tags are unstructured, in that you can define new ones at will;

- Tags are structured by convention, e.g. you can establish that a
hyphen or a colon is your convention to separate key-value pairs;

- Tags are stored as integers, with a lookup table for their names, so
searching is fast;

- You provide fast tagging autocomplete to reduce the risk of typos.

The "global vs. private" distinction is not two separate "lists" of
possible tags, because there is no list of possible tags. All that
happens is that the tag is associated with a particular user ID rather
than NULL in the database, and it's only displayed to that user, or if
someone explicitly asks for all tags on an item.

> So we need a
> solution that starts off with some specific problem statement (like
> bsmedberg's, which was great) and demonstrates why a much simpler
> implementation than this is an excellent solution for both broad
> distributed teams like Mozilla, and in-house corporate shops (who are
> the majority of consumers of Bugzilla).

Why do you think the requirements for a tagging system might divide
along that particular division?

Here's some specific problem statements:

PROBLEM STATEMENT C:

I am unable to easily define or label an arbitrary set of bugs without
having to either a) spam all the CC list of the bug (whiteboard), or
trying to construct a query which will return the exact list (existing
tagging), or adding them one by one (existing tagging). The number of
uses for this ability are many and varied.

I would like to retain the ability that I would have, were I to use the
whiteboard solution, of sending someone else a link to a buglist of all
the bugs.

Gerv
_______________________________________________
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  Mon Feb 15 18:51:03 2010
From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=)
Date: Mon, 15 Feb 2010 19:51:03 +0100
Subject: post FOSDEM
In-Reply-To: <kP-dnVNSWJxf-eTWnZ2dnUVZ_rJi4p2d@mozilla.org>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>		<WcidnWPFppxcZe7WnZ2dnUVZ_gZi4p2d@mozilla.org>		<97784.55432.qm@web114014.mail.gq1.yahoo.com>	<d8a74af11002111422k21e6c47eqda30746a08713dc4@mail.gmail.com>	<mailman.4642.1266011129.4112.dev-apps-bugzilla@lists.mozilla.org>	<_4idnZedMrtbsuTWnZ2dnUVZ_h1i4p2d@mozilla.org>	<mailman.4777.1266234028.4112.dev-apps-bugzilla@lists.mozilla.org> <kP-dnVNSWJxf-eTWnZ2dnUVZ_rJi4p2d@mozilla.org>
Message-ID: <4B799797.3020104@gmail.com>

Le 15. 02. 10 16:14, Gervase Markham a ?crit :
> How does that "consequently" follow? If we need a CVS mirror for our own
> purposes, sure. But why do we need to make people wanting to use
> Bugzilla use CVS?

People already using CVS to update their installation are external to
the core team. I have some scripts myself which also use CVS, and from
time to time I need to refresh my memory when I need to do something
manually. And I don't have the time currently to play with my scripts
and installations to make them work with bzr.

LpSolit


From lpsolit at gmail.com  Mon Feb 15 19:02:36 2010
From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=)
Date: Mon, 15 Feb 2010 20:02:36 +0100
Subject: Fwd: REST APIs, and Tags
In-Reply-To: <8PadncL6B6wxwOTWnZ2dnUVZ_qSdnZ2d@mozilla.org>
References: <lJ-dnTp28csNE5PWnZ2dnUVZ_hmdnZ2d@mozilla.org>	<yZidndn6Ks90U-_WnZ2dnUVZ_i2dnZ2d@mozilla.org>	<mailman.4482.1265904519.4112.dev-apps-bugzilla@lists.mozilla.org>	<DLOdnbzZ_Y171unWnZ2dnUVZ_hudnZ2d@mozilla.org>	<mailman.4514.1265914983.4112.dev-apps-bugzilla@lists.mozilla.org> <8PadncL6B6wxwOTWnZ2dnUVZ_qSdnZ2d@mozilla.org>
Message-ID: <4B799A4C.7090400@gmail.com>

Le 15. 02. 10 15:43, Gervase Markham a ?crit :
> What if, instead of having custom fields, we had hard-coded an
> additional 3 of every custom field type into the default UI? When people
> complained, we could have said: "why do you pay attention to them if you
> aren't using them?"

You like to be out-of-topic. This doesn't even worth a reply from me.

LpSolit


From mkanat at bugzilla.org  Mon Feb 15 22:14:13 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Mon, 15 Feb 2010 14:14:13 -0800
Subject: post FOSDEM
In-Reply-To: <_4idnZedMrtbsuTWnZ2dnUVZ_h1i4p2d@mozilla.org>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>		<WcidnWPFppxcZe7WnZ2dnUVZ_gZi4p2d@mozilla.org>		<97784.55432.qm@web114014.mail.gq1.yahoo.com>	<d8a74af11002111422k21e6c47eqda30746a08713dc4@mail.gmail.com>	<mailman.4642.1266011129.4112.dev-apps-bugzilla@lists.mozilla.org> <_4idnZedMrtbsuTWnZ2dnUVZ_h1i4p2d@mozilla.org>
Message-ID: <4B79C735.40103@bugzilla.org>

On 02/15/2010 03:28 AM, Gervase Markham wrote:
> Is it really true that CVS will be easier for some people?

	Yes, people on old distros who can't install a new-enough version of
bzr, or where they don't have a distro package for bzr.

> Bugzilla Update is low enough traffic that I think we should just submit
> it to both these aggregators now, without worrying.

	Sure, that sounds reasonable. Do you want to do that, or should I?

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


From mkanat at bugzilla.org  Mon Feb 15 22:14:55 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Mon, 15 Feb 2010 14:14:55 -0800
Subject: post FOSDEM
In-Reply-To: <4B793730.3020804@colinogilvie.co.uk>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>		<WcidnWPFppxcZe7WnZ2dnUVZ_gZi4p2d@mozilla.org>		<97784.55432.qm@web114014.mail.gq1.yahoo.com>	<d8a74af11002111422k21e6c47eqda30746a08713dc4@mail.gmail.com>	<mailman.4642.1266011129.4112.dev-apps-bugzilla@lists.mozilla.org> <_4idnZedMrtbsuTWnZ2dnUVZ_h1i4p2d@mozilla.org> <4B793212.3070206@gmail.com> <4B793730.3020804@colinogilvie.co.uk>
Message-ID: <4B79C75F.7060907@bugzilla.org>

On 02/15/2010 03:59 AM, Colin Ogilvie wrote:
> On 15/02/2010 11:37, Fr?d?ric Buclin wrote:
>> There are some external tools or scripts which use CVS. And in the
>> short term, we have more urgent things to do than updating them to
>> point to and use bzr. So it still makes sense to keep CVS for now as a
>> mirror, and consequently CVS instructions. 
> Surely that means the solution is to then:
> 
> - Keep CVS for the scripts.
> - Update instructions to use BZR.

	That's essentially what's going to happen, yes. Remember, it's only
been about a week since we switched. :-)

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


From mkanat at bugzilla.org  Mon Feb 15 22:16:17 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Mon, 15 Feb 2010 14:16:17 -0800
Subject: post FOSDEM
In-Reply-To: <kP-dnVNSWJxf-eTWnZ2dnUVZ_rJi4p2d@mozilla.org>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>		<WcidnWPFppxcZe7WnZ2dnUVZ_gZi4p2d@mozilla.org>		<97784.55432.qm@web114014.mail.gq1.yahoo.com>	<d8a74af11002111422k21e6c47eqda30746a08713dc4@mail.gmail.com>	<mailman.4642.1266011129.4112.dev-apps-bugzilla@lists.mozilla.org>	<_4idnZedMrtbsuTWnZ2dnUVZ_h1i4p2d@mozilla.org>	<mailman.4777.1266234028.4112.dev-apps-bugzilla@lists.mozilla.org> <kP-dnVNSWJxf-eTWnZ2dnUVZ_rJi4p2d@mozilla.org>
Message-ID: <4B79C7B1.2010609@bugzilla.org>

On 02/15/2010 07:14 AM, Gervase Markham wrote:
> If we need a CVS mirror for our own
> purposes, sure. But why do we need to make people wanting to use
> Bugzilla use CVS?

	All the the tarballs that we ship are primed for CVS, and my current
plan is that stable branches will continue that way until they EOL, so
there are some places where we will need to keep around CVS
instructions--probably just in the docs and on the Download page.

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


From mkanat at bugzilla.org  Mon Feb 15 22:21:09 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Mon, 15 Feb 2010 14:21:09 -0800
Subject: Fwd: REST APIs, and Tags
In-Reply-To: <XfGdnavAld2fxuTWnZ2dnUVZ_qudnZ2d@mozilla.org>
References: <lJ-dnTp28csNE5PWnZ2dnUVZ_hmdnZ2d@mozilla.org>	<yZidndn6Ks90U-_WnZ2dnUVZ_i2dnZ2d@mozilla.org>	<mailman.4482.1265904519.4112.dev-apps-bugzilla@lists.mozilla.org>	<DLOdnbzZ_Y171unWnZ2dnUVZ_hudnZ2d@mozilla.org>	<mailman.4512.1265914114.4112.dev-apps-bugzilla@lists.mozilla.org> <XfGdnavAld2fxuTWnZ2dnUVZ_qudnZ2d@mozilla.org>
Message-ID: <4B79C8D5.1000707@bugzilla.org>

On 02/15/2010 06:32 AM, Gervase Markham wrote:
> I agree we need to change something here... but does the simple form
> encourage or help people to search for existing bugs first? If not, how
> could that be incorporated?

	Yeah, I was thinking about that this morning, actually. I think that
you could display a few extra items (maybe even using template hooks) on
bmo for users who don't have editbugs.

>> 	Yeah, I agree. I believe my most last suggestion in this area was that
>> Mozilla should hire several full-time bug triagers.
> 
> That may or may not happen; but it shouldn't stop us looking at ways
> that we can change the software to make them less necessary :-)

	You know, having discussed this problem for years and years now with
the Mozilla team, I think that ultimately the problem is a human problem
that can't totally be solved with a tool. So I think that in the end,
it's going to be having more humans do the right thing that solves the
problem that Mozilla is experiencing, because for the most part, the
tool is capable of doing *most* of what's necessary to solve the problem
already, and it's just not being done because there is a lack of
manpower (or organization, re: components?) to do it.

>> 	Hmm. I do agree that there are a lot of cases where certain data just
>> isn't very important, particularly Platform/OS. Translating those into
>> tags might be reasonable, but I worry that then we'd shift the burden of
>> setting them properly *entirely* onto developers instead of how it is
>> now, where it's just *mostly* on developers (or the fields are ignored).
> 
> How would that be significantly worse? At least the responsibility is
> clear in the new world.

	When you have hundreds of thousands of bugs, having 10% of the work
done for you is far better than having 0% of the work done for you.

> Quite :-) Here is the problem Mozilla has been struggling with for
> years. We started with keywords, then moved to flags, and have now moved
> to custom fields. None are ideal. What we really need is proper branch
> support - although (and see my comments in that bug) there's a danger
> that you are going to implement it and it won't be suitable either!

	I suspect that it will be suitable. I've actually had the exact same
feature proposed by two separate clients as necessary to solve their
problem, and I've seen the UI mockups and it will work.

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


From mkanat at bugzilla.org  Mon Feb 15 22:22:43 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Mon, 15 Feb 2010 14:22:43 -0800
Subject: Fwd: REST APIs, and Tags
In-Reply-To: <hK2dncNCMevb_eTWnZ2dnUVZ_uZi4p2d@mozilla.org>
References: <lJ-dnTp28csNE5PWnZ2dnUVZ_hmdnZ2d@mozilla.org>	<yZidndn6Ks90U-_WnZ2dnUVZ_i2dnZ2d@mozilla.org>	<mailman.4482.1265904519.4112.dev-apps-bugzilla@lists.mozilla.org>	<DLOdnbzZ_Y171unWnZ2dnUVZ_hudnZ2d@mozilla.org>	<mailman.4514.1265914983.4112.dev-apps-bugzilla@lists.mozilla.org>	<8PadncL6B6wxwOTWnZ2dnUVZ_qSdnZ2d@mozilla.org> <hK2dncNCMevb_eTWnZ2dnUVZ_uZi4p2d@mozilla.org>
Message-ID: <4B79C933.9000302@bugzilla.org>

On 02/15/2010 06:55 AM, Benjamin Smedberg wrote:
> This gets into b.m.o-specific workflow, but neither of those states
> represents what I'm really interested in as module owner. What I want to
> know is "have I or my peers looked at this bug, assigned it a
> priority/owner, and commented setting expectations"? There are many bugs
> which have good testcases and are "ready to be fixed" which I have not
> prioritized... in fact many of the bugs filed in the XPCOM component
> *come with patches*, and I still would like to triage them.

	Hmm, okay. But that could be done now with keywords, right? If the
keywords aren't being set, isn't that mostly just because of a lack of
manpower?

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


From mkanat at bugzilla.org  Mon Feb 15 22:33:39 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Mon, 15 Feb 2010 14:33:39 -0800
Subject: Results of Community Research
In-Reply-To: <kP-dnVBSWJz5-eTWnZ2dnUVZ_rKdnZ2d@mozilla.org>
References: <mailman.2477.1263867262.4112.dev-apps-bugzilla@lists.mozilla.org>	<4B55A7AF.2040803@mozilla.org>	<mailman.4649.1266014288.4112.dev-apps-bugzilla@lists.mozilla.org> <kP-dnVBSWJz5-eTWnZ2dnUVZ_rKdnZ2d@mozilla.org>
Message-ID: <4B79CBC3.5060602@bugzilla.org>

On 02/15/2010 07:12 AM, Gervase Markham wrote:
> What I meant was, if your definition of "leave" was "didn't contribute
> for a month", then I'm sure I "left" and "rejoined" several times over
> the last 10 years. I wanted to suggest that if you saw it was common for
> people to "leave" and "rejoin", then perhaps you needed to average over
> a longer time.

	Oh, if it's just a month-to-month issue, then that didn't really
matter, because I was looking at trends over several months (I think 5
at the fewest) instead of looking at the month-to-month relationship.

> There's a difference between "half-implemented" and "half-implemented" :-)
> 
> If something is half-implemented in the sense that "it half-does A",
> then I can see what you mean, and you are right to object. But if it's
> half-implemented in the sense that "it does A, but it would be great if
> it did B too, because really B and A go together, and in an ideal world
> Bugzilla would do both A and B", then IMO we should still take it.

	Yeah, I usually do take patches like that.

> It's
> normally things in the latter category that I object to. For example,
> Myk's component watching patch was rejected in favour of fixing a
> "generic watching" bug. Five years later, we have neither.

	Yeah, and I would accept a component-watching thing that was based on a
generic-watching thing, now. In fact, that might even be the next patch
I write.

> I would politely suggest a better rule would be to ask the patch
> submitter if they were interested in doing the generic feature. If they
> said no, and if no-one else was working on it actively at that exact
> moment, take the patch - even if you think generalising it isn't hard at
> all. If it's not hard, then someone can do it as a further development :-)

	That sounds like a reasonable suggestion that I can keep in mind in
similar situations.

>> 	Perhaps a trade-off would be keeping the installation instructions in
>> Docbook, and putting everything else into the Wiki. 
> 
> I think the installation instructions would benefit just as much, if not
> more, from being in a wiki.

	Hmmm, well, at the moment I disagree. Perhaps an errata for the
installation or a FAQ about installation would do well in the Wiki though.

> According to http://www.bugzilla.org/docs/, we haven't had localized
> documentation since 2.18. Regardless, we could have a parallel set of
> wiki pages just as easily as we could have a parallel set of XML files.

	Yeah, that's reasonable.

	Actually, I think I'm more concerned about providing documentation for
separate versions, which we *do* do, and is still important, because
things really do change across versions. I don't currently know a simple
way to keep several different versions of the documentation in sync on a
Wiki in the way that we can do with patches and branches.

> I don't myself think it's particularly important, but I've never had to
> install Bugzilla in a location where I couldn't access the Internet.
> Even machines which are isolated from the net can often be installed by
> ssh-ing in from another machine which does have access, or another
> machine which can sit next to a laptop which does have access, on which
> you can read the docs.
> 
> But I'm sure we could ship docs anyway. There's a MediaWiki2HTML Perl
> module:
> http://www.gerv.net/cgi-bin/mediawiki2html

	Yeah, that seems reasonable. I don't think it's that important either.

> The trick is mapping "I have a bug in product Foo and component Bar"
> into "therefore the responsible module owner is Fred Bloggs".
> https://spreadsheets.google.com/ccc?key=0AjgkRw6P9EKGcGNSLWhGaXI5eDBQbi1UeFYzajJaYmc&hl=en_GB
> is our attempt thusfar.

	Yeah, maybe a Bugzilla Extension that added a "manager" or something to
a Component would help keep track of it a bit better.

>>> Also, bad coders might make great support people, or documenters (if
>>> your documentation system isn't the functional and process equivalent of
>>> writing code ;-).
>>
>> 	Yeah...I don't think I've ever seen a really poor coder write good
>> documentation or provide good support, though.
> 
> Lots of people who can't code provide good support.

	No, that's true for sure. I've just never met somebody who *started* as
a coder, and was bad, and then went on to be a good support technician.

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


From lpsolit at gmail.com  Mon Feb 15 22:41:58 2010
From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=)
Date: Mon, 15 Feb 2010 23:41:58 +0100
Subject: Results of Community Research
In-Reply-To: <kP-dnVBSWJz5-eTWnZ2dnUVZ_rKdnZ2d@mozilla.org>
References: <mailman.2477.1263867262.4112.dev-apps-bugzilla@lists.mozilla.org>	<4B55A7AF.2040803@mozilla.org>	<mailman.4649.1266014288.4112.dev-apps-bugzilla@lists.mozilla.org> <kP-dnVBSWJz5-eTWnZ2dnUVZ_rKdnZ2d@mozilla.org>
Message-ID: <4B79CDB6.3040501@gmail.com>

Le 15. 02. 10 16:12, Gervase Markham a ?crit :
> According to http://www.bugzilla.org/docs/, we haven't had localized
> documentation since 2.18.

We have french documentation since 3.0:

http://www.frenchmozilla.fr/bugzilla/

LpSolit


From mkanat at bugzilla.org  Mon Feb 15 23:26:19 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Mon, 15 Feb 2010 15:26:19 -0800
Subject: Voting is now an Extension, looking for a maintainer
Message-ID: <4B79D81B.6010809@bugzilla.org>

	So recently, I was looking over the highest-voted items in the Bugzilla
product, and several of the top items were related to the voting system.
Also, one of the "3.6 focus" items was "move voting into an extension".

	So, on trunk, I have now moved voting into an extension called Voting.
For at least the next few releases of Bugzilla, this extension will ship
with Bugzilla. However, it is now an entirely-self-contained piece of
code that should be easier to hack on for anybody who wants to enhance
or work on it. Eventually, I'd like to separate it from Bugzilla and
find a maintainer who really cares about the voting system and wants to
maintain it themselves. If anybody wants to step up to start working on
it now and addressing some of the requests that remain filed on
bugzilla.mozilla.org about voting, then I'd be happy to help them get up
to speed with the extension and how it works.

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


From dmarshal at yahoo-inc.com  Tue Feb 16 06:16:24 2010
From: dmarshal at yahoo-inc.com (David Marshall)
Date: Mon, 15 Feb 2010 22:16:24 -0800
Subject: Test coverage is 18.4%
In-Reply-To: <4B7965FF.6030803@peshkin.net>
Message-ID: <C79F7838.402BF%dmarshal@yahoo-inc.com>




On 2/15/10 7:19 AM, "Joel Peshkin" <bugreport at peshkin.net> wrote:

> 
> The 18.4% number seems to refer to the t/ tests.   I think, if we are
> serious about this, we need to start by creating a mechanism in the t/
> tests to have it use a test database.  So, you do the following...

I don't agree that a low coverage number from what has always been static
tests means that interest in testing is not serious.
> 
> perl Makefile.PL --db_server=localhost --db=bztest --db_user=foo
> --db_passwd=bar
> make test
> 
> and the tests create their own databases, preloading them with data, and
> run.
> 

I'd personally rather such tests existed in some separate directories from
the static tests.  But I agree that it would be useful to have dynamic
testing against a database.

I've wrestled with this at Yahoo!.  We do a lot of testing with a
LWP::UserAgent and a test database.  It wouldn't really be convenient to
start each test with the same database starting position.  I think sometimes
about creating a minimal database that I can initialize to a know state, run
the tests, and then look at how it has changed, but that may be overkill.
As it is now, for something like creating a new bug, we fill in the form,
submit it to get the new bug number, then go look around the database to
check that the attributes of the new bug are correct.


> Naturally, this also means that we need to figure out how to do the
> equivalent of the selenium tests in a way that won't break all of the
> tests every time a trivial change is made in a template.
> 

If the a change to a template is trivial, shouldn't the corresponding change
to the Selenium tests be equally non-trivial?  If modifying the tests to
reflect the change is non-trivial, how can the change itself be trivial?



From jmdesp at alussinan.org  Tue Feb 16 17:43:39 2010
From: jmdesp at alussinan.org (Jean-Marc Desperrier)
Date: Tue, 16 Feb 2010 18:43:39 +0100
Subject: post FOSDEM
In-Reply-To: <mailman.4630.1266006694.4112.dev-apps-bugzilla@lists.mozilla.org>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>	<WcidnWPFppxcZe7WnZ2dnUVZ_gZi4p2d@mozilla.org>	<97784.55432.qm@web114014.mail.gq1.yahoo.com>	<mailman.4542.1265926982.4112.dev-apps-bugzilla@lists.mozilla.org>	<ArudnbvuMs7M2-jWnZ2dnUVZ_oKdnZ2d@mozilla.org>
	<mailman.4630.1266006694.4112.dev-apps-bugzilla@lists.mozilla.org>
Message-ID: <1sydnVG4rMrQROfWnZ2dnUVZ_jFi4p2d@mozilla.org>

Gabor Szabo wrote:
> With some more work the installation of Bugzilla might be changed so that in
> addition to the current way it will also work using
>
> cpan>  install Bugzilla

Bugzilla has a Himalaya of bad karma about not being easy to install.
And developers who don't *really* care about that.

At my company, that's one of the reason we're not using it. Not the only 
reason, there's also the fact it had from start the image of being ugly 
looking and complex (and based on perl I have to say, but if all the 
rest had been right ...) , but when the person in charge of having a go 
at all the tools tried to install it, failed, spent more time trying, 
failed again, then ended the report with "I couldn't install it", when 
he had had success installing most of the other tools in minutes, it was 
the final nail in the coffin.
_______________________________________________
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 Feb 16 18:21:14 2010
From: bugreport at peshkin.net (Joel Peshkin)
Date: Tue, 16 Feb 2010 10:21:14 -0800
Subject: post FOSDEM
In-Reply-To: <1sydnVG4rMrQROfWnZ2dnUVZ_jFi4p2d@mozilla.org>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>	<WcidnWPFppxcZe7WnZ2dnUVZ_gZi4p2d@mozilla.org>	<97784.55432.qm@web114014.mail.gq1.yahoo.com>	<mailman.4542.1265926982.4112.dev-apps-bugzilla@lists.mozilla.org>	<ArudnbvuMs7M2-jWnZ2dnUVZ_oKdnZ2d@mozilla.org>	<mailman.4630.1266006694.4112.dev-apps-bugzilla@lists.mozilla.org> <1sydnVG4rMrQROfWnZ2dnUVZ_jFi4p2d@mozilla.org>
Message-ID: <4B7AE21A.6010306@peshkin.net>

Jean-Marc Desperrier wrote:
> <snip>
>
> At my company, that's one of the reason we're not using it. Not the 
> only reason, there's also the fact it had from start the image of 
> being ugly looking and complex (and based on perl I have to say, but 
> if all the rest had been right ...) , but when the person in charge of 
> having a go at all the tools tried to install it, failed, spent more 
> time trying, failed again, then ended the report with "I couldn't 
> install it", when he had had success installing most of the other 
> tools in minutes, it was the final nail in the coffin.
> _______________________________________________

Jean-Marc,

   I hear this a lot and it baffles me.    Could you be more specific 
about where he failed?  Did he have problems with CPAN?  Was he trying 
to install on Windows?  Did he have trouble setting mysql privileges or 
apache webserver configuration?

-Joel



From jmdesp at alussinan.org  Tue Feb 16 19:18:59 2010
From: jmdesp at alussinan.org (Jean-Marc Desperrier)
Date: Tue, 16 Feb 2010 20:18:59 +0100
Subject: post FOSDEM
In-Reply-To: <mailman.4859.1266344502.4112.dev-apps-bugzilla@lists.mozilla.org>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>	<WcidnWPFppxcZe7WnZ2dnUVZ_gZi4p2d@mozilla.org>	<97784.55432.qm@web114014.mail.gq1.yahoo.com>	<mailman.4542.1265926982.4112.dev-apps-bugzilla@lists.mozilla.org>	<ArudnbvuMs7M2-jWnZ2dnUVZ_oKdnZ2d@mozilla.org>	<mailman.4630.1266006694.4112.dev-apps-bugzilla@lists.mozilla.org>	<1sydnVG4rMrQROfWnZ2dnUVZ_jFi4p2d@mozilla.org>
	<mailman.4859.1266344502.4112.dev-apps-bugzilla@lists.mozilla.org>
Message-ID: <prGdndGiP7o-cufWnZ2dnUVZ_t2dnZ2d@mozilla.org>

Joel Peshkin wrote:
> I hear this a lot and it baffles me.    Could you be more specific about
> where he failed?  Did he have problems with CPAN?  Was he trying to
> install on Windows?  Did he have trouble setting mysql privileges or
> apache webserver configuration?

I think he was trying under Windows. I'm not saying he was *very* 
motivated to install it from start.

I think the easiest solution would be to make available, and very 
visible, one setup package with everything included that you just click 
through to install with a default database.

Easybugzilla is what's needed, just like Easyphp (which install just 
like I described PHP+Apache+MySql+PhpMyAdmin, together with a 
start/stop/configure icon in the task bar).
_______________________________________________
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  Tue Feb 16 21:27:33 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Tue, 16 Feb 2010 13:27:33 -0800
Subject: post FOSDEM
In-Reply-To: <1sydnVG4rMrQROfWnZ2dnUVZ_jFi4p2d@mozilla.org>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>	<WcidnWPFppxcZe7WnZ2dnUVZ_gZi4p2d@mozilla.org>	<97784.55432.qm@web114014.mail.gq1.yahoo.com>	<mailman.4542.1265926982.4112.dev-apps-bugzilla@lists.mozilla.org>	<ArudnbvuMs7M2-jWnZ2dnUVZ_oKdnZ2d@mozilla.org>	<mailman.4630.1266006694.4112.dev-apps-bugzilla@lists.mozilla.org> <1sydnVG4rMrQROfWnZ2dnUVZ_jFi4p2d@mozilla.org>
Message-ID: <4B7B0DC5.60306@bugzilla.org>

On 02/16/2010 09:43 AM, Jean-Marc Desperrier wrote:
> Bugzilla has a Himalaya of bad karma about not being easy to install.
> And developers who don't *really* care about that.

	Hey Jean-Marc. I absolutely care about whether or not it's easy to
install. It's currently far easier to install on *nix than it is on
Windows, though, and that's something that I want to fix.

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


From szabgab at gmail.com  Tue Feb 16 21:29:44 2010
From: szabgab at gmail.com (Gabor Szabo)
Date: Tue, 16 Feb 2010 23:29:44 +0200
Subject: post FOSDEM
In-Reply-To: <prGdndGiP7o-cufWnZ2dnUVZ_t2dnZ2d@mozilla.org>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>
	 <WcidnWPFppxcZe7WnZ2dnUVZ_gZi4p2d@mozilla.org>
	 <97784.55432.qm@web114014.mail.gq1.yahoo.com>
	 <mailman.4542.1265926982.4112.dev-apps-bugzilla@lists.mozilla.org>
	 <ArudnbvuMs7M2-jWnZ2dnUVZ_oKdnZ2d@mozilla.org>
	 <mailman.4630.1266006694.4112.dev-apps-bugzilla@lists.mozilla.org>
	 <1sydnVG4rMrQROfWnZ2dnUVZ_jFi4p2d@mozilla.org>
	 <mailman.4859.1266344502.4112.dev-apps-bugzilla@lists.mozilla.org>
	 <prGdndGiP7o-cufWnZ2dnUVZ_t2dnZ2d@mozilla.org>
Message-ID: <d8a74af11002161329q17f77a00nc7aa8acfd6d44017@mail.gmail.com>

On Tue, Feb 16, 2010 at 9:18 PM, Jean-Marc Desperrier
<jmdesp at alussinan.org> wrote:

> Easybugzilla is what's needed, just like Easyphp (which install just like I
> described PHP+Apache+MySql+PhpMyAdmin, together with a start/stop/configure
> icon in the task bar).

IMHO for windows Bugzilla could be integrated with Strawberry Perl Professional
and distributed that way.

On Ubuntu I can just type

$ sudo aptitude install bugzilla3

but I have not tried it yet so I am not sure what will be the end result.

In any case it would be nice if that was working on all the major
Linux distributions
if it is not yet already.

Gabor


From mkanat at bugzilla.org  Tue Feb 16 21:34:34 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Tue, 16 Feb 2010 13:34:34 -0800
Subject: post FOSDEM
In-Reply-To: <d8a74af11002161329q17f77a00nc7aa8acfd6d44017@mail.gmail.com>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>	 <WcidnWPFppxcZe7WnZ2dnUVZ_gZi4p2d@mozilla.org>	 <97784.55432.qm@web114014.mail.gq1.yahoo.com>	 <mailman.4542.1265926982.4112.dev-apps-bugzilla@lists.mozilla.org>	 <ArudnbvuMs7M2-jWnZ2dnUVZ_oKdnZ2d@mozilla.org>	 <mailman.4630.1266006694.4112.dev-apps-bugzilla@lists.mozilla.org>	 <1sydnVG4rMrQROfWnZ2dnUVZ_jFi4p2d@mozilla.org>	 <mailman.4859.1266344502.4112.dev-apps-bugzilla@lists.mozilla.org>	 <prGdndGiP7o-cufWnZ2dnUVZ_t2dnZ2d@mozilla.org> <d8a74af11002161329q17f77a00nc7aa8acfd6d44017@mail.gmail.com>
Message-ID: <4B7B0F6A.70405@bugzilla.org>

On 02/16/2010 01:29 PM, Gabor Szabo wrote:
> IMHO for windows Bugzilla could be integrated with Strawberry Perl Professional
> and distributed that way.

	The reason that Bugzilla can't currently use Strawberry Perl is that
explaining how to compile DBD::mysql (or any other CPAN module dependent
upon external headers) is too complicated and difficult.

> On Ubuntu I can just type
> 
> $ sudo aptitude install bugzilla3
> 
> but I have not tried it yet so I am not sure what will be the end result.

	The Ubuntu package seems to have a lot of issues, and is, I believe,
unmaintainted. The Fedora package is kept up-to-date, though, and seems
to work fine.

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


From dwierenga at gmail.com  Tue Feb 16 21:37:39 2010
From: dwierenga at gmail.com (Dan Wierenga)
Date: Tue, 16 Feb 2010 13:37:39 -0800
Subject: post FOSDEM
In-Reply-To: <4B7B0F6A.70405@bugzilla.org>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>
	 <97784.55432.qm@web114014.mail.gq1.yahoo.com>
	 <mailman.4542.1265926982.4112.dev-apps-bugzilla@lists.mozilla.org>
	 <ArudnbvuMs7M2-jWnZ2dnUVZ_oKdnZ2d@mozilla.org>
	 <mailman.4630.1266006694.4112.dev-apps-bugzilla@lists.mozilla.org>
	 <1sydnVG4rMrQROfWnZ2dnUVZ_jFi4p2d@mozilla.org>
	 <mailman.4859.1266344502.4112.dev-apps-bugzilla@lists.mozilla.org>
	 <prGdndGiP7o-cufWnZ2dnUVZ_t2dnZ2d@mozilla.org>
	 <d8a74af11002161329q17f77a00nc7aa8acfd6d44017@mail.gmail.com>
	 <4B7B0F6A.70405@bugzilla.org>
Message-ID: <a3717d971002161337j777f9ee7t43e0020cdcd6f482@mail.gmail.com>

On Tue, Feb 16, 2010 at 1:34 PM, Max Kanat-Alexander
<mkanat at bugzilla.org> wrote:
> On 02/16/2010 01:29 PM, Gabor Szabo wrote:
>> IMHO for windows Bugzilla could be integrated with Strawberry Perl Professional
>> and distributed that way.
>
> ? ? ? ?The reason that Bugzilla can't currently use Strawberry Perl is that
> explaining how to compile DBD::mysql (or any other CPAN module dependent
> upon external headers) is too complicated and difficult.

But if you were making an installer package that bundled Strawberry
Perl, wouldn't you be doing the DBD::mysql compile for the end-user
anyway?


From szabgab at gmail.com  Tue Feb 16 21:54:37 2010
From: szabgab at gmail.com (Gabor Szabo)
Date: Tue, 16 Feb 2010 23:54:37 +0200
Subject: post FOSDEM
In-Reply-To: <a3717d971002161337j777f9ee7t43e0020cdcd6f482@mail.gmail.com>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>
	 <mailman.4542.1265926982.4112.dev-apps-bugzilla@lists.mozilla.org>
	 <ArudnbvuMs7M2-jWnZ2dnUVZ_oKdnZ2d@mozilla.org>
	 <mailman.4630.1266006694.4112.dev-apps-bugzilla@lists.mozilla.org>
	 <1sydnVG4rMrQROfWnZ2dnUVZ_jFi4p2d@mozilla.org>
	 <mailman.4859.1266344502.4112.dev-apps-bugzilla@lists.mozilla.org>
	 <prGdndGiP7o-cufWnZ2dnUVZ_t2dnZ2d@mozilla.org>
	 <d8a74af11002161329q17f77a00nc7aa8acfd6d44017@mail.gmail.com>
	 <4B7B0F6A.70405@bugzilla.org>
	 <a3717d971002161337j777f9ee7t43e0020cdcd6f482@mail.gmail.com>
Message-ID: <d8a74af11002161354s383b3cbeve44e6dc8c207948d@mail.gmail.com>

On Tue, Feb 16, 2010 at 11:37 PM, Dan Wierenga <dwierenga at gmail.com> wrote:
> On Tue, Feb 16, 2010 at 1:34 PM, Max Kanat-Alexander
> <mkanat at bugzilla.org> wrote:
>> On 02/16/2010 01:29 PM, Gabor Szabo wrote:
>>> IMHO for windows Bugzilla could be integrated with Strawberry Perl Professional
>>> and distributed that way.
>>
>> ? ? ? ?The reason that Bugzilla can't currently use Strawberry Perl is that
>> explaining how to compile DBD::mysql (or any other CPAN module dependent
>> upon external headers) is too complicated and difficult.
>
> But if you were making an installer package that bundled Strawberry
> Perl, wouldn't you be doing the DBD::mysql compile for the end-user
> anyway?

According to the web site DBD::mysql is part of Strawberry Perl already.
see http://strawberryperl.com/

Gabor


From mkanat at bugzilla.org  Tue Feb 16 22:31:16 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Tue, 16 Feb 2010 14:31:16 -0800
Subject: post FOSDEM
In-Reply-To: <a3717d971002161337j777f9ee7t43e0020cdcd6f482@mail.gmail.com>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>	 <97784.55432.qm@web114014.mail.gq1.yahoo.com>	 <mailman.4542.1265926982.4112.dev-apps-bugzilla@lists.mozilla.org>	 <ArudnbvuMs7M2-jWnZ2dnUVZ_oKdnZ2d@mozilla.org>	 <mailman.4630.1266006694.4112.dev-apps-bugzilla@lists.mozilla.org>	 <1sydnVG4rMrQROfWnZ2dnUVZ_jFi4p2d@mozilla.org>	 <mailman.4859.1266344502.4112.dev-apps-bugzilla@lists.mozilla.org>	 <prGdndGiP7o-cufWnZ2dnUVZ_t2dnZ2d@mozilla.org>	 <d8a74af11002161329q17f77a00nc7aa8acfd6d44017@mail.gmail.com>	 <4B7B0F6A.70405@bugzilla.org> <a3717d971002161337j777f9ee7t43e0020cdcd6f482@mail.gmail.com>
Message-ID: <4B7B1CB4.4020005@bugzilla.org>

On 02/16/2010 01:37 PM, Dan Wierenga wrote:
> But if you were making an installer package that bundled Strawberry
> Perl, wouldn't you be doing the DBD::mysql compile for the end-user
> anyway?

	You can't--it depends on the version of MySQL in use. (It might also
depend on the Windows version in use? I'm not sure. I suspect 32-bit vs.
64-bit would be an issue, but Perl is already compiled differently for
those, so that's not a problem.) If we bundled MySQL also, we could
build a DBD::mysql. But then if people wanted to use PostgreSQL, they'd
have a hard time.

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


From mkanat at bugzilla.org  Tue Feb 16 22:32:16 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Tue, 16 Feb 2010 14:32:16 -0800
Subject: post FOSDEM
In-Reply-To: <d8a74af11002161354s383b3cbeve44e6dc8c207948d@mail.gmail.com>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>	 <mailman.4542.1265926982.4112.dev-apps-bugzilla@lists.mozilla.org>	 <ArudnbvuMs7M2-jWnZ2dnUVZ_oKdnZ2d@mozilla.org>	 <mailman.4630.1266006694.4112.dev-apps-bugzilla@lists.mozilla.org>	 <1sydnVG4rMrQROfWnZ2dnUVZ_jFi4p2d@mozilla.org>	 <mailman.4859.1266344502.4112.dev-apps-bugzilla@lists.mozilla.org>	 <prGdndGiP7o-cufWnZ2dnUVZ_t2dnZ2d@mozilla.org>	 <d8a74af11002161329q17f77a00nc7aa8acfd6d44017@mail.gmail.com>	 <4B7B0F6A.70405@bugzilla.org>	 <a3717d971002161337j777f9ee7t43e0020cdcd6f482@mail.gmail.com> <d8a74af11002161354s383b3cbeve44e6dc8c207948d@mail.gmail.com>
Message-ID: <4B7B1CF0.7060501@bugzilla.org>

On 02/16/2010 01:54 PM, Gabor Szabo wrote:
> According to the web site DBD::mysql is part of Strawberry Perl already.
> see http://strawberryperl.com/

	Oh, that's new since the last time we tried it out. Maybe we can try
again--it would be nice to be able to use normal CPAN tools on Windows.

	What about other things that depend on external libraries, like the GD
modules that we use?

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


From dwierenga at gmail.com  Tue Feb 16 22:46:22 2010
From: dwierenga at gmail.com (Dan Wierenga)
Date: Tue, 16 Feb 2010 14:46:22 -0800
Subject: post FOSDEM
In-Reply-To: <4B7B1CB4.4020005@bugzilla.org>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>
	 <ArudnbvuMs7M2-jWnZ2dnUVZ_oKdnZ2d@mozilla.org>
	 <mailman.4630.1266006694.4112.dev-apps-bugzilla@lists.mozilla.org>
	 <1sydnVG4rMrQROfWnZ2dnUVZ_jFi4p2d@mozilla.org>
	 <mailman.4859.1266344502.4112.dev-apps-bugzilla@lists.mozilla.org>
	 <prGdndGiP7o-cufWnZ2dnUVZ_t2dnZ2d@mozilla.org>
	 <d8a74af11002161329q17f77a00nc7aa8acfd6d44017@mail.gmail.com>
	 <4B7B0F6A.70405@bugzilla.org>
	 <a3717d971002161337j777f9ee7t43e0020cdcd6f482@mail.gmail.com>
	 <4B7B1CB4.4020005@bugzilla.org>
Message-ID: <a3717d971002161446w4dedfd05hf89a68aafffac978@mail.gmail.com>

On Tue, Feb 16, 2010 at 2:31 PM, Max Kanat-Alexander
<mkanat at bugzilla.org> wrote:
> If we bundled MySQL also, we could
> build a DBD::mysql. But then if people wanted to use PostgreSQL, they'd
> have a hard time.
>

People who want choices of which database to use, or which webserver
to use, or where your files install to, can install everything
manually.

On the other hand, the people who want to use a
just-a-few-clicks-and-it-WORKS Windows installer probably don't care
if they end up using MySQL or PostgresSQL, or Apache or IIS, or
ActiveState Perl or Strawberry Perl.  What they will care about is
that they're suddenly using *BUGZILLA*.


From szabgab at gmail.com  Tue Feb 16 22:55:31 2010
From: szabgab at gmail.com (Gabor Szabo)
Date: Wed, 17 Feb 2010 00:55:31 +0200
Subject: post FOSDEM
In-Reply-To: <4B7B1CF0.7060501@bugzilla.org>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>
	 <mailman.4630.1266006694.4112.dev-apps-bugzilla@lists.mozilla.org>
	 <1sydnVG4rMrQROfWnZ2dnUVZ_jFi4p2d@mozilla.org>
	 <mailman.4859.1266344502.4112.dev-apps-bugzilla@lists.mozilla.org>
	 <prGdndGiP7o-cufWnZ2dnUVZ_t2dnZ2d@mozilla.org>
	 <d8a74af11002161329q17f77a00nc7aa8acfd6d44017@mail.gmail.com>
	 <4B7B0F6A.70405@bugzilla.org>
	 <a3717d971002161337j777f9ee7t43e0020cdcd6f482@mail.gmail.com>
	 <d8a74af11002161354s383b3cbeve44e6dc8c207948d@mail.gmail.com>
	 <4B7B1CF0.7060501@bugzilla.org>
Message-ID: <d8a74af11002161455m2c9c52bai64be13f057fffd87@mail.gmail.com>

On Wed, Feb 17, 2010 at 12:32 AM, Max Kanat-Alexander
<mkanat at bugzilla.org> wrote:
> On 02/16/2010 01:54 PM, Gabor Szabo wrote:
>> According to the web site DBD::mysql is part of Strawberry Perl already.
>> see http://strawberryperl.com/
>
> ? ? ? ?Oh, that's new since the last time we tried it out. Maybe we can try
> again--it would be nice to be able to use normal CPAN tools on Windows.
>
> ? ? ? ?What about other things that depend on external libraries, like the GD
> modules that we use?

I don't know but if they are missing we could talk to Adam Kennedy
and/or Curtis Jewell who build Starwberry and ask them to make
Strawberry - or Strawberry Professional ready for Bugzilla.

They might also be able to help building a distribution that will
include everything Bugzilla needs including the database.

BTW can Bugzilla use SQLite? Can it use a perl based web server? If
those could work then you could have a much slimmer installation for
Windows.

Gabor


From mkanat at bugzilla.org  Tue Feb 16 23:14:05 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Tue, 16 Feb 2010 15:14:05 -0800
Subject: post FOSDEM
In-Reply-To: <d8a74af11002161455m2c9c52bai64be13f057fffd87@mail.gmail.com>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>	 <mailman.4630.1266006694.4112.dev-apps-bugzilla@lists.mozilla.org>	 <1sydnVG4rMrQROfWnZ2dnUVZ_jFi4p2d@mozilla.org>	 <mailman.4859.1266344502.4112.dev-apps-bugzilla@lists.mozilla.org>	 <prGdndGiP7o-cufWnZ2dnUVZ_t2dnZ2d@mozilla.org>	 <d8a74af11002161329q17f77a00nc7aa8acfd6d44017@mail.gmail.com>	 <4B7B0F6A.70405@bugzilla.org>	 <a3717d971002161337j777f9ee7t43e0020cdcd6f482@mail.gmail.com>	 <d8a74af11002161354s383b3cbeve44e6dc8c207948d@mail.gmail.com>	 <4B7B1CF0.7060501@bugzilla.org> <d8a74af11002161455m2c9c52bai64be13f057fffd87@mail.gmail.com>
Message-ID: <4B7B26BD.6040902@bugzilla.org>

On 02/16/2010 02:55 PM, Gabor Szabo wrote:
> BTW can Bugzilla use SQLite?

	Not yet, but I'd like it to:

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

> Can it use a perl based web server?

	Well, theoretically it can use any web server, but I prefer that users
use Apache, because it will use our .htaccess files and is something
that we know well and can provide support for.

> If
> those could work then you could have a much slimmer installation for
> Windows.

	Yeah, I've actually thought about that before, and thanks for reminding
me, because that's something I definitely want.

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


From mkanat at bugzilla.org  Tue Feb 16 23:15:23 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Tue, 16 Feb 2010 15:15:23 -0800
Subject: post FOSDEM
In-Reply-To: <a3717d971002161446w4dedfd05hf89a68aafffac978@mail.gmail.com>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>	 <ArudnbvuMs7M2-jWnZ2dnUVZ_oKdnZ2d@mozilla.org>	 <mailman.4630.1266006694.4112.dev-apps-bugzilla@lists.mozilla.org>	 <1sydnVG4rMrQROfWnZ2dnUVZ_jFi4p2d@mozilla.org>	 <mailman.4859.1266344502.4112.dev-apps-bugzilla@lists.mozilla.org>	 <prGdndGiP7o-cufWnZ2dnUVZ_t2dnZ2d@mozilla.org>	 <d8a74af11002161329q17f77a00nc7aa8acfd6d44017@mail.gmail.com>	 <4B7B0F6A.70405@bugzilla.org>	 <a3717d971002161337j777f9ee7t43e0020cdcd6f482@mail.gmail.com>	 <4B7B1CB4.4020005@bugzilla.org> <a3717d971002161446w4dedfd05hf89a68aafffac978@mail.gmail.com>
Message-ID: <4B7B270B.8060809@bugzilla.org>

On 02/16/2010 02:46 PM, Dan Wierenga wrote:
> On the other hand, the people who want to use a
> just-a-few-clicks-and-it-WORKS Windows installer probably don't care
> if they end up using MySQL or PostgresSQL, or Apache or IIS, or
> ActiveState Perl or Strawberry Perl.  What they will care about is
> that they're suddenly using *BUGZILLA*.

	Yeah, that makes sense.

	Also, somebody would have to maintain this installer and promptly
update it every release, or it wouldn't be that useful. I suspect that
that person wouldn't be me, so we'd need somebody willing to dedicate
themselves to producing the installer every time we have a release.

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


From mkanat at bugzilla.org  Wed Feb 17 00:22:54 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Tue, 16 Feb 2010 16:22:54 -0800
Subject: Some Review Help
Message-ID: <4B7B36DE.1070107@bugzilla.org>

	Hey Developers. Does anybody want to help out with some code reviews?
You don't have to be an official reviewer to test a patch or to provide
some comments on the code.

	Here are some patches of mine that are in need of review:

	Make First/Last/Next/Prev work with multiple bug lists:
	https://bugzilla.mozilla.org/show_bug.cgi?id=24896

	Change the default workflow:
	https://bugzilla.mozilla.org/show_bug.cgi?id=486292

	Make validation happen with JS when filing a bug:
	https://bugzilla.mozilla.org/show_bug.cgi?id=490767

	Add a Calendar widget to the Deadline field (really simple patch):
	https://bugzilla.mozilla.org/show_bug.cgi?id=329637

	Refactor Bugzilla's language-choosing code:
	https://bugzilla.mozilla.org/show_bug.cgi?id=545235

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


From spamsux at forgetit.org  Wed Feb 17 00:23:00 2010
From: spamsux at forgetit.org (Steve Wendt)
Date: Tue, 16 Feb 2010 16:23:00 -0800
Subject: post FOSDEM
In-Reply-To: <mailman.4897.1266362148.4112.dev-apps-bugzilla@lists.mozilla.org>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>		<ArudnbvuMs7M2-jWnZ2dnUVZ_oKdnZ2d@mozilla.org>		<mailman.4630.1266006694.4112.dev-apps-bugzilla@lists.mozilla.org>		<1sydnVG4rMrQROfWnZ2dnUVZ_jFi4p2d@mozilla.org>		<mailman.4859.1266344502.4112.dev-apps-bugzilla@lists.mozilla.org>		<prGdndGiP7o-cufWnZ2dnUVZ_t2dnZ2d@mozilla.org>		<d8a74af11002161329q17f77a00nc7aa8acfd6d44017@mail.gmail.com>		<4B7B0F6A.70405@bugzilla.org>		<a3717d971002161337j777f9ee7t43e0020cdcd6f482@mail.gmail.com>		<4B7B1CB4.4020005@bugzilla.org>	<a3717d971002161446w4dedfd05hf89a68aafffac978@mail.gmail.com>
	<mailman.4897.1266362148.4112.dev-apps-bugzilla@lists.mozilla.org>
Message-ID: <J96dnWiZqtF4q-bWnZ2dnUVZ_s9i4p2d@mozilla.org>

On 2/16/2010 3:15 PM, Max Kanat-Alexander wrote:

>> On the other hand, the people who want to use a
>> just-a-few-clicks-and-it-WORKS Windows installer probably don't care
>> if they end up using MySQL or PostgresSQL, or Apache or IIS, or
>
> 	Also, somebody would have to maintain this installer and promptly
> update it every release, or it wouldn't be that useful.

Which means chasing down the latest MySQL and Apache for bundling in. 
And what do you do if there's an important Apache security fix?  Release 
a new package, even if there's not a new Bugzilla?  If not, how do you 
handle user-installed updates?  It's a can of worms...
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla


From byron at glob.com.au  Wed Feb 17 00:32:33 2010
From: byron at glob.com.au (Byron Jones)
Date: Wed, 17 Feb 2010 08:32:33 +0800
Subject: post FOSDEM
In-Reply-To: <4B7B1CB4.4020005@bugzilla.org>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>	 <97784.55432.qm@web114014.mail.gq1.yahoo.com>	 <mailman.4542.1265926982.4112.dev-apps-bugzilla@lists.mozilla.org>	 <ArudnbvuMs7M2-jWnZ2dnUVZ_oKdnZ2d@mozilla.org>	 <mailman.4630.1266006694.4112.dev-apps-bugzilla@lists.mozilla.org>	 <1sydnVG4rMrQROfWnZ2dnUVZ_jFi4p2d@mozilla.org>	 <mailman.4859.1266344502.4112.dev-apps-bugzilla@lists.mozilla.org>	 <prGdndGiP7o-cufWnZ2dnUVZ_t2dnZ2d@mozilla.org>	 <d8a74af11002161329q17f77a00nc7aa8acfd6d44017@mail.gmail.com>	 <4B7B0F6A.70405@bugzilla.org> <a3717d971002161337j777f9ee7t43e0020cdcd6f482@mail.gmail.com> <4B7B1CB4.4020005@bugzilla.org>
Message-ID: <75cc53a2a760216394e1fbfd902885b6@localhost>


> [..] If we bundled MySQL also, we could build a DBD::mysql

we can't bundle mysql because bugzilla isn't gpl.


-- 

byron.jones :: http://glob.com.au


From dwierenga at gmail.com  Wed Feb 17 00:38:15 2010
From: dwierenga at gmail.com (Dan Wierenga)
Date: Tue, 16 Feb 2010 16:38:15 -0800
Subject: post FOSDEM
In-Reply-To: <4B7B270B.8060809@bugzilla.org>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>
	 <1sydnVG4rMrQROfWnZ2dnUVZ_jFi4p2d@mozilla.org>
	 <mailman.4859.1266344502.4112.dev-apps-bugzilla@lists.mozilla.org>
	 <prGdndGiP7o-cufWnZ2dnUVZ_t2dnZ2d@mozilla.org>
	 <d8a74af11002161329q17f77a00nc7aa8acfd6d44017@mail.gmail.com>
	 <4B7B0F6A.70405@bugzilla.org>
	 <a3717d971002161337j777f9ee7t43e0020cdcd6f482@mail.gmail.com>
	 <4B7B1CB4.4020005@bugzilla.org>
	 <a3717d971002161446w4dedfd05hf89a68aafffac978@mail.gmail.com>
	 <4B7B270B.8060809@bugzilla.org>
Message-ID: <a3717d971002161638l1e5fc983i566f962f784ab2f7@mail.gmail.com>

Hi Max (noticably, not to the list),

On Tue, Feb 16, 2010 at 3:15 PM, Max Kanat-Alexander
<mkanat at bugzilla.org> wrote:
> ? ? ? ?Also, somebody would have to maintain this installer and promptly
> update it every release, or it wouldn't be that useful. I suspect that
> that person wouldn't be me, so we'd need somebody willing to dedicate
> themselves to producing the installer every time we have a release.

I think that's the wrong way to go about this, and IMO it's indicative
of the entire thought process of the Bugzilla Project in regards to
Windows.  It's fairly obvious that Windows is the red-headed stepchild
platform.  Too little effort goes into making things work on Windows
for it to be really, truly considered a "supported platform".

 A command-line script is The Way You Install Things on Linux, and you
wouldn't ship a Linux release with a broken checksetup.pl.  Similarly,
an installer package (.msi or .exe) is The Way You Install Things on
Windows, and yet here you're talking about "promptly updating it every
release".  In other words, there's a Bugzilla release, and then the
installer would have to be nudged along.

>From my perspective, the release isn't RELEASABLE until the installer
is done.  It's what the release manager is doing from the time the
code base freezes in preparation for the release until the release
actually happens.

Yes, that means that the release management for a Windows build is a
whole lot more complicated than just some command-line perl scripts.
But that's the price of reaching the Windows audience;  you either
support Windows and its relatively un-technical userbase, or you
don't.  But you can't say "we support Windows" and then have a high
failure rate on installation.  All it does is give Bugzilla some
really bad press, because the Windows crowd doesn't think, "Bugzilla
doesn't work on Windows", they think "Bugzilla doesn't work".

I'd like to help on a Windows installer, I really would.  I sent you
my thoughts on why I wasn't contributing to the community, and I saw
your email thread on your research results.  You'll notice that thread
was enough to keep me here on the mailing list  :) , but I'm still not
*really* contributing.  A couple of things need to happen from the
Bugzilla developers before I'd really want to devote any time to a
Windows packager (and by "developers", I mean the real ones, not just
the members of the mailing list; I guess for my purpose the list of
code reviewers is "the real developers"):

- A simple clarion call to the list(s) for some help in sprucing up
the process of installing Bugzilla on Windows.  It's okay that none of
the reviewers knows much about making things install gracefully on
Windows; what's not okay is that you KNOW that, and you still haven't
put out a call for help.
- A commitment to a Windows installer, and the general treatment of a
Windows installation as "just as important as another platform".   You
can't make a release and then say the release is waiting for one
person to create an installer.  (Just think of the Firefox Project.
If they "released" Firefox 4 and said, "oh yeah, you can get the code
from CVS, but the Windows installer isn't ready yet", the majority of
the Internet would think "Firefox 4 isn't released", and the rest of
the Internet would think the Firefox Project has a screw loose for
even announcing it was.)


Basically, the Bugzilla Project needs to show it *wants* to be part of
the Windows community before the Windows community can be expected to
want to be part of the Bugzilla community.

-Dan


From dwierenga at gmail.com  Wed Feb 17 00:47:25 2010
From: dwierenga at gmail.com (Dan Wierenga)
Date: Tue, 16 Feb 2010 16:47:25 -0800
Subject: post FOSDEM
In-Reply-To: <a3717d971002161638l1e5fc983i566f962f784ab2f7@mail.gmail.com>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org> <1sydnVG4rMrQROfWnZ2dnUVZ_jFi4p2d@mozilla.org> <mailman.4859.1266344502.4112.dev-apps-bugzilla@lists.mozilla.org> <prGdndGiP7o-cufWnZ2dnUVZ_t2dnZ2d@mozilla.org> <d8a74af11002161329q17f77a00nc7aa8acfd6d44017@mail.gmail.com> <4B7B0F6A.70405@bugzilla.org> <a3717d971002161337j777f9ee7t43e0020cdcd6f482@mail.gmail.com> <4B7B1CB4.4020005@bugzilla.org> <a3717d971002161446w4dedfd05hf89a68aafffac978@mail.gmail.com> <4B7B270B.8060809@bugzilla.org> <a3717d971002161638l1e5fc983i566f962f784ab2f7@mail.gmail.com>
Message-ID: <40FA7815-F118-46BB-8ECF-3BCD58CEBE54@gmail.com>

I suppose I should double-check my recipient list when I'm typing an  
email that I'm excited about....  Ah well.



On Feb 16, 2010, at 4:38 PM, Dan Wierenga <dwierenga at gmail.com> wrote:

> Hi Max (noticably, not to the list),
>
> On Tue, Feb 16, 2010 at 3:15 PM, Max Kanat-Alexander
> <mkanat at bugzilla.org> wrote:
>>        Also, somebody would have to maintain this installer and  
>> promptly
>> update it every release, or it wouldn't be that useful. I suspect  
>> that
>> that person wouldn't be me, so we'd need somebody willing to dedicate
>> themselves to producing the installer every time we have a release.
>
> I think that's the wrong way to go about this, and IMO it's indicative
> of the entire thought process of the Bugzilla Project in regards to
> Windows.  It's fairly obvious that Windows is the red-headed stepchild
> platform.  Too little effort goes into making things work on Windows
> for it to be really, truly considered a "supported platform".
>
> A command-line script is The Way You Install Things on Linux, and you
> wouldn't ship a Linux release with a broken checksetup.pl.  Similarly,
> an installer package (.msi or .exe) is The Way You Install Things on
> Windows, and yet here you're talking about "promptly updating it every
> release".  In other words, there's a Bugzilla release, and then the
> installer would have to be nudged along.
>
> From my perspective, the release isn't RELEASABLE until the installer
> is done.  It's what the release manager is doing from the time the
> code base freezes in preparation for the release until the release
> actually happens.
>
> Yes, that means that the release management for a Windows build is a
> whole lot more complicated than just some command-line perl scripts.
> But that's the price of reaching the Windows audience;  you either
> support Windows and its relatively un-technical userbase, or you
> don't.  But you can't say "we support Windows" and then have a high
> failure rate on installation.  All it does is give Bugzilla some
> really bad press, because the Windows crowd doesn't think, "Bugzilla
> doesn't work on Windows", they think "Bugzilla doesn't work".
>
> I'd like to help on a Windows installer, I really would.  I sent you
> my thoughts on why I wasn't contributing to the community, and I saw
> your email thread on your research results.  You'll notice that thread
> was enough to keep me here on the mailing list  :) , but I'm still not
> *really* contributing.  A couple of things need to happen from the
> Bugzilla developers before I'd really want to devote any time to a
> Windows packager (and by "developers", I mean the real ones, not just
> the members of the mailing list; I guess for my purpose the list of
> code reviewers is "the real developers"):
>
> - A simple clarion call to the list(s) for some help in sprucing up
> the process of installing Bugzilla on Windows.  It's okay that none of
> the reviewers knows much about making things install gracefully on
> Windows; what's not okay is that you KNOW that, and you still haven't
> put out a call for help.
> - A commitment to a Windows installer, and the general treatment of a
> Windows installation as "just as important as another platform".   You
> can't make a release and then say the release is waiting for one
> person to create an installer.  (Just think of the Firefox Project.
> If they "released" Firefox 4 and said, "oh yeah, you can get the code
> from CVS, but the Windows installer isn't ready yet", the majority of
> the Internet would think "Firefox 4 isn't released", and the rest of
> the Internet would think the Firefox Project has a screw loose for
> even announcing it was.)
>
>
> Basically, the Bugzilla Project needs to show it *wants* to be part of
> the Windows community before the Windows community can be expected to
> want to be part of the Bugzilla community.
>
> -Dan


From bugreport at peshkin.net  Wed Feb 17 00:48:04 2010
From: bugreport at peshkin.net (Joel Peshkin)
Date: Tue, 16 Feb 2010 16:48:04 -0800
Subject: post FOSDEM
In-Reply-To: <a3717d971002161638l1e5fc983i566f962f784ab2f7@mail.gmail.com>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>	 <1sydnVG4rMrQROfWnZ2dnUVZ_jFi4p2d@mozilla.org>	 <mailman.4859.1266344502.4112.dev-apps-bugzilla@lists.mozilla.org>	 <prGdndGiP7o-cufWnZ2dnUVZ_t2dnZ2d@mozilla.org>	 <d8a74af11002161329q17f77a00nc7aa8acfd6d44017@mail.gmail.com>	 <4B7B0F6A.70405@bugzilla.org>	 <a3717d971002161337j777f9ee7t43e0020cdcd6f482@mail.gmail.com>	 <4B7B1CB4.4020005@bugzilla.org>	 <a3717d971002161446w4dedfd05hf89a68aafffac978@mail.gmail.com>	 <4B7B270B.8060809@bugzilla.org> <a3717d971002161638l1e5fc983i566f962f784ab2f7@mail.gmail.com>
Message-ID: <4B7B3CC4.8080102@peshkin.net>

Dan Wierenga wrote:
>
>  A command-line script is The Way You Install Things on Linux, and you
> wouldn't ship a Linux release with a broken checksetup.pl.  Similarly,
> an installer package (.msi or .exe) is The Way You Install Things on
> Windows, and yet here you're talking about "promptly updating it every
> release".  In other words, there's a Bugzilla release, and then the
> installer would have to be nudged along.
>
>   
The part that hangs me up here is what do we expect a Windows installer 
to do?  Does it need to install Apache and Mysql and ActivState Perl?  
Or does it presume certain things were previously set up before it is run.

Would it be reasonable to provide an installer that does the following....

1) Checks for perl ... if no Perl ...  pop up instructions to install 
Perl first and quit
2) Check for perl modules, if modules are missing, ask PPM to install them.
3) Prompt the user for Mysql connection information.  Test the 
connection, if it doesn't work, pop up instructions to install/configure 
MySQL
4) Offer to start a perl-based Webserver for Bugzilla.




From mkanat at bugzilla.org  Wed Feb 17 00:50:07 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Tue, 16 Feb 2010 16:50:07 -0800
Subject: post FOSDEM
In-Reply-To: <a3717d971002161638l1e5fc983i566f962f784ab2f7@mail.gmail.com>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>	 <1sydnVG4rMrQROfWnZ2dnUVZ_jFi4p2d@mozilla.org>	 <mailman.4859.1266344502.4112.dev-apps-bugzilla@lists.mozilla.org>	 <prGdndGiP7o-cufWnZ2dnUVZ_t2dnZ2d@mozilla.org>	 <d8a74af11002161329q17f77a00nc7aa8acfd6d44017@mail.gmail.com>	 <4B7B0F6A.70405@bugzilla.org>	 <a3717d971002161337j777f9ee7t43e0020cdcd6f482@mail.gmail.com>	 <4B7B1CB4.4020005@bugzilla.org>	 <a3717d971002161446w4dedfd05hf89a68aafffac978@mail.gmail.com>	 <4B7B270B.8060809@bugzilla.org> <a3717d971002161638l1e5fc983i566f962f784ab2f7@mail.gmail.com>
Message-ID: <4B7B3D3F.8090805@bugzilla.org>

On 02/16/2010 04:38 PM, Dan Wierenga wrote:
> I think that's the wrong way to go about this, and IMO it's indicative
> of the entire thought process of the Bugzilla Project in regards to
> Windows.  It's fairly obvious that Windows is the red-headed stepchild
> platform.  Too little effort goes into making things work on Windows
> for it to be really, truly considered a "supported platform".

	Hey Dan. Here's the problem:

	Nobody pays me to work on Bugzilla. Nobody is paid to do Bugzilla
releases. (In fact, *nobody* is paid to work on Bugzilla full time, at
all.) The current release package process is very simple, whereas an MSI
that would install and configure Bugzilla, Apache, MySQL and Perl all at
once is an incredibly complex undertaking requiring an immense amount of
specialized skill that I don't currently have. It's not that I don't
understand the importance or the utility of such a project, it's simply
that I *cannot do it*. So I need somebody else to do it, and then I
would be *really glad* to have it.

> - A simple clarion call to the list(s) for some help in sprucing up
> the process of installing Bugzilla on Windows.  It's okay that none of
> the reviewers knows much about making things install gracefully on
> Windows; what's not okay is that you KNOW that, and you still haven't
> put out a call for help.

	Every time somebody has suggested this I've said that I would gladly
accept help. It would be one of the most valuable contributions that
anybody could make to Bugzilla. I think that the last time somebody
suggested it was before you were on the list, though, or it's possible
that the discussions happened on IRC.

	So yes, if you want to do this, it would be totally awesome, and I will
help review it and talk about how it should be done.

> - A commitment to a Windows installer, and the general treatment of a
> Windows installation as "just as important as another platform". 

	In fact, we'd be making a commitment to Windows, in this case, as being
*more* important than other platforms. We don't provide distro packages
for any other OS.

> You
> can't make a release and then say the release is waiting for one
> person to create an installer.  

	If you think that you could get me an MSI simultaneously with every
Bugzilla release, then I'd be happy to commit to it. Alternately, the
Windows installer could come a few days after the release, and I would
post it then.

> Basically, the Bugzilla Project needs to show it *wants* to be part of
> the Windows community before the Windows community can be expected to
> want to be part of the Bugzilla community.

	I'm extremely interested in contributions from Windows developers--I
think that Windows may be the most popular platform to install Bugzilla on.

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


From mockodin at gmail.com  Wed Feb 17 00:51:22 2010
From: mockodin at gmail.com (Michael Thomas)
Date: Tue, 16 Feb 2010 16:51:22 -0800
Subject: post FOSDEM
In-Reply-To: <4B7B3CC4.8080102@peshkin.net>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>
	 <prGdndGiP7o-cufWnZ2dnUVZ_t2dnZ2d@mozilla.org>
	 <d8a74af11002161329q17f77a00nc7aa8acfd6d44017@mail.gmail.com>
	 <4B7B0F6A.70405@bugzilla.org>
	 <a3717d971002161337j777f9ee7t43e0020cdcd6f482@mail.gmail.com>
	 <4B7B1CB4.4020005@bugzilla.org>
	 <a3717d971002161446w4dedfd05hf89a68aafffac978@mail.gmail.com>
	 <4B7B270B.8060809@bugzilla.org>
	 <a3717d971002161638l1e5fc983i566f962f784ab2f7@mail.gmail.com>
	 <4B7B3CC4.8080102@peshkin.net>
Message-ID: <6b9407351002161651n4d6a6695r78877b8fd229c860@mail.gmail.com>

Typically the difference between Standard Install (include mysql,
apache, perl, etc..) and Custom Install (pick and choose)

So yes, I would expect those options to some extent or another, either
prompting for their existance and give instructions or to simple do
the install.

On Tue, Feb 16, 2010 at 4:48 PM, Joel Peshkin <bugreport at peshkin.net> wrote:
>
> The part that hangs me up here is what do we expect a Windows installer to
> do? ?Does it need to install Apache and Mysql and ActivState Perl? ?Or does
> it presume certain things were previously set up before it is run.
>
> Would it be reasonable to provide an installer that does the following....
>
> 1) Checks for perl ... if no Perl ... ?pop up instructions to install Perl
> first and quit
> 2) Check for perl modules, if modules are missing, ask PPM to install them.
> 3) Prompt the user for Mysql connection information. ?Test the connection,
> if it doesn't work, pop up instructions to install/configure MySQL
> 4) Offer to start a perl-based Webserver for Bugzilla.
>
>
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=mockodin at gmail.com>
>


From mkanat at bugzilla.org  Wed Feb 17 00:55:14 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Tue, 16 Feb 2010 16:55:14 -0800
Subject: post FOSDEM
In-Reply-To: <75cc53a2a760216394e1fbfd902885b6@localhost>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>	 <97784.55432.qm@web114014.mail.gq1.yahoo.com>	 <mailman.4542.1265926982.4112.dev-apps-bugzilla@lists.mozilla.org>	 <ArudnbvuMs7M2-jWnZ2dnUVZ_oKdnZ2d@mozilla.org>	 <mailman.4630.1266006694.4112.dev-apps-bugzilla@lists.mozilla.org>	 <1sydnVG4rMrQROfWnZ2dnUVZ_jFi4p2d@mozilla.org>	 <mailman.4859.1266344502.4112.dev-apps-bugzilla@lists.mozilla.org>	 <prGdndGiP7o-cufWnZ2dnUVZ_t2dnZ2d@mozilla.org>	 <d8a74af11002161329q17f77a00nc7aa8acfd6d44017@mail.gmail.com>	 <4B7B0F6A.70405@bugzilla.org> <a3717d971002161337j777f9ee7t43e0020cdcd6f482@mail.gmail.com> <4B7B1CB4.4020005@bugzilla.org> <75cc53a2a760216394e1fbfd902885b6@localhost>
Message-ID: <4B7B3E72.2070302@bugzilla.org>

On 02/16/2010 04:32 PM, Byron Jones wrote:
>> [..] If we bundled MySQL also, we could build a DBD::mysql
> 
> we can't bundle mysql because bugzilla isn't gpl.

	Hmm, is that actually true? I mean, we can't include it in the same
installer as a non-GPL program? I think that would prevent distros from
shipping both GPL and non-GPL software on the same medium, which isn't
prohibited.

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


From byron at glob.com.au  Wed Feb 17 02:58:35 2010
From: byron at glob.com.au (Byron Jones)
Date: Wed, 17 Feb 2010 10:58:35 +0800
Subject: post FOSDEM
In-Reply-To: <4B7B3E72.2070302@bugzilla.org>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>	 <97784.55432.qm@web114014.mail.gq1.yahoo.com>	 <mailman.4542.1265926982.4112.dev-apps-bugzilla@lists.mozilla.org>	 <ArudnbvuMs7M2-jWnZ2dnUVZ_oKdnZ2d@mozilla.org>	 <mailman.4630.1266006694.4112.dev-apps-bugzilla@lists.mozilla.org>	 <1sydnVG4rMrQROfWnZ2dnUVZ_jFi4p2d@mozilla.org>	 <mailman.4859.1266344502.4112.dev-apps-bugzilla@lists.mozilla.org>	 <prGdndGiP7o-cufWnZ2dnUVZ_t2dnZ2d@mozilla.org>	 <d8a74af11002161329q17f77a00nc7aa8acfd6d44017@mail.gmail.com>	 <4B7B0F6A.70405@bugzilla.org> <a3717d971002161337j777f9ee7t43e0020cdcd6f482@mail.gmail.com> <4B7B1CB4.4020005@bugzilla.org> <75cc53a2a760216394e1fbfd902885b6@localhost> <4B7B3E72.2070302@bugzilla.org>
Message-ID: <74afd5aae7112052d3f6704afe9def08@localhost>


>>> [..] If we bundled MySQL also, we could build a DBD::mysql
>> 
>> we can't bundle mysql because bugzilla isn't gpl.
> 
> 	Hmm, is that actually true? I mean, we can't include it in the same
> installer as a non-GPL program? I think that would prevent distros from
> shipping both GPL and non-GPL software on the same medium, which isn't
> prohibited.

when i was looking at building a windows installer for bugzilla i emailed
mysql for clarification.  the response was that unless the open source
product is licensed as gpl, you're not able to bundle mysql in your
installer.  this was several years ago however.

http://www.mysql.com/about/legal/licensing/index.html

i suspect they have different licensing terms for distros vs open-source
projects.



-- 

byron.jones :: http://glob.com.au


From mkanat at bugzilla.org  Wed Feb 17 06:08:57 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Tue, 16 Feb 2010 22:08:57 -0800
Subject: post FOSDEM
In-Reply-To: <74afd5aae7112052d3f6704afe9def08@localhost>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>	 <97784.55432.qm@web114014.mail.gq1.yahoo.com>	 <mailman.4542.1265926982.4112.dev-apps-bugzilla@lists.mozilla.org>	 <ArudnbvuMs7M2-jWnZ2dnUVZ_oKdnZ2d@mozilla.org>	 <mailman.4630.1266006694.4112.dev-apps-bugzilla@lists.mozilla.org>	 <1sydnVG4rMrQROfWnZ2dnUVZ_jFi4p2d@mozilla.org>	 <mailman.4859.1266344502.4112.dev-apps-bugzilla@lists.mozilla.org>	 <prGdndGiP7o-cufWnZ2dnUVZ_t2dnZ2d@mozilla.org>	 <d8a74af11002161329q17f77a00nc7aa8acfd6d44017@mail.gmail.com>	 <4B7B0F6A.70405@bugzilla.org> <a3717d971002161337j777f9ee7t43e0020cdcd6f482@mail.gmail.com> <4B7B1CB4.4020005@bugzilla.org> <75cc53a2a760216394e1fbfd902885b6@localhost> <4B7B3E72.2070302@bugzilla.org> <74afd5aae7112052d3f6704afe9def08@localhost>
Message-ID: <4B7B87F9.6020103@bugzilla.org>

On 02/16/2010 06:58 PM, Byron Jones wrote:
> when i was looking at building a windows installer for bugzilla i emailed
> mysql for clarification.  the response was that unless the open source
> product is licensed as gpl, you're not able to bundle mysql in your
> installer.  this was several years ago however.
> 
> http://www.mysql.com/about/legal/licensing/index.html
> 
> i suspect they have different licensing terms for distros vs open-source
> projects.

	Ohh, no, actually, distros used to have the same problem, I remember
this now! I thought that the FOSS Exception was supposed to resolve this:

	http://www.mysql.com/about/legal/licensing/foss-exception/

	Except that it appears that it only applies to the client libraries.
However, this item in the FSF FAQ:

	http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLCompatInstaller

	Particularly "the installer and the files it installs are separate
works" would be enough for me to suspect that Bugzilla and MySQL, though
both being installed by the same installer, would be considered separate
works. Otherwise no distro could ship GPL'ed software that was installed
by its installer along with GPL-incompatible software (which, I believe,
every distro does).

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


From mkanat at bugzilla.org  Wed Feb 17 06:41:46 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Tue, 16 Feb 2010 22:41:46 -0800
Subject: Free Bugzilla T-Shirts for Bugzilla Contributors!
Message-ID: <4B7B8FAA.5030906@bugzilla.org>

	Hey Bugzilla-ers. I don't know if you noticed, but the old Mozilla
Store (where you could buy Bugzilla t-shirts) closed down a few months
back, and it never re-opened. Well, I don't know if it's ever going to
re-open, but Mozilla apparently got all the stock from it, and one of
the things they did was they gave me all the Bugzilla t-shirts from the
store.

	I happen to have been given all of the Bugzilla t-shirts that were in
the Mozilla Store, to do whatever I want with. :-) As it turns out, what
I want to do with them is to give them away to you! :-)

	According to the box, I have about 80 shirts in the following sizes:

	* LARGE: 32
	* MEDIUM: 34
	* SMALL 27

	These are all the Bugzilla shirts that are left in the world, pretty
much, and if you've ever contributed to Bugzilla (code, documentation,
UI/web design, translation, promotion, or a fair bit of support), I want
to ship one of them to you for free, no matter where you are in the
world. Mozilla has been kind enough to offer to foot the bill for shipping.

	If you would like a t-shirt, just send me your name and address by
direct email, and what size of shirt you'd like. If you've already
bought a shirt for yourself in the past, you're still eligible for a
free shirt if you'd like one to give to somebody else (or just to have
as a spare). If you think that I might not know or remember your
contributions, then just remind me what they were, briefly, in your email.

	The shirts are American Apparel, so they run a little small, but
they're very comfortable.

	As they say, "offer good while supplies last". :-) So if you were
thinking about contributing to Bugzilla, and you want a t-shirt, now's
the time! :-)

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


From mkanat at bugzilla.org  Wed Feb 17 07:22:19 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Tue, 16 Feb 2010 23:22:19 -0800
Subject: Free Bugzilla T-Shirts for Bugzilla Contributors!
In-Reply-To: <4B7B8FAA.5030906@bugzilla.org>
References: <4B7B8FAA.5030906@bugzilla.org>
Message-ID: <4B7B992B.8000304@bugzilla.org>

On 02/16/2010 10:41 PM, Max Kanat-Alexander wrote:
> 	If you would like a t-shirt, just send me your name and address by
> direct email, 

	Oh, and apparently we also need your phone number! I guess that FedEx
uses it to contact you if they can't deliver your package, or something.

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


From Callek at gmail.com  Wed Feb 17 10:44:34 2010
From: Callek at gmail.com (Justin Wood (Callek))
Date: Wed, 17 Feb 2010 05:44:34 -0500
Subject: Why Not Y!?
In-Reply-To: <mailman.4634.1266008456.4112.dev-apps-bugzilla@lists.mozilla.org>
References: <mailman.4634.1266008456.4112.dev-apps-bugzilla@lists.mozilla.org>
Message-ID: <SNednR6J9eMOVebWnZ2dnUVZ_smdnZ2d@mozilla.org>

[My remarks can be shared with *or* without my personal data attached]

In my particular case, I did not have even the slightest interest in 
doing bugzilla dev then. (nor do I recall seeing the post).

However I still likely would not have applied for the job, as I do not 
have a desire to move permanently across the country (Live in MA right 
now) but should Yahoo! offer, even the chance at a "mostly" remote 
employment I'd be happy to reconsider that opinion.

By mostly I mean, I'm ok with a few weeks here and there needing to go 
for on-hands meetings, actual face-to-face, etc. But I have such a 
strong connection to my family whom all live around here that committing 
more time to a distant job is not worthwhile for me.

Hope that helps.

-- 
~Justin Wood (Callek)

On 2/12/2010 3:59 PM, David Marshall wrote:
> Hi all,
>
> This is very informal, totally optional (of course), and entirely a matter
> of curiosity for me.
>
> Last March, I sent email to this mailing list announcing that Yahoo! was
> hiring an additional Bugzilla developer.  I received a number of inquiries,
> for which I'm grateful.  To be honest, though, I expected more interest than
> I saw.
>
> We're not currently hiring anyone for Bugzilla, and I don't know when/if we
> will be next, so this isn't a preface to a similar announcement.
>
> However, I'm interested in why any given person chose not to express any
> interest.  For a number of people (some who wrote and some who didn't), it's
> not desirable or feasible to move to California.  Others are very happy with
> what they're doing and don't want to do something else (like me!).  Some
> people don't want to be or cannot be a full-timer at a big company.  That's
> all completely understandable.
>
> I'd really like to hear from you if you were looking for a job or were
> thinking about it at the time but decided not to express interest in my
> posting.  Was there anything about the description or Yahoo! itself that
> made you decide against?  Was there anything *not* in the description or
> some area in which you think Yahoo! is lacking that made you decide against?
>
> As I said above, this is very informal.  I am just gathering information to
> see whether it supports certain hypotheses.  Unless I ask for and receive
> your explicit permission to share your remarks (anonymously) with others at
> Yahoo!, I'll regard your communication as private between us.
>
> If you would prefer to email me at some other email address, please find me
> on #mozwebtools (as dwm), and I'll give you my personal email address.
>
> Thank you very much!
>
> -
> 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 lpsolit at gmail.com  Wed Feb 17 12:23:47 2010
From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=)
Date: Wed, 17 Feb 2010 13:23:47 +0100
Subject: post FOSDEM
In-Reply-To: <4B7B3CC4.8080102@peshkin.net>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>	 <1sydnVG4rMrQROfWnZ2dnUVZ_jFi4p2d@mozilla.org>	 <mailman.4859.1266344502.4112.dev-apps-bugzilla@lists.mozilla.org>	 <prGdndGiP7o-cufWnZ2dnUVZ_t2dnZ2d@mozilla.org>	 <d8a74af11002161329q17f77a00nc7aa8acfd6d44017@mail.gmail.com>	 <4B7B0F6A.70405@bugzilla.org>	 <a3717d971002161337j777f9ee7t43e0020cdcd6f482@mail.gmail.com>	 <4B7B1CB4.4020005@bugzilla.org>	 <a3717d971002161446w4dedfd05hf89a68aafffac978@mail.gmail.com>	 <4B7B270B.8060809@bugzilla.org> <a3717d971002161638l1e5fc983i566f962f784ab2f7@mail.gmail.com> <4B7B3CC4.8080102@peshkin.net>
Message-ID: <4B7BDFD3.6020809@gmail.com>

Le 17. 02. 10 01:48, Joel Peshkin a ?crit :
> Would it be reasonable to provide an installer that does the following....
> 
> 1) Checks for perl ... if no Perl ...  pop up instructions to install
> Perl first and quit
> 2) Check for perl modules, if modules are missing, ask PPM to install them.
> 3) Prompt the user for Mysql connection information.  Test the
> connection, if it doesn't work, pop up instructions to install/configure
> MySQL
> 4) Offer to start a perl-based Webserver for Bugzilla.


I filed a bug 6 months ago on my local Bugzilla about creating an
installer for Windows. Then I had no time to look at it in greater
details, so I still have no idea whether it's relatively simple or not
to build. When I filed my bug, I had three ideas in mind:
- NSIS
- Inno Setup
- Perl::Win32::GUI on Win32 and Gtk2 on Linux.

Then it seemed to me that NSIS was more powerful than Inno Setup.


I don't think we need to update our installer for each new release. What
I had in mind was to combine the current Bugzilla tarball with the
installer in a single NSIS executable, and the executable would untar
the Bugzilla tarball, then do what Joel proposed:
1) Check for Perl. If no Perl installed, suggest to install it (with a
URL to the download page of ActivePerl). We should only point to the
download page rather than to a specific Perl version so that we always
point to the more recent ActivePerl release.
2) Check for Perl modules, and call PPM itself if needed to install
missing modules.
3) If the MySQL is not running, offer to download it, and offer a URL to
the MySQL download page, again to always point to the more recent release.
4) Same for Apache.

So the installer wouldn't need to be updated as it wouldn't include any
specific software with it. It would simply point to the download pages
of MySQL, Apache and ActivePerl when they are missing.

I don't know if NSIS can do it. Else I don't know how MSI works, but I
would be happy to try. I would just need some free time and why not
someone with some experience with MSI to help. :)

LpSolit


From jmdesp at alussinan.org  Wed Feb 17 13:21:42 2010
From: jmdesp at alussinan.org (Jean-Marc Desperrier)
Date: Wed, 17 Feb 2010 14:21:42 +0100
Subject: post FOSDEM
In-Reply-To: <mailman.4879.1266355684.4112.dev-apps-bugzilla@lists.mozilla.org>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>	<WcidnWPFppxcZe7WnZ2dnUVZ_gZi4p2d@mozilla.org>	<97784.55432.qm@web114014.mail.gq1.yahoo.com>	<mailman.4542.1265926982.4112.dev-apps-bugzilla@lists.mozilla.org>	<ArudnbvuMs7M2-jWnZ2dnUVZ_oKdnZ2d@mozilla.org>	<mailman.4630.1266006694.4112.dev-apps-bugzilla@lists.mozilla.org>	<1sydnVG4rMrQROfWnZ2dnUVZ_jFi4p2d@mozilla.org>
	<mailman.4879.1266355684.4112.dev-apps-bugzilla@lists.mozilla.org>
Message-ID: <0PSdnWOtuePPcObWnZ2dnUVZ_vmdnZ2d@mozilla.org>

Max Kanat-Alexander wrote:
> I absolutely care about whether or not it's easy to
> install. It's currently far easier to install on *nix than it is on
> Windows, though, and that's something that I want to fix.

OK, I need to check again under *nix.

- I hope it's now, as much as possible, *obvious* that ImageMagick only 
brings a really minor functionality, so that people know that if they 
have some problem with it, it's no use spending time solving them

- that the "Just tell me what to install to get everything" option is 
clearly documented and the default, in all the doc and not just in some 
parts of it

- that the "Just tell me what to install to get everything" option in 
fact does *not* really get everything, and instead in the first steps 
leads to choosing the db format used, instead of by default leading you 
to install everything for every supported db format
_______________________________________________
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  Wed Feb 17 13:34:45 2010
From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=)
Date: Wed, 17 Feb 2010 14:34:45 +0100
Subject: post FOSDEM
In-Reply-To: <0PSdnWOtuePPcObWnZ2dnUVZ_vmdnZ2d@mozilla.org>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>	<WcidnWPFppxcZe7WnZ2dnUVZ_gZi4p2d@mozilla.org>	<97784.55432.qm@web114014.mail.gq1.yahoo.com>	<mailman.4542.1265926982.4112.dev-apps-bugzilla@lists.mozilla.org>	<ArudnbvuMs7M2-jWnZ2dnUVZ_oKdnZ2d@mozilla.org>	<mailman.4630.1266006694.4112.dev-apps-bugzilla@lists.mozilla.org>	<1sydnVG4rMrQROfWnZ2dnUVZ_jFi4p2d@mozilla.org>	<mailman.4879.1266355684.4112.dev-apps-bugzilla@lists.mozilla.org> <0PSdnWOtuePPcObWnZ2dnUVZ_vmdnZ2d@mozilla.org>
Message-ID: <4B7BF075.3090706@gmail.com>

Le 17. 02. 10 14:21, Jean-Marc Desperrier a ?crit :
> - I hope it's now, as much as possible, *obvious* that ImageMagick only
> brings a really minor functionality

ImageMagick has been removed from Bugzilla 3.6. I moved it into an
extension.

LpSolit


From eblack at higherone.com  Wed Feb 17 16:28:12 2010
From: eblack at higherone.com (Eric Black)
Date: Wed, 17 Feb 2010 11:28:12 -0500
Subject: Some Review Help
In-Reply-To: <4B7B36DE.1070107@bugzilla.org>
References: <4B7B36DE.1070107@bugzilla.org>
Message-ID: <4F91EB003F5C784084736E717AB5AFCA1A0275A793@mail02.higherone.com>


>         Hey Developers. Does anybody want to help out with some code reviews?
> You don't have to be an official reviewer to test a patch or to provide
> some comments on the code.

I don't mind helping out with this, although I don't really feel qualified, so if I post irrelevant info/questions/suggestions it would be to get more familiar with the code standards. Let me know if you or anyone would like me to focus on something in particular.


From dwierenga at gmail.com  Wed Feb 17 17:46:31 2010
From: dwierenga at gmail.com (Dan Wierenga)
Date: Wed, 17 Feb 2010 09:46:31 -0800
Subject: post FOSDEM
In-Reply-To: <74afd5aae7112052d3f6704afe9def08@localhost>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>
	 <mailman.4859.1266344502.4112.dev-apps-bugzilla@lists.mozilla.org>
	 <prGdndGiP7o-cufWnZ2dnUVZ_t2dnZ2d@mozilla.org>
	 <d8a74af11002161329q17f77a00nc7aa8acfd6d44017@mail.gmail.com>
	 <4B7B0F6A.70405@bugzilla.org>
	 <a3717d971002161337j777f9ee7t43e0020cdcd6f482@mail.gmail.com>
	 <4B7B1CB4.4020005@bugzilla.org>
	 <75cc53a2a760216394e1fbfd902885b6@localhost>
	 <4B7B3E72.2070302@bugzilla.org>
	 <74afd5aae7112052d3f6704afe9def08@localhost>
Message-ID: <a3717d971002170946k3982b708s2d93e70aa75d4303@mail.gmail.com>

On Tue, Feb 16, 2010 at 6:58 PM, Byron Jones <byron at glob.com.au> wrote:
>
> when i was looking at building a windows installer for bugzilla i emailed
> mysql for clarification. ?the response was that unless the open source
> product is licensed as gpl, you're not able to bundle mysql in your
> installer. ?this was several years ago however.

Ok, fine.  MySQL has issues. However, PostgreSQL is released under a
MIT/BSD style license.

The idea of a Windows installer isn't to give the full-fledged
spectrum of choices to the naive Windows user.  The idea is to give
them SOMETHING that's fully supported by the Bugzilla Project, and
give it to them in an easy to install clickable package.

So, the installer gives them Apache, and PostgreSQL, and
ActiveState/Strawberry Perl as well. Those who truly need the
installer won't care what DB or webserver they use, those who like the
installer probably won't either, and those who are technically savvy
enough to not need and not like the installer can configure things
manually.

Sure, it'd be nice if the installer grew to something that offered the
full array of choices (assuming licensing can be worked out in the
future).  But seriously... baby steps!  Let's get SOMETHING working
before we try to get everything working.


From mkanat at bugzilla.org  Wed Feb 17 18:00:48 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Wed, 17 Feb 2010 10:00:48 -0800
Subject: Some Review Help
In-Reply-To: <4F91EB003F5C784084736E717AB5AFCA1A0275A793@mail02.higherone.com>
References: <4B7B36DE.1070107@bugzilla.org> <4F91EB003F5C784084736E717AB5AFCA1A0275A793@mail02.higherone.com>
Message-ID: <4B7C2ED0.6000701@bugzilla.org>

On 02/17/2010 08:28 AM, Eric Black wrote:
> I don't mind helping out with this, although I don't really feel qualified, so if I post irrelevant info/questions/suggestions it would be to get more familiar with the code standards. Let me know if you or anyone would like me to focus on something in particular.

	Hey, it would be great to get some feedback, even if you don't feel
qualified. :-) The bugs that I posted are a general good area of
focus--I'd say pick whichever one you feel most comfortable with.

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


From guy.pyrzak at gmail.com  Wed Feb 17 18:03:48 2010
From: guy.pyrzak at gmail.com (Guy Pyrzak)
Date: Wed, 17 Feb 2010 10:03:48 -0800
Subject: Fwd: REST APIs, and Tags
In-Reply-To: <hK2dncNCMevb_eTWnZ2dnUVZ_uZi4p2d@mozilla.org>
References: <lJ-dnTp28csNE5PWnZ2dnUVZ_hmdnZ2d@mozilla.org>
	 <yZidndn6Ks90U-_WnZ2dnUVZ_i2dnZ2d@mozilla.org>
	 <mailman.4482.1265904519.4112.dev-apps-bugzilla@lists.mozilla.org>
	 <DLOdnbzZ_Y171unWnZ2dnUVZ_hudnZ2d@mozilla.org>
	 <mailman.4514.1265914983.4112.dev-apps-bugzilla@lists.mozilla.org>
	 <8PadncL6B6wxwOTWnZ2dnUVZ_qSdnZ2d@mozilla.org>
	 <hK2dncNCMevb_eTWnZ2dnUVZ_uZi4p2d@mozilla.org>
Message-ID: <df4dec6f1002171003w3a711ce9u8fddee1b2c76b4fc@mail.gmail.com>

Ben,

This is actually a workflow we use at work for triaging our bugs and all we
did was add permissions to status changes so that only particular users
could change a state from "unco" to "ready". I'm not sure of the bug number
bug we find this really useful.

Also I've discussed with a few people that Bugzilla needs a better "triaging
ui". I haven't thought through the whole problem quite yet, and there have
been a few pencil sketches which no one has been super happy with. But I'm
not sure if tagging solves the triaging problem

*attempts to duck out of the rest of this discussion*

-Guy

On Mon, Feb 15, 2010 at 6:55 AM, Benjamin Smedberg <benjamin at smedbergs.us>wrote:

> On 2/15/10 9:43 AM, Gervase Markham wrote:
>
>> On 11/02/10 19:01, Fr?d?ric Buclin wrote:
>>
>>> IMO, an additional bug status doesn't fix anything. You move the problem
>>> from UNCO/NEW to NEW/READY.
>>>
>>
>> Except that you can't file bugs as READY.
>>
>> And there is a distinction between "yes, this is definitely a problem"
>> (->  NEW) and "this bug report is ready to be fixed" (->  READY).
>>
>
> This gets into b.m.o-specific workflow, but neither of those states
> represents what I'm really interested in as module owner. What I want to
> know is "have I or my peers looked at this bug, assigned it a
> priority/owner, and commented setting expectations"? There are many bugs
> which have good testcases and are "ready to be fixed" which I have not
> prioritized... in fact many of the bugs filed in the XPCOM component *come
> with patches*, and I still would like to triage them.
>
> --BDS
>
>
>
> _______________________________________________
> 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=$MSGRCPT>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20100217/1bc18f44/attachment.html>

From ahdevans at gmail.com  Wed Feb 17 22:18:04 2010
From: ahdevans at gmail.com (Aaron Evans)
Date: Wed, 17 Feb 2010 14:18:04 -0800
Subject: Free Bugzilla T-Shirts for Bugzilla Contributors!
In-Reply-To: <4B7B992B.8000304@bugzilla.org>
References: <4B7B8FAA.5030906@bugzilla.org> <4B7B992B.8000304@bugzilla.org>
Message-ID: <36fce4891002171418q1e80c51ese1d8a2979f5b889f@mail.gmail.com>

I guess I'd better get to work on testing, because I want a T-Shirt!

On Tue, Feb 16, 2010 at 11:22 PM, Max Kanat-Alexander
<mkanat at bugzilla.org>wrote:

> On 02/16/2010 10:41 PM, Max Kanat-Alexander wrote:
> >       If you would like a t-shirt, just send me your name and address by
> > direct email,
>
>         Oh, and apparently we also need your phone number! I guess that
> FedEx
> uses it to contact you if they can't deliver your package, or something.
>
>        -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=ahdevans at gmail.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20100217/77ce3e02/attachment.html>

From szabgab at gmail.com  Thu Feb 18 03:54:35 2010
From: szabgab at gmail.com (Gabor Szabo)
Date: Thu, 18 Feb 2010 05:54:35 +0200
Subject: =?windows-1252?Q?Failing_is_not_an_option=85?=
Message-ID: <d8a74af11002171954t79e40025ha1e86962b448d1db@mail.gmail.com>

I just saw this blog entry http://blog.kuhn-kt.de/?p=308
comparing RT and OTRS.

I wonder if you see Bugzilla the same market as those two?

Is there a competitor analysis for Bugzilla somewhere on the Bugzilla
home page or wiki?


If I am already writing let me share with you the reasons why did I
pick Trac and not Bugzilla as the bug tracking system of Padre:

1) Trac looks great and simple on the default
     The search of Bugzilla is just way too complex for me as a beginner.
     As a first step I'd just like to list all the bugs filed (latest first)
     or maybe even all the activities (latest first)
     (What is called Timeline in Trac)
2) Default searches
    actually I think "list all the bugs I filed" was not one of them
even though that's an important one.
3) Out of the box SVN integration showing the svn commits along the tickets
4) Integrated wiki that could be used as our home page till the
project has the time to create a proper web site with easy linking to
commits and tickets
5) Nice way to connect bugs and SVN commits in the display. (r123 in
bug reports autolinking to revisions 123 and #76 in commits
autolinking to ticket 76)

The biggest downsides of Trac (that I found out later) is that I could
not setup a properly working spam filter and I cannot require the
users to register with an e-mail address and then confirm it. So I had
to turn off registration

regards
   Gabor


From mkanat at bugzilla.org  Thu Feb 18 04:52:58 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Wed, 17 Feb 2010 20:52:58 -0800
Subject: Failing is not an =?UTF-8?B?b3B0aW9u4oCm?=
In-Reply-To: <d8a74af11002171954t79e40025ha1e86962b448d1db@mail.gmail.com>
References: <d8a74af11002171954t79e40025ha1e86962b448d1db@mail.gmail.com>
Message-ID: <4B7CC7AA.6000707@bugzilla.org>

On 02/17/2010 07:54 PM, Gabor Szabo wrote:
> I just saw this blog entry http://blog.kuhn-kt.de/?p=308
> comparing RT and OTRS.
> 
> I wonder if you see Bugzilla the same market as those two?

	No, I don't, at least. RT and OTRS are support ticket systems,
primarily, and Bugzilla is a bug-tracking system. Sometimes people use
RT or OTRS to track bugs, and sometimes people use Bugzilla to track
tickets. It has to do with what people want in their environment, but
generally I wouldn't say that we're in competition with helpdesk systems.

> Is there a competitor analysis for Bugzilla somewhere on the Bugzilla
> home page or wiki?

	Not on any Bugzilla pages, no. There are some comparisons around the
Internet. I don't have anything against other bug-trackers, personally,
but I think we could present an objective comparison of certain systems
on the Wiki, if we wanted to.

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


From lajjr at yahoo.com  Thu Feb 18 06:55:15 2010
From: lajjr at yahoo.com (Leo Jackson)
Date: Wed, 17 Feb 2010 22:55:15 -0800 (PST)
Subject: Some Review Help
In-Reply-To: <4F91EB003F5C784084736E717AB5AFCA1A0275A793@mail02.higherone.com>
Message-ID: <53951.68187.qm@web84307.mail.re1.yahoo.com>

Eric,

I will any code special you need to get checked??

Regards,
Leo Jackson 

--- On Wed, 2/17/10, Eric Black <eblack at higherone.com> wrote:

> From: Eric Black <eblack at higherone.com>
> Subject: Re: Some Review Help
> To: "developers at bugzilla.org" <developers at bugzilla.org>
> Date: Wednesday, February 17, 2010, 11:28 AM
> 
> >? ? ? ???Hey Developers.
> Does anybody want to help out with some code reviews?
> > You don't have to be an official reviewer to test a
> patch or to provide
> > some comments on the code.
> 
> I don't mind helping out with this, although I don't really
> feel qualified, so if I post irrelevant
> info/questions/suggestions it would be to get more familiar
> with the code standards. Let me know if you or anyone would
> like me to focus on something in particular.
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=lajjr at yahoo.com>
> 


From bbaetz at gmail.com  Thu Feb 18 12:42:54 2010
From: bbaetz at gmail.com (Bradley Baetz)
Date: Thu, 18 Feb 2010 23:42:54 +1100
Subject: Free Bugzilla T-Shirts for Bugzilla Contributors!
In-Reply-To: <4B7B8FAA.5030906@bugzilla.org>
References: <4B7B8FAA.5030906@bugzilla.org>
Message-ID: <99435f5b1002180442n213d4daax31adecf2e2b95622@mail.gmail.com>

Hi - thanks for the offer.

Bradley Baetz
c/o Keith Baetz
605/35 Spring St
Bondi Junction NSW 2022
AUSTRALIA
Phone: +61-416-080841

Size: Large

Thanks,

Bradley

On Wed, Feb 17, 2010 at 5:41 PM, Max Kanat-Alexander
<mkanat at bugzilla.org> wrote:
> ? ? ? ?Hey Bugzilla-ers. I don't know if you noticed, but the old Mozilla
> Store (where you could buy Bugzilla t-shirts) closed down a few months
> back, and it never re-opened. Well, I don't know if it's ever going to
> re-open, but Mozilla apparently got all the stock from it, and one of
> the things they did was they gave me all the Bugzilla t-shirts from the
> store.
>
> ? ? ? ?I happen to have been given all of the Bugzilla t-shirts that were in
> the Mozilla Store, to do whatever I want with. :-) As it turns out, what
> I want to do with them is to give them away to you! :-)
>
> ? ? ? ?According to the box, I have about 80 shirts in the following sizes:
>
> ? ? ? ?* LARGE: 32
> ? ? ? ?* MEDIUM: 34
> ? ? ? ?* SMALL 27
>
> ? ? ? ?These are all the Bugzilla shirts that are left in the world, pretty
> much, and if you've ever contributed to Bugzilla (code, documentation,
> UI/web design, translation, promotion, or a fair bit of support), I want
> to ship one of them to you for free, no matter where you are in the
> world. Mozilla has been kind enough to offer to foot the bill for shipping.
>
> ? ? ? ?If you would like a t-shirt, just send me your name and address by
> direct email, and what size of shirt you'd like. If you've already
> bought a shirt for yourself in the past, you're still eligible for a
> free shirt if you'd like one to give to somebody else (or just to have
> as a spare). If you think that I might not know or remember your
> contributions, then just remind me what they were, briefly, in your email.
>
> ? ? ? ?The shirts are American Apparel, so they run a little small, but
> they're very comfortable.
>
> ? ? ? ?As they say, "offer good while supplies last". :-) So if you were
> thinking about contributing to Bugzilla, and you want a t-shirt, now's
> the time! :-)
>
> ? ? ? ?-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=bbaetz at gmail.com>
>


From eblack at higherone.com  Thu Feb 18 14:25:58 2010
From: eblack at higherone.com (Eric Black)
Date: Thu, 18 Feb 2010 09:25:58 -0500
Subject: Some Review Help
In-Reply-To: <53951.68187.qm@web84307.mail.re1.yahoo.com>
References: <4F91EB003F5C784084736E717AB5AFCA1A0275A793@mail02.higherone.com>,<53951.68187.qm@web84307.mail.re1.yahoo.com>
Message-ID: <4F91EB003F5C784084736E717AB5AFCA1A0275A797@mail02.higherone.com>

> From: developers-owner at bugzilla.org [developers-owner at bugzilla.org] On Behalf Of Leo Jackson [lajjr at yahoo.com]
> Sent: Thursday, February 18, 2010 1:55 AM
> To: developers at bugzilla.org
> Subject: Re: Some Review Help
> 
> Eric,
> 
> I will any code special you need to get checked??
> 
> Regards,
> Leo Jackson

Hi Leo,

The original message was sent by Max. He suggested working on any of the bugs listed in his email below:


        Hey Developers. Does anybody want to help out with some code reviews?
You don't have to be an official reviewer to test a patch or to provide
some comments on the code.

        Here are some patches of mine that are in need of review:

        Make First/Last/Next/Prev work with multiple bug lists:
        https://bugzilla.mozilla.org/show_bug.cgi?id=24896

        Change the default workflow:
        https://bugzilla.mozilla.org/show_bug.cgi?id=486292

        Make validation happen with JS when filing a bug:
        https://bugzilla.mozilla.org/show_bug.cgi?id=490767

        Add a Calendar widget to the Deadline field (really simple patch):
        https://bugzilla.mozilla.org/show_bug.cgi?id=329637

        Refactor Bugzilla's language-choosing code:
        https://bugzilla.mozilla.org/show_bug.cgi?id=545235

        -Max



From szabgab at gmail.com  Fri Feb 19 06:07:00 2010
From: szabgab at gmail.com (Gabor Szabo)
Date: Fri, 19 Feb 2010 08:07:00 +0200
Subject: Strawberry Perl Professional for Windows - Alpha 1
Message-ID: <d8a74af11002182207u6cb796f0s9d84433c185d7b20@mail.gmail.com>

Hi,

in connection to our recent discussion regarding Bugzilla on windows,
I just noticed the announcement from Curtis Jewell about the first
Alpha release of Strawberry Perl Professional for Windows:

http://csjewell.dreamwidth.org/8928.html

I think it would be a good time to see if Bugzilla could be installed
on this using the cpan client for installing the CPAN prereqs and talk
to Curtis what else might need to be added in order to make the
Bugzilla installation smooth.


Gabor
http://szabgab.com/


From mkanat at bugzilla.org  Fri Feb 19 23:47:06 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Fri, 19 Feb 2010 15:47:06 -0800
Subject: Strawberry Perl Professional for Windows - Alpha 1
In-Reply-To: <d8a74af11002182207u6cb796f0s9d84433c185d7b20@mail.gmail.com>
References: <d8a74af11002182207u6cb796f0s9d84433c185d7b20@mail.gmail.com>
Message-ID: <4B7F22FA.3020604@bugzilla.org>

On 02/18/2010 10:07 PM, Gabor Szabo wrote:
> I think it would be a good time to see if Bugzilla could be installed
> on this using the cpan client for installing the CPAN prereqs and talk
> to Curtis what else might need to be added in order to make the
> Bugzilla installation smooth.

	Hey! So, indeed, Bugzilla can be installed on it. Here's the bug for
some changes to the installation procedure to recommend using
install-module.pl during checksetup, if we're on Strawberry, instead of
recommending ppm:

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

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


From mkanat at bugzilla.org  Sat Feb 20 02:06:32 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Fri, 19 Feb 2010 18:06:32 -0800
Subject: Wiki Updated With Bzr Instructions
Message-ID: <4B7F43A8.2010207@bugzilla.org>

	I've updated the Wiki with Bzr instructions, for developers. The
central point is:

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

	Specifically, the updated/new pages are:

	https://wiki.mozilla.org/Bugzilla:Bzr
	https://wiki.mozilla.org/Bugzilla:Patches
	https://wiki.mozilla.org/Bugzilla:Committing_Patches

	They each contain a little more information than I originally posted to
the list.

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


From sbodomerle at gmail.com  Sat Feb 20 11:54:38 2010
From: sbodomerle at gmail.com (Sandor Bodo-Merle)
Date: Sat, 20 Feb 2010 12:54:38 +0100
Subject: Wiki Updated With Bzr Instructions
In-Reply-To: <4B7F43A8.2010207@bugzilla.org>
References: <4B7F43A8.2010207@bugzilla.org>
Message-ID: <a07057191002200354s6264d24ct78a905b9cbfebeb1@mail.gmail.com>

On the https://wiki.mozilla.org/Bugzilla:Bzr page the example for
Checking Out Over HTTP
still has the bzr:// URL
Most probably a typo.

br
Sanyi


On Sat, Feb 20, 2010 at 3:06 AM, Max Kanat-Alexander <mkanat at bugzilla.org>wrote:

>        I've updated the Wiki with Bzr instructions, for developers. The
> central point is:
>
>        http://wiki.mozilla.org/Bugzilla:Developers
>
>        Specifically, the updated/new pages are:
>
>        https://wiki.mozilla.org/Bugzilla:Bzr
>        https://wiki.mozilla.org/Bugzilla:Patches
>        https://wiki.mozilla.org/Bugzilla:Committing_Patches
>
>        They each contain a little more information than I originally posted
> to
> the list.
>
>        -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=sbodomerle at gmail.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20100220/2303a225/attachment.html>

From erickfjordan at gmail.com  Sat Feb 20 15:31:07 2010
From: erickfjordan at gmail.com (Erick Jordan)
Date: Sat, 20 Feb 2010 07:31:07 -0800
Subject: Free Bugzilla T-Shirts for Bugzilla Contributors!
In-Reply-To: <99435f5b1002180442n213d4daax31adecf2e2b95622@mail.gmail.com>
References: <4B7B8FAA.5030906@bugzilla.org>
	 <99435f5b1002180442n213d4daax31adecf2e2b95622@mail.gmail.com>
Message-ID: <40130fb71002200731o18f5d7abx3733e7dbfe7ad567@mail.gmail.com>

Yes, I'd like a free t-shirt too.

Erick Jordan
34 Via Gatillo
Rancho Santa Margarita, CA 92688
US
Phone: 949-858-3219

Size: Large

Thank you!

On Thu, Feb 18, 2010 at 4:42 AM, Bradley Baetz <bbaetz at gmail.com> wrote:

> Hi - thanks for the offer.
>
> Bradley Baetz
> c/o Keith Baetz
> 605/35 Spring St
> Bondi Junction NSW 2022
> AUSTRALIA
> Phone: +61-416-080841
>
> Size: Large
>
> Thanks,
>
> Bradley
>
> On Wed, Feb 17, 2010 at 5:41 PM, Max Kanat-Alexander
> <mkanat at bugzilla.org> wrote:
> >        Hey Bugzilla-ers. I don't know if you noticed, but the old Mozilla
> > Store (where you could buy Bugzilla t-shirts) closed down a few months
> > back, and it never re-opened. Well, I don't know if it's ever going to
> > re-open, but Mozilla apparently got all the stock from it, and one of
> > the things they did was they gave me all the Bugzilla t-shirts from the
> > store.
> >
> >        I happen to have been given all of the Bugzilla t-shirts that were
> in
> > the Mozilla Store, to do whatever I want with. :-) As it turns out, what
> > I want to do with them is to give them away to you! :-)
> >
> >        According to the box, I have about 80 shirts in the following
> sizes:
> >
> >        * LARGE: 32
> >        * MEDIUM: 34
> >        * SMALL 27
> >
> >        These are all the Bugzilla shirts that are left in the world,
> pretty
> > much, and if you've ever contributed to Bugzilla (code, documentation,
> > UI/web design, translation, promotion, or a fair bit of support), I want
> > to ship one of them to you for free, no matter where you are in the
> > world. Mozilla has been kind enough to offer to foot the bill for
> shipping.
> >
> >        If you would like a t-shirt, just send me your name and address by
> > direct email, and what size of shirt you'd like. If you've already
> > bought a shirt for yourself in the past, you're still eligible for a
> > free shirt if you'd like one to give to somebody else (or just to have
> > as a spare). If you think that I might not know or remember your
> > contributions, then just remind me what they were, briefly, in your
> email.
> >
> >        The shirts are American Apparel, so they run a little small, but
> > they're very comfortable.
> >
> >        As they say, "offer good while supplies last". :-) So if you were
> > thinking about contributing to Bugzilla, and you want a t-shirt, now's
> > the time! :-)
> >
> >        -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=bbaetz at gmail.com>
> >
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=erickfjordan at gmail.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20100220/e8b4cad8/attachment.html>

From mkanat at bugzilla.org  Sat Feb 20 19:09:57 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Sat, 20 Feb 2010 11:09:57 -0800
Subject: Wiki Updated With Bzr Instructions
In-Reply-To: <a07057191002200354s6264d24ct78a905b9cbfebeb1@mail.gmail.com>
References: <4B7F43A8.2010207@bugzilla.org> <a07057191002200354s6264d24ct78a905b9cbfebeb1@mail.gmail.com>
Message-ID: <4B803385.9050905@bugzilla.org>

On 02/20/2010 03:54 AM, Sandor Bodo-Merle wrote:
> On the https://wiki.mozilla.org/Bugzilla:Bzr page the example for
> 
>     Checking Out Over HTTP
> 
> still has the bzr:// URL
> Most probably a typo.

	Oh, thank you! Yes, that was a typo. I've fixed it now.

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


From mkanat at bugzilla.org  Sat Feb 20 20:31:04 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Sat, 20 Feb 2010 12:31:04 -0800
Subject: Want to Help With Bugzilla's Oracle Support?
Message-ID: <4B804688.5060202@bugzilla.org>

	Hey folks! Does anybody have some Oracle expertise and want to help us
out with Bugzilla's Oracle support? Right now there's only one person
working on Oracle support, and he's not always available. In particular,
the following bug needs to be fixed or Bugzilla 3.6 won't have Oracle
support:

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

	For anything else, just search for bugs with "Oracle" in the summary,
and you'll see other stuff that needs help.

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


From jochen.wiedmann at gmail.com  Sat Feb 20 21:13:42 2010
From: jochen.wiedmann at gmail.com (Jochen Wiedmann)
Date: Sat, 20 Feb 2010 22:13:42 +0100
Subject: Want to Help With Bugzilla's Oracle Support?
In-Reply-To: <4B804688.5060202@bugzilla.org>
References: <4B804688.5060202@bugzilla.org>
Message-ID: <e75283b11002201313m22005317k81a61910fc5bbae9@mail.gmail.com>

If you can provide me a database dump and a copy of the Bugzilla
installation, so that I can reproduce the problem without too much
efforts, then I should be able to help.

Jochen


On Sat, Feb 20, 2010 at 9:31 PM, Max Kanat-Alexander
<mkanat at bugzilla.org> wrote:
> ? ? ? ?Hey folks! Does anybody have some Oracle expertise and want to help us
> out with Bugzilla's Oracle support? Right now there's only one person
> working on Oracle support, and he's not always available. In particular,
> the following bug needs to be fixed or Bugzilla 3.6 won't have Oracle
> support:
>
> ? ? ? ?https://bugzilla.mozilla.org/show_bug.cgi?id=541553
>
> ? ? ? ?For anything else, just search for bugs with "Oracle" in the summary,
> and you'll see other stuff that needs help.
>
> ? ? ? ?-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=jochen.wiedmann at gmail.com>
>



-- 
Germanys national anthem is the most boring in the world - how telling!


From mkanat at bugzilla.org  Sun Feb 21 03:12:44 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Sat, 20 Feb 2010 19:12:44 -0800
Subject: Want to Help With Bugzilla's Oracle Support?
In-Reply-To: <e75283b11002201313m22005317k81a61910fc5bbae9@mail.gmail.com>
References: <4B804688.5060202@bugzilla.org> <e75283b11002201313m22005317k81a61910fc5bbae9@mail.gmail.com>
Message-ID: <4B80A4AC.1030802@bugzilla.org>

On 02/20/2010 01:13 PM, Jochen Wiedmann wrote:
> If you can provide me a database dump and a copy of the Bugzilla
> installation, so that I can reproduce the problem without too much
> efforts, then I should be able to help.

	I believe that it should be reproducible simply by installing 3.4 and
then attempting to update to the current 3.6 code using checksetup.pl.

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


From jmdesp at free.fr  Sun Feb 21 16:15:32 2010
From: jmdesp at free.fr (Jean-Marc Desperrier)
Date: Sun, 21 Feb 2010 17:15:32 +0100
Subject: post FOSDEM
In-Reply-To: <mailman.4937.1266413756.4112.dev-apps-bugzilla@lists.mozilla.org>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>	<WcidnWPFppxcZe7WnZ2dnUVZ_gZi4p2d@mozilla.org>	<97784.55432.qm@web114014.mail.gq1.yahoo.com>	<mailman.4542.1265926982.4112.dev-apps-bugzilla@lists.mozilla.org>	<ArudnbvuMs7M2-jWnZ2dnUVZ_oKdnZ2d@mozilla.org>	<mailman.4630.1266006694.4112.dev-apps-bugzilla@lists.mozilla.org>	<1sydnVG4rMrQROfWnZ2dnUVZ_jFi4p2d@mozilla.org>	<mailman.4879.1266355684.4112.dev-apps-bugzilla@lists.mozilla.org>	<0PSdnWOtuePPcObWnZ2dnUVZ_vmdnZ2d@mozilla.org>
	<mailman.4937.1266413756.4112.dev-apps-bugzilla@lists.mozilla.org>
Message-ID: <L7adnX6AB6m_wRzWnZ2dnUVZ_jFi4p2d@mozilla.org>

On 17/02/2010 14:34, Fr?d?ric Buclin wrote:
> Le 17. 02. 10 14:21, Jean-Marc Desperrier a ?crit :
>> - I hope it's now, as much as possible, *obvious* that ImageMagick only
>> brings a really minor functionality
>
> ImageMagick has been removed from Bugzilla 3.6. I moved it into an
> extension.

That's a good thing !
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla


From jochen.wiedmann at gmail.com  Mon Feb 22 07:08:01 2010
From: jochen.wiedmann at gmail.com (Jochen Wiedmann)
Date: Mon, 22 Feb 2010 08:08:01 +0100
Subject: Want to Help With Bugzilla's Oracle Support?
In-Reply-To: <4B80A4AC.1030802@bugzilla.org>
References: <4B804688.5060202@bugzilla.org>
	 <e75283b11002201313m22005317k81a61910fc5bbae9@mail.gmail.com>
	 <4B80A4AC.1030802@bugzilla.org>
Message-ID: <e75283b11002212308m3032bb2eqc0c3913f5d9f35ac@mail.gmail.com>

I was able to find a workaround, which you'll find in the bug. Feel
free to contact me for any followup questions.

Jochen


On Sun, Feb 21, 2010 at 4:12 AM, Max Kanat-Alexander
<mkanat at bugzilla.org> wrote:
> On 02/20/2010 01:13 PM, Jochen Wiedmann wrote:
>> If you can provide me a database dump and a copy of the Bugzilla
>> installation, so that I can reproduce the problem without too much
>> efforts, then I should be able to help.
>
> ? ? ? ?I believe that it should be reproducible simply by installing 3.4 and
> then attempting to update to the current 3.6 code using checksetup.pl.
>
> ? ? ? ?-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=jochen.wiedmann at gmail.com>
>



-- 
Germanys national anthem is the most boring in the world - how telling!


From gerv at mozilla.org  Mon Feb 22 17:14:25 2010
From: gerv at mozilla.org (Gervase Markham)
Date: Mon, 22 Feb 2010 17:14:25 +0000
Subject: post FOSDEM
In-Reply-To: <mailman.4880.1266355789.4112.dev-apps-bugzilla@lists.mozilla.org>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>	<WcidnWPFppxcZe7WnZ2dnUVZ_gZi4p2d@mozilla.org>	<97784.55432.qm@web114014.mail.gq1.yahoo.com>	<mailman.4542.1265926982.4112.dev-apps-bugzilla@lists.mozilla.org>	<ArudnbvuMs7M2-jWnZ2dnUVZ_oKdnZ2d@mozilla.org>	<mailman.4630.1266006694.4112.dev-apps-bugzilla@lists.mozilla.org>	<1sydnVG4rMrQROfWnZ2dnUVZ_jFi4p2d@mozilla.org>	<mailman.4859.1266344502.4112.dev-apps-bugzilla@lists.mozilla.org>	<prGdndGiP7o-cufWnZ2dnUVZ_t2dnZ2d@mozilla.org>
	<mailman.4880.1266355789.4112.dev-apps-bugzilla@lists.mozilla.org>
Message-ID: <CvSdnSpJYpLuJh_WnZ2dnUVZ_rOdnZ2d@mozilla.org>

On 16/02/10 21:29, Gabor Szabo wrote:
> On Ubuntu I can just type
> 
> $ sudo aptitude install bugzilla3
> 
> but I have not tried it yet so I am not sure what will be the end result.

As Max says, the price of that is that Debian rearrange our stuff to
conform to their file system standard, and things have a tendency to
break. :-(

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  Mon Feb 22 17:17:46 2010
From: gerv at mozilla.org (Gervase Markham)
Date: Mon, 22 Feb 2010 17:17:46 +0000
Subject: post FOSDEM
In-Reply-To: <1sydnVG4rMrQROfWnZ2dnUVZ_jFi4p2d@mozilla.org>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>	<WcidnWPFppxcZe7WnZ2dnUVZ_gZi4p2d@mozilla.org>	<97784.55432.qm@web114014.mail.gq1.yahoo.com>	<mailman.4542.1265926982.4112.dev-apps-bugzilla@lists.mozilla.org>	<ArudnbvuMs7M2-jWnZ2dnUVZ_oKdnZ2d@mozilla.org>
	<mailman.4630.1266006694.4112.dev-apps-bugzilla@lists.mozilla.org>
	<1sydnVG4rMrQROfWnZ2dnUVZ_jFi4p2d@mozilla.org>
Message-ID: <_KmdnRLtM6umIR_WnZ2dnUVZ_vKdnZ2d@mozilla.org>

On 16/02/10 17:43, Jean-Marc Desperrier wrote:
> At my company, that's one of the reason we're not using it. Not the only
> reason, there's also the fact it had from start the image of being ugly
> looking and complex

This is another complexity penalty we pay, even before people get it
installed and try to use it. Having 20 or more fields on the default
show_bug page scares people away.

> (and based on perl I have to say, but if all the
> rest had been right ...) , but when the person in charge of having a go
> at all the tools tried to install it, failed, spent more time trying,
> failed again, then ended the report with "I couldn't install it", when
> he had had success installing most of the other tools in minutes, it was
> the final nail in the coffin.

It doesn't help that our install documentation is hard to follow due to
layout limitations caused by our technical solution, and that's hard to
fix because the technical solution also makes refactoring it hard. (And
because it's compiled, we review it like code rather than like
documentation - or, at least, we used to last time I tried to refactor it.)

All of these little bumps in the road add up. If people can just install
trac using a single command, many people will just be happy with that.

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  Mon Feb 22 17:19:54 2010
From: gerv at mozilla.org (Gervase Markham)
Date: Mon, 22 Feb 2010 17:19:54 +0000
Subject: post FOSDEM
In-Reply-To: <mailman.4890.1266359508.4112.dev-apps-bugzilla@lists.mozilla.org>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>		<97784.55432.qm@web114014.mail.gq1.yahoo.com>		<mailman.4542.1265926982.4112.dev-apps-bugzilla@lists.mozilla.org>		<ArudnbvuMs7M2-jWnZ2dnUVZ_oKdnZ2d@mozilla.org>		<mailman.4630.1266006694.4112.dev-apps-bugzilla@lists.mozilla.org>		<1sydnVG4rMrQROfWnZ2dnUVZ_jFi4p2d@mozilla.org>		<mailman.4859.1266344502.4112.dev-apps-bugzilla@lists.mozilla.org>		<prGdndGiP7o-cufWnZ2dnUVZ_t2dnZ2d@mozilla.org>		<d8a74af11002161329q17f77a00nc7aa8acfd6d44017@mail.gmail.com>		<4B7B0F6A.70405@bugzilla.org>	<a3717d971002161337j777f9ee7t43e0020cdcd6f482@mail.gmail.com>
	<mailman.4890.1266359508.4112.dev-apps-bugzilla@lists.mozilla.org>
Message-ID: <_KmdnQ3tM6smIR_WnZ2dnUVZ_vJi4p2d@mozilla.org>

On 16/02/10 22:31, Max Kanat-Alexander wrote:
> 	You can't--it depends on the version of MySQL in use. (It might also
> depend on the Windows version in use? I'm not sure. I suspect 32-bit vs.
> 64-bit would be an issue, but Perl is already compiled differently for
> those, so that's not a problem.) If we bundled MySQL also, we could
> build a DBD::mysql. But then if people wanted to use PostgreSQL, they'd
> have a hard time.

If people want to choose particular database software, then this sort of
bundle isn't for them anyway.

I suspect at least 90%, and maybe even 95% of people installing Bugzilla
don't give a stuff which database it uses, they just want it to work. I
myself certainly didn't care when I started hacking on Bugzilla that it
used MySQL as opposed to PostgreSQL. I still use MySQL out of habit, but
it doesn't matter to me.

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  Mon Feb 22 17:23:33 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Mon, 22 Feb 2010 09:23:33 -0800
Subject: Want to Help With Bugzilla's Oracle Support?
In-Reply-To: <e75283b11002212308m3032bb2eqc0c3913f5d9f35ac@mail.gmail.com>
References: <4B804688.5060202@bugzilla.org>	 <e75283b11002201313m22005317k81a61910fc5bbae9@mail.gmail.com>	 <4B80A4AC.1030802@bugzilla.org> <e75283b11002212308m3032bb2eqc0c3913f5d9f35ac@mail.gmail.com>
Message-ID: <4B82BD95.104@bugzilla.org>

On 02/21/2010 11:08 PM, Jochen Wiedmann wrote:
> I was able to find a workaround, which you'll find in the bug. Feel
> free to contact me for any followup questions.

	Cool, thanks! :-) Your workaround looks like something we actually
ought to be doing anyway....

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


From gerv at mozilla.org  Mon Feb 22 17:21:53 2010
From: gerv at mozilla.org (Gervase Markham)
Date: Mon, 22 Feb 2010 17:21:53 +0000
Subject: post FOSDEM
In-Reply-To: <mailman.4906.1266367120.4112.dev-apps-bugzilla@lists.mozilla.org>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>	<1sydnVG4rMrQROfWnZ2dnUVZ_jFi4p2d@mozilla.org>	<mailman.4859.1266344502.4112.dev-apps-bugzilla@lists.mozilla.org>	<prGdndGiP7o-cufWnZ2dnUVZ_t2dnZ2d@mozilla.org>	<d8a74af11002161329q17f77a00nc7aa8acfd6d44017@mail.gmail.com>	<4B7B0F6A.70405@bugzilla.org>	<a3717d971002161337j777f9ee7t43e0020cdcd6f482@mail.gmail.com>	<4B7B1CB4.4020005@bugzilla.org>	<a3717d971002161446w4dedfd05hf89a68aafffac978@mail.gmail.com>	<4B7B270B.8060809@bugzilla.org>
	<mailman.4906.1266367120.4112.dev-apps-bugzilla@lists.mozilla.org>
Message-ID: <_KmdnQztM6uuIB_WnZ2dnUVZ_vJi4p2d@mozilla.org>

On 17/02/10 00:38, Dan Wierenga wrote:
> Hi Max (noticably, not to the list),

There wasn't anything in this email that wasn't list-appropriate. It was
fine to post it (even if it was accidental).

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  Mon Feb 22 17:33:08 2010
From: gerv at mozilla.org (Gervase Markham)
Date: Mon, 22 Feb 2010 17:33:08 +0000
Subject: Fwd: REST APIs, and Tags
In-Reply-To: <mailman.4806.1266272500.4112.dev-apps-bugzilla@lists.mozilla.org>
References: <lJ-dnTp28csNE5PWnZ2dnUVZ_hmdnZ2d@mozilla.org>	<yZidndn6Ks90U-_WnZ2dnUVZ_i2dnZ2d@mozilla.org>	<mailman.4482.1265904519.4112.dev-apps-bugzilla@lists.mozilla.org>	<DLOdnbzZ_Y171unWnZ2dnUVZ_hudnZ2d@mozilla.org>	<mailman.4512.1265914114.4112.dev-apps-bugzilla@lists.mozilla.org>	<XfGdnavAld2fxuTWnZ2dnUVZ_qudnZ2d@mozilla.org>
	<mailman.4806.1266272500.4112.dev-apps-bugzilla@lists.mozilla.org>
Message-ID: <9eidnc1QFf1IIh_WnZ2dnUVZ_r2dnZ2d@mozilla.org>

On 15/02/10 22:21, Max Kanat-Alexander wrote:
> 	Yeah, I was thinking about that this morning, actually. I think that
> you could display a few extra items (maybe even using template hooks) on
> bmo for users who don't have editbugs.

We could try that - although of course, adding stuff is increasing
complexity. I'd like to try out a step-by-step wizard-style interface,
but I don't have time to write it :-(

> 	You know, having discussed this problem for years and years now with
> the Mozilla team, I think that ultimately the problem is a human problem
> that can't totally be solved with a tool. So I think that in the end,
> it's going to be having more humans do the right thing that solves the
> problem that Mozilla is experiencing, because for the most part, the
> tool is capable of doing *most* of what's necessary to solve the problem
> already, and it's just not being done because there is a lack of
> manpower (or organization, re: components?) to do it.

Mozilla does have a pretty large QA organization - including many paid
staff. It's not like they've hired no-one. And they are always trying to
find more people, and we are working on ways to do that. But it's never
enough.

>>> 	Hmm. I do agree that there are a lot of cases where certain data just
>>> isn't very important, particularly Platform/OS. Translating those into
>>> tags might be reasonable, but I worry that then we'd shift the burden of
>>> setting them properly *entirely* onto developers instead of how it is
>>> now, where it's just *mostly* on developers (or the fields are ignored).
>>
>> How would that be significantly worse? At least the responsibility is
>> clear in the new world.
> 
> 	When you have hundreds of thousands of bugs, having 10% of the work
> done for you is far better than having 0% of the work done for you.

Except that I suggest that you don't actually have 10% of the work done
for you. Because you have to check that 10% of the work anyway, and fix
it where it's wrong. And there's the increased uncertainty of not
knowing if the fields were set by someone competent or auto-set by the
reporter. IOW, putting it 100% in the hands of one group removes
coordination cost.

>> Quite :-) Here is the problem Mozilla has been struggling with for
>> years. We started with keywords, then moved to flags, and have now moved
>> to custom fields. None are ideal. What we really need is proper branch
>> support - although (and see my comments in that bug) there's a danger
>> that you are going to implement it and it won't be suitable either!
> 
> 	I suspect that it will be suitable. I've actually had the exact same
> feature proposed by two separate clients as necessary to solve their
> problem, and I've seen the UI mockups and it will work.

The two Mozilla people who commented on the bug agreed with each other
that it would be a "disaster"[0], and the design, while it has been
clarified, hasn't changed significantly since, nor (as far as I know)
has further requirements input been sought from them or other groups at
Mozilla.

This is what I meant when I wrote
https://bugzilla.mozilla.org/show_bug.cgi?id=55970#c40 . How am I to
interpret your confidence that "it will work", combined with their
statements that it will not, apart from as "you aren't listening"? I
don't think you're not listening with malicious intent, but how else am
I supposed to reconcile those two facts? That's a genuine question.

Gerv

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=55970#c32
_______________________________________________
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  Mon Feb 22 17:35:41 2010
From: gerv at mozilla.org (Gervase Markham)
Date: Mon, 22 Feb 2010 17:35:41 +0000
Subject: Fwd: REST APIs, and Tags
In-Reply-To: <mailman.4795.1266260614.4112.dev-apps-bugzilla@lists.mozilla.org>
References: <lJ-dnTp28csNE5PWnZ2dnUVZ_hmdnZ2d@mozilla.org>	<yZidndn6Ks90U-_WnZ2dnUVZ_i2dnZ2d@mozilla.org>	<mailman.4482.1265904519.4112.dev-apps-bugzilla@lists.mozilla.org>	<DLOdnbzZ_Y171unWnZ2dnUVZ_hudnZ2d@mozilla.org>	<mailman.4514.1265914983.4112.dev-apps-bugzilla@lists.mozilla.org>	<8PadncL6B6wxwOTWnZ2dnUVZ_qSdnZ2d@mozilla.org>
	<mailman.4795.1266260614.4112.dev-apps-bugzilla@lists.mozilla.org>
Message-ID: <9eidncxQFf3zXR_WnZ2dnUVZ_r1i4p2d@mozilla.org>

On 15/02/10 19:02, Fr?d?ric Buclin wrote:
> You like to be out-of-topic. This doesn't even worth a reply from me.

It was a serious question. The answer is "because it would be
complicated and ugly", right? Then why can't we apply the same logic to
the current UI? If we can make it simpler, we should do so. The install
thread further down has turned up at least one person who looked at the
default Bugzilla UI and got scared by the complexity. I'm sure there are
more we don't hear about.

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  Mon Feb 22 17:39:21 2010
From: gerv at mozilla.org (Gervase Markham)
Date: Mon, 22 Feb 2010 17:39:21 +0000
Subject: Failing is not an =?UTF-8?B?b3B0aW9u4oCm?=
In-Reply-To: <mailman.5016.1266465304.4112.dev-apps-bugzilla@lists.mozilla.org>
References: <mailman.5016.1266465304.4112.dev-apps-bugzilla@lists.mozilla.org>
Message-ID: <jtWdnZyulpDXXB_WnZ2dnUVZ_tednZ2d@mozilla.org>

On 18/02/10 03:54, Gabor Szabo wrote:
> I just saw this blog entry http://blog.kuhn-kt.de/?p=308
> comparing RT and OTRS.
> 
> I wonder if you see Bugzilla the same market as those two?

I've never used OTRS, but I don't see us in the same market as RT.

> 2) Default searches
>     actually I think "list all the bugs I filed" was not one of them
> even though that's an important one.

That's a good idea. We currently have a single, special, default saved
search called (unhelpfully and unclearly) "My Bugs". It would be better
to have some non-special ones which were populated by default, with
things like "Filed By Me", "Assigned To Me" and so on.

> 3) Out of the box SVN integration showing the svn commits along the tickets

Hmm. Is there an intermediate interface here we could write to which
would allow pluggable SCM backends?

> 4) Integrated wiki that could be used as our home page till the
> project has the time to create a proper web site with easy linking to
> commits and tickets

Yeah... I'm not sure we are ever going to have that.

> 5) Nice way to connect bugs and SVN commits in the display. (r123 in
> bug reports autolinking to revisions 123 and #76 in commits
> autolinking to ticket 76)

It would be great if there was a GUI way to expand the autolinker -
define a regexp, then a URL with a %s in it or something.

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  Mon Feb 22 18:17:40 2010
From: gerv at mozilla.org (Gervase Markham)
Date: Mon, 22 Feb 2010 18:17:40 +0000
Subject: Fwd: REST APIs, and Tags
In-Reply-To: <9eidnc1QFf1IIh_WnZ2dnUVZ_r2dnZ2d@mozilla.org>
References: <lJ-dnTp28csNE5PWnZ2dnUVZ_hmdnZ2d@mozilla.org>	<yZidndn6Ks90U-_WnZ2dnUVZ_i2dnZ2d@mozilla.org>	<mailman.4482.1265904519.4112.dev-apps-bugzilla@lists.mozilla.org>	<DLOdnbzZ_Y171unWnZ2dnUVZ_hudnZ2d@mozilla.org>	<mailman.4512.1265914114.4112.dev-apps-bugzilla@lists.mozilla.org>	<XfGdnavAld2fxuTWnZ2dnUVZ_qudnZ2d@mozilla.org>
	<mailman.4806.1266272500.4112.dev-apps-bugzilla@lists.mozilla.org>
	<9eidnc1QFf1IIh_WnZ2dnUVZ_r2dnZ2d@mozilla.org>
Message-ID: <IYqdnTWAkrLYVx_WnZ2dnUVZ_j5i4p2d@mozilla.org>

On 22/02/10 17:33, Gervase Markham wrote:
> This is what I meant when I wrote
> https://bugzilla.mozilla.org/show_bug.cgi?id=55970#c40 . How am I to
> interpret your confidence that "it will work", combined with their
> statements that it will not, apart from as "you aren't listening"? I
> don't think you're not listening with malicious intent, but how else am
> I supposed to reconcile those two facts? That's a genuine question.

I should add... I stand ready to help make this conversation between
Mozilla and Bugzilla happen.

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  Mon Feb 22 18:38:31 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Mon, 22 Feb 2010 10:38:31 -0800
Subject: Companies That Contributed To 3.6?
Message-ID: <4B82CF27.803@bugzilla.org>

	Hey folks. Were any of your contributions explicitly supported by a
company that hired you to contribute to upstream Bugzilla? I ask because
we like to credit those sorts of contributions (paying people to work on
Bugzilla) in the release notes, and I'm working on the release notes now.

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


From ghendricks at novell.com  Mon Feb 22 19:07:28 2010
From: ghendricks at novell.com (Gregary Hendricks)
Date: Mon, 22 Feb 2010 12:07:28 -0700
Subject: Companies That Contributed To 3.6?
Message-ID: <4B827380020000D20006D2D6@soto.provo.novell.com>

On Mon, 2010-02-22 at 10:38 -0800, Max Kanat-Alexander wrote:
> 	Hey folks. Were any of your contributions explicitly supported by a
> company that hired you to contribute to upstream Bugzilla? I ask because
> we like to credit those sorts of contributions (paying people to work on
> Bugzilla) in the release notes, and I'm working on the release notes now.

I suppose that Novell still sponsors the work I do on Bugzilla. They
certainly have in the past releases. Might be nice to mention them. :)

I don't know off the top of my head which bug numbers I have worked on
that are going into this release though.

++Greg



From guy.pyrzak at gmail.com  Mon Feb 22 20:25:42 2010
From: guy.pyrzak at gmail.com (Guy Pyrzak)
Date: Mon, 22 Feb 2010 12:25:42 -0800
Subject: Fwd: REST APIs, and Tags
In-Reply-To: <9eidncxQFf3zXR_WnZ2dnUVZ_r1i4p2d@mozilla.org>
References: <lJ-dnTp28csNE5PWnZ2dnUVZ_hmdnZ2d@mozilla.org>
	 <yZidndn6Ks90U-_WnZ2dnUVZ_i2dnZ2d@mozilla.org>
	 <mailman.4482.1265904519.4112.dev-apps-bugzilla@lists.mozilla.org>
	 <DLOdnbzZ_Y171unWnZ2dnUVZ_hudnZ2d@mozilla.org>
	 <mailman.4514.1265914983.4112.dev-apps-bugzilla@lists.mozilla.org>
	 <8PadncL6B6wxwOTWnZ2dnUVZ_qSdnZ2d@mozilla.org>
	 <mailman.4795.1266260614.4112.dev-apps-bugzilla@lists.mozilla.org>
	 <9eidncxQFf3zXR_WnZ2dnUVZ_r1i4p2d@mozilla.org>
Message-ID: <df4dec6f1002221225n76c22202r23b0eb58cec79a75@mail.gmail.com>

On Mon, Feb 22, 2010 at 9:35 AM, Gervase Markham <gerv at mozilla.org> wrote:

> On 15/02/10 19:02, Fr?d?ric Buclin wrote:
> > You like to be out-of-topic. This doesn't even worth a reply from me.
>
> It was a serious question. The answer is "because it would be
> complicated and ugly", right? Then why can't we apply the same logic to
> the current UI? If we can make it simpler, we should do so. The install
> thread further down has turned up at least one person who looked at the
> default Bugzilla UI and got scared by the complexity. I'm sure there are
> more we don't hear about.
>
> Gerv,

I think all of us agree the UI is too complex as it stands and could
use improvement. Bug we've also done lots of small improvements. However,
we've found time and time again it's hard to find...

1. People willing to work on the UI.
2. Mozilla folks who are supportive of simplification of the UI
3. Designers willing to post constructive ideas about how to improve the
complex parts of the UI

I think any of these three things would be appreciated. I've posted on my
blog how we plan to simplify the advanced search page. The admin side is
VERY scary looking but I personally (as do many other bugzilla developers)
think the users UI should be simplified first so we've been focusing on the
edit, search and homepage UIs.

That being said, if ANYONE wants to post some mocks of ideas on how to
simplify the UI for the admin I'd be happy to look at them and consider
implementing them myself to make sure they get in there. The problem is many
people who post UI ideas are only thinking about how they use the tool
(which isn't a bad thing but that's why we usually don't
just implement their ideas directly) not how new users AND extreme experts
would use the tool which is what makes designing for Bugzilla challenging. I
myself am guilty of doing this and have slowly learned the right way to
approach doing these sorts of designs.

Anyway, when it comes to the UI needing usability improvement you're not
going to get any disagreements but instead you're going to get one clear
message.

"Give us mocks, give us people willing work collaboratively on improving
things. Give us people willing to think through the problems not just say
'but i like this one more' "

I've worked with the Mozilla folks about UI improvements here is the first
post that has been made a while ago :
http://www.azarask.in/blog/post/improving-bugzilla-people-bugs-search-and-planning/

And there have been at least 3 other talks with them, many of which focused
on making it easier for end users to change the bugzilla skin and add more
fancy webservices (which your restful service should help a lot with)

The problem is of course, we need more UI people to step up and contribute.
If you find or know people who want to do so, send them my way. I am
watching ALL UI bugs and LpSolit and MKanat  often request me to review UI
changes even if I'm not the one to review the perl etc.

Bugzilla moves slowly, no question, but when you see how few active
contributors there are (i took like a year and half long hiatus) you quickly
realize why. But we've been trying and we've been trying to invite others to
contribute. There isn't a large usability community in open source in
general and many that do exist are paid to do that by some company (most of
mozilla's design team are), i could explain why but basically it comes down
to designing a usable and pretty UI takes a LOT more work than writing a
feature and requires you to be in a different head space.

Anyway, if you want to continue saying "Bugzilla is ugly/unusable", feel
free, everyone else does.  But if you want to contribute to fixing the
problem, grab a copy of your favorite image editing software and start
drawing up how you think Bugzilla should work, post some blogs to
planet.mozilla, get some feed back, do it again until you start hearing
positive feedback. Then after you're done with all of that fun, file some
bugs :D

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

From gerv at mozilla.org  Mon Feb 22 21:04:42 2010
From: gerv at mozilla.org (Gervase Markham)
Date: Mon, 22 Feb 2010 21:04:42 +0000
Subject: Mozilla in the Google Summer of Code 2010
Message-ID: <4B82F16A.20808@mozilla.org>

[Please respect the Followup-To header, although questions about the
process should probably come straight to me.]

The Google Summer of Code is running again this year[0]. :-) This is an
opportunity for students to be paid by Google to work on open source
software, mentored by community members. Selected free software projects
are asked to provide a list of ideas that students can work on. Last
year, Mozilla had ten slots, from all across the project.

So, Mozilla people, please visit the Brainstorming page at:

https://wiki.mozilla.org/Community:SummerOfCode10:Brainstorming

and, after having read and carefully considered How To Make Good
Suggestions, put down ideas for Summer of Code projects. Ideas where you
are willing to mentor, or where you have found someone who is, are much
more likely to make it to the Approved Ideas page.

Mentoring is not a massive commitment, and may help to get a new person
involved in your area of your project, reducing your workload in the
long run. So it's well worth doing :-)

Applications for mentoring organizations open on March 8th, and if we
are going to get chosen, we need to have a decent list of potential
projects available by then so Google can see we are serious. So please
do consider whether you have a suitable idea to submit.

Thanks!

Gerv

[0]
http://groups.google.com/group/google-summer-of-code-discuss/browse_thread/thread/d839c0b02ac15b3f

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


From dwierenga at gmail.com  Mon Feb 22 22:31:31 2010
From: dwierenga at gmail.com (Dan Wierenga)
Date: Mon, 22 Feb 2010 14:31:31 -0800
Subject: =?windows-1252?Q?Re=3A_Failing_is_not_an_option=85?=
In-Reply-To: <jtWdnZyulpDXXB_WnZ2dnUVZ_tednZ2d@mozilla.org>
References: <mailman.5016.1266465304.4112.dev-apps-bugzilla@lists.mozilla.org>
	 <jtWdnZyulpDXXB_WnZ2dnUVZ_tednZ2d@mozilla.org>
Message-ID: <a3717d971002221431h68cc0968mcabc1858ad33f1e8@mail.gmail.com>

On Mon, Feb 22, 2010 at 9:39 AM, Gervase Markham <gerv at mozilla.org> wrote:

> It would be great if there was a GUI way to expand the autolinker -
> define a regexp, then a URL with a %s in it or something.
>
> Gerv

Has there ever been any thought to adding "BB code" [0] parsing to
comments? It would alleviate the need for admin-defined autolinker
regexps, and allow people to emphasize parts of their comment.  I
doubt the full spectrum of BB code is needed (spoilers, 18-point
fonts, colors, etc. all seem malapropos) but the ability to link
something or make it bold would seem to have a good use-case.

A quick search of BMO didn't turn up anything about BB code support.
There does seem to be a couple of CPAN modules to handle the parsing
(though I've no idea of their utility).

[0] http://en.wikipedia.org/wiki/Bb_code


From mkanat at bugzilla.org  Mon Feb 22 22:48:43 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Mon, 22 Feb 2010 14:48:43 -0800
Subject: Markdown (WAS Re: Failing is not an =?UTF-8?B?b3B0aW9u4oCmKQ==?=
In-Reply-To: <a3717d971002221431h68cc0968mcabc1858ad33f1e8@mail.gmail.com>
References: <mailman.5016.1266465304.4112.dev-apps-bugzilla@lists.mozilla.org>	 <jtWdnZyulpDXXB_WnZ2dnUVZ_tednZ2d@mozilla.org> <a3717d971002221431h68cc0968mcabc1858ad33f1e8@mail.gmail.com>
Message-ID: <4B8309CB.3000103@bugzilla.org>

On 02/22/2010 02:31 PM, Dan Wierenga wrote:
> Has there ever been any thought to adding "BB code" [0] parsing to
> comments? 

	I was actually just thinking yesterday about writing an extension to
Bugzilla that would allow using Markdown for comments. (That's what
Stack Overflow uses, basically, if you've used Stack Overflow.)

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


From mkanat at bugzilla.org  Tue Feb 23 00:23:00 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Mon, 22 Feb 2010 16:23:00 -0800
Subject: trunk supports Strawberry Perl
Message-ID: <4B831FE4.5000502@bugzilla.org>

	Hey folks. So, I just checked in a patch that allows using Bugzilla
(trunk) with the current Strawberry Perl Professional Alpha on Windows.
Feel free to try it out and let me know if you run into any problems.

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


From mkanat at bugzilla.org  Tue Feb 23 00:31:11 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Mon, 22 Feb 2010 16:31:11 -0800
Subject: Companies That Contributed To 3.6?
In-Reply-To: <4B827380020000D20006D2D6@soto.provo.novell.com>
References: <4B827380020000D20006D2D6@soto.provo.novell.com>
Message-ID: <4B8321CF.9070006@bugzilla.org>

On 02/22/2010 11:07 AM, Gregary Hendricks wrote:
> I suppose that Novell still sponsors the work I do on Bugzilla. They
> certainly have in the past releases. Might be nice to mention them. :)

	Okay, added Novell.

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


From byron at glob.com.au  Tue Feb 23 01:17:18 2010
From: byron at glob.com.au (Byron Jones)
Date: Tue, 23 Feb 2010 09:17:18 +0800
Subject: post FOSDEM
In-Reply-To: <_KmdnQ3tM6smIR_WnZ2dnUVZ_vJi4p2d@mozilla.org>
References: <mailman.4369.1265808879.4112.dev-apps-bugzilla@lists.mozilla.org>		<97784.55432.qm@web114014.mail.gq1.yahoo.com>		<mailman.4542.1265926982.4112.dev-apps-bugzilla@lists.mozilla.org>		<ArudnbvuMs7M2-jWnZ2dnUVZ_oKdnZ2d@mozilla.org>		<mailman.4630.1266006694.4112.dev-apps-bugzilla@lists.mozilla.org>		<1sydnVG4rMrQROfWnZ2dnUVZ_jFi4p2d@mozilla.org>		<mailman.4859.1266344502.4112.dev-apps-bugzilla@lists.mozilla.org>		<prGdndGiP7o-cufWnZ2dnUVZ_t2dnZ2d@mozilla.org>		<d8a74af11002161329q17f77a00nc7aa8acfd6d44017@mail.gmail.com>		<4B7B0F6A.70405@bugzilla.org>	<a3717d971002161337j777f9ee7t43e0020cdcd6f482@mail.gmail.com> <mailman.4890.1266359508.4112.dev-apps-bugzilla@lists.mozilla.org> <_KmdnQ3tM6smIR_WnZ2dnUVZ_vJi4p2d@mozilla.org>
Message-ID: <870e6fdeec0eb15355f3ff57986db4fe@localhost>

> I suspect at least 90%, and maybe even 95% of people installing Bugzilla
> don't give a stuff which database it uses, they just want it to work. I
> myself certainly didn't care when I started hacking on Bugzilla that it
> used MySQL as opposed to PostgreSQL. I still use MySQL out of habit, but
> it doesn't matter to me.

i agree that most users won't care about the bundled database, however
there will be a significant impact on support.

as we are currently most familiar with mysql, it would make sense to try
getting mysql as the bundled database first.



-- 

byron.jones :: http://glob.com.au


From szabgab at gmail.com  Tue Feb 23 03:35:34 2010
From: szabgab at gmail.com (Gabor Szabo)
Date: Tue, 23 Feb 2010 05:35:34 +0200
Subject: trunk supports Strawberry Perl
In-Reply-To: <4B831FE4.5000502@bugzilla.org>
References: <4B831FE4.5000502@bugzilla.org>
Message-ID: <d8a74af11002221935y4bc286deuc3260ca89e45d22f@mail.gmail.com>

On Tue, Feb 23, 2010 at 2:23 AM, Max Kanat-Alexander
<mkanat at bugzilla.org> wrote:
> ? ? ? ?Hey folks. So, I just checked in a patch that allows using Bugzilla
> (trunk) with the current Strawberry Perl Professional Alpha on Windows.
> Feel free to try it out and let me know if you run into any problems.
>
> ? ? ? ?-Max

nice but IMHO an important step is missing here.

A blog entry about this as we discussed earlier. I know it is extra
work that you are still not paid to do but I think it will pay off
well.

regards
   Gabor


From mkanat at bugzilla.org  Tue Feb 23 06:24:14 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Mon, 22 Feb 2010 22:24:14 -0800
Subject: trunk supports Strawberry Perl
In-Reply-To: <d8a74af11002221935y4bc286deuc3260ca89e45d22f@mail.gmail.com>
References: <4B831FE4.5000502@bugzilla.org> <d8a74af11002221935y4bc286deuc3260ca89e45d22f@mail.gmail.com>
Message-ID: <4B83748E.1070500@bugzilla.org>

On 02/22/2010 07:35 PM, Gabor Szabo wrote:
> A blog entry about this as we discussed earlier. I know it is extra
> work that you are still not paid to do but I think it will pay off
> well.

	Hey Gabor. A blog about it would probably be more appropriate when I'm
more sure that it's ready for public consumption, given our current
standard blog avenues.

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


From guy.pyrzak at gmail.com  Tue Feb 23 18:37:29 2010
From: guy.pyrzak at gmail.com (Guy Pyrzak)
Date: Tue, 23 Feb 2010 10:37:29 -0800
Subject: Fwd: REST APIs, and Tags
In-Reply-To: <4B83E11B.9050905@mozilla.org>
References: <lJ-dnTp28csNE5PWnZ2dnUVZ_hmdnZ2d@mozilla.org>
	 <yZidndn6Ks90U-_WnZ2dnUVZ_i2dnZ2d@mozilla.org>
	 <mailman.4482.1265904519.4112.dev-apps-bugzilla@lists.mozilla.org>
	 <DLOdnbzZ_Y171unWnZ2dnUVZ_hudnZ2d@mozilla.org>
	 <mailman.4514.1265914983.4112.dev-apps-bugzilla@lists.mozilla.org>
	 <8PadncL6B6wxwOTWnZ2dnUVZ_qSdnZ2d@mozilla.org>
	 <mailman.4795.1266260614.4112.dev-apps-bugzilla@lists.mozilla.org>
	 <9eidncxQFf3zXR_WnZ2dnUVZ_r1i4p2d@mozilla.org>
	 <mailman.5337.1266870351.4112.dev-apps-bugzilla@lists.mozilla.org>
	 <4B83E11B.9050905@mozilla.org>
Message-ID: <df4dec6f1002231037h617c12dbje9d7becebeb33d98@mail.gmail.com>

On Tue, Feb 23, 2010 at 6:07 AM, Gervase Markham <gerv at mozilla.org> wrote:

> On 22/02/10 20:25, Guy Pyrzak wrote:
> > 1. People willing to work on the UI.
>
> I agree that this is tricky, but if we had a big pile of excellent
> designs and no-one to implement them, we'd be in a much better place
> than we are now.


I am happy to implement actual UIs, getting "ready to build" UI's is
somewhat difficult though. So here is a challenge to you: You get the
designs in a ready to build state, I'll get the developers. I say it that
way b/c I'm happy to implement the UI's myself if I have to, I'll call it my
Bugzilla vacation.


> > 2. Mozilla folks who are supportive of simplification of the UI
>
> That's an incredible thing to say. It's Mozilla folk who scream most
> loudly at me that Bugzilla is overly-complex.
>
See most of my UI changes. However, to be fair they might be the few angry
folks and 99% of the community might like it but just stays silent. I'm not
as familiar as some of the veterans at ignoring the "trolls" and I usually
try to listen to everyone who is willing to give feedback and find solutions
that fit as many issues as possible.


> Who have you heard complaining about UI simplification ideas, and where?
>

I really dislike naming names, but see my latest blog post about the new
search UI.


>
> > 3. Designers willing to post constructive ideas about how to improve the
> > complex parts of the UI
>
> I have recently posted proposals for:
>
> - Tagging (which would allow us to remove some hard-coded fields and
> increase flexibility, thereby simplifying the UI)
>
> - Generic bug relationships (which would allow us to remove
> depends/blocked and See Also and increase flexibility, thereby
> simplifying the UI)
>

Tagging is something we have talked about for a while in terms of UI. I
think the disagreement is how Tags would actually work and how they would
fix EVERYTHING or just some things. I thought jjclark was working on a
generalized bug relationship, but again, i see that as a how the backend
works not the UI/experience.

I think being able to remove ANY of the Bugzilla fields from the UI is a
good idea and I think there is a bug to make many of the built in fields
into custom fields so that they can be removed. Not sure what the status of
that bug is. On that note i think stuff like OS/Platform etc could also be
made into custom fields so they could be removed if that was a desire. By
moving the built in fields into custom fields we'd also get showing and
hiding of fields based on other fields so that some components could use
them and others could chose to not use them.  I chalk this up to Bugzilla
moving slowly, not to Bugzilla being unwilling to listen to feedback.


> and both of these suggestions have received negative feedback from
> prominent members of the Bugzilla community.
>
> There have also been shedloads of posts from Mozilla community members
> about UI design and simplification, including some actual practical
> implementations (things like Jesse's TidyBug).
>
>
> http://www.azarask.in/blog/post/improving-bugzilla-people-bugs-search-and-planning/
> http://jboriss.wordpress.com/2009/04/22/my-bugzilla-redesign-2%C2%A2/
> http://blog.fligtar.com/2009/04/23/fancypants-a-new-bugzilla-skin/
> http://www.squarefree.com/2009/04/20/getting-bugs-done/

I've been involved with all of these guys and talked to them at length and
filed bugs, made jetpacks, worked on mocks based on these discussions. But 4
posts does not equal an active design community. Please read through these
and you'll see that I've either implemented or discussed many of the
suggestions in one way or another (aza's will be the next thing i work on by
trying to add more "human" elements via gravatar). Fligtar's UI/Tidybug I
have turned into a jetpack and Mkanat has a similar UI that tries to follow
a similar concept of getting rid of lots of the fields.

Jesse's GBD stuff is great! It's a great idea for BMO and probably lots of
other places. It can technically be implemented via the current
infrastructure so all we really need is mocks and specifics and we could
start playing around with it either as an extension or core Bugzilla, but I
personally need more than just a matrix to implement this UI. If the
BMO/MoCo/MoFo folks want this lets move on it and get some mocks put
together.

Jborris's hompeage UI is actually available on BMO right now (you filed the
bug to make it the default) and as far as I know it is awaiting 1 bug fix to
make it the default UI on BMO. I've been hesitant to fix it b/c in its
current state I think it is SUPER ugly, and needs more TLC but maybe I
shouldn't wait anymore.

Aza's stuff will take longer but just last night I was talking to Mkanat
about an extension to add a more human element to Bugzilla via a
gravatars extension. His concepts are defiantly a direction I'd like to see
Bugzilla or some Uber Extensions go, but I think you would agree many of
them are big features that are much more than just UI.

And on a side topic, Gerv, we should post Aza's ideas for some of the summer
of code work. Should I do it or do you mind?

> The problem is many
> > people who post UI ideas are only thinking about how they use the tool
> > (which isn't a bad thing but that's why we usually don't
> > just implement their ideas directly) not how new users AND extreme
> experts
> > would use the tool which is what makes designing for Bugzilla
> challenging. I
> > myself am guilty of doing this and have slowly learned the right way to
> > approach doing these sorts of designs.
>
> I don't think the professional UI people represented in the above blog
> posts could be accused of that. (And I, while not being paid to do UI
> design, have read extensively on the subject, redesigned several sites,
> and count it among one of my primary interests.)
>

The guys posted above have done a FANTASTIC job of posting ideas, I
encourage others and these guys to post more! I know the Bugzilla community
(and me personally) have listened and tried to implement and experiment with
their ideas. I would hope that the same way you defend their 4 posts as a
"shedloads" of ideas, you would recognize the work we're doing on the
Bugzilla community side to implement the suggestions. Yes, we're slow and if
that's the accusation then it's a very fair one. But accusing us of not
caring about UI or not trying to fix it is not.

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

From after.fallout at gmail.com  Tue Feb 23 19:18:21 2010
From: after.fallout at gmail.com (Bill Barry)
Date: Tue, 23 Feb 2010 12:18:21 -0700
Subject: Failing is not an =?windows-1252?Q?option=85?=
In-Reply-To: <jtWdnZyulpDXXB_WnZ2dnUVZ_tednZ2d@mozilla.org>
References: <mailman.5016.1266465304.4112.dev-apps-bugzilla@lists.mozilla.org>
	<jtWdnZyulpDXXB_WnZ2dnUVZ_tednZ2d@mozilla.org>
Message-ID: <4B8429FD.4030907@gmail.com>

Gervase Markham wrote:
>
>   
>> 3) Out of the box SVN integration showing the svn commits along the tickets
>>     
>
> Hmm. Is there an intermediate interface here we could write to which
> would allow pluggable SCM backends?
>   
The incoming email interface makes for a very simple way to write 
anything to bugs from outside systems.  Perhaps some better 
documentation there (maybe a whole page/chapter in the book on it) would 
be a good start (perhaps shipping with contrib hooks for some popular 
systems: git, hg, bzr, cvs and svn)? As for other potential integration 
points:

One could use custom fields to create some sort of bisection table 
(known good revisions, known bad revisions); integration here could 
consist of links to the revisions in some type of viewvc related app 
(maybe it could simply be a custom field that works like the 
blocks/dependson fields but has a configurable hyperlink generator string).

The patch reader related functionality (I don't remember what it is 
called anymore, I havent used/looked at it in years) should have the 
ability to allow the user to click a button which would write the file 
to the server somewhere and then call a hook script with the filename. 
Example contrib scripts could then be written which could commit patches 
to various popular VCSes.

None of these really need any kind of VCS abstraction interface. 
Integration with any VCS popular enough that someone cares to write some 
integration hooks and example documentation should be as simple as 
merely enabling the hooks (by following the documentation). What I have 
found harder than writing these hooks (I wrote email_in based hooks for 
both svn and hg) is figuring out how to go about getting them into 
bugzilla's contrib (or somewhere else that people might notice them and 
that the howto could be easily followed) folder and what to do about 
documenting some sort of howto in a place where it might actually be 
noticed by a potential user.

The point is, I don't think this is so much a problem with the available 
interfaces as it is with communicating the knowledge of how to use them 
and what others have already done.
>   
>> 4) Integrated wiki that could be used as our home page till the
>> project has the time to create a proper web site with easy linking to
>> commits and tickets
>>     
>
> Yeah... I'm not sure we are ever going to have that.
>   
(more to the OP here than to Gerv, I am just being lazy here with only 
intending to reply once instead of individually to both mails)
Personally I cannot stand the new home page with the 3 giant buttons, 
but I see its point and concede that I have yet to come up with anything 
better to do here (or a desire to write a patch). Perhaps with the 
[relatively] new extension related functionality someone could write a 
simplistic wiki extension to replace the home page. I doubt it is on the 
radar of any of the core devs for several reasons:
1. it is a reasonably large undertaking for a project as mature as 
Bugzilla (new code = new bugs = more support needed)
2. it isn't part of the project goals (heard many times now: Bugzilla is 
a bug tracker, not an overall project management application)
3. it simply isn't an itch that anybody has taken the time to scratch
>   
>> 5) Nice way to connect bugs and SVN commits in the display. (r123 in
>> bug reports autolinking to revisions 123 and #76 in commits
>> autolinking to ticket 76)
>>     
>
> It would be great if there was a GUI way to expand the autolinker -
> define a regexp, then a URL with a %s in it or something.
>   
Oooh, is there a bug for this that I can vote on?

As far as linking inside SVN to bugzilla, that is up to your SVN related 
applications. TortoiseSvn does support this at least via folder properties:
http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-bugtracker.html

_______________________________________________
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  Tue Feb 23 21:04:11 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Tue, 23 Feb 2010 13:04:11 -0800
Subject: Free Bugzilla T-Shirts for Bugzilla Contributors!
In-Reply-To: <4B7B8FAA.5030906@bugzilla.org>
References: <4B7B8FAA.5030906@bugzilla.org>
Message-ID: <4B8442CB.4020802@bugzilla.org>

	Hey everybody. If you sent me your info, just wanted to let you know
that we're in the process of printing labels and hopefully I'll be
shipping out shirts by next week.

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


From mkanat at bugzilla.org  Tue Feb 23 22:42:16 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Tue, 23 Feb 2010 14:42:16 -0800
Subject: 3.6 Release Notes, Want to Help Review?
Message-ID: <4B8459C8.1090106@bugzilla.org>

	Hey folks. So, I've posted a Release Notes patch for 3.6rc1 (which is
probably going to happen surprisingly soon), and I wanted to let
everybody look over it in case you had any feedback:

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

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


From gerv at mozilla.org  Fri Feb 26 12:48:18 2010
From: gerv at mozilla.org (Gervase Markham)
Date: Fri, 26 Feb 2010 12:48:18 +0000
Subject: Bugzilla: Philosophy
In-Reply-To: <4B79420C.8030109@mozilla.org>
References: <mailman.4490.1265908384.4112.dev-apps-bugzilla@lists.mozilla.org>
	<4B79420C.8030109@mozilla.org>
Message-ID: <4aidnTEl7ICPXhrWnZ2dnUVZ_u5i4p2d@mozilla.org>

On 15/02/10 12:46, Gervase Markham wrote:
> But that leads fairly neatly onto a discussion of what they _should_ be
> :-) Here are my suggestions:
> 
> https://wiki.mozilla.org/Bugzilla_Talk:Philosophy

No-one have any comments? :-(

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  Fri Feb 26 13:03:43 2010
From: gerv at mozilla.org (Gervase Markham)
Date: Fri, 26 Feb 2010 13:03:43 +0000
Subject: Fwd: REST APIs, and Tags
In-Reply-To: <mailman.5459.1266950281.4112.dev-apps-bugzilla@lists.mozilla.org>
References: <lJ-dnTp28csNE5PWnZ2dnUVZ_hmdnZ2d@mozilla.org>	<yZidndn6Ks90U-_WnZ2dnUVZ_i2dnZ2d@mozilla.org>	<mailman.4482.1265904519.4112.dev-apps-bugzilla@lists.mozilla.org>	<DLOdnbzZ_Y171unWnZ2dnUVZ_hudnZ2d@mozilla.org>	<mailman.4514.1265914983.4112.dev-apps-bugzilla@lists.mozilla.org>	<8PadncL6B6wxwOTWnZ2dnUVZ_qSdnZ2d@mozilla.org>	<mailman.4795.1266260614.4112.dev-apps-bugzilla@lists.mozilla.org>	<9eidncxQFf3zXR_WnZ2dnUVZ_r1i4p2d@mozilla.org>	<mailman.5337.1266870351.4112.dev-apps-bugzilla@lists.mozilla.org>	<4B83E11B.9050905@mozilla.org>
	<mailman.5459.1266950281.4112.dev-apps-bugzilla@lists.mozilla.org>
Message-ID: <86ydnRt5mYktWxrWnZ2dnUVZ_jGdnZ2d@mozilla.org>

On 23/02/10 18:37, Guy Pyrzak wrote:
> I am happy to implement actual UIs, getting "ready to build" UI's is
> somewhat difficult though. So here is a challenge to you: You get the
> designs in a ready to build state, I'll get the developers. I say it that
> way b/c I'm happy to implement the UI's myself if I have to, I'll call it my
> Bugzilla vacation.

:-) That's really cool, and an amazing offer.

Why don't we start with the query UI, given that this is what you are
thinking about at the moment? I will blog and we can generate some noise
about the process, and try and get some Mozilla UI folk involved. Sound
good?

(Let's assume for the moment that a "complete" search UI allowing
someone to specify the values of all individual fields is still
something we want, even if one day in the future it's not the primary
search UI.)

> See most of my UI changes. However, to be fair they might be the few angry
> folks and 99% of the community might like it but just stays silent. I'm not
> as familiar as some of the veterans at ignoring the "trolls" and I usually
> try to listen to everyone who is willing to give feedback and find solutions
> that fit as many issues as possible.

If you want help in distinguishing troll from "person whose UI input
should be valued" I can certainly help with that :-)

>> Who have you heard complaining about UI simplification ideas, and where?
> 
> I really dislike naming names, but see my latest blog post about the new
> search UI.

/me checks.
http://guy-pyrzak.blogspot.com/2010/02/update-to-advanced-search-ui.html

The input there seems broadly positive. Smokey's comments were negative,
but you seem to have accepted they are good. I don't see anyone
screaming "No, stop, I love the current UI, don't change a thing!" :-)

> Tagging is something we have talked about for a while in terms of UI. I
> think the disagreement is how Tags would actually work and how they would
> fix EVERYTHING or just some things.

Well, let's implement them and different people can use them to fix
different levels of things.

As to how they work, we definitely need to have that discussion.

> I thought jjclark was working on a
> generalized bug relationship, but again, i see that as a how the backend
> works not the UI/experience.

I think the two are (unfortunately, one might say) connected. The way
HTML forms work, the UI is often a reflection of the underlying data
model. So in that case, it's best to decide the UI first, and then
design a data model which matches it.

> Aza's stuff will take longer but just last night I was talking to Mkanat
> about an extension to add a more human element to Bugzilla via a
> gravatars extension. His concepts are defiantly a direction I'd like to see
> Bugzilla or some Uber Extensions go, but I think you would agree many of
> them are big features that are much more than just UI.

Also, we are currently working on a Mozilla community directory called
Mozillians; I hope that it'll have a JSON API, so Bugzilla pages can
have mouseover points for each user which will call into that and return
some info about the person.

> And on a side topic, Gerv, we should post Aza's ideas for some of the summer
> of code work. Should I do it or do you mind?

Go for it :-)

> their ideas. I would hope that the same way you defend their 4 posts as a
> "shedloads" of ideas, you would recognize the work we're doing on the
> Bugzilla community side to implement the suggestions. Yes, we're slow and if
> that's the accusation then it's a very fair one. But accusing us of not
> caring about UI or not trying to fix it is not.

It's certainly been the case that there's been a lot more activity on
this recently, and I'm very grateful you are involved.

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


From Callek at gmail.com  Sat Feb 27 03:50:06 2010
From: Callek at gmail.com (Justin Wood (Callek))
Date: Fri, 26 Feb 2010 22:50:06 -0500
Subject: Bugzilla: Philosophy
In-Reply-To: <4aidnTEl7ICPXhrWnZ2dnUVZ_u5i4p2d@mozilla.org>
References: <mailman.4490.1265908384.4112.dev-apps-bugzilla@lists.mozilla.org>
	<4B79420C.8030109@mozilla.org>
	<4aidnTEl7ICPXhrWnZ2dnUVZ_u5i4p2d@mozilla.org>
Message-ID: <kdydnQ8h3PnzCxXWnZ2dnUVZ_q6dnZ2d@mozilla.org>

On 2/26/2010 7:48 AM, Gervase Markham wrote:
> On 15/02/10 12:46, Gervase Markham wrote:
>> But that leads fairly neatly onto a discussion of what they _should_ be
>> :-) Here are my suggestions:
>>
>> https://wiki.mozilla.org/Bugzilla_Talk:Philosophy
>
> No-one have any comments? :-(

Thank you for bubbling this, I missed it the first time (your link; not 
mkanat's)

My *only* negative comment about your proposal is in your suggestions it 
makes "Bugzilla is a bug tracker, not a project management system. " 
seem more out of place with the other listed goals.

help PEOPLE fix bugs. PEOPLE to fix bugs well usually wish to have a 
project management system of some sort. In Mozilla Project Management 
uses Bugzilla features for their ease of use, while I also *agree* it 
should NOT be a project management system this point should be felt more 
through the other goals rather than in opposition to them.

-- 
~Justin Wood (Callek)

_______________________________________________
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  Sun Feb 28 22:45:45 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Sun, 28 Feb 2010 14:45:45 -0800
Subject: Revamped Landfill Tools
Message-ID: <4B8AF219.8060300@bugzilla.org>

	Hey hey. So, the /tools/ directory on landfill (the thing that lets you
create your own installs, if you have access to it) was pretty old and
it wasn't working, in certain ways, so I re-wrote most of its code. If
you have access, you can see it now here:

	http://landfill.bugzilla.org/tools/

	(I haven't updated patches.cgi yet.) Also, it creates installs using
bzr now, instead of CVS.

	I also put up the code for the landfill tools in bzr, in case anybody
wants to contribute to them:

	http://bzr.mozilla.org/bugzilla/misc/landfill/files

	(Just file a bug and attach a patch in the bugzilla.org component if
you want to modify them, and ask me for review. Review requirements are
pretty loose, as long as the code works and doesn't look bad.)

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