From mkanat at bugzilla.org  Thu Apr  1 01:11:38 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Wed, 31 Mar 2010 18:11:38 -0700
Subject: Emails Won't Be Sent By The Template for 3.6
Message-ID: <4BB3F2CA.4070305@bugzilla.org>

	Since this could affect some extensions or customizations, I thought I
should let you know about this bug:

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

	Basically, we used to send bugmails by processing
template/en/default/bug/process/bugmail.html.tmpl, but now we just call
Bugzilla::BugMail::Send directly in the Perl code, and send its results
to the template.

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


From mattr at kde.org  Thu Apr  1 03:10:26 2010
From: mattr at kde.org (Matt Rogers)
Date: Wed, 31 Mar 2010 22:10:26 -0500
Subject: Emails Won't Be Sent By The Template for 3.6
In-Reply-To: <4BB3F2CA.4070305@bugzilla.org>
References: <4BB3F2CA.4070305@bugzilla.org>
Message-ID: <201003312210.30105.mattr@kde.org>

On Wednesday 31 March 2010 08:11:38 pm you wrote:
> 	Since this could affect some extensions or customizations, I thought I
> should let you know about this bug:
> 
> 	https://bugzilla.mozilla.org/show_bug.cgi?id=556429
> 
> 	Basically, we used to send bugmails by processing
> template/en/default/bug/process/bugmail.html.tmpl, but now we just call
> Bugzilla::BugMail::Send directly in the Perl code, and send its results
> to the template.
> 
> 	-Max

That last part doesn't make sense to me. If you're calling 
Bugzilla::BugMail::Send directly in the Perl code, how are you sending its 
results to the template?

As a bugzilla admin who may have customized this template, what impact would 
the bug really have on me? That I can't templatize the email anymore? That's 
what I would be most interested in from that point of view.

Although, the other issues mentioned in the bug aren't so nice either. :)
-- 
Matt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20100331/43df9534/attachment.sig>

From szabgab at gmail.com  Thu Apr  1 04:51:21 2010
From: szabgab at gmail.com (Gabor Szabo)
Date: Thu, 1 Apr 2010 07:51:21 +0300
Subject: Releasing Bugzilla to CPAN
In-Reply-To: <4BB3AA83.1060206@bugzilla.org>
References: <d8a74af11003210251x2ac6b581q3a3b23096d0108da@mail.gmail.com>
	 <d8a74af11003261019xff458b9xc19cfcf23c1601bd@mail.gmail.com>
	 <d8a74af11003270137g58453623wb105dbc69b71e9fc@mail.gmail.com>
	 <4BAE8952.1010607@bugzilla.org>
	 <d8a74af11003300856l72db220bsb8ab1e5574cf6f42@mail.gmail.com>
	 <4BB26C8C.5020801@bugzilla.org>
	 <t2xd8a74af11003302249ped91bb7cz1a847b8ffdd652e1@mail.gmail.com>
	 <4BB3AA83.1060206@bugzilla.org>
Message-ID: <i2wd8a74af11003312151nad574748l609068e26ecf086b@mail.gmail.com>

On Wed, Mar 31, 2010 at 11:03 PM, Max Kanat-Alexander
<mkanat at bugzilla.org> wrote:
> On 03/30/2010 10:49 PM, Gabor Szabo wrote:

>> to some web applications.
>
> ? ? ? ?I'd be interested to see which web applications are distributed on
> CPAN, and how they do it.

Let's look at Catalyst, while it is a framework and not an application.
IT installs to the system and then you run a separate script that will copy
(and generate) the necessary file in your application directory.

Kwiki

I am sure there are a few other wikis there and other applications.


>> I am not sure why bzr status would show Makefile.PL is missing
>
> ? ? ? ?Because if you delete a file that's in the repo, it will show as missing.

This did not make sense to me until I read on where you explained that
you distribute the CVS directory (and will distribute the .bzr
directory) in the tarball
but...

>
>> but I hope those
>> who are using Bugzilla straight from the repository know what they do.
>> After all,
>> if I understand correctly, they can easily update themselves to some very buggy
>> development state of the code base.
>
> ? ? ? ?No, actually, we recommend that even normal users upgrade using CVS,
> currently, which will be bzr for 3.7 and above. All the tarballs we send
> out retain the "CVS" directories currently, and will likely retain the
> ".bzr" directory (probably as a lightweight checkout) too.

... that sounds crazy.

I have not heard any application doing that, but of course that might
be just me.

I don't understand why do you recommend upgrade via CVS and why do you
distribute
the files that belong to the version control system.
I'd be glad to read the explanation though.


regards
   Gabor


From szabgab at gmail.com  Thu Apr  1 05:53:03 2010
From: szabgab at gmail.com (Gabor Szabo)
Date: Thu, 1 Apr 2010 08:53:03 +0300
Subject: Releasing Bugzilla to CPAN
In-Reply-To: <i2wd8a74af11003312151nad574748l609068e26ecf086b@mail.gmail.com>
References: <d8a74af11003210251x2ac6b581q3a3b23096d0108da@mail.gmail.com>
	 <d8a74af11003261019xff458b9xc19cfcf23c1601bd@mail.gmail.com>
	 <d8a74af11003270137g58453623wb105dbc69b71e9fc@mail.gmail.com>
	 <4BAE8952.1010607@bugzilla.org>
	 <d8a74af11003300856l72db220bsb8ab1e5574cf6f42@mail.gmail.com>
	 <4BB26C8C.5020801@bugzilla.org>
	 <t2xd8a74af11003302249ped91bb7cz1a847b8ffdd652e1@mail.gmail.com>
	 <4BB3AA83.1060206@bugzilla.org>
	 <i2wd8a74af11003312151nad574748l609068e26ecf086b@mail.gmail.com>
Message-ID: <m2ld8a74af11003312253hfe86b6d2i55fb1143cd40f44f@mail.gmail.com>

On Thu, Apr 1, 2010 at 7:51 AM, Gabor Szabo <szabgab at gmail.com> wrote:
> On Wed, Mar 31, 2010 at 11:03 PM, Max Kanat-Alexander
> <mkanat at bugzilla.org> wrote:
>> On 03/30/2010 10:49 PM, Gabor Szabo wrote:
>
>>> to some web applications.
>>
>> ? ? ? ?I'd be interested to see which web applications are distributed on
>> CPAN, and how they do it.

I even blogged about this now:
http://blogs.perl.org/users/gabor_szabo/2010/04/distributing-applications-via-cpan.html

It would be very nice if you could take your time and comment on that
blog explaining what do
*you* see missing from the CPAN toolchain in order to make it easy to
distribute Bugzialla
and install it via CPAN.

regards
   Gabor


From emmanuel.seyman at club-internet.fr  Thu Apr  1 06:08:30 2010
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Thu, 1 Apr 2010 08:08:30 +0200
Subject: Releasing Bugzilla to CPAN
In-Reply-To: <4BB3AA83.1060206@bugzilla.org>
References: <d8a74af11003210251x2ac6b581q3a3b23096d0108da@mail.gmail.com>
	<d8a74af11003261019xff458b9xc19cfcf23c1601bd@mail.gmail.com>
	<d8a74af11003270137g58453623wb105dbc69b71e9fc@mail.gmail.com>
	<4BAE8952.1010607@bugzilla.org>
	<d8a74af11003300856l72db220bsb8ab1e5574cf6f42@mail.gmail.com>
	<4BB26C8C.5020801@bugzilla.org>
	<t2xd8a74af11003302249ped91bb7cz1a847b8ffdd652e1@mail.gmail.com>
	<4BB3AA83.1060206@bugzilla.org>
Message-ID: <20100401060830.GA7514@orient.maison.lan>

* Max Kanat-Alexander [31/03/2010 22:11] :
>
> 	I'd be interested to see which web applications are distributed on
> CPAN, and how they do it.

Miril is the only one that comes to mind right now.
http://search.cpan.org/~pshangov/Miril-0.007/

Emmanuel

_______________________________________________
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  Fri Apr  2 04:19:34 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Thu, 01 Apr 2010 21:19:34 -0700
Subject: Emails Won't Be Sent By The Template for 3.6
In-Reply-To: <201003312210.30105.mattr@kde.org>
References: <4BB3F2CA.4070305@bugzilla.org> <201003312210.30105.mattr@kde.org>
Message-ID: <4BB57056.5070005@bugzilla.org>

On 03/31/2010 08:10 PM, Matt Rogers wrote:
> That last part doesn't make sense to me. If you're calling 
> Bugzilla::BugMail::Send directly in the Perl code, how are you sending its 
> results to the template?

	$vars->{'sent_bugmail'} = Bugzilla::BugMail::Send($bug_id,
$vars->{'mailrecipients'};

> As a bugzilla admin who may have customized this template, what impact would 
> the bug really have on me?  That I can't templatize the email anymore?

	I'm talking about template/en/default/bug/process/bugmail.html.tmpl,
not about template/en/default/email/newchangedmail.txt.tmpl.

	This bug is about the way that bugmail is *sent*, not about its contents.

	If you have custom code that was running the template
template/en/default/bug/process/results.html.tmpl to send bugmail, you'd
have to modify your code to send bugmail before processing that template.

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


From mkanat at bugzilla.org  Fri Apr  2 04:25:06 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Thu, 01 Apr 2010 21:25:06 -0700
Subject: Releasing Bugzilla to CPAN
In-Reply-To: <i2wd8a74af11003312151nad574748l609068e26ecf086b@mail.gmail.com>
References: <d8a74af11003210251x2ac6b581q3a3b23096d0108da@mail.gmail.com>	 <d8a74af11003261019xff458b9xc19cfcf23c1601bd@mail.gmail.com>	 <d8a74af11003270137g58453623wb105dbc69b71e9fc@mail.gmail.com>	 <4BAE8952.1010607@bugzilla.org>	 <d8a74af11003300856l72db220bsb8ab1e5574cf6f42@mail.gmail.com>	 <4BB26C8C.5020801@bugzilla.org>	 <t2xd8a74af11003302249ped91bb7cz1a847b8ffdd652e1@mail.gmail.com>	 <4BB3AA83.1060206@bugzilla.org> <i2wd8a74af11003312151nad574748l609068e26ecf086b@mail.gmail.com>
Message-ID: <4BB571A2.5010005@bugzilla.org>

On 03/31/2010 09:51 PM, Gabor Szabo wrote:
> Let's look at Catalyst, while it is a framework and not an application.
> IT installs to the system and then you run a separate script that will copy
> (and generate) the necessary file in your application directory.

	Yeah, but Catalyst, being a framework, is essentially a library, and
something that developers use, not that end users use.

>>        No, actually, we recommend that even normal users upgrade using CVS,
>> currently, which will be bzr for 3.7 and above. All the tarballs we send
>> out retain the "CVS" directories currently, and will likely retain the
>> ".bzr" directory (probably as a lightweight checkout) too.
> 
> ... that sounds crazy.

	Well, I understand how you feel about that, but sometimes when you're
new on a project, the way that the project operates might seem strange,
since you are unfamiliar with it or its userbase. The thing to do isn't
to insult the methodology of the system out of hand, but to instead
spend some time getting familiar with the system and its existing
userbase before you make decisions about what should and shouldn't be done.

> I don't understand why do you recommend upgrade via CVS and why do you
> distribute the files that belong to the version control system.

	Because many, many people customize Bugzilla, and thus the simplest
series of step-by-step instructions that are most likely to allow for
smooth point-release upgrades for everyone, regardless of their
situation, involve upgrading via CVS. CVS (and bzr) have much better
merge behavior than just "patch", and we don't even provide patches for
upgrades between major releases.

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


From mkanat at bugzilla.org  Fri Apr  2 04:37:30 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Thu, 01 Apr 2010 21:37:30 -0700
Subject: Releasing Bugzilla to CPAN
In-Reply-To: <m2ld8a74af11003312253hfe86b6d2i55fb1143cd40f44f@mail.gmail.com>
References: <d8a74af11003210251x2ac6b581q3a3b23096d0108da@mail.gmail.com>	 <d8a74af11003261019xff458b9xc19cfcf23c1601bd@mail.gmail.com>	 <d8a74af11003270137g58453623wb105dbc69b71e9fc@mail.gmail.com>	 <4BAE8952.1010607@bugzilla.org>	 <d8a74af11003300856l72db220bsb8ab1e5574cf6f42@mail.gmail.com>	 <4BB26C8C.5020801@bugzilla.org>	 <t2xd8a74af11003302249ped91bb7cz1a847b8ffdd652e1@mail.gmail.com>	 <4BB3AA83.1060206@bugzilla.org>	 <i2wd8a74af11003312151nad574748l609068e26ecf086b@mail.gmail.com> <m2ld8a74af11003312253hfe86b6d2i55fb1143cd40f44f@mail.gmail.com>
Message-ID: <4BB5748A.7000503@bugzilla.org>

On 03/31/2010 10:53 PM, Gabor Szabo wrote:
> I even blogged about this now:
> http://blogs.perl.org/users/gabor_szabo/2010/04/distributing-applications-via-cpan.html

	Hey Gabor. Thanks! I actually read your blog earlier today, even--I
have a Google Alert for the word "Bugzilla". :-)

	It looks like, from the comments, that CPAN is generally considered
pretty tough as a distribution mechanism for applications that end users
can actually use, though sometimes people do consider it somewhat worth
distributing source code via CPAN.

	The only web applications that sound like they've been successfully
distributed via CPAN are FastCGI applications, or pure mod_perl apps,
and Bugzilla is not a FastCGI application or purely a series of mod_perl
modules. It has many separate and individual .cgi files that are not
command-line-executable binaries, and it has a terrific number of static
files that must be directly accessible to the web server.

	Also, much like miyagawa mentions in the comments about Remedie and
github-growler, the target audience of Bugzilla is not Perl users, but
rather anybody who needs to do bug-tracking.

	I think that perhaps, in the future, if Bugzilla becomes a FastCGI
application, CPAN distribution would be more reasonable for end users.
But for now, I don't see a reasonable way to do it (see below for a bit
more about this).

> It would be very nice if you could take your time and comment on that
> blog explaining what do *you* see missing from the CPAN toolchain in order to make it easy to
> distribute Bugzialla and install it via CPAN.

	I don't think it's an issue of the CPAN toolchain. I can't imagine any
cross-platform automated distribution system that would properly install
Bugzilla, other than one which simply downloaded the tarball and
unzipped it into a directory. If you have some ideas about how to do
that well, then I'd be interested to hear them, but I'm not thinking of
any myself.

	Distro-specific packages are fine (at least theoretically) though,
because within one distro the package maintainers can make logical
decisions about how everything should go, based on how that distro
works. But I don't see a reasonable cross-platform distribution
mechanism other than our current "roll everything up in a tarball in a
single directory" method.

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


From szabgab at gmail.com  Fri Apr  2 08:57:47 2010
From: szabgab at gmail.com (Gabor Szabo)
Date: Fri, 2 Apr 2010 11:57:47 +0300
Subject: Releasing Bugzilla to CPAN
In-Reply-To: <4BB571A2.5010005@bugzilla.org>
References: <d8a74af11003210251x2ac6b581q3a3b23096d0108da@mail.gmail.com>
	 <d8a74af11003261019xff458b9xc19cfcf23c1601bd@mail.gmail.com>
	 <d8a74af11003270137g58453623wb105dbc69b71e9fc@mail.gmail.com>
	 <4BAE8952.1010607@bugzilla.org>
	 <d8a74af11003300856l72db220bsb8ab1e5574cf6f42@mail.gmail.com>
	 <4BB26C8C.5020801@bugzilla.org>
	 <t2xd8a74af11003302249ped91bb7cz1a847b8ffdd652e1@mail.gmail.com>
	 <4BB3AA83.1060206@bugzilla.org>
	 <i2wd8a74af11003312151nad574748l609068e26ecf086b@mail.gmail.com>
	 <4BB571A2.5010005@bugzilla.org>
Message-ID: <m2vd8a74af11004020157v67622538m2f870b30799481e3@mail.gmail.com>

On Fri, Apr 2, 2010 at 7:25 AM, Max Kanat-Alexander <mkanat at bugzilla.org> wrote:
> On 03/31/2010 09:51 PM, Gabor Szabo wrote:
>
>>> ? ? ? ?No, actually, we recommend that even normal users upgrade using CVS,
>>> currently, which will be bzr for 3.7 and above. All the tarballs we send
>>> out retain the "CVS" directories currently, and will likely retain the
>>> ".bzr" directory (probably as a lightweight checkout) too.
>>
>> ... that sounds crazy.
>
> ? ? ? ?Well, I understand how you feel about that, but sometimes when you're
> new on a project, the way that the project operates might seem strange,
> since you are unfamiliar with it or its userbase. The thing to do isn't
> to insult the methodology of the system out of hand, but to instead
> spend some time getting familiar with the system and its existing
> userbase before you make decisions about what should and shouldn't be done.

Sorry for that, I did not want to insult you or the methodology, I was
just very surprised as I have not heard any open source project doing that.
I did work on a corporate project doing that and they suffered a lot
from the close binding to CVS.

>
>> I don't understand why do you recommend upgrade via CVS and why do you
>> distribute the files that belong to the version control system.
>
> ? ? ? ?Because many, many people customize Bugzilla, and thus the simplest
> series of step-by-step instructions that are most likely to allow for
> smooth point-release upgrades for everyone, regardless of their
> situation, involve upgrading via CVS. CVS (and bzr) have much better
> merge behavior than just "patch", and we don't even provide patches for
> upgrades between major releases.

I wonder if Bugzilla is so different from every other project or that
maybe the other
projects have not considered such fine tuned (or smooth?) upgrade mechanism.
In the latter case I'd really like to read some explanation - maybe you already
wrote about this elsewhere ? - what are the problems you encounter that you
solve that other projects don't yet solve and how could these projects
solve the
same issue?

What I am saying is that projects can learn from each other. If you
feel that Bugzilla
provides some very good distribution and upgrade mechanism that other project
don't provide then help those project by explaining your way of working.

regards
   Gabor


From mattr at kde.org  Sun Apr  4 03:28:53 2010
From: mattr at kde.org (Matt Rogers)
Date: Sat, 03 Apr 2010 22:28:53 -0500
Subject: Emails Won't Be Sent By The Template for 3.6
In-Reply-To: <4BB57056.5070005@bugzilla.org>
References: <4BB3F2CA.4070305@bugzilla.org> <201003312210.30105.mattr@kde.org>
 <4BB57056.5070005@bugzilla.org>
Message-ID: <201004032228.53410.mattr@kde.org>

On Thursday 01 April 2010 11:19:34 pm you wrote:
> On 03/31/2010 08:10 PM, Matt Rogers wrote:
> > That last part doesn't make sense to me. If you're calling
> > Bugzilla::BugMail::Send directly in the Perl code, how are you sending
> > its results to the template?
> 
> 	$vars->{'sent_bugmail'} = Bugzilla::BugMail::Send($bug_id,
> $vars->{'mailrecipients'};
> 
> > As a bugzilla admin who may have customized this template, what impact
> > would the bug really have on me?  That I can't templatize the email
> > anymore?
> 
> 	I'm talking about template/en/default/bug/process/bugmail.html.tmpl,
> not about template/en/default/email/newchangedmail.txt.tmpl.
> 
> 	This bug is about the way that bugmail is *sent*, not about its contents.
> 
> 	If you have custom code that was running the template
> template/en/default/bug/process/results.html.tmpl to send bugmail, you'd
> have to modify your code to send bugmail before processing that template.
> 
> 	-Max

Thanks for the explanation. :) 

Next time I will read the patch that comes with the bug report as well.
-- 
Matt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20100403/b7e81278/attachment.sig>

From mkanat at bugzilla.org  Tue Apr  6 00:44:16 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Mon, 05 Apr 2010 17:44:16 -0700
Subject: Bugzilla 3.6 Coming Soon
In-Reply-To: <4BB16430.40806@bugzilla.org>
References: <4BB16430.40806@bugzilla.org>
Message-ID: <4BBA83E0.80103@bugzilla.org>

On 03/29/2010 07:38 PM, Max Kanat-Alexander wrote:
> 	Hey folks. So, all 3.6 blockers are resolved (or will be resolved
> soon). I'm planning to release Bugzilla 3.6 on April 6 if nothing comes up.

	Okay, so to give LpSolit and the QA team more time for testing, we're
going to wait until next Tuesday to release. So Bugzilla 3.6 will come
out on April 13.

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


From mkanat at bugzilla.org  Wed Apr  7 04:41:00 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Tue, 06 Apr 2010 21:41:00 -0700
Subject: Need Help with C# Reviews, for MS-SQL Support!
Message-ID: <4BBC0CDC.4050403@bugzilla.org>

	Hey everybody! So, I've started to review the contributed patches for
MS-SQL support, and it's coming along, but there's one problem! Some of
the patches are in C#, and although I can read it, I don't have enough
experience writing C# for MS-SQL to feel that I can confidently review
the contribution. So, I'd really like somebody from the community (or
perhaps many people) who have some C# experience to take a look at the
patch on this bug:

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

	At the end is a bunch of C# and Visual Studio project files, and I'd
really like somebody to take a look at it for code clarity,
implementation, and security. Even if the existing patch there already
has "review-" on it, don't fear--that's just me reviewing the Perl code;
I'm not touching the C# stuff.

	If you'd really like to see MS-SQL support (or if you just happen to
have some C# experience and would like to contribute to Bugzilla), this
is the way to help! :-)

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


From after.fallout at gmail.com  Wed Apr  7 17:49:33 2010
From: after.fallout at gmail.com (Bill Barry)
Date: Wed, 07 Apr 2010 11:49:33 -0600
Subject: Need Help with C# Reviews, for MS-SQL Support!
In-Reply-To: <4BBC0CDC.4050403@bugzilla.org>
References: <4BBC0CDC.4050403@bugzilla.org>
Message-ID: <4BBCC5AD.6000209@gmail.com>

I'd be happy to help out.
Should Bugzilla style conventions be used for this project or standard C# ones?

Ignoring any of the style issues there are actual code issues I am seeing. 
I don't see any actual security issues here, but there could very well be race conditions (which could result in bad/missing data). 
There will be people who have issues with using managed functions in general, but I don't see a way around it particularly for the concat aggregate and the regex search (everything else I think is doable in raw sql functions; though I suppose a regex engine is possible there too, I wouldn't want to try writing it).


Anyway, assuming standard (mostly because I don't feel comfortable enough with the Bugzilla ones since not having done any bz or perl coding in quite a while now; I am pretty sure other things will need to change if it is to be Bugzilla):

Bugzilla.MSSQL.pidb
Bugzilla.MSSQL.suo
Bugzilla.MSSQL.userprefs

these files should be ignored, not added (IDE/compiler generated)

into actual changes:
AssemblyInfo.cs
===============
+using System.Runtime.CompilerServices;

this line is unused in the current file (hence should not be there)

+[assembly: AssemblyTitle("Bugzilla.MSSQL")]

Nit: Standard C# naming practices would have this be Bugzilla.Mssql (or perhaps MSSql, but eww...; mssql is usually referred to in .NET as SqlServer though, don't know if that should be given any weight or not)
see: http://msdn.microsoft.com/en-us/library/ms229043.aspx
quote: Do capitalize only the first character of acronyms
with three or more characters, except the first word of a camel-cased
identifier

overall assemblyinfo.cs nits:
1. Every bit of information in this file should be filled in
2. The following addititional code should be in assemblyinfo.cs as standard practice:
using System.Runtime.InteropServices;

[assembly: AssemblyFileVersion("1.0.*")]

// Setting ComVisible to false makes the types in this assembly not visible
// to COM components.  If you need to access a type in this assembly from
// COM, set the ComVisible attribute to true on that type.
[assembly: ComVisible(false)]

// The following GUID is for the ID of the typelib if this project is exposed to COM (create a new GUID for this)
[assembly: Guid("f06345e0-a4d4-47d8-99fc-5af3232233cf")]

(reasoning: it is far better to be explicit up front than to add it in later on)

Bugzilla.MSSQL.cs
=================
Filename should be Bugzilla.Mssql.cs

+using System.Data;
+using System.Data.SqlClient;

unused, shouldn't be there

+using System.Text;

unused, shouldn't be there

+using NaturalComparer;

unused, shouldn't be there

+public partial class UserDefinedFunctions

This class is not partial, it is fully defined. This class should be in a Bugzilla.Mssql namespace. This class should be marked static.

+    [Microsoft.SqlServer.Server.SqlFunction()]

Namespace is unnecessary (included in using statements), used multiple times in the file, will not repeat myself over and over again

+    public static SqlBoolean REGEXP([SqlFacet(MaxSize = -1)]SqlString subject, [SqlFacet(MaxSize = -1)]SqlString pattern, SqlBoolean ignorecase)

Function name is not in line with naming conventions for C# function names, Should be Regexp
nit: In .NET regexes are of the type Regex, not Regexp. Should the function name match?

+        string str_subject = subject.Value;
+        string str_pattern = pattern.Value;

names are nonstandard, should be strSubject and strPattern, though you should avoid any form of Hungarian notation. Better names would be subjectValue and patternValue.

+            test = System.Text.RegularExpressions.Regex.IsMatch(str_subject, str_pattern,RegexOptions.IgnoreCase);

namespace is unnecessary (included in using statements)

+            test = System.Text.RegularExpressions.Regex.IsMatch(str_subject, str_pattern);

namespace is unnecessary (included in using statements)

+        if (test)
+        {
+            return SqlBoolean.True;
+        }
+        else
+        {
+            return SqlBoolean.False;
+        }

nit: stylistically I do not like this code; better would be to pull out the Regexp function to:

private static bool RegexpImpl(SqlString subject, SqlString pattern, SqlBoolean ignorecase)

then replace the implementation of Regexp with:

return ToSqlBoolean(RegexpImpl(subject, pattern, ignorecase));

and have a function ToSqlBoolean:

private static SqlBoolean ToSqlBoolean(bool test)
{
    return test ? SqlBoolean.True : SqlBoolean.False;
}

This would allow you to also replace the contents of NOT_REGEX with

return ToSqlBoolean(!RegexpImpl(subject, pattern, ignorecase));

cutting the file shorter by about 15 lines and making the methods slightly more optimized.

+    public static SqlBoolean NOT_REGEXP([SqlFacet(MaxSize = -1)]SqlString subject, [SqlFacet(MaxSize = -1)]SqlString pattern, SqlBoolean ignorecase)

Function name should be NotRegexp

+    public static SqlInt32 INSTR([SqlFacet(MaxSize = -1)]SqlString find, [SqlFacet(MaxSize = -1)]SqlString inthis, SqlBoolean CaseSensitive)

Function name should be InStr
parameter inthis should be inThis
parameter CaseSensitive should be caseSensitive

nit: Why does this one have caseSensitive and the regex functions have ignorecase? The parameters should be consistent with each other as the current method could be confusing and eventually lead to issues.

+        if (ind == -1)
+        {
+            return 0;
+        }
+        else {
+            return ind+1;
+        }

condition is unnecessary, should be:

+        return ind+1;

empty line at the end of this method should be removed

+    [Microsoft.SqlServer.Server.SqlFunction()]
+    public static SqlDateTime NOW()
+    {
+
+        return DateTime.Now;
+    }
+
+    [Microsoft.SqlServer.Server.SqlFunction()]
+    public static SqlDateTime LOCALTIMESTAMP()
+    {
+        return NOW();
+    }

Aren't both of these doing the same thing that getdate() does?
Again nonstandard names (will stop saying this now for future methods)

nit: empty line at beginning of NOW() (empty lines at the beginning and end of methods are quite pointless and IMO can only possibly serve to be an attempt to get the reader to disassociate the method name from its implementation or to make syntax errors when modifying and I decree that this is a bad thing in all cases)

+    public static SqlInt32 TO_DAYS(SqlDateTime date)
+    {
+        DateTime SubjectDate = date.Value;
+        DateTime Y1900 = new DateTime(1900, 1, 1);
+
+        long elapsedTicks = SubjectDate.Ticks - Y1900.Ticks;
+        TimeSpan elapsedSpan = new TimeSpan(elapsedTicks);
+        return Convert.ToInt32(elapsedSpan.TotalDays);
+
+    }

1. Shouldn't you be checking if date is null?
2. Why are you subtracting ticks like that? Can't you just do
+        return Convert.ToInt32((SubjectDate - Y1900).TotalDays);
3. variable names (should be camelCase), will not repeat again

+        Y1900.AddDays(days.Value);

shouldn't be here, statement has no side affect and is repeated anyway on the next line

+        if (SqlDate.IsNull) return SqlChars.Null;
+        string str_format = format.Value;
+        DateTime Date = SqlDate.Value;
+
+        string a = Date.DayOfWeek.ToString();

if statement uses different syntax than before; should be consistent
variable "a" is unused

As for the if statements: most of the time spent inside string.Replace is spent doing the same thing that string.Contains does. Both take far longer than evaluating whatever the replacement would be.
I would replace that whole section (from the first if to the return statement) with:
        return new SqlChars(str_format
            .Replace(@"%a", Date.DayOfWeek.ToString().Substring(0, 3))
            .Replace(@"%b", ((ShortMonthOfYear) Date.Month).ToString())
            .Replace(@"%c", Date.Month.ToString())
            .Replace(@"%D", Date.Day.ToString() + GetDateSuffix(Date))
            .Replace(@"%d", Date.Day.ToString().PadLeft(2, '0'))
            .Replace(@"%e", Date.Day.ToString())
            .Replace(@"%f", Date.Millisecond.ToString().PadRight(6, '0'))
            .Replace(@"%H", Date.Hour.ToString().PadLeft(2, '0'))
            .Replace(@"%h", Date.Hour.ToString().PadLeft(2, '0'))
            .Replace(@"%I", Date.Hour.ToString().PadLeft(2, '0'))
            .Replace(@"%i", Date.Minute.ToString().PadLeft(2, '0'))
            .Replace(@"%j", Date.DayOfYear.ToString().PadLeft(3, '0'))
            .Replace(@"%k", Date.Hour.ToString().PadLeft(2, '0'))
            .Replace(@"%l", Date.Hour.ToString())
            .Replace(@"%M", ((LongMonthOfYear) Date.Month).ToString())
            .Replace(@"%m", Date.Month.ToString().PadLeft(2, '0'))
            .Replace(@"%p", Date.Hour >= 12 ? @"PM" : @"AM")
            .Replace(@"%r", Date.TimeOfDay.ToString())
            .Replace(@"%S", Date.Second.ToString().PadLeft(2, '0'))
            .Replace(@"%s", Date.Second.ToString().PadLeft(2, '0'))
            .Replace(@"%T", Date.ToShortTimeString().ToString())
            .Replace(@"%U", WeekOfYear(Date).ToString())
            .Replace(@"%u", WeekOfYear(Date).ToString())
            .Replace(@"%V", WeekOfYear(Date).ToString())
            .Replace(@"%v", WeekOfYear(Date).ToString())
            .Replace(@"%W", Date.DayOfWeek.ToString())
            .Replace(@"%w", ((LongDayofWeek) Date.DayOfWeek).ToString())
            .Replace(@"%X", Date.Year.ToString())
            .Replace(@"%x", Date.Year.ToString())
            .Replace(@"%Y", Date.Year.ToString())
            .Replace(@"%y", Date.Year.ToString().Substring(2, 2))
            .Replace(@"%%", @"%"));

That said, I think there are some bugs here:
I doubt that %H, %h, %I and %k are supposed to return the same value (similarly U,u,V,v, and X,x,Y).
Is %f correct or should it also be PadLeft?
You have an if for capital S and then do a replace with lowercase s.
Could a test be written to ensure the correctness of this function?
Are there l10n issues here?

+    [Serializable]
+    private enum LongDayofWeek
...
+
+    [Serializable]
+    private enum ShortMonthOfYear
...
+
+    [Serializable]
+    private enum LongMonthOfYear

These should be public to prevent a future compiler from obfuciating them.

+    private static string GetDateSuffix(SqlDateTime SqlDate)
+    {
+        if (SqlDate.IsNull) return null;
+
+        DateTime date = SqlDate.Value;
+
+        string day = date.Day.ToString();
+        if (day.EndsWith("1"))
+        {
+            return day.StartsWith("1") && date.Day != 1 ? "th" : "st";
+        }
+        else if (day.EndsWith("2"))
+        {
+            return day.StartsWith("1") ? "th" : "nd";
+        }
+        else if (day.EndsWith("3"))
+        {
+            return day.StartsWith("1") ? "th" : "rd";
+        }
+        return "th";
+    }

parameter being passed in is DateTime, not SqlDateTime (makes first if and assignment unnecessary)
first if syntax inconsistent with second if syntax
else keywords are unneeded

+    private static int WeekOfYear(SqlDateTime SqlDate)
+    {
+        if (SqlDate.IsNull) return 0;
+
+        DateTime date = SqlDate.Value;
+
+        System.Globalization.CultureInfo ci = System.Threading.Thread.CurrentThread.CurrentCulture;
+        System.Globalization.Calendar cal = ci.Calendar;
+        System.Globalization.CalendarWeekRule cwr = ci.DateTimeFormat.CalendarWeekRule;
+        DayOfWeek fdow = ci.DateTimeFormat.FirstDayOfWeek;
+        return cal.GetWeekOfYear(date, cwr, fdow);
+    }

parameter being passed in is DateTime, not SqlDateTime (makes first if and assignment unnecessary)
if syntax inconsistant again
using CurrentThread.CurrentCulture here, is this ok in sql app domain context (I think so but I am not certain)?
You use the current culture here but previously you used InvariantCulture for case sensitivity. Does that present an internationalization issue (how does mysql do case sensitivity particularly for accented characters? does it vary per culture and if so should this or should it do it however mssql does case sensitivity when it is configured as insensitive, if they are different?)?

+public struct GROUP_CONCAT : Microsoft.SqlServer.Server.IBinarySerialize

should be in separate file, should be in Bugzilla.Mssql namespace, should be named GroupConcat
This class feels smelly:
1. A List<T> datatype is almost always better than an ArrayList (and in worst case is equivalent)
2. this keyword is not necessary for accessing your own members unless they share a name with something else you are trying to use
3. Read is not a compliment to Write
4. Lists are not thread safe. I wouldn't doubt there may be race conditions in this code.

I would write this class as follows (completely untested code, but it looks less buggy I think):
public struct GROUP_CONCAT : Microsoft.SqlServer.Server.IBinarySerialize {
    private static readonly object lockobj = new object();
    private List<string> _remembered;
    private List<GROUP_CONCAT> _merged;
    private string _seperator;
    private string _sortOrder;
    public void Init() {
        _remembered = new List<string>();
        _merged = new List<GROUP_CONCAT>();
        _seperator = null;
        _sortOrder = null;
    }
    public void Accumulate([SqlFacet(MaxSize = -1)]SqlString value, [SqlFacet(MaxSize = -1, IsNullable = true)]SqlString seperator, SqlString sortOrder) {
        // Default a Null to Seperator to an empty string
        _seperator = seperator.IsNull ? "" : seperator.Value;

        // Add the Seperator as the first array element
        _sortOrder = sortOrder.IsNull ? "NTRL" : sortOrder.Value.ToUpper();

        if (_sortOrder != "ASC" && _sortOrder != "DESC" && _sortOrder != "NTRL") {
            throw new ArgumentException(sortOrder.Value + " is not valid for Sort Order");
        }

        if (value.IsNull) return;

        lock (lockobj) {
            _remembered.Add(value.Value);
        }
    }
    public void Merge(GROUP_CONCAT group) {
        if(group._seperator!=_seperator) {
            throw new ArgumentException("Seperators do not match: " + group._seperator+", "+_seperator);
        }
        if(group._sortOrder!=_sortOrder) {
            throw new ArgumentException("Sort Orders do not match: " + group._sortOrder + ", " + _sortOrder);
        }

        //not sure about the thread safety of Add/AddRange so...
        lock (lockobj) {
            _merged.Add(group);
        }
    }

    private IEnumerable<string> Enumerate() {
        lock (lockobj) {
            foreach (var value in _remembered) {
                yield return value;
            }
            foreach (var list in _merged) {
                foreach (var value in list.Enumerate()) {
                    yield return value;
                }
            }
        }
    }

    public SqlString Terminate() {
        List<string> all = new List<string>(Enumerate());

        // If ASC or DESC then Sort
        //new NaturalComparer(NaturalComparerOptions.RomanNumbers));
        if (_sortOrder != "NTRL") all.Sort(new NaturalComparer.NaturalComparer());
        // If DESC then reverse the Sort order
        if (_sortOrder == "DESC") all.Reverse();
        return new SqlString(string.Join(_seperator, all.ToArray()));
    }

    public void Read(System.IO.BinaryReader r) {
        int itemCount = r.ReadInt32();

        // Retrieve the Seperator for use by Terminate()
        _seperator = r.ReadString();
        _sortOrder = r.ReadString();
        lock (lockobj) {
            _remembered = new List<string>(itemCount - 2);
        }
        for (int i = 2; i <= itemCount - 1; i++) {
            lock (lockobj) {
                _remembered.Add(r.ReadString());
            }
        }
    }

    public void Write(System.IO.BinaryWriter w) {
        List<string> all = new List<string>(Enumerate());
        w.Write(all.Count);
        w.Write(_seperator);
        w.Write(_sortOrder);
        foreach (string s in all) {
            w.Write(s);
        }
    }
}

Bugzilla.MSSQL.csproj
=====================
+    <RootNamespace>Bugzilla.MSSQL</RootNamespace>
+    <AssemblyName>Bugzilla.MSSQL</AssemblyName>
+    <TargetFrameworkVersion>v3.5</TargetFrameworkVersion>

Names again...
Should this be targeting .net 3.5? or should it target 2.0 (for a potentially wider audience)? It doesn't appear to be using any 3.5 assemblies or syntax (unless you use the GROUP_CONCAT class I provided above, in which case you would have to remove the 3.5 var syntax).

NaturalSortComparer.cs
======================
Assuming this code is correct (not even going to bother going there at least yet) my most significant issue is that the variable names are not very explicit. In my company we use _camelCase for fields, camelCase for method variables and parameters and PascalCase for just about everything visible outside of the class.
These classes should also be in a Bugzilla.Mssql namespace and they should be in separate files per class (at least according to C# conventions that I know of, perhaps the bugzilla devs do not care to follow this).

I am finding myself questioning what the whole point of this class is.
What advantages does it provide that Bugzilla might need that will permit it to waste so much time (parsing strings) as part of the sql execution?




Max Kanat-Alexander wrote:
> 	Hey everybody! So, I've started to review the contributed patches for
> MS-SQL support, and it's coming along, but there's one problem! Some of
> the patches are in C#, and although I can read it, I don't have enough
> experience writing C# for MS-SQL to feel that I can confidently review
> the contribution. So, I'd really like somebody from the community (or
> perhaps many people) who have some C# experience to take a look at the
> patch on this bug:
>
> 	https://bugzilla.mozilla.org/show_bug.cgi?id=487437
>
> 	At the end is a bunch of C# and Visual Studio project files, and I'd
> really like somebody to take a look at it for code clarity,
> implementation, and security. Even if the existing patch there already
> has "review-" on it, don't fear--that's just me reviewing the Perl code;
> I'm not touching the C# stuff.
>
> 	If you'd really like to see MS-SQL support (or if you just happen to
> have some C# experience and would like to contribute to Bugzilla), this
> is the way to help! :-)
>
> 	-Max
>   



From mockodin at gmail.com  Wed Apr  7 18:21:32 2010
From: mockodin at gmail.com (Michael Thomas)
Date: Wed, 7 Apr 2010 11:21:32 -0700
Subject: Need Help with C# Reviews, for MS-SQL Support!
In-Reply-To: <4BBCC5AD.6000209@gmail.com>
References: <4BBC0CDC.4050403@bugzilla.org> <4BBCC5AD.6000209@gmail.com>
Message-ID: <p2s6b9407351004071121l29093c6en4fd0d9e5bb2e7bd2@mail.gmail.com>

Can you post this to the ticket, rather than my addressing it here.

Some of the items such as what 'using' statements are in
AssemblyInfo.cs are default our of Visual Studio, unless there is a
reason to remove them, eh, since Visual Studio wanted/defaulted I left
them.

Style wise, cutting new territory a bit here so probably kinda sorta
C# with bugzilla style mixed in or preferred where possible... er ah
Mkanat opinion?

On Wed, Apr 7, 2010 at 10:49 AM, Bill Barry <after.fallout at gmail.com> wrote:
> I'd be happy to help out.
> Should Bugzilla style conventions be used for this project or standard C#
> ones?
>
> Ignoring any of the style issues there are actual code issues I am seeing. I
> don't see any actual security issues here, but there could very well be race
> conditions (which could result in bad/missing data). There will be people
> who have issues with using managed functions in general, but I don't see a
> way around it particularly for the concat aggregate and the regex search
> (everything else I think is doable in raw sql functions; though I suppose a
> regex engine is possible there too, I wouldn't want to try writing it).
>
>
> Anyway, assuming standard (mostly because I don't feel comfortable enough
> with the Bugzilla ones since not having done any bz or perl coding in quite
> a while now; I am pretty sure other things will need to change if it is to
> be Bugzilla):
>
> Bugzilla.MSSQL.pidb
> Bugzilla.MSSQL.suo
> Bugzilla.MSSQL.userprefs
>
> these files should be ignored, not added (IDE/compiler generated)
>
> into actual changes:
> AssemblyInfo.cs
> ===============
> +using System.Runtime.CompilerServices;
>
> this line is unused in the current file (hence should not be there)
>
> +[assembly: AssemblyTitle("Bugzilla.MSSQL")]
>
> Nit: Standard C# naming practices would have this be Bugzilla.Mssql (or
> perhaps MSSql, but eww...; mssql is usually referred to in .NET as SqlServer
> though, don't know if that should be given any weight or not)
> see: http://msdn.microsoft.com/en-us/library/ms229043.aspx
> quote: Do capitalize only the first character of acronyms
> with three or more characters, except the first word of a camel-cased
> identifier
>
> overall assemblyinfo.cs nits:
> 1. Every bit of information in this file should be filled in
> 2. The following addititional code should be in assemblyinfo.cs as standard
> practice:
> using System.Runtime.InteropServices;
>
> [assembly: AssemblyFileVersion("1.0.*")]
>
> // Setting ComVisible to false makes the types in this assembly not visible
> // to COM components. ?If you need to access a type in this assembly from
> // COM, set the ComVisible attribute to true on that type.
> [assembly: ComVisible(false)]
>
> // The following GUID is for the ID of the typelib if this project is
> exposed to COM (create a new GUID for this)
> [assembly: Guid("f06345e0-a4d4-47d8-99fc-5af3232233cf")]
>
> (reasoning: it is far better to be explicit up front than to add it in later
> on)
>
> Bugzilla.MSSQL.cs
> =================
> Filename should be Bugzilla.Mssql.cs
>
> +using System.Data;
> +using System.Data.SqlClient;
>
> unused, shouldn't be there
>
> +using System.Text;
>
> unused, shouldn't be there
>
> +using NaturalComparer;
>
> unused, shouldn't be there
>
> +public partial class UserDefinedFunctions
>
> This class is not partial, it is fully defined. This class should be in a
> Bugzilla.Mssql namespace. This class should be marked static.
>
> + ? ?[Microsoft.SqlServer.Server.SqlFunction()]
>
> Namespace is unnecessary (included in using statements), used multiple times
> in the file, will not repeat myself over and over again
>
> + ? ?public static SqlBoolean REGEXP([SqlFacet(MaxSize = -1)]SqlString
> subject, [SqlFacet(MaxSize = -1)]SqlString pattern, SqlBoolean ignorecase)
>
> Function name is not in line with naming conventions for C# function names,
> Should be Regexp
> nit: In .NET regexes are of the type Regex, not Regexp. Should the function
> name match?
>
> + ? ? ? ?string str_subject = subject.Value;
> + ? ? ? ?string str_pattern = pattern.Value;
>
> names are nonstandard, should be strSubject and strPattern, though you
> should avoid any form of Hungarian notation. Better names would be
> subjectValue and patternValue.
>
> + ? ? ? ? ? ?test =
> System.Text.RegularExpressions.Regex.IsMatch(str_subject,
> str_pattern,RegexOptions.IgnoreCase);
>
> namespace is unnecessary (included in using statements)
>
> + ? ? ? ? ? ?test =
> System.Text.RegularExpressions.Regex.IsMatch(str_subject, str_pattern);
>
> namespace is unnecessary (included in using statements)
>
> + ? ? ? ?if (test)
> + ? ? ? ?{
> + ? ? ? ? ? ?return SqlBoolean.True;
> + ? ? ? ?}
> + ? ? ? ?else
> + ? ? ? ?{
> + ? ? ? ? ? ?return SqlBoolean.False;
> + ? ? ? ?}
>
> nit: stylistically I do not like this code; better would be to pull out the
> Regexp function to:
>
> private static bool RegexpImpl(SqlString subject, SqlString pattern,
> SqlBoolean ignorecase)
>
> then replace the implementation of Regexp with:
>
> return ToSqlBoolean(RegexpImpl(subject, pattern, ignorecase));
>
> and have a function ToSqlBoolean:
>
> private static SqlBoolean ToSqlBoolean(bool test)
> {
> ? return test ? SqlBoolean.True : SqlBoolean.False;
> }
>
> This would allow you to also replace the contents of NOT_REGEX with
>
> return ToSqlBoolean(!RegexpImpl(subject, pattern, ignorecase));
>
> cutting the file shorter by about 15 lines and making the methods slightly
> more optimized.
>
> + ? ?public static SqlBoolean NOT_REGEXP([SqlFacet(MaxSize = -1)]SqlString
> subject, [SqlFacet(MaxSize = -1)]SqlString pattern, SqlBoolean ignorecase)
>
> Function name should be NotRegexp
>
> + ? ?public static SqlInt32 INSTR([SqlFacet(MaxSize = -1)]SqlString find,
> [SqlFacet(MaxSize = -1)]SqlString inthis, SqlBoolean CaseSensitive)
>
> Function name should be InStr
> parameter inthis should be inThis
> parameter CaseSensitive should be caseSensitive
>
> nit: Why does this one have caseSensitive and the regex functions have
> ignorecase? The parameters should be consistent with each other as the
> current method could be confusing and eventually lead to issues.
>
> + ? ? ? ?if (ind == -1)
> + ? ? ? ?{
> + ? ? ? ? ? ?return 0;
> + ? ? ? ?}
> + ? ? ? ?else {
> + ? ? ? ? ? ?return ind+1;
> + ? ? ? ?}
>
> condition is unnecessary, should be:
>
> + ? ? ? ?return ind+1;
>
> empty line at the end of this method should be removed
>
> + ? ?[Microsoft.SqlServer.Server.SqlFunction()]
> + ? ?public static SqlDateTime NOW()
> + ? ?{
> +
> + ? ? ? ?return DateTime.Now;
> + ? ?}
> +
> + ? ?[Microsoft.SqlServer.Server.SqlFunction()]
> + ? ?public static SqlDateTime LOCALTIMESTAMP()
> + ? ?{
> + ? ? ? ?return NOW();
> + ? ?}
>
> Aren't both of these doing the same thing that getdate() does?
> Again nonstandard names (will stop saying this now for future methods)
>
> nit: empty line at beginning of NOW() (empty lines at the beginning and end
> of methods are quite pointless and IMO can only possibly serve to be an
> attempt to get the reader to disassociate the method name from its
> implementation or to make syntax errors when modifying and I decree that
> this is a bad thing in all cases)
>
> + ? ?public static SqlInt32 TO_DAYS(SqlDateTime date)
> + ? ?{
> + ? ? ? ?DateTime SubjectDate = date.Value;
> + ? ? ? ?DateTime Y1900 = new DateTime(1900, 1, 1);
> +
> + ? ? ? ?long elapsedTicks = SubjectDate.Ticks - Y1900.Ticks;
> + ? ? ? ?TimeSpan elapsedSpan = new TimeSpan(elapsedTicks);
> + ? ? ? ?return Convert.ToInt32(elapsedSpan.TotalDays);
> +
> + ? ?}
>
> 1. Shouldn't you be checking if date is null?
> 2. Why are you subtracting ticks like that? Can't you just do
> + ? ? ? ?return Convert.ToInt32((SubjectDate - Y1900).TotalDays);
> 3. variable names (should be camelCase), will not repeat again
>
> + ? ? ? ?Y1900.AddDays(days.Value);
>
> shouldn't be here, statement has no side affect and is repeated anyway on
> the next line
>
> + ? ? ? ?if (SqlDate.IsNull) return SqlChars.Null;
> + ? ? ? ?string str_format = format.Value;
> + ? ? ? ?DateTime Date = SqlDate.Value;
> +
> + ? ? ? ?string a = Date.DayOfWeek.ToString();
>
> if statement uses different syntax than before; should be consistent
> variable "a" is unused
>
> As for the if statements: most of the time spent inside string.Replace is
> spent doing the same thing that string.Contains does. Both take far longer
> than evaluating whatever the replacement would be.
> I would replace that whole section (from the first if to the return
> statement) with:
> ? ? ? return new SqlChars(str_format
> ? ? ? ? ? .Replace(@"%a", Date.DayOfWeek.ToString().Substring(0, 3))
> ? ? ? ? ? .Replace(@"%b", ((ShortMonthOfYear) Date.Month).ToString())
> ? ? ? ? ? .Replace(@"%c", Date.Month.ToString())
> ? ? ? ? ? .Replace(@"%D", Date.Day.ToString() + GetDateSuffix(Date))
> ? ? ? ? ? .Replace(@"%d", Date.Day.ToString().PadLeft(2, '0'))
> ? ? ? ? ? .Replace(@"%e", Date.Day.ToString())
> ? ? ? ? ? .Replace(@"%f", Date.Millisecond.ToString().PadRight(6, '0'))
> ? ? ? ? ? .Replace(@"%H", Date.Hour.ToString().PadLeft(2, '0'))
> ? ? ? ? ? .Replace(@"%h", Date.Hour.ToString().PadLeft(2, '0'))
> ? ? ? ? ? .Replace(@"%I", Date.Hour.ToString().PadLeft(2, '0'))
> ? ? ? ? ? .Replace(@"%i", Date.Minute.ToString().PadLeft(2, '0'))
> ? ? ? ? ? .Replace(@"%j", Date.DayOfYear.ToString().PadLeft(3, '0'))
> ? ? ? ? ? .Replace(@"%k", Date.Hour.ToString().PadLeft(2, '0'))
> ? ? ? ? ? .Replace(@"%l", Date.Hour.ToString())
> ? ? ? ? ? .Replace(@"%M", ((LongMonthOfYear) Date.Month).ToString())
> ? ? ? ? ? .Replace(@"%m", Date.Month.ToString().PadLeft(2, '0'))
> ? ? ? ? ? .Replace(@"%p", Date.Hour >= 12 ? @"PM" : @"AM")
> ? ? ? ? ? .Replace(@"%r", Date.TimeOfDay.ToString())
> ? ? ? ? ? .Replace(@"%S", Date.Second.ToString().PadLeft(2, '0'))
> ? ? ? ? ? .Replace(@"%s", Date.Second.ToString().PadLeft(2, '0'))
> ? ? ? ? ? .Replace(@"%T", Date.ToShortTimeString().ToString())
> ? ? ? ? ? .Replace(@"%U", WeekOfYear(Date).ToString())
> ? ? ? ? ? .Replace(@"%u", WeekOfYear(Date).ToString())
> ? ? ? ? ? .Replace(@"%V", WeekOfYear(Date).ToString())
> ? ? ? ? ? .Replace(@"%v", WeekOfYear(Date).ToString())
> ? ? ? ? ? .Replace(@"%W", Date.DayOfWeek.ToString())
> ? ? ? ? ? .Replace(@"%w", ((LongDayofWeek) Date.DayOfWeek).ToString())
> ? ? ? ? ? .Replace(@"%X", Date.Year.ToString())
> ? ? ? ? ? .Replace(@"%x", Date.Year.ToString())
> ? ? ? ? ? .Replace(@"%Y", Date.Year.ToString())
> ? ? ? ? ? .Replace(@"%y", Date.Year.ToString().Substring(2, 2))
> ? ? ? ? ? .Replace(@"%%", @"%"));
>
> That said, I think there are some bugs here:
> I doubt that %H, %h, %I and %k are supposed to return the same value
> (similarly U,u,V,v, and X,x,Y).
> Is %f correct or should it also be PadLeft?
> You have an if for capital S and then do a replace with lowercase s.
> Could a test be written to ensure the correctness of this function?
> Are there l10n issues here?
>
> + ? ?[Serializable]
> + ? ?private enum LongDayofWeek
> ...
> +
> + ? ?[Serializable]
> + ? ?private enum ShortMonthOfYear
> ...
> +
> + ? ?[Serializable]
> + ? ?private enum LongMonthOfYear
>
> These should be public to prevent a future compiler from obfuciating them.
>
> + ? ?private static string GetDateSuffix(SqlDateTime SqlDate)
> + ? ?{
> + ? ? ? ?if (SqlDate.IsNull) return null;
> +
> + ? ? ? ?DateTime date = SqlDate.Value;
> +
> + ? ? ? ?string day = date.Day.ToString();
> + ? ? ? ?if (day.EndsWith("1"))
> + ? ? ? ?{
> + ? ? ? ? ? ?return day.StartsWith("1") && date.Day != 1 ? "th" : "st";
> + ? ? ? ?}
> + ? ? ? ?else if (day.EndsWith("2"))
> + ? ? ? ?{
> + ? ? ? ? ? ?return day.StartsWith("1") ? "th" : "nd";
> + ? ? ? ?}
> + ? ? ? ?else if (day.EndsWith("3"))
> + ? ? ? ?{
> + ? ? ? ? ? ?return day.StartsWith("1") ? "th" : "rd";
> + ? ? ? ?}
> + ? ? ? ?return "th";
> + ? ?}
>
> parameter being passed in is DateTime, not SqlDateTime (makes first if and
> assignment unnecessary)
> first if syntax inconsistent with second if syntax
> else keywords are unneeded
>
> + ? ?private static int WeekOfYear(SqlDateTime SqlDate)
> + ? ?{
> + ? ? ? ?if (SqlDate.IsNull) return 0;
> +
> + ? ? ? ?DateTime date = SqlDate.Value;
> +
> + ? ? ? ?System.Globalization.CultureInfo ci =
> System.Threading.Thread.CurrentThread.CurrentCulture;
> + ? ? ? ?System.Globalization.Calendar cal = ci.Calendar;
> + ? ? ? ?System.Globalization.CalendarWeekRule cwr =
> ci.DateTimeFormat.CalendarWeekRule;
> + ? ? ? ?DayOfWeek fdow = ci.DateTimeFormat.FirstDayOfWeek;
> + ? ? ? ?return cal.GetWeekOfYear(date, cwr, fdow);
> + ? ?}
>
> parameter being passed in is DateTime, not SqlDateTime (makes first if and
> assignment unnecessary)
> if syntax inconsistant again
> using CurrentThread.CurrentCulture here, is this ok in sql app domain
> context (I think so but I am not certain)?
> You use the current culture here but previously you used InvariantCulture
> for case sensitivity. Does that present an internationalization issue (how
> does mysql do case sensitivity particularly for accented characters? does it
> vary per culture and if so should this or should it do it however mssql does
> case sensitivity when it is configured as insensitive, if they are
> different?)?
>
> +public struct GROUP_CONCAT : Microsoft.SqlServer.Server.IBinarySerialize
>
> should be in separate file, should be in Bugzilla.Mssql namespace, should be
> named GroupConcat
> This class feels smelly:
> 1. A List<T> datatype is almost always better than an ArrayList (and in
> worst case is equivalent)
> 2. this keyword is not necessary for accessing your own members unless they
> share a name with something else you are trying to use
> 3. Read is not a compliment to Write
> 4. Lists are not thread safe. I wouldn't doubt there may be race conditions
> in this code.
>
> I would write this class as follows (completely untested code, but it looks
> less buggy I think):
> public struct GROUP_CONCAT : Microsoft.SqlServer.Server.IBinarySerialize {
> ? private static readonly object lockobj = new object();
> ? private List<string> _remembered;
> ? private List<GROUP_CONCAT> _merged;
> ? private string _seperator;
> ? private string _sortOrder;
> ? public void Init() {
> ? ? ? _remembered = new List<string>();
> ? ? ? _merged = new List<GROUP_CONCAT>();
> ? ? ? _seperator = null;
> ? ? ? _sortOrder = null;
> ? }
> ? public void Accumulate([SqlFacet(MaxSize = -1)]SqlString value,
> [SqlFacet(MaxSize = -1, IsNullable = true)]SqlString seperator, SqlString
> sortOrder) {
> ? ? ? // Default a Null to Seperator to an empty string
> ? ? ? _seperator = seperator.IsNull ? "" : seperator.Value;
>
> ? ? ? // Add the Seperator as the first array element
> ? ? ? _sortOrder = sortOrder.IsNull ? "NTRL" : sortOrder.Value.ToUpper();
>
> ? ? ? if (_sortOrder != "ASC" && _sortOrder != "DESC" && _sortOrder !=
> "NTRL") {
> ? ? ? ? ? throw new ArgumentException(sortOrder.Value + " is not valid for
> Sort Order");
> ? ? ? }
>
> ? ? ? if (value.IsNull) return;
>
> ? ? ? lock (lockobj) {
> ? ? ? ? ? _remembered.Add(value.Value);
> ? ? ? }
> ? }
> ? public void Merge(GROUP_CONCAT group) {
> ? ? ? if(group._seperator!=_seperator) {
> ? ? ? ? ? throw new ArgumentException("Seperators do not match: " +
> group._seperator+", "+_seperator);
> ? ? ? }
> ? ? ? if(group._sortOrder!=_sortOrder) {
> ? ? ? ? ? throw new ArgumentException("Sort Orders do not match: " +
> group._sortOrder + ", " + _sortOrder);
> ? ? ? }
>
> ? ? ? //not sure about the thread safety of Add/AddRange so...
> ? ? ? lock (lockobj) {
> ? ? ? ? ? _merged.Add(group);
> ? ? ? }
> ? }
>
> ? private IEnumerable<string> Enumerate() {
> ? ? ? lock (lockobj) {
> ? ? ? ? ? foreach (var value in _remembered) {
> ? ? ? ? ? ? ? yield return value;
> ? ? ? ? ? }
> ? ? ? ? ? foreach (var list in _merged) {
> ? ? ? ? ? ? ? foreach (var value in list.Enumerate()) {
> ? ? ? ? ? ? ? ? ? yield return value;
> ? ? ? ? ? ? ? }
> ? ? ? ? ? }
> ? ? ? }
> ? }
>
> ? public SqlString Terminate() {
> ? ? ? List<string> all = new List<string>(Enumerate());
>
> ? ? ? // If ASC or DESC then Sort
> ? ? ? //new NaturalComparer(NaturalComparerOptions.RomanNumbers));
> ? ? ? if (_sortOrder != "NTRL") all.Sort(new
> NaturalComparer.NaturalComparer());
> ? ? ? // If DESC then reverse the Sort order
> ? ? ? if (_sortOrder == "DESC") all.Reverse();
> ? ? ? return new SqlString(string.Join(_seperator, all.ToArray()));
> ? }
>
> ? public void Read(System.IO.BinaryReader r) {
> ? ? ? int itemCount = r.ReadInt32();
>
> ? ? ? // Retrieve the Seperator for use by Terminate()
> ? ? ? _seperator = r.ReadString();
> ? ? ? _sortOrder = r.ReadString();
> ? ? ? lock (lockobj) {
> ? ? ? ? ? _remembered = new List<string>(itemCount - 2);
> ? ? ? }
> ? ? ? for (int i = 2; i <= itemCount - 1; i++) {
> ? ? ? ? ? lock (lockobj) {
> ? ? ? ? ? ? ? _remembered.Add(r.ReadString());
> ? ? ? ? ? }
> ? ? ? }
> ? }
>
> ? public void Write(System.IO.BinaryWriter w) {
> ? ? ? List<string> all = new List<string>(Enumerate());
> ? ? ? w.Write(all.Count);
> ? ? ? w.Write(_seperator);
> ? ? ? w.Write(_sortOrder);
> ? ? ? foreach (string s in all) {
> ? ? ? ? ? w.Write(s);
> ? ? ? }
> ? }
> }
>
> Bugzilla.MSSQL.csproj
> =====================
> + ? ?<RootNamespace>Bugzilla.MSSQL</RootNamespace>
> + ? ?<AssemblyName>Bugzilla.MSSQL</AssemblyName>
> + ? ?<TargetFrameworkVersion>v3.5</TargetFrameworkVersion>
>
> Names again...
> Should this be targeting .net 3.5? or should it target 2.0 (for a
> potentially wider audience)? It doesn't appear to be using any 3.5
> assemblies or syntax (unless you use the GROUP_CONCAT class I provided
> above, in which case you would have to remove the 3.5 var syntax).
>
> NaturalSortComparer.cs
> ======================
> Assuming this code is correct (not even going to bother going there at least
> yet) my most significant issue is that the variable names are not very
> explicit. In my company we use _camelCase for fields, camelCase for method
> variables and parameters and PascalCase for just about everything visible
> outside of the class.
> These classes should also be in a Bugzilla.Mssql namespace and they should
> be in separate files per class (at least according to C# conventions that I
> know of, perhaps the bugzilla devs do not care to follow this).
>
> I am finding myself questioning what the whole point of this class is.
> What advantages does it provide that Bugzilla might need that will permit it
> to waste so much time (parsing strings) as part of the sql execution?
>
>
>
>
> Max Kanat-Alexander wrote:
>>
>> ? ? ? ?Hey everybody! So, I've started to review the contributed patches
>> for
>> MS-SQL support, and it's coming along, but there's one problem! Some of
>> the patches are in C#, and although I can read it, I don't have enough
>> experience writing C# for MS-SQL to feel that I can confidently review
>> the contribution. So, I'd really like somebody from the community (or
>> perhaps many people) who have some C# experience to take a look at the
>> patch on this bug:
>>
>> ? ? ? ?https://bugzilla.mozilla.org/show_bug.cgi?id=487437
>>
>> ? ? ? ?At the end is a bunch of C# and Visual Studio project files, and
>> I'd
>> really like somebody to take a look at it for code clarity,
>> implementation, and security. Even if the existing patch there already
>> has "review-" on it, don't fear--that's just me reviewing the Perl code;
>> I'm not touching the C# stuff.
>>
>> ? ? ? ?If you'd really like to see MS-SQL support (or if you just happen
>> to
>> have some C# experience and would like to contribute to Bugzilla), this
>> is the way to help! :-)
>>
>> ? ? ? ?-Max
>>
>
> -
> 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  Thu Apr  8 01:20:23 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Wed, 07 Apr 2010 18:20:23 -0700
Subject: Need Help with C# Reviews, for MS-SQL Support!
In-Reply-To: <4BBCC5AD.6000209@gmail.com>
References: <4BBC0CDC.4050403@bugzilla.org> <4BBCC5AD.6000209@gmail.com>
Message-ID: <4BBD2F57.9070602@bugzilla.org>

On 04/07/2010 10:49 AM, Bill Barry wrote:
> Should Bugzilla style conventions be used for this project or standard
> C# ones?

	Whatever is most comfortable and standard for reading. We generally
have slightly different style guides for all the various languages we
use, so I'd say to go with C# standards if they're definite standards,
and to follow the Bugzilla style guide where there's any ambiguity.

> quote: Do capitalize only the first character of acronyms
> with three or more characters, except the first word of a camel-cased
> identifier

	I support this, FWIW. The best example I saw on reasons for this naming
were from Effective Java--HttpUrl is readable, HTTPURL is less so.

	But yeah, the comments should go on the bug, and we'll respond to them
there. Thank you so much for your detailed review, Bill. :-)

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


From mkanat at bugzilla.org  Thu Apr  8 04:01:22 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Wed, 07 Apr 2010 21:01:22 -0700
Subject: How To Port Forward Customizations From One Bzr Branch to a Newer
 Bzr Branch
Message-ID: <4BBD5512.7070806@bugzilla.org>

	Let's say that you have a customized Bugzilla 3.4 in a local bzr
branch, and you want to upgrade to Bugzilla 3.6. Here's how to do it:

	cd custom-bugzilla-3.4
	bzr bundle bzr://bzr.mozilla.org/bugzilla/3.4 > ../customizations.diff
	cd ..
	bzr co bzr://bzr.mozilla.org/bugzilla/3.6 new-custom-3.6
	cd new-custom-3.6
	bzr merge ../customizations.diff

	And then resolve any conflicts, and then commit.

	You can't just merge 3.6 into 3.4. Unfortunately that doesn't work,
because we frequently added patches to both 3.4 and 3.6 that are
slightly different, and thus there are conflicts. (This would work
better if we had a slightly different development methodology, but
that's something I'm still thinking about, and for now, the above
instructions work very well and are really easy to do.)

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


From gerv at mozilla.org  Wed Apr 14 10:18:35 2010
From: gerv at mozilla.org (Gervase Markham)
Date: Wed, 14 Apr 2010 11:18:35 +0100
Subject: Apache.org JIRA compromise
Message-ID: <aZKdnfr8WafhC1jWnZ2dnUVZ_rSdnZ2d@mozilla.org>

We rock:
https://blogs.apache.org/infra/entry/apache_org_04_09_2010

"JIRA and Confluence both use a SHA-512 hash, but without a random salt. 
We believe the risk to simple passwords based on dictionary words is 
quite high, and most users should rotate their passwords.

Bugzilla uses a SHA-256, including a random salt. The risk for most 
users is low to moderate, since pre-built password dictionaries are not 
effective, but we recommend users should still remove these passwords 
from use."

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


From guy.pyrzak at gmail.com  Wed Apr 14 14:15:41 2010
From: guy.pyrzak at gmail.com (Guy Pyrzak)
Date: Wed, 14 Apr 2010 10:15:41 -0400
Subject: Apache.org JIRA compromise
In-Reply-To: <aZKdnfr8WafhC1jWnZ2dnUVZ_rSdnZ2d@mozilla.org>
References: <aZKdnfr8WafhC1jWnZ2dnUVZ_rSdnZ2d@mozilla.org>
Message-ID: <k2rdf4dec6f1004140715z90456f99qdb18cc62ef857df3@mail.gmail.com>

Newer versions of Bugzilla use an MD5-hash with salt, I believe. So they
might have been even safer if they had upgraded.

-Guy

On Wed, Apr 14, 2010 at 6:18 AM, Gervase Markham <gerv at mozilla.org> wrote:

> We rock:
> https://blogs.apache.org/infra/entry/apache_org_04_09_2010
>
> "JIRA and Confluence both use a SHA-512 hash, but without a random salt. We
> believe the risk to simple passwords based on dictionary words is quite
> high, and most users should rotate their passwords.
>
> Bugzilla uses a SHA-256, including a random salt. The risk for most users
> is low to moderate, since pre-built password dictionaries are not effective,
> but we recommend users should still remove these passwords from use."
>
> Gerv
> _______________________________________________
> dev-apps-bugzilla mailing list
> dev-apps-bugzilla at lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-bugzilla
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=guy.pyrzak at gmail.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20100414/7d961883/attachment.html>

From reed at reedloden.com  Wed Apr 14 15:49:14 2010
From: reed at reedloden.com (Reed Loden)
Date: Wed, 14 Apr 2010 10:49:14 -0500
Subject: Apache.org JIRA compromise
In-Reply-To: <k2rdf4dec6f1004140715z90456f99qdb18cc62ef857df3@mail.gmail.com>
References: <aZKdnfr8WafhC1jWnZ2dnUVZ_rSdnZ2d@mozilla.org>
	<k2rdf4dec6f1004140715z90456f99qdb18cc62ef857df3@mail.gmail.com>
Message-ID: <20100414104914.47eb1473.reed@reedloden.com>

On Wed, 14 Apr 2010 10:15:41 -0400
Guy Pyrzak <guy.pyrzak at gmail.com> wrote:

> Newer versions of Bugzilla use an MD5-hash with salt, I believe. So they
> might have been even safer if they had upgraded.

No, SHA-256 hash with per-user unique salts is what current Bugzilla
trunk (since 3.4, iirc) uses. MD5 hash is bad and should be avoided at
all costs. We could technically swap to SHA-512, but I'm not sure it's
worth it for what little extra "protection" would be gained (vs. the
cost of computing the hash).

~reed

-- 
Reed Loden - <reed at reedloden.com>

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


From guy.pyrzak at gmail.com  Wed Apr 14 17:58:28 2010
From: guy.pyrzak at gmail.com (Guy Pyrzak)
Date: Wed, 14 Apr 2010 10:58:28 -0700
Subject: Apache.org JIRA compromise
In-Reply-To: <20100414104914.47eb1473.reed@reedloden.com>
References: <aZKdnfr8WafhC1jWnZ2dnUVZ_rSdnZ2d@mozilla.org>
	 <k2rdf4dec6f1004140715z90456f99qdb18cc62ef857df3@mail.gmail.com>
	 <20100414104914.47eb1473.reed@reedloden.com>
Message-ID: <g2hdf4dec6f1004141058v903b6e56mf28b009141ffdec@mail.gmail.com>

Ah, did we recently upgrade from the MD5 then? I just know we changed our
password hashing method recently.

-Guy

On Wed, Apr 14, 2010 at 8:49 AM, Reed Loden <reed at reedloden.com> wrote:

> On Wed, 14 Apr 2010 10:15:41 -0400
> Guy Pyrzak <guy.pyrzak at gmail.com> wrote:
>
> > Newer versions of Bugzilla use an MD5-hash with salt, I believe. So they
> > might have been even safer if they had upgraded.
>
> No, SHA-256 hash with per-user unique salts is what current Bugzilla
> trunk (since 3.4, iirc) uses. MD5 hash is bad and should be avoided at
> all costs. We could technically swap to SHA-512, but I'm not sure it's
> worth it for what little extra "protection" would be gained (vs. the
> cost of computing the hash).
>
> ~reed
>
> --
> Reed Loden - <reed at reedloden.com>
>
> _______________________________________________
> dev-apps-bugzilla mailing list
> dev-apps-bugzilla at lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-bugzilla
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=guy.pyrzak at gmail.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20100414/a7fbc7bc/attachment.html>

From lpsolit at gmail.com  Wed Apr 14 18:09:03 2010
From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=)
Date: Wed, 14 Apr 2010 20:09:03 +0200
Subject: Apache.org JIRA compromise
In-Reply-To: <g2hdf4dec6f1004141058v903b6e56mf28b009141ffdec@mail.gmail.com>
References: <aZKdnfr8WafhC1jWnZ2dnUVZ_rSdnZ2d@mozilla.org>	 <k2rdf4dec6f1004140715z90456f99qdb18cc62ef857df3@mail.gmail.com>	 <20100414104914.47eb1473.reed@reedloden.com> <g2hdf4dec6f1004141058v903b6e56mf28b009141ffdec@mail.gmail.com>
Message-ID: <4BC604BF.4090800@gmail.com>

Le 14. 04. 10 19:58, Guy Pyrzak a ?crit :
> Ah, did we recently upgrade from the MD5 then? I just know we changed our
> password hashing method recently.

We moved from crypt() to SHA-256 in Bugzilla 3.4 (or 3.3.1, to be exact)
in early 2009, see bug 211006.

LpSolit


From mkanat at bugzilla.org  Wed Apr 14 20:09:55 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Wed, 14 Apr 2010 13:09:55 -0700
Subject: Apache.org JIRA compromise
In-Reply-To: <aZKdnfr8WafhC1jWnZ2dnUVZ_rSdnZ2d@mozilla.org>
References: <aZKdnfr8WafhC1jWnZ2dnUVZ_rSdnZ2d@mozilla.org>
Message-ID: <4BC62113.7040802@bugzilla.org>

On 04/14/2010 03:18 AM, Gervase Markham wrote:
> We rock:
> https://blogs.apache.org/infra/entry/apache_org_04_09_2010

	Indeed, the whole attack would have been impossible against Bugzilla. I
wrote about it here:

	http://avatraxiom.livejournal.com/102080.html

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


From mkanat at bugzilla.org  Thu Apr 15 03:32:33 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Wed, 14 Apr 2010 20:32:33 -0700
Subject: Tinderboxen Temporarily Offline
Message-ID: <4BC688D1.3050309@bugzilla.org>

	The Bugzilla tinderbox tests are killing the performance of landfill
and the other VMs on the same box, to the point that the IRC bots keep
falling offline, some users are unable to download glob's Windows
installers, and I am frequently unable to use landfill for development.

	We have a new machine, thanks to Mozilla, that the tests will be moving
to soon (possibly tomorrow). When that happens, the boxen will come back
online.

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


From mkgnu at mkgnu.net  Thu Apr 15 17:04:45 2010
From: mkgnu at mkgnu.net (Kristis Makris)
Date: Thu, 15 Apr 2010 10:04:45 -0700
Subject: [Fwd: Re: [scmbug-users] Error on changing status of bugs with
	Bugzilla  3.4.x]
Message-ID: <1271351085.3535.47.camel@localhost>

Hello,

How does bugzilla 3.2/3.4/3.6 handle errors with Bug::check() ? Does it
throw exceptions with die() ? Is this necessary ?

I'm sure you folks must have a more user-friendly API than this. We must
be missing something.

We are discussing this on:

http://lists.mkgnu.net/pipermail/scmbug-users/2010-April/002745.html

-------- Forwarded Message --------
From: Yavor Nikolov <nikolov.javor at gmail.com>
To: Kristis Makris <mkgnu at mkgnu.net>
Cc: scmbug-users <scmbug-users at lists.mkgnu.net>
Subject: Re: [scmbug-users] Error on changing status of bugs with
Bugzilla 3.4.x
Date: Thu, 15 Apr 2010 09:24:25 +0300

Bugzilla does throw exceptions (in a "die" way) on certain places: e.g.
- on calling Bug::check(), when providing bad user
- Invalid duplicate bug id
... etc.

I.e. - more often Bugzilla throws exception when error is encountered
(bad parameter, lack of permissions, etc.) than returning an error code.
Actually - exception handling is in general a cleaner approach to manage
error situations than dealing with return codes. Just the die/eval/$@/..
is some kind of limited workaround since older versions of Perl didn't
have exceptions.

So what happens if we don't catch these exceptions: scmbug dies, error
message is logged in scmbug log. However end user gets a general purpose
error which doesn't explain the root cause of the problem (i.e. user
receives something like "scmbug died for unknown reason" than duplicate
bug id is bad; or we don't have permissions to edit the bug).

Regards,
Yavor

On Thu, Apr 15, 2010 at 02:18, Kristis Makris <mkgnu at mkgnu.net> wrote:
        
        >         If there is a possibility for Bugzilla to raise
        exceptions
        >         inside the
        >         eval {} blocks, is there another way of eliminating
        that
        >         possibility ?
        > I think If we use the WebService API error would be signalled
        in a bit
        > different manner. Another approach would be to patch Bugzilla.
        
        
        I suppose my question is, why are we so fearful that something
        bad will
        happen that will throw an exception ? Can't we simply check the
        return
        values of function calls to see if the calls succeeded ?
        
        

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

From mkanat at bugzilla.org  Thu Apr 15 23:24:19 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Thu, 15 Apr 2010 16:24:19 -0700
Subject: [Fwd: Re: [scmbug-users] Error on changing status of bugs with
 Bugzilla  3.4.x]
In-Reply-To: <1271351085.3535.47.camel@localhost>
References: <1271351085.3535.47.camel@localhost>
Message-ID: <4BC7A023.4090203@bugzilla.org>

On 04/15/2010 10:04 AM, Kristis Makris wrote:
> How does bugzilla 3.2/3.4/3.6 handle errors with Bug::check() ? Does it
> throw exceptions with die() ? Is this necessary ?

	It calls ThrowUserError. By default this calls exit(), but you can
switch to Bugzilla->error_mode(ERROR_MODE_DIE) before calling it (and
then switch back to the normal error mode) if you'd like.

	However, generally you shouldn't be calling things inside of an
eval--there's always ways to check things for yourself. What
specifically are you trying to do?

> I'm sure you folks must have a more user-friendly API than this. We must
> be missing something.

	Yeah, the WebService is the API.

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


From nikolov.javor at gmail.com  Fri Apr 16 08:48:26 2010
From: nikolov.javor at gmail.com (Yavor Nikolov)
Date: Fri, 16 Apr 2010 11:48:26 +0300
Subject: [Fwd: Re: [scmbug-users] Error on changing status of bugs with 
	Bugzilla 3.4.x]
In-Reply-To: <4BC7A023.4090203@bugzilla.org>
References: <1271351085.3535.47.camel@localhost> <4BC7A023.4090203@bugzilla.org>
Message-ID: <o2z8e45d0591004160148s6821a58av194dec1d33fb600c@mail.gmail.com>

Hi,

Kristis will explain best what he means - here are my comments below inline
(since I'm the one intending to wrap bugzilla calls in eval block). Excuse
me for my ignorance since I'm not a Perl guru (I just got involved to fix my
problems as end user).

On Fri, Apr 16, 2010 at 02:24, Max Kanat-Alexander <mkanat at bugzilla.org>wrote:

> On 04/15/2010 10:04 AM, Kristis Makris wrote:
> > How does bugzilla 3.2/3.4/3.6 handle errors with Bug::check() ? Does it
> > throw exceptions with die() ? Is this necessary ?
>
>         It calls ThrowUserError. By default this calls exit(), but you can
> switch to Bugzilla->error_mode(ERROR_MODE_DIE) before calling it (and
> then switch back to the normal error mode) if you'd like.
>
We're calling this from separate perl application - not as CGI. So I believe
error_mode is ERROR_MODE_DIE by default in our case.


>
>        However, generally you shouldn't be calling things inside of an
> eval--there's always ways to check things for yourself. What
> specifically are you trying to do?
>
Good to know if there are better alternatives. We have a daemon (perl
application) which is integrating version control systems (e.g. Subversion)
with Bug-tracking system (Bugzilla). So for example - on commit to version
control we want to perform following with Bugzilla on behalf of the user
performing scm commit (we have the mapping to the corresponding bugzilla
username):
 - add comment to the bug (extracted from version control system commit
message)
 - update bugzilla bug status and resolution; or reassign bug
 - send e-mail notifications to interested parties (that's my custom
extension not yet in official scmbug release)
 - Some other checks and verifications (e.g. possible workflow transitions
are extracted to signal some errors even before version control commit).
* And on error version control user is supposed to get appropriate error
message (e.g. the given duplicate bug id is wrong; the new asaignee user is
invalid; Lack of permissions to modify bug).


For example - consider following fragment of code:
        my $dbh = Bugzilla->dbh;
        my @ret_list = eval {
        my $userid = Bugzilla::User::login_to_id( $username );
        if ( $userid > 0 ) {
            $dbh->bz_start_transaction();
            my $user = new Bugzilla::User($userid);
            Bugzilla->set_user($user);
            my $bug = Bugzilla::Bug->check($bugid);
            $bug->add_comment($comment, {isprivate => 0, work_time => 0,
type => Bugzilla::Constants->CMT_NORMAL, extra_data => ""} );
            $bug->update();
            $dbh->bz_commit_transaction();
            return 0;
        } else {
            # This should never happen. Each user should have a
            # corresponding userid in the database schema
            return 1, "Login '$username' could not be converted to an id in
Bugzilla. Is username mapping setup correctly in daemon.conf ?\n" ;
        }
        }; # eval
        if ($@) {
            my $err = $@;
            log_daemon_warn( undef, $err );
            $dbh->bz_rollback_transaction() if $dbh->bz_in_transaction();
            return 1, "Error while adding bug comment: $err";
        }
        else {
            return @ret_list;
        }

We didn't have eval block here before - which resulted in aborting
processing when check() fails and notifying scm user with quite general
error message.

The case with change of status resolution is more interesting - you can see
last section of additions (within eval block) in the attached patch.

I added that patch to simplify a bit the communication between scmbug and
Bugzilla and reduce compatibility issues with current and future releases.
What we had before was code initially developed against older versions of
Bugzilla with multiple direct database calls, explicit validations.

So from my point of view - some kind of exception handling seems better in
order to avoid bloating code and checking return codes on each step. However
I see some drawbacks with the current die/eval/if($@) approach that I'm
trying to hook in scmbug with that patch:
 - die/eval has some limitations - it's not easy /if possible at all/ to
track original call stack (in order to see where did the error came from).
 - Nor type of error could be easily distinguished (it's just plain text).
 + Recent versions of Perl support object oriented exception handling
mechanism which sounds better to me.


>
> > I'm sure you folks must have a more user-friendly API than this. We must
> > be missing something.
>
>         Yeah, the WebService is the API.
>
I can't find the link now but I've found some discussion where Kristis
explained that WebService API was not powerful enough (maybe since the
scmbug daemon should be able to impersonate as any user without requesting
version control user to provide a password).
As far as I see - Bugzilla cgi modules are using Perl API instead of
WebService too.


>
>        -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=nikolov.javor at gmail.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20100416/75cb658c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Bugzilla.pm-resolution-and-comment-latest_version.patch
Type: application/octet-stream
Size: 6434 bytes
Desc: not available
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20100416/75cb658c/attachment.obj>

From mkanat at bugzilla.org  Fri Apr 16 09:01:45 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Fri, 16 Apr 2010 02:01:45 -0700
Subject: [Fwd: Re: [scmbug-users] Error on changing status of bugs with
 	Bugzilla 3.4.x]
In-Reply-To: <o2z8e45d0591004160148s6821a58av194dec1d33fb600c@mail.gmail.com>
References: <1271351085.3535.47.camel@localhost> <4BC7A023.4090203@bugzilla.org> <o2z8e45d0591004160148s6821a58av194dec1d33fb600c@mail.gmail.com>
Message-ID: <4BC82779.6090008@bugzilla.org>

On 04/16/2010 01:48 AM, Yavor Nikolov wrote:
> We're calling this from separate perl application - not as CGI. So I
> believe error_mode is ERROR_MODE_DIE by default in our case.

	Yeah, if you're not running in a web server, you're using
ERROR_MODE_DIE by default.

> Good to know if there are better alternatives. We have a daemon (perl
> application) which is integrating version control systems (e.g.
> Subversion) with Bug-tracking system (Bugzilla).

	Yeah, I know what scmbug is. :-) I just needed to see the code of what
you were doing.

>  - add comment to the bug (extracted from version control system commit
> message)

	I'd suggest doing this via the WebServices--Bug.add_comment.

>  - update bugzilla bug status and resolution; or reassign bug

>         my @ret_list = eval {

	Don't run the whole block of code in an eval--just run the parts that
can throw errors.

>         my $userid = Bugzilla::User::login_to_id( $username );

	You should probably just be doing "my $user = new Bugzilla::User({ name
=> $username }) there.

	You could also do:

	my $user = eval { Bugzilla::User->check($username) };
	error($@) if !$user;

>             my $bug = Bugzilla::Bug->check($bugid);

	Okay, that you can do, but wrap it in an eval and return the error to
the user if there's a problem.

	So you'd want to do something like:

	my $bug = eval { Bugzilla::Bug->check($bugid) };
	error($@) if !$bug;

	Note that error() is a made-up subroutine. I just mean handle the error
however scmbug normally does.

>             $bug->add_comment($comment, {isprivate => 0, work_time => 0,
> type => Bugzilla::Constants->CMT_NORMAL, extra_data => ""} );

	You don't need to specify those extra arguments if they're all at the
defaults.

	This could *theoretically* throw an error, although it's pretty
unlikely. You could put it in an eval if you *really want to*.

>             $bug->update();

	$bug->update() is not generally capable of throwing an error.

>             $dbh->bz_commit_transaction();

	You don't need bz_start_transaction or bz_commit_transaction for this
block, you can get rid of them. $bug->update() will do a transaction itself.

>  - Nor type of error could be easily distinguished (it's just plain text).

	You shouldn't have to distinguish the type of error, in this particular
case, though--just return it to the user.

>  + Recent versions of Perl support object oriented exception handling
> mechanism which sounds better to me.

	No, they don't. There are just various CPAN modules available that
attempt to implement exceptions, and they probably aren't quite as good
as you'd imagine.

> I can't find the link now but I've found some discussion where Kristis
> explained that WebService API was not powerful enough (maybe since the
> scmbug daemon should be able to impersonate as any user without
> requesting version control user to provide a password).

	Well, okay. You could also have scmbug use one Bugzilla user for all of
its changes.

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


From nikolov.javor at gmail.com  Fri Apr 16 12:55:30 2010
From: nikolov.javor at gmail.com (Yavor Nikolov)
Date: Fri, 16 Apr 2010 15:55:30 +0300
Subject: [Fwd: Re: [scmbug-users] Error on changing status of bugs with 
	Bugzilla 3.4.x]
In-Reply-To: <4BC82779.6090008@bugzilla.org>
References: <1271351085.3535.47.camel@localhost> <4BC7A023.4090203@bugzilla.org> 
	<o2z8e45d0591004160148s6821a58av194dec1d33fb600c@mail.gmail.com> 
	<4BC82779.6090008@bugzilla.org>
Message-ID: <s2w8e45d0591004160555x358d8576vc988e58fa452ba33@mail.gmail.com>

Many thanks for your great feedback, Max!

On Fri, Apr 16, 2010 at 12:01, Max Kanat-Alexander <mkanat at bugzilla.org>wrote:

> On 04/16/2010 01:48 AM, Yavor Nikolov wrote:
> > We're calling this from separate perl application - not as CGI. So I
> > believe error_mode is ERROR_MODE_DIE by default in our case.
>
>         Yeah, if you're not running in a web server, you're using
> ERROR_MODE_DIE by default.
>
> > Good to know if there are better alternatives. We have a daemon (perl
> > application) which is integrating version control systems (e.g.
> > Subversion) with Bug-tracking system (Bugzilla).
>
>         Yeah, I know what scmbug is. :-) I just needed to see the code of
> what
> you were doing.
>
> >  - add comment to the bug (extracted from version control system commit
> > message)
>
>         I'd suggest doing this via the WebServices--Bug.add_comment.
>
> >  - update bugzilla bug status and resolution; or reassign bug
>
> >         my @ret_list = eval {
>
>        Don't run the whole block of code in an eval--just run the parts
> that
> can throw errors.
>
Well, maybe that's closest to what Kristis had in mind. But seems too much
bloating to me if we wrap each call to Bugzilla in eval and check each time
for errors (maybe not each function in Bugzilla is throwing errors but for
safety I'm assuming that it might throw one /some day in some release/).


>
> >         my $userid = Bugzilla::User::login_to_id( $username );
>
>         You should probably just be doing "my $user = new Bugzilla::User({
> name
> => $username }) there.
>
>        You could also do:
>
>        my $user = eval { Bugzilla::User->check($username) };
>        error($@) if !$user;
>
> >             my $bug = Bugzilla::Bug->check($bugid);
>
>         Okay, that you can do, but wrap it in an eval and return the error
> to
> the user if there's a problem.
>
>        So you'd want to do something like:
>
>        my $bug = eval { Bugzilla::Bug->check($bugid) };
>        error($@) if !$bug;
>
>        Note that error() is a made-up subroutine. I just mean handle the
> error
> however scmbug normally does.
>
> >             $bug->add_comment($comment, {isprivate => 0, work_time => 0,
> > type => Bugzilla::Constants->CMT_NORMAL, extra_data => ""} );
>
>         You don't need to specify those extra arguments if they're all at
> the
> defaults.
>
>        This could *theoretically* throw an error, although it's pretty
> unlikely. You could put it in an eval if you *really want to*.
>
> >             $bug->update();
>
>        $bug->update() is not generally capable of throwing an error.
>
> >             $dbh->bz_commit_transaction();
>
>        You don't need bz_start_transaction or bz_commit_transaction for
> this
> block, you can get rid of them. $bug->update() will do a transaction
> itself.
>
OK. I found that Object::update has start/commit transaction block but there
are some other actions in Bug::update after that which I'm not sure about
(activity log, duplicates, etc, ...)... Looking at process_bug.cgi I felt
safer to wrap this in transaction block. (I'm not sure what isolation level
is being used).
In fact - original code here called bz_lock_tables/bz_unlock_tables which
has been removed from recent Bugzilla versions: that has triggered rewriting
these parts of scmbug. As first attempt to fix it I just replaced lock with
start and unlock with commit.


>
> >  - Nor type of error could be easily distinguished (it's just plain
> text).
>
>         You shouldn't have to distinguish the type of error, in this
> particular
> case, though--just return it to the user.
>
You're right - in the particular cases we're just passing the error message
to user. My comment has been of a bit more general nature:
 - imagine we have some bulk activity - adding comments, updating status,
resolution, etc. And same error message (e.g. invalid bug id) may come out
from different places. We may want to know if it's a problem with duplicate
bug id (DUPLICATE OF); or the main bug.
 - Or we may want to distinguish between more common user errors (bad
argument provided: resolution status name, bug id, username, etc); security
error; CodeError; or a more fatal one (database, etc.)


>
> >  + Recent versions of Perl support object oriented exception handling
> > mechanism which sounds better to me.
>
>         No, they don't. There are just various CPAN modules available that
> attempt to implement exceptions, and they probably aren't quite as good
> as you'd imagine.
>
Good point (damn Perl... :-)) I got false impression that these have been
designed as part of language... But really that seems more like a wish for
future: http://dev.perl.org/perl6/rfc/63.pod, though some improvements have
been added in v 5.005 as per this article:
http://www.perl.com/pub/a/2002/11/14/exception.html?page=1


> > I can't find the link now but I've found some discussion where Kristis
> > explained that WebService API was not powerful enough (maybe since the
> > scmbug daemon should be able to impersonate as any user without
> > requesting version control user to provide a password).
>
>         Well, okay. You could also have scmbug use one Bugzilla user for
> all of
> its changes.
>
The point is that we want to see same result as if the committing user
itself has updated the bug. But maybe we could make that work if it's
possible to log-in as user with sudoer user and impersonate to someone later
- is it? At first glimpse I can't see how to call  Bugzilla::BugMail::Send(
$bugid, $vars ); either.
Anyway - definitely interaction through the WebService API is something I'd
like to experiment with (could flesh out other limitations which may be good
for WebService API improvement ideas). I hope there is a better
object-oriented approach (i.e. proxy to look like just as the real object)
to call web service methods in Perl than passing around strings (what I see
in bz_webservice_demo.pl).


>
>        -Max
> --
> http://www.everythingsolved.com/
> Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20100416/d1d1a1e7/attachment.html>

From mkanat at bugzilla.org  Sat Apr 17 01:27:41 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Fri, 16 Apr 2010 18:27:41 -0700
Subject: [Fwd: Re: [scmbug-users] Error on changing status of bugs with
 	Bugzilla 3.4.x]
In-Reply-To: <s2w8e45d0591004160555x358d8576vc988e58fa452ba33@mail.gmail.com>
References: <1271351085.3535.47.camel@localhost> <4BC7A023.4090203@bugzilla.org> 	<o2z8e45d0591004160148s6821a58av194dec1d33fb600c@mail.gmail.com> 	<4BC82779.6090008@bugzilla.org> <s2w8e45d0591004160555x358d8576vc988e58fa452ba33@mail.gmail.com>
Message-ID: <4BC90E8D.1090308@bugzilla.org>

On 04/16/2010 05:55 AM, Yavor Nikolov wrote:
> Well, maybe that's closest to what Kristis had in mind. But seems too
> much bloating to me if we wrap each call to Bugzilla in eval and check
> each time for errors (maybe not each function in Bugzilla is throwing
> errors but for safety I'm assuming that it might throw one /some day in
> some release/).

	It's not bloat. As you can see by my comments below, only one statement
in your code needed eval{}.

	Functions that don't throw errors now probably won't start throwing
errors in the future.

> OK. I found that Object::update has start/commit transaction block but
> there are some other actions in Bug::update after that which I'm not
> sure about (activity log, duplicates, etc, ...)... Looking at
> process_bug.cgi I felt safer to wrap this in transaction block. (I'm not
> sure what isolation level is being used).

	You don't need to wrap it in a transaction.

>  - imagine we have some bulk activity - adding comments, updating
> status, resolution, etc. And same error message (e.g. invalid bug id)
> may come out from different places. We may want to know if it's a
> problem with duplicate bug id (DUPLICATE OF); or the main bug.

	The error message from Bugzilla will tell you that. If it doesn't, you
can file a bug requesting that Bugzilla throw a clearer error message.

>  - Or we may want to distinguish between more common user errors (bad
> argument provided: resolution status name, bug id, username, etc);
> security error; CodeError; or a more fatal one (database, etc.)

	When you have a specific instance of wanting to do this, there will
most likely be a way to handle it.

> Good point (damn Perl... :-)) I got false impression that these have
> been designed as part of language... But really that seems more like a
> wish for future: http://dev.perl.org/perl6/rfc/63.pod,

	Perl 6 is not the same language as Perl 5. (Confusing, I know.)

> The point is that we want to see same result as if the committing user
> itself has updated the bug.

	Okay. Starting with Bugzilla 3.6, you could also write an Extension
that would help you do what you want.

> But maybe we could make that work if it's
> possible to log-in as user with sudoer user and impersonate to someone
> later - is it?

	It might be possible, although sudoers can't impersonate admins. It's
not possible via the WebService, currently, though, at all.

> At first glimpse I can't see how to call
> Bugzilla::BugMail::Send( $bugid, $vars ); either.

	You would never call that yourself in the WebService--it does it for you.

> I hope there is a better
> object-oriented approach (i.e. proxy to look like just as the real
> object) to call web service methods in Perl than passing around strings

	The WebService is documented here:

	http://www.bugzilla.org/docs/tip/en/html/api/Bugzilla/WebService.html

	It is not SOAP, if that is what you're asking. It is instead a simple
series of functions that perform specific actions. Depending on what
language you're using, there are various libraries that wrap Bugzilla's
WebService API. For Perl there's BZ::Client:
http://search.cpan.org/dist/BZ-Client/

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


From nikolov.javor at gmail.com  Sat Apr 17 07:21:12 2010
From: nikolov.javor at gmail.com (Yavor Nikolov)
Date: Sat, 17 Apr 2010 10:21:12 +0300
Subject: [Fwd: Re: [scmbug-users] Error on changing status of bugs with 
	Bugzilla 3.4.x]
In-Reply-To: <4BC90E8D.1090308@bugzilla.org>
References: <1271351085.3535.47.camel@localhost> <4BC7A023.4090203@bugzilla.org> 
	<o2z8e45d0591004160148s6821a58av194dec1d33fb600c@mail.gmail.com> 
	<4BC82779.6090008@bugzilla.org> <s2w8e45d0591004160555x358d8576vc988e58fa452ba33@mail.gmail.com> 
	<4BC90E8D.1090308@bugzilla.org>
Message-ID: <w2i8e45d0591004170021jbad33109g9506134b01859235@mail.gmail.com>

Thanks again for your reply, Max!

On Sat, Apr 17, 2010 at 04:27, Max Kanat-Alexander <mkanat at bugzilla.org>wrote:

> On 04/16/2010 05:55 AM, Yavor Nikolov wrote:
> > Well, maybe that's closest to what Kristis had in mind. But seems too
> > much bloating to me if we wrap each call to Bugzilla in eval and check
> > each time for errors (maybe not each function in Bugzilla is throwing
> > errors but for safety I'm assuming that it might throw one /some day in
> > some release/).
>
>         It's not bloat. As you can see by my comments below, only one
> statement
> in your code needed eval{}.
>
Agreed for this case. A bit simplified code of the function which raised the
question here is something like that (I know we can merge all these 3-4
set_status calls into 1 - but let's imagine we have several of them):
         my @ret_list = eval {
        ...
        my $user = Bugzilla::User->new( { name => $username } );
        Bugzilla->set_user($user);
        my $bug = Bugzilla::Bug->check($bugid);
        ...
        ...
        ...
                my $assignee_user = Bugzilla::User->new( {name =>
$resolution} );
        ...
                $bug->set_assigned_to($assignee_user);
        ...
        ...
            $dbh->bz_start_transaction();
        ...
        ... if (...) {
        ...
            $bug->set_status($new_status1);
        ...
        ... else {
        ...
            $bug->set_status($new_status4, $my_resolution);
        ...

            $bug->update();
            $dbh->bz_commit_transaction();

            return 0;
        ...
        }; # eval
        if ($@) {
            my $err = $@;
            log_daemon_warn( undef, $err );
            $dbh->bz_rollback_transaction() if $dbh->bz_in_transaction();
            return 1, "Error while changing bug resolution: $err";
        }
        else {
            return @ret_list;
        }

I suppose you'll suggest start_transaction is not needed here either.
Is there anything bad in particular if we wrap multiple statements in eval
block? I know Kristis opened that request to ask for better alternative but
I still can't see why calling eval multiple times is cleaner (In case we
don't need to do anything special on these errors nor to customize error
message).


>        Functions that don't throw errors now probably won't start throwing
> errors in the future.
>
> > OK. I found that Object::update has start/commit transaction block but
> > there are some other actions in Bug::update after that which I'm not
> > sure about (activity log, duplicates, etc, ...)... Looking at
> > process_bug.cgi I felt safer to wrap this in transaction block. (I'm not
> > sure what isolation level is being used).
>
>         You don't need to wrap it in a transaction.
>
Great. Is it bad to to so? Imagine following scenario:
1. We're already in transaction for some reason (e.g. bugzilla throwed error
in the middle of transaction and didn't rollback since it's in eval block.
Could be other reason too).
2. We call set_status (RESOLVED DUPLICATE M) and update for bug N - no
errors raised here. All seems OK.
3. Something else goes wrong later (e.g. dealing with another bug -
Bug->check($user)). As result: bz_rollback_transaction is called (e.g. by
ThrowUserError outside eval block; or we quit/or abort scmbug deamon). In
fact - even if nothing fails - transaction is not committed either.
---
Finally: we have the considered successful update of bug N not reflected in
bugzilla database. (I just tested that and the result is as bug N is in fact
not updated as I suspected).


> >  - imagine we have some bulk activity - adding comments, updating
> > status, resolution, etc. And same error message (e.g. invalid bug id)
> > may come out from different places. We may want to know if it's a
> > problem with duplicate bug id (DUPLICATE OF); or the main bug.
>
>         The error message from Bugzilla will tell you that. If it doesn't,
> you
> can file a bug requesting that Bugzilla throw a clearer error message.
>
> >  - Or we may want to distinguish between more common user errors (bad
> > argument provided: resolution status name, bug id, username, etc);
> > security error; CodeError; or a more fatal one (database, etc.)
>
>         When you have a specific instance of wanting to do this, there will
> most likely be a way to handle it.
>
> > Good point (damn Perl... :-)) I got false impression that these have
> > been designed as part of language... But really that seems more like a
> > wish for future: http://dev.perl.org/perl6/rfc/63.pod,
>
>         Perl 6 is not the same language as Perl 5. (Confusing, I know.)
>
> > The point is that we want to see same result as if the committing user
> > itself has updated the bug.
>
>         Okay. Starting with Bugzilla 3.6, you could also write an Extension
> that would help you do what you want.
>
Seems a nice feature! But that means we'll need to maintain these
extensions, which will rely on the Perl API - pretty much same low-level
dependency on Bugzilla we have now in scmbug.


>
> > But maybe we could make that work if it's
> > possible to log-in as user with sudoer user and impersonate to someone
> > later - is it?
>
>         It might be possible, although sudoers can't impersonate admins.
> It's
> not possible via the WebService, currently, though, at all.
>
> > At first glimpse I can't see how to call
> > Bugzilla::BugMail::Send( $bugid, $vars ); either.
>
>         You would never call that yourself in the WebService--it does it
> for you.
>
> > I hope there is a better
> > object-oriented approach (i.e. proxy to look like just as the real
> > object) to call web service methods in Perl than passing around strings
>
>         The WebService is documented here:
>
>
> http://www.bugzilla.org/docs/tip/en/html/api/Bugzilla/WebService.html
>
>        It is not SOAP, if that is what you're asking. It is instead a
> simple
> series of functions that perform specific actions. Depending on what
> language you're using, there are various libraries that wrap Bugzilla's
> WebService API. For Perl there's BZ::Client:
> http://search.cpan.org/dist/BZ-Client/
>
Thanks for that reference. I asked about something like BZ::Client imagining
that this could be automatically generated from WS definition - I want most
of code look the same /no matter if it's direct Bugzilla Perl call or via
web service/. I didn't know it doesn't support SOAP - maybe that means lack
of self-description which clarifies my automatic proxy generation question.


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

Regards,
Yavor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20100417/bbfc20a9/attachment.html>

From mkgnu at mkgnu.net  Sun Apr 18 16:24:52 2010
From: mkgnu at mkgnu.net (Kristis Makris)
Date: Sun, 18 Apr 2010 09:24:52 -0700
Subject: [Fwd: Re: [scmbug-users] Error on changing status of bugs with
	Bugzilla 3.4.x]
In-Reply-To: <4BC82779.6090008@bugzilla.org>
References: <1271351085.3535.47.camel@localhost>
	 <4BC7A023.4090203@bugzilla.org>
	 <o2z8e45d0591004160148s6821a58av194dec1d33fb600c@mail.gmail.com>
	 <4BC82779.6090008@bugzilla.org>
Message-ID: <1271607892.3979.15.camel@localhost>

Max thanks for spending time on this.

I believe my question boils down to:

> 	my $user = eval { Bugzilla::User->check($username) };

1. Does the check() call return a value we could test for error (rather
than parse an error message string), and
2. How can we avoid the scmbug process calling check() from dieing ?

You mentioned Bugzilla->error_mode(ERROR_MODE_DIE). That sounds like it
would lead the process to die. What is the "normal" error mode in which
the call to check() won't die, if there is one ?


From a design standpoint, I am not convinced that "eval" needs to be
part of the call to check(). But, if that's the state of things we'll
have to live with it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20100418/d4d46fdd/attachment.sig>

From mkanat at bugzilla.org  Mon Apr 19 08:02:17 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Mon, 19 Apr 2010 01:02:17 -0700
Subject: [Fwd: Re: [scmbug-users] Error on changing status of bugs with
 Bugzilla 3.4.x]
In-Reply-To: <1271607892.3979.15.camel@localhost>
References: <1271351085.3535.47.camel@localhost>	 <4BC7A023.4090203@bugzilla.org>	 <o2z8e45d0591004160148s6821a58av194dec1d33fb600c@mail.gmail.com>	 <4BC82779.6090008@bugzilla.org> <1271607892.3979.15.camel@localhost>
Message-ID: <4BCC0E09.6050807@bugzilla.org>

On 04/18/2010 09:24 AM, Kristis Makris wrote:
> 1. Does the check() call return a value we could test for error (rather
> than parse an error message string), and

	Hey Kristis. No, check() throws exceptions when there is a problem.

> 2. How can we avoid the scmbug process calling check() from dieing ?

	You can't--"die" is how Perl throws exceptions.

> You mentioned Bugzilla->error_mode(ERROR_MODE_DIE). That sounds like it
> would lead the process to die.

	It will lead the process to use "die" to throw errors. By default this 
is what scmbug will do anyhow, because that is the default for 
command-line applications.

> What is the "normal" error mode in which
> the call to check() won't die, if there is one ?

	The call to check() will always throw an error if there is a 
problem--that is what check() does. You could re-implement all of the 
checks that check() does yourself, which would be fragile in terms of 
forward-compatibility, or you could just call it and return the error to 
the user if there is an error.

>  From a design standpoint, I am not convinced that "eval" needs to be
> part of the call to check().

	The standard Perl exception-catching mechanism is eval {}. It's 
confusing, I know, but that's what it is. eval("") is slow, eval {} is fast.

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


From gerv at mozilla.org  Tue Apr 20 15:56:18 2010
From: gerv at mozilla.org (Gervase Markham)
Date: Tue, 20 Apr 2010 16:56:18 +0100
Subject: Bugzilla RESTful API: Status Update
Message-ID: <yISdnQGYS5A4U1DWnZ2dnUVZ_vidnZ2d@mozilla.org>

Back in September of last year, I posted asking for input on a RESTful 
HTTP API for Bugzilla. This project is now feature-complete, deployed 
and ready for production use:
https://wiki.mozilla.org/Bugzilla:REST_API

It is already suitable for:

- Mashups and tool integration[0]

- Jetpacks/Greasemonkey scripts to enhance the current Bugzilla UI[1]

- Guided bug-filing wizards[2]

- Personal dashboards[3]

- Task-specific bug filing or updating UIs[4]

- Bugzilla integration addons for Firefox and Thunderbird[5]

- Extracting data for doing statistical analysis[6]

(The project is not yet marked as version 1.0 because the API design has 
not been officially agreed by the Bugzilla project. But I hope there 
will be little or no further change.)

I am extremely interested in seeing people use this to solve their 
problems, and hearing how it could be further improved to address new 
use cases. If there are Bugzilla-related problems you want to solve and 
think BzAPI could help, please let me know.

Gerv

[0] http://hg.mozilla.org/users/mstange_themasta.com/tinderboxpushlog
[1] http://hg.mozilla.org/users/jnightingale_mozilla.com/jetpacks/
[2] http://hg.toolness.com/bugzilla-dashboard/raw-file/tip/file-bug.html
[3] 
http://hg.toolness.com/bugzilla-dashboard/raw-file/tip/index.html?username=avarma at mozilla.com
[4] https://l10n-stage-sj.mozilla.org/bugs/file-bugs
[5] https://addons.mozilla.org/en-US/thunderbird/addon/45501
[6] Talk to dascher or murali
_______________________________________________
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 Apr 20 20:27:24 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Tue, 20 Apr 2010 13:27:24 -0700
Subject: Bugzilla 3.6 In The News
Message-ID: <4BCE0E2C.4000600@bugzilla.org>

	Hey folks. Just wanted to show you guys the few articles that got 
written up about the Bugzilla 3.6 release. :-)

OStatic: 
http://ostatic.com/blog/bugzilla-3-6-brings-extensions-and-addresses-usability
Softpedia: http://news.softpedia.com/news/Bugzilla-3-6-Released-139788.shtml

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


From szabgab at gmail.com  Thu Apr 22 07:36:45 2010
From: szabgab at gmail.com (Gabor Szabo)
Date: Thu, 22 Apr 2010 10:36:45 +0300
Subject: Bugzilla 3.6 In The News
In-Reply-To: <4BCE0E2C.4000600@bugzilla.org>
References: <4BCE0E2C.4000600@bugzilla.org>
Message-ID: <g2kd8a74af11004220036qac606224y12c99c1b466255db@mail.gmail.com>

congrats to both the release and the news coverage.
Have you done anything in particular to get the coverage or they just picked
up the release on the Bugzilla web site?

Gabor

On Tue, Apr 20, 2010 at 11:27 PM, Max Kanat-Alexander
<mkanat at bugzilla.org> wrote:
> ? ? ? ?Hey folks. Just wanted to show you guys the few articles that got
> written up about the Bugzilla 3.6 release. :-)
>
> OStatic:
> http://ostatic.com/blog/bugzilla-3-6-brings-extensions-and-addresses-usability
> Softpedia: http://news.softpedia.com/news/Bugzilla-3-6-Released-139788.shtml
>
> ? ? ? ?-Max


From szabgab at gmail.com  Thu Apr 22 07:38:37 2010
From: szabgab at gmail.com (Gabor Szabo)
Date: Thu, 22 Apr 2010 10:38:37 +0300
Subject: Bugzilla on LinuxTag Berlin
Message-ID: <h2qd8a74af11004220038hb58cd1bep5b08ea166d170d3f@mail.gmail.com>

hi,

the Perl community is going to have a Perl booth on LinuxTag Berlin in June.
We would like to represent a number of Perl based projects.

Is there anyone from Bugzilla around who would be interested in participating
(on some of the days) and show Bugzilla to the visitors?

more details here:
http://szabgab.com/blog/2010/04/1271829580.html

regards
   Gabor


From mkanat at bugzilla.org  Thu Apr 22 17:32:53 2010
From: mkanat at bugzilla.org (Max Kanat-Alexander)
Date: Thu, 22 Apr 2010 10:32:53 -0700
Subject: Bugzilla 3.6 In The News
In-Reply-To: <g2kd8a74af11004220036qac606224y12c99c1b466255db@mail.gmail.com>
References: <4BCE0E2C.4000600@bugzilla.org> <g2kd8a74af11004220036qac606224y12c99c1b466255db@mail.gmail.com>
Message-ID: <4BD08845.7070907@bugzilla.org>

On 04/22/2010 12:36 AM, Gabor Szabo wrote:
> congrats to both the release and the news coverage.

	Thanks!

> Have you done anything in particular to get the coverage or they just picked
> up the release on the Bugzilla web site?

	Well, Mozilla PR helps us out with outreach on major releases. However, 
if you have any thoughts on promotion beyond what we've done, I'd be 
totally interested (or perhaps Mozilla PR would be)!

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


From lpsolit at gmail.com  Sun Apr 25 21:57:21 2010
From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=)
Date: Sun, 25 Apr 2010 23:57:21 +0200
Subject: Bugzilla meeting on Tuesday, April 27
Message-ID: <4BD4BAC1.9080409@gmail.com>

Hello,

Our next Bugzilla meeting will take place on Tuesday, April 27, at 11:00
PDT (18:00 GMT, 20:00 CEST) in the #bugzilla-meeting channel on IRC, as
usual.

Our main topic will be to talk about Bugzilla 3.8, and confirm its
roadmap. I hope most of the core developers and active contributors can
attend, so that we can get a clear picture of what to expect for the
next few months. Less active developers are also welcome, of course. :)

For your information, our last meeting on February 16 has been canceled,
because we were only 3 developers present (oops!).


See you on Tuesday,

LpSolit


From justdave at bugzilla.org  Wed Apr 28 00:02:57 2010
From: justdave at bugzilla.org (David Miller)
Date: Tue, 27 Apr 2010 20:02:57 -0400
Subject: Fwd: Design Lunch this Thursday: Atul Varma on Bugzilla Dashboard
Message-ID: <4BD77B31.40203@bugzilla.org>

FYI, in case anyone's interested.  Looks cool so far.

-------- Original Message --------
Subject: Design Lunch this Thursday: Atul Varma on Bugzilla Dashboard
Date: Tue, 27 Apr 2010 16:01:25 -0700
From: Jono S. Xia <jdicarlo at mozilla.com>
Reply-To: jono at mozilla.com
Organization: Mozilla

This week's Design Lunch will feature Atul Varma presenting his Bugzilla 
  Dashboard, a higher-level interface to Bugzilla that helps you manage 
  your bugs while abstracting away a lot of the gruesome details of the 
  Bugzilla interface.  He'll be looking for your feedback on the design.

The Design Lunch is 12:30pm Pacific time in Ten-Forward in the Mountain 
View office, and will be recorded and broadcast on Air Mozilla.

Bugzilla Dashboard: http://bit.ly/bzdash

Instructions for calling in: https://wiki.mozilla.org/Labs/DesignLunch

See you there!
--Jono