From christian.masopust at siemens.com Tue Oct 2 06:11:05 2007 From: christian.masopust at siemens.com (Masopust, Christian) Date: Tue, 2 Oct 2007 08:11:05 +0200 Subject: Best way to move Product.... In-Reply-To: <20070928152424.0de5edf9@es-compy> References: <60721B67EAF0994EAFFB561767B700140125DAC3@nets13ha.ww300.siemens.net> <20070928152424.0de5edf9@es-compy> Message-ID: <60721B67EAF0994EAFFB561767B700140125DADB@nets13ha.ww300.siemens.net> Sorry again for wasting bandwidth, but i only want to say that it is fine to see that there are mailing-lists out there where you don't get flamed when posting to the wrong list.. and much more enjoyable is receiving an answer instead of getting flamed... :-) thanks a lot! christian -- "I sense much NT in you, NT leads to Blue Screen. Blue Screen leads to downtime, downtime leads to suffering. NT is the path to the darkside." - Unknown Unix Jedi > -----Original Message----- > From: developers-owner at bugzilla.org > [mailto:developers-owner at bugzilla.org] On Behalf Of Max > Kanat-Alexander > Sent: Saturday, September 29, 2007 12:24 AM > To: developers at bugzilla.org > Subject: Re: Best way to move Product.... > > On Fri, 28 Sep 2007 12:34:15 +0200 "Masopust, Christian" > wrote: > > is there a way to move a whole product from one Bugzilla to > an other?? > > Hi Christian. This question belongs on the support list, and > I've answered it there. You can find out about the support list here: > > http://www.bugzilla.org/support/ > > -Max > -- > http://www.everythingsolved.com/ > Competent, Friendly Bugzilla Services. And Everything Else, too. > - > To view or change your list settings, click here: > > From justdave at bugzilla.org Tue Oct 2 16:31:19 2007 From: justdave at bugzilla.org (David Miller) Date: Tue, 02 Oct 2007 12:31:19 -0400 Subject: Bugzilla meeting on Tuesday, October 2 at 18:00 GMT In-Reply-To: <46FBFE92.5010002@gmail.com> References: <46FBFE92.5010002@gmail.com> Message-ID: <47027257.3080907@bugzilla.org> Fr?d?ric Buclin wrote on 9/27/07 3:03 PM: > We will meet again on IRC next Tuesday, October 2 at 11:00 PST (18:00 > GMT, 20:00 CEST) in the #bugzilla-meeting channel. The meeting is public > and everybody is free to attend. We are getting closer to the freezing > date for Bugzilla 3.2, so tell us soon enough if something important > should land for 3.2 RC1. Features which won't be implemented on time > will be delayed till Bugzilla 4.0. Or 3.4? I didn't remember hearing we were going to do a full version bump again. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From lpsolit at gmail.com Tue Oct 2 16:37:10 2007 From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Tue, 02 Oct 2007 18:37:10 +0200 Subject: Bugzilla meeting on Tuesday, October 2 at 18:00 GMT In-Reply-To: <47027257.3080907@bugzilla.org> References: <46FBFE92.5010002@gmail.com> <47027257.3080907@bugzilla.org> Message-ID: <470273B6.6020305@gmail.com> >> should land for 3.2 RC1. Features which won't be implemented on time >> will be delayed till Bugzilla 4.0. > > Or 3.4? I didn't remember hearing we were going to do a full version > bump again. We said we would bump the version again if Bugzilla installations are able to talk to each others. This is probably something we can do as soon as Bug->update() is fully implemented. LpSolit From cchan at mvista.com Sat Oct 13 22:53:57 2007 From: cchan at mvista.com (Clement Chan) Date: Sat, 13 Oct 2007 15:53:57 -0700 Subject: 3.0 upgrade - checksetup.pl etc. Message-ID: <1192316037.28777.7.camel@bugtest> Hi, I am migrating a bugzilla 2.22 application to 3.0.2 and noticed lots of changes. For example, the checksetup.pl no longer deals with the creating of admin any more, all the LDAP stuff has been relocated to the contrib/ folder. And I just began the migration and have already encountered some sort of branching of codes. Is that because of a total new design? Are there any design documents out there that will help me to get a overall developer view of the upgrade? TIA, - Clement From mkanat at bugzilla.org Sat Oct 13 23:05:02 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sat, 13 Oct 2007 16:05:02 -0700 Subject: 3.0 upgrade - checksetup.pl etc. In-Reply-To: <1192316037.28777.7.camel@bugtest> References: <1192316037.28777.7.camel@bugtest> Message-ID: <20071013160502.25f99502@es-compy> On Sat, 13 Oct 2007 15:53:57 -0700 Clement Chan wrote: > For example, the checksetup.pl no longer deals with the > creating of admin any more, Um, untrue. It does create the admin. > all the LDAP stuff has been relocated to the contrib/ folder. Not true. > Are there any design documents out there that will > help me to get a overall developer view of the upgrade? You could read the API docs: http://www.bugzilla.org/docs/3.0/html/api/ Also feel free to come into IRC and ask us questions. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From cchan at mvista.com Sat Oct 13 23:08:57 2007 From: cchan at mvista.com (Clement Chan) Date: Sat, 13 Oct 2007 16:08:57 -0700 Subject: 3.0 upgrade - checksetup.pl etc. In-Reply-To: <20071013160502.25f99502@es-compy> References: <1192316037.28777.7.camel@bugtest> <20071013160502.25f99502@es-compy> Message-ID: <1192316937.28777.12.camel@bugtest> Thanks you Max, that's what I need, I will go over the APIs first and get to the IRC, - Clement On Sat, 2007-10-13 at 16:05 -0700, Max Kanat-Alexander wrote: > On Sat, 13 Oct 2007 15:53:57 -0700 Clement Chan > wrote: > > For example, the checksetup.pl no longer deals with the > > creating of admin any more, > > Um, untrue. It does create the admin. > > > all the LDAP stuff has been relocated to the contrib/ folder. > > Not true. > > > Are there any design documents out there that will > > help me to get a overall developer view of the upgrade? > > You could read the API docs: > > http://www.bugzilla.org/docs/3.0/html/api/ > > Also feel free to come into IRC and ask us questions. > > -Max From cchan at mvista.com Sat Oct 13 23:48:10 2007 From: cchan at mvista.com (Clement Chan) Date: Sat, 13 Oct 2007 16:48:10 -0700 Subject: 3.0 upgrade - checksetup.pl etc. In-Reply-To: <20071013160502.25f99502@es-compy> References: <1192316037.28777.7.camel@bugtest> <20071013160502.25f99502@es-compy> Message-ID: <1192319291.28777.22.camel@bugtest> I've found it, the admin stuff is in Bugzilla::Install::create_admin(), only partially LDAP stuff that can be run as script is relocated to contrib/, the core is still in LDAP.pm. I am in! - Clement On Sat, 2007-10-13 at 16:05 -0700, Max Kanat-Alexander wrote: > On Sat, 13 Oct 2007 15:53:57 -0700 Clement Chan > wrote: > > For example, the checksetup.pl no longer deals with the > > creating of admin any more, > > Um, untrue. It does create the admin. > > > all the LDAP stuff has been relocated to the contrib/ folder. > > Not true. > > > Are there any design documents out there that will > > help me to get a overall developer view of the upgrade? > > You could read the API docs: > > http://www.bugzilla.org/docs/3.0/html/api/ > > Also feel free to come into IRC and ask us questions. > > -Max From sam at predisposition.com Sun Oct 14 18:11:01 2007 From: sam at predisposition.com (Sam Folk-Williams) Date: Sun, 14 Oct 2007 14:11:01 -0400 Subject: database schema doc Message-ID: Hi, I'm looking at Bug 188033, which points out that this graphic is not properly updated: http://www.bugzilla.org/docs216/html/dbschema.html Looking at the current documentation, though, it looks like this isn't even in the docs any more. Am I right in assuming that we no longer produce this graphic and instead point people here: http://www.ravenbrook.com/project/p4dti/tool/cgi/bugzilla-schema/ ? -Sam From justdave at bugzilla.org Sun Oct 14 18:58:16 2007 From: justdave at bugzilla.org (David Miller) Date: Sun, 14 Oct 2007 14:58:16 -0400 Subject: database schema doc In-Reply-To: References: Message-ID: <471266C8.9060901@bugzilla.org> Sam Folk-Williams wrote on 10/14/07 2:11 PM: > I'm looking at Bug 188033, which points out that this graphic is not > properly updated: > > http://www.bugzilla.org/docs216/html/dbschema.html > > Looking at the current documentation, though, it looks like this isn't > even in the docs any more. > > Am I right in assuming that we no longer produce this graphic and > instead point people here: > > http://www.ravenbrook.com/project/p4dti/tool/cgi/bugzilla-schema/ > > ? Yes, that's correct. Nick Barnes has been great at keeping that updated (for which we're eternally grateful), and Perforce has been awesome to pay him to keep it that way. :) His charts have much more information on them than our old schema diagram did anyway. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From mkanat at bugzilla.org Tue Oct 16 08:48:26 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 16 Oct 2007 01:48:26 -0700 Subject: A Tool For Auto-Installing CPAN Packages Message-ID: <20071016014826.4c39a060@es-compy> To make Bugzilla installation easier, I've written a script that takes the hard work out of installing CPAN packages, and also easily allows a user to install CPAN packages to the local Bugzilla directory if they're not root. Anybody who feels like they have some experience with CPAN or wants to give some input is free to look over the patch here: https://bugzilla.mozilla.org/show_bug.cgi?id=262269 This will be the recommended way to install Bugzilla's Perl dependencies starting with Bugzilla 3.2. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From bugreport at peshkin.net Tue Oct 16 12:55:53 2007 From: bugreport at peshkin.net (Joel Peshkin) Date: Tue, 16 Oct 2007 05:55:53 -0700 Subject: A Tool For Auto-Installing CPAN Packages In-Reply-To: <20071016014826.4c39a060@es-compy> References: <20071016014826.4c39a060@es-compy> Message-ID: <4714B4D9.1040206@peshkin.net> Neat. I guess it would be interesting to be able to satisfy the modules' library dependencies the same way. I wonder if that is possible? From dwilliss at microimages.com Tue Oct 16 13:52:35 2007 From: dwilliss at microimages.com (Dave Williss) Date: Tue, 16 Oct 2007 08:52:35 -0500 Subject: A Tool For Auto-Installing CPAN Packages In-Reply-To: <20071016014826.4c39a060@es-compy> References: <20071016014826.4c39a060@es-compy> Message-ID: <4714C223.30104@microimages.com> I would also like to see a link on the download page which would download ALL the CPAN packages required by Bugzilla. Perhaps this package could be updated nightly via a cron script of something. Ideally, it would also come with a Makefile which would build and install only the packages which are not already installed or are newer than what's installed, and in the correct dependency order. The reason for this is that I've had to install Bugzilla multiple times on machines which were on a private LAN and did not have internet access, so just running CPAN to download and build packages wasn't possible. I'm sure there must be other sites with this same limitation. There *is* a list of CPAN modules that Bugzilla requires, but then sometimes those modules require other modules which require other modules, etc.. Dave Williss MicroImages, Inc. Max Kanat-Alexander wrote: > To make Bugzilla installation easier, I've written a script > that takes the hard work out of installing CPAN packages, and also > easily allows a user to install CPAN packages to the local Bugzilla > directory if they're not root. > > Anybody who feels like they have some experience with CPAN or > wants to give some input is free to look over the patch here: > > https://bugzilla.mozilla.org/show_bug.cgi?id=262269 > > This will be the recommended way to install Bugzilla's Perl > dependencies starting with Bugzilla 3.2. > > -Max > From sam at predisposition.com Tue Oct 16 16:54:51 2007 From: sam at predisposition.com (Sam Folk-Williams) Date: Tue, 16 Oct 2007 12:54:51 -0400 Subject: A Tool For Auto-Installing CPAN Packages In-Reply-To: <20071016014826.4c39a060@es-compy> References: <20071016014826.4c39a060@es-compy> Message-ID: On 10/16/07, Max Kanat-Alexander wrote: > To make Bugzilla installation easier, I've written a script > that takes the hard work out of installing CPAN packages, and also > easily allows a user to install CPAN packages to the local Bugzilla > directory if they're not root. > > Anybody who feels like they have some experience with CPAN or > wants to give some input is free to look over the patch here: > > https://bugzilla.mozilla.org/show_bug.cgi?id=262269 > > This will be the recommended way to install Bugzilla's Perl > dependencies starting with Bugzilla 3.2. > > -Max Max - at what point should these be added to the docs? > -- > http://www.everythingsolved.com/ > Competent, Friendly Bugzilla Services. And Everything Else, too. > - > To view or change your list settings, click here: > > From bugzilla at colinogilvie.co.uk Tue Oct 16 17:49:24 2007 From: bugzilla at colinogilvie.co.uk (Colin Ogilvie) Date: Tue, 16 Oct 2007 18:49:24 +0100 Subject: A Tool For Auto-Installing CPAN Packages In-Reply-To: References: <20071016014826.4c39a060@es-compy> Message-ID: <4714F9A4.6070409@colinogilvie.co.uk> Sam Folk-Williams wrote: > Max - at what point should these be added to the docs? They should be added to the documentation when they are checked in... it doesn't help to have the patches ready in advance for that though (and possibly attached to the same bug). Colin From bugzilla at colinogilvie.co.uk Tue Oct 16 19:06:02 2007 From: bugzilla at colinogilvie.co.uk (Colin Ogilvie) Date: Tue, 16 Oct 2007 20:06:02 +0100 Subject: A Tool For Auto-Installing CPAN Packages In-Reply-To: <4714F9A4.6070409@colinogilvie.co.uk> References: <20071016014826.4c39a060@es-compy> <4714F9A4.6070409@colinogilvie.co.uk> Message-ID: <47150B9A.5000601@colinogilvie.co.uk> Colin Ogilvie wrote: > They should be added to the documentation when they are checked in... > it doesn't help to have the patches ready in advance for that though > (and possibly attached to the same bug). Replace help with hurt in that sentence (Thanks Dave!) Colin From cchan at mvista.com Tue Oct 16 20:45:00 2007 From: cchan at mvista.com (Clement Chan) Date: Tue, 16 Oct 2007 13:45:00 -0700 Subject: A Tool For Auto-Installing CPAN Packages In-Reply-To: <20071016014826.4c39a060@es-compy> References: <20071016014826.4c39a060@es-compy> Message-ID: <1192567500.2594.15.camel@localhost6.localdomain6> I have problems installing the GD and XML::Twig modules for Bugzilla 3.0 on FC7, and I can't go to 3.2 because it's risky for the production environment. The staging server seems to be working fine, it is not a problem for upgrading. But setting a newly installed version on the workstation machine for development is a pain. ...still can't pass the checksetup.pl for a day of work. I am running FC7, and it uses mostly latest versions of libraries and Perl modules, the downloaded CPAN modules just clobber over each other. A quick and dirty solution is to have a list of the perl modules. If the latest isn't available, I can always grok for archive folder of the Author to retrieve earlier version. This will help me to install everything with just one pass, instead of juggling with dependencies issues between modules. Automation isn't as helpful for me. Does anyone happen to have the libraries and Perl module version list handy? - Clement On Tue, 2007-10-16 at 01:48 -0700, Max Kanat-Alexander wrote: > To make Bugzilla installation easier, I've written a script > that takes the hard work out of installing CPAN packages, and also > easily allows a user to install CPAN packages to the local Bugzilla > directory if they're not root. > > Anybody who feels like they have some experience with CPAN or > wants to give some input is free to look over the patch here: > > https://bugzilla.mozilla.org/show_bug.cgi?id=262269 > > This will be the recommended way to install Bugzilla's Perl > dependencies starting with Bugzilla 3.2. > > -Max From gerv at mozilla.org Tue Oct 16 22:25:00 2007 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 16 Oct 2007 23:25:00 +0100 Subject: A Tool For Auto-Installing CPAN Packages In-Reply-To: <20071016014826.4c39a060@es-compy> References: <20071016014826.4c39a060@es-compy> Message-ID: <47153A3C.6010607@mozilla.org> Max Kanat-Alexander wrote: > To make Bugzilla installation easier, I've written a script > that takes the hard work out of installing CPAN packages, and also > easily allows a user to install CPAN packages to the local Bugzilla > directory if they're not root. How does this interface with the Bundle:: mechanism? Gerv From mkanat at bugzilla.org Tue Oct 16 23:27:47 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 16 Oct 2007 16:27:47 -0700 Subject: A Tool For Auto-Installing CPAN Packages In-Reply-To: <4714C223.30104@microimages.com> References: <20071016014826.4c39a060@es-compy> <4714C223.30104@microimages.com> Message-ID: <20071016162747.5094ad56@es-compy> On Tue, 16 Oct 2007 08:52:35 -0500 Dave Williss wrote: > I would also like to see a link on the download page which would > download ALL the CPAN packages required by Bugzilla. It's not possible to download them as installed code, because there are many XS modules in the dependency chain which must be compiled for your specific version of Perl and processor type. It *would* be possible to provide all of the .tar.gz files from CPAN. > The reason for this is that I've had to install Bugzilla multiple > times on machines which were on a private LAN and did not have > internet access, Yes, this is a very common situation and we will probably enhance install-module.pl in the future to deal with it. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From mkanat at bugzilla.org Tue Oct 16 23:28:56 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 16 Oct 2007 16:28:56 -0700 Subject: A Tool For Auto-Installing CPAN Packages In-Reply-To: <1192567500.2594.15.camel@localhost6.localdomain6> References: <20071016014826.4c39a060@es-compy> <1192567500.2594.15.camel@localhost6.localdomain6> Message-ID: <20071016162856.20381031@es-compy> On Tue, 16 Oct 2007 13:45:00 -0700 Clement Chan wrote: > Does anyone happen to have the libraries and Perl module version list > handy? This question would be more appropriate for the bugzilla-support list described here: http://www.bugzilla.org/support/ -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From mkanat at bugzilla.org Tue Oct 16 23:29:27 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 16 Oct 2007 16:29:27 -0700 Subject: A Tool For Auto-Installing CPAN Packages In-Reply-To: <47153A3C.6010607@mozilla.org> References: <20071016014826.4c39a060@es-compy> <47153A3C.6010607@mozilla.org> Message-ID: <20071016162927.1f88d7e8@es-compy> On Tue, 16 Oct 2007 23:25:00 +0100 Gervase Markham wrote: > How does this interface with the Bundle:: mechanism? It doesn't. It's not necessary to. I also added a comment on the bug itself about that. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From dwilliss at microimages.com Wed Oct 17 14:24:27 2007 From: dwilliss at microimages.com (Dave Williss) Date: Wed, 17 Oct 2007 09:24:27 -0500 Subject: A Tool For Auto-Installing CPAN Packages In-Reply-To: <20071016162747.5094ad56@es-compy> References: <20071016014826.4c39a060@es-compy> <4714C223.30104@microimages.com> <20071016162747.5094ad56@es-compy> Message-ID: <47161B1B.2090808@microimages.com> Max Kanat-Alexander wrote: > On Tue, 16 Oct 2007 08:52:35 -0500 Dave Williss > wrote: > >> I would also like to see a link on the download page which would >> download ALL the CPAN packages required by Bugzilla. >> > > It's not possible to download them as installed code, because > there are many XS modules in the dependency chain which must be > compiled for your specific version of Perl and processor type. > > It *would* be possible to provide all of the .tar.gz files from > CPAN. > > Yes, that's what I was suggesting. The configure script would figure out which ones it actually needed to install on your system and build a Makefile which would untar and build the necessary modules. I like the suggestion somebody else had here about installing them into the Bugzilla directory itself if the installer doesn't have root access. That might be good for many people too. >> The reason for this is that I've had to install Bugzilla multiple >> times on machines which were on a private LAN and did not have >> internet access, >> > > Yes, this is a very common situation and we will probably > enhance install-module.pl in the future to deal with it. > > Yay! > -Max > From bugzilla at glob.com.au Wed Oct 17 14:52:02 2007 From: bugzilla at glob.com.au (byron) Date: Wed, 17 Oct 2007 22:52:02 +0800 Subject: A Tool For Auto-Installing CPAN Packages In-Reply-To: <47161B1B.2090808@microimages.com> References: <20071016014826.4c39a060@es-compy> <4714C223.30104@microimages.com> <20071016162747.5094ad56@es-compy> <47161B1B.2090808@microimages.com> Message-ID: <20071017145202.GB23755@bur.st> i'm probably missing something, but wouldn't it be easier to maintain Bundle::Bugzilla rather than write a downloader script? -b begin-base64 644 signature.gif R0lGODlhbQAHAIAAAABPo////ywAAAAAbQAHAAACfAxuGAnch+Bibkn7FL1p XgVl4Ig1jjlZRoqybgun2Cur5uOunq7u/Ipq7WIyIc7XG9JquEgumPzdlhTf h0O83kDJaXEm8mRHwXKJy5sac7qYOpT+gtv0n+0ujQOfdqh16caWt0foBViH N1PRMXimiLUGt3ElVimlgbllWAAAOw== From LpSolit at gmail.com Wed Oct 17 19:34:42 2007 From: LpSolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Wed, 17 Oct 2007 21:34:42 +0200 Subject: Removal of several parameters just around the corner Message-ID: <471663D2.9090307@gmail.com> Just so that you all know, and because the previous announcement was only made to the developer mailing-list, we are going to remove many parameters in a future Bugzilla release. Maybe in Bugzilla 3.2, but more probably in Bugzilla 3.4/4.0. You can see the list of parameters we are going to kill here: https://bugzilla.mozilla.org/buglist.cgi?short_desc_type=allwordssubstr&short_desc=remove+parameter&product=Bugzilla&resolution=--- If for any reason you think removing such or such parameter is definitely a bad idea, *and* you have a real use case, please comment in the bug directly rather than replying to this email (unless you have no user account on b.m.o, but you could easily create one). LpSolit From mkanat at bugzilla.org Thu Oct 18 00:00:24 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 17 Oct 2007 17:00:24 -0700 Subject: A Tool For Auto-Installing CPAN Packages In-Reply-To: <20071017145202.GB23755@bur.st> References: <20071016014826.4c39a060@es-compy> <4714C223.30104@microimages.com> <20071016162747.5094ad56@es-compy> <47161B1B.2090808@microimages.com> <20071017145202.GB23755@bur.st> Message-ID: <20071017170024.1337eecb@es-compy> On Wed, 17 Oct 2007 22:52:02 +0800 byron wrote: > i'm probably missing something, but wouldn't it be easier to maintain > Bundle::Bugzilla rather than write a downloader script? Yes, see my several comments on the bug about that. The downloader script is also much easier to use than CPAN, as it does all the configuration for you. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From dkl at redhat.com Fri Oct 19 20:52:13 2007 From: dkl at redhat.com (Dave Lawrence) Date: Fri, 19 Oct 2007 16:52:13 -0400 Subject: Bugzilla Fast CGI Message-ID: <471918FD.8090009@redhat.com> Out of curiosity, does anyone know of anyone using Bugzilla (recent versions) under mod_fastcgi instead of mod_perl? If so, anyone one what the advantages/disadvantages of doing so would be? One advantage I have seen for other cgi projects is the ability to bring up and down applications without restart of Apache and also some nice failover functionality. Also I have read that performance is on par with that of mod_perl. Just curious if anyone has made it work with Bugzilla and what their impression was. Thanks Dave Lawrence From mkanat at bugzilla.org Fri Oct 19 21:48:09 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 19 Oct 2007 14:48:09 -0700 Subject: Bugzilla Fast CGI In-Reply-To: <471918FD.8090009@redhat.com> References: <471918FD.8090009@redhat.com> Message-ID: <20071019144809.2733c2fe@es-compy> On Fri, 19 Oct 2007 16:52:13 -0400 Dave Lawrence wrote: > Out of curiosity, does anyone know of anyone using Bugzilla (recent > versions) under mod_fastcgi instead of mod_perl? I don't know of anybody using FastCGI with Bugzilla. I imagine performance would be similar to mod_perl. FastCGI works with lighttpd, which mod_perl doesn't. I don't know what would be required to run Bugzilla under FastCGI, but I'm guessing it would only require a wrapper somewhat like mod_perl.pl, but for the FastCGI architecture. Right now I'm perfectly happy with mod_perl, but if anybody can show a significant advantage to implementing FastCGI, I'd be willing to look into it. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From justdave at bugzilla.org Sat Oct 20 03:12:11 2007 From: justdave at bugzilla.org (David Miller) Date: Fri, 19 Oct 2007 23:12:11 -0400 Subject: new: developers == dev-apps-bugzilla Message-ID: <4719720B.40803@bugzilla.org> I've just completed setting up the bi-directional gateway between developers at bugzilla.org and dev-apps-bugzilla at lists.mozilla.org . Any posts to either list (and to the newsgroup mozilla.dev.apps.bugzilla on news.mozilla.org for that matter) should show up on the other now. This is according to https://bugzilla.mozilla.org/show_bug.cgi?id=382231 and to plans we've been intending to implement but never really got around to ever since the new mozilla.* hierarchy went live on news.mozilla.org. We may, at some point, drop the gateway and just forward one of the addresses to the other, and copy the subscriber lists across to the other one. But for now, a bi-directional gateway was fairly painless to set up, and less of a pain to implement than moving subscribers around. We'll see how this goes and make modifications as needed. If anyone discovers any adnormalities, please let me know. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From justdave at bugzilla.org Sat Oct 20 03:17:47 2007 From: justdave at bugzilla.org (David Miller) Date: Fri, 19 Oct 2007 23:17:47 -0400 Subject: new: developers == dev-apps-bugzilla In-Reply-To: <4719720B.40803@bugzilla.org> References: <4719720B.40803@bugzilla.org> Message-ID: <4719735B.6080506@bugzilla.org> David Miller wrote on 10/19/07 11:12 PM: > If anyone discovers any adnormalities, please let me know. "abnormalities" even. Already found one... we're getting a bad Reply-to header on the copy going to dev-apps-bugzilla if the mail originates on developers. I'll see if I can fix that. (this copy going to dev-apps-bugzilla via mail) -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From justdave at bugzilla.org Sat Oct 20 03:19:46 2007 From: justdave at bugzilla.org (David Miller) Date: Fri, 19 Oct 2007 23:19:46 -0400 Subject: new: developers == dev-apps-bugzilla In-Reply-To: <4719735B.6080506@bugzilla.org> References: <4719720B.40803@bugzilla.org> <4719735B.6080506@bugzilla.org> Message-ID: <471973D2.6040004@bugzilla.org> David Miller wrote on 10/19/07 11:17 PM: > David Miller wrote on 10/19/07 11:12 PM: >> If anyone discovers any adnormalities, please let me know. > > "abnormalities" even. > > Already found one... we're getting a bad Reply-to header on the copy > going to dev-apps-bugzilla if the mail originates on developers. I'll > see if I can fix that. (this copy going to dev-apps-bugzilla via mail) OK, replying via developers to see if the header is fixed... -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From justdave at bugzilla.org Sat Oct 20 03:32:20 2007 From: justdave at bugzilla.org (David Miller) Date: Fri, 19 Oct 2007 23:32:20 -0400 Subject: new: developers == dev-apps-bugzilla In-Reply-To: <4719735B.6080506@bugzilla.org> References: <4719720B.40803@bugzilla.org> <4719735B.6080506@bugzilla.org> Message-ID: <471976C4.3020607@bugzilla.org> David Miller wrote on 10/19/07 11:17 PM: > David Miller wrote on 10/19/07 11:12 PM: >> If anyone discovers any adnormalities, please let me know. > > "abnormalities" even. > > Already found one... we're getting a bad Reply-to header on the copy > going to dev-apps-bugzilla if the mail originates on developers. I'll > see if I can fix that. (this copy going to dev-apps-bugzilla via mail) One thing I notice is that if I "reply-to-all" on a message that got posted to dev-apps-bugzilla and is being replied to via developers that Thunderbird addresses the reply to both lists. This could be interesting. Attempting it to see what happens (maybe they'll screen each other - maybe we'll get two copies). -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From justdave at bugzilla.org Sat Oct 20 03:41:26 2007 From: justdave at bugzilla.org (David Miller) Date: Fri, 19 Oct 2007 23:41:26 -0400 Subject: new: developers == dev-apps-bugzilla In-Reply-To: <471976C4.3020607@bugzilla.org> References: <4719720B.40803@bugzilla.org> <4719735B.6080506@bugzilla.org> <471976C4.3020607@bugzilla.org> Message-ID: <471978E6.1030005@bugzilla.org> David Miller wrote on 10/19/07 11:32 PM: > One thing I notice is that if I "reply-to-all" on a message that got > posted to dev-apps-bugzilla and is being replied to via developers that > Thunderbird addresses the reply to both lists. This could be > interesting. Attempting it to see what happens (maybe they'll screen > each other - maybe we'll get two copies). developers (majordomo2) screened the duplicate out because the Message-Id matched one it had already seen, dev-apps-bugzilla (mailman) posted both copies. Oof. Maybe this isn't so cut and dried after all. I'm not adverse to making a small hack to mailman, but not a major one, and I'm not sure where to hack it at (we're on version 2.1.9 if anyone wants to make suggestions) What do you all think, should we just make one of the addresses forward to the other and move the subscribers over, or find a way to munge the headers so replies don't cause duplicates? -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From lpsolit at gmail.com Sat Oct 20 11:56:11 2007 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Sat, 20 Oct 2007 13:56:11 +0200 Subject: new: developers == dev-apps-bugzilla In-Reply-To: <471978E6.1030005@bugzilla.org> References: <4719720B.40803@bugzilla.org> <4719735B.6080506@bugzilla.org> <471976C4.3020607@bugzilla.org> <471978E6.1030005@bugzilla.org> Message-ID: <4719ECDB.8070207@gmail.com> David Miller a ?crit : > What do you all think, should we just make one of the addresses forward > to the other and move the subscribers over, or find a way to munge the > headers so replies don't cause duplicates? I commented in the bug about why I'm opposed to leave developers@: https://bugzilla.mozilla.org/show_bug.cgi?id=382231#c7 LpSolit From gerv at mozilla.org Sat Oct 20 13:39:03 2007 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 20 Oct 2007 14:39:03 +0100 Subject: new: developers == dev-apps-bugzilla In-Reply-To: <4719ECDB.8070207@gmail.com> References: <4719720B.40803@bugzilla.org> <4719735B.6080506@bugzilla.org> <471976C4.3020607@bugzilla.org> <471978E6.1030005@bugzilla.org> <4719ECDB.8070207@gmail.com> Message-ID: <471A04F7.1000001@mozilla.org> Fr?d?ric Buclin wrote: > I commented in the bug about why I'm opposed to leave developers@: > https://bugzilla.mozilla.org/show_bug.cgi?id=382231#c7 I think you've got the wrong end of the stick. No-one is suggesting that there will no longer be a mailing list. If you prefer mailing lists to newsgroups, that's not a problem. Gerv From myk at mozilla.org Sat Oct 20 16:35:03 2007 From: myk at mozilla.org (Myk Melez) Date: Sat, 20 Oct 2007 09:35:03 -0700 Subject: new: developers == dev-apps-bugzilla In-Reply-To: <471978E6.1030005@bugzilla.org> References: <4719720B.40803@bugzilla.org> <4719735B.6080506@bugzilla.org> <471976C4.3020607@bugzilla.org> <471978E6.1030005@bugzilla.org> Message-ID: <471A2E37.1080509@mozilla.org> David Miller wrote: > What do you all think, should we just make one of the addresses forward > to the other and move the subscribers over, or find a way to munge the > headers so replies don't cause duplicates? > I think we should make one of the addresses forward to the other and move the subscribers over. It's not worth the time spent figuring out how to keep both lists and perpetually explaining to new subscribers why they both exist. -myk From bugzilla-developers at compoundeye.co.uk Sun Oct 21 18:05:17 2007 From: bugzilla-developers at compoundeye.co.uk (Mark Stockley) Date: Sun, 21 Oct 2007 19:05:17 +0100 Subject: Self-Introduction: Mark Stockley Message-ID: <471B94DD.70605@compoundeye.co.uk> Hi, it says on the website I should introduce myself, so here goes. My name's Mark Stockley and I'm a 32 year old Information Architect working in Oxford in the UK. I'll probably be appearing on IRC as makaq. Short term I'm interested in dipping my toe in the water wherever my skills might be useful. Longer term I expect I'll be drawn towards working on the UI. The technical skills I have that might be useful are: UI/UX design, OO Perl, HTML, CSS and OO Javascript. Done some Ajax and I've spent a bit of time working with the YAHOO YUI library recently. At home I work on a Mac, at work it's FreeBSD. To start with I guess I'm looking for some pointers on a useful place to start. Cheers M. From mkanat at bugzilla.org Sun Oct 21 23:37:30 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sun, 21 Oct 2007 16:37:30 -0700 Subject: Self-Introduction: Mark Stockley In-Reply-To: <471B94DD.70605@compoundeye.co.uk> References: <471B94DD.70605@compoundeye.co.uk> Message-ID: <20071021163730.56d1ae0a@es-compy> On Sun, 21 Oct 2007 19:05:17 +0100 Mark Stockley wrote: > Longer term I expect I'll be drawn towards working on the UI. Great, we'd love that!! > The technical skills I have that might be useful are: UI/UX design, > OO Perl, HTML, CSS and OO Javascript. Done some Ajax and I've spent a > bit of time working with the YAHOO YUI library recently. Great, we were thinking about using YUI for Bugzilla, actually. > To start with I guess I'm looking for some pointers on a useful place > to start. Here's a list of open bugs that we've marked "[Good Intro Bug]": http://tinyurl.com/2l6usq Also, here's a larger bug you might want to try your hand at: https://bugzilla.mozilla.org/show_bug.cgi?id=325487 (You can ask LpSolit on IRC about that one.) -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From mkanat at bugzilla.org Tue Oct 23 19:40:45 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 23 Oct 2007 12:40:45 -0700 Subject: Date & Time JavaScript Widget? Message-ID: <20071023124045.38d1a22b@es-compy> So I just added date/time fields to Bugzilla. Now I'd like to add a pop-up JavaScript widget that contains a calendar & a time-drop down. YUI has the calendar, but no time drop-down. Any ideas? Here's the bug for this, by the way: https://bugzilla.mozilla.org/show_bug.cgi?id=397099 -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From bugzilla at colinogilvie.co.uk Tue Oct 23 19:47:45 2007 From: bugzilla at colinogilvie.co.uk (Colin Ogilvie) Date: Tue, 23 Oct 2007 20:47:45 +0100 Subject: Date & Time JavaScript Widget? In-Reply-To: <20071023124045.38d1a22b@es-compy> References: <20071023124045.38d1a22b@es-compy> Message-ID: <471E4FE1.7070001@colinogilvie.co.uk> Max Kanat-Alexander wrote: > Any ideas? There are plugin's to jQuery to do Calendar and Time Pickers... http://jquery.com/plugins/project/Plugins/name Colin From ghendricks at novell.com Tue Oct 23 22:10:22 2007 From: ghendricks at novell.com (Gregary Hendricks) Date: Tue, 23 Oct 2007 16:10:22 -0600 Subject: Date & Time JavaScript Widget? In-Reply-To: <471E1CEE020000D200013A67@sinclair.provo.novell.com> References: <471DFA15020000EE000128AA@sinclair.provo.novell.com> <471E1CEE020000D200013A67@sinclair.provo.novell.com> Message-ID: <471E1CEE020000D200013A67@sinclair.provo.novell.com> On Tue, 2007-10-23 at 12:40 -0700, Max Kanat-Alexander wrote: > So I just added date/time fields to Bugzilla. > > Now I'd like to add a pop-up JavaScript widget that contains a > calendar & a time-drop down. > > YUI has the calendar, but no time drop-down. > > Any ideas? > > Here's the bug for this, by the way: > https://bugzilla.mozilla.org/show_bug.cgi?id=397099 > > -Max I am plugging Extjs into Testopia. It has a real nice calendar widget. It is demonstrated here: http://extjs.com/deploy/dev/examples/menu/menus.html They have it as a menu item, but you can make it out of a button or anything else you want. Of courese, these are a lot to download for a single widget. I am sure there are more specific ones out there. But this would be a good time to make a decision on a way to go for Javascript and AJAX libs in general so that we aren't requiring 30 different libs in bugzilla. Greg From mkanat at bugzilla.org Wed Oct 24 01:20:12 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 23 Oct 2007 18:20:12 -0700 Subject: Date & Time JavaScript Widget? In-Reply-To: <471E1CEE020000D200013A67@sinclair.provo.novell.com> References: <471DFA15020000EE000128AA@sinclair.provo.novell.com> <471E1CEE020000D200013A67@sinclair.provo.novell.com> <471E1CEE020000D200013A67@sinclair.provo.novell.com> Message-ID: <20071023182012.388f1ff9@es-compy> On Tue, 23 Oct 2007 16:10:22 -0600 "Gregary Hendricks" wrote: > I am plugging Extjs into Testopia. It has a real nice calendar widget. Yes, so does YUI. The Calendar widget isn't the problem, it's the time-of-day part that's a problem. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From fergus at yahoo-inc.com Wed Oct 24 20:07:47 2007 From: fergus at yahoo-inc.com (Fergus Sullivan) Date: Wed, 24 Oct 2007 13:07:47 -0700 Subject: Date & Time JavaScript Widget? In-Reply-To: <20071023124045.38d1a22b@es-compy> References: <20071023124045.38d1a22b@es-compy> Message-ID: <22E0AF5A-E310-444C-9140-2A62DF327608@yahoo-inc.com> I just spoke to the YUI guys. A time selection widget hadn't occurred to them, but they'll consider it for their 3.0 release which I think is early next year (too late for this I assume). Part of the plan for YUI 3.0 is to separate the underlying code from the presentation layer, so in theory it would just be a changed presentation widget. They might, or might not, want to have it as a new widget rather than a bolt-on to the calendar widget. I'll let you know if it gets added to the roadmap. (Note to self: ybugzilla ticket 1557374) /ferg -- fergus sullivan | yahoo developer tools team | fergus at yahoo-inc.com | o. 408.349.6807 | m. 408.203.FERG On Oct 23, 2007, at 12:40 PM, Max Kanat-Alexander wrote: > > So I just added date/time fields to Bugzilla. > > Now I'd like to add a pop-up JavaScript widget that contains a > calendar & a time-drop down. > > YUI has the calendar, but no time drop-down. > > Any ideas? > > Here's the bug for this, by the way: > https://bugzilla.mozilla.org/show_bug.cgi?id=397099 > > -Max > -- > http://www.everythingsolved.com/ > Competent, Friendly Bugzilla Services. And Everything Else, too. > - > To view or change your list settings, click here: > From mkanat at bugzilla.org Wed Oct 24 20:22:11 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 24 Oct 2007 13:22:11 -0700 Subject: Date & Time JavaScript Widget? In-Reply-To: <22E0AF5A-E310-444C-9140-2A62DF327608@yahoo-inc.com> References: <20071023124045.38d1a22b@es-compy> <22E0AF5A-E310-444C-9140-2A62DF327608@yahoo-inc.com> Message-ID: <20071024132211.38155ae3@es-compy> On Wed, 24 Oct 2007 13:07:47 -0700 Fergus Sullivan wrote: > Part of the plan for YUI 3.0 is to separate the underlying code from > the presentation layer, so in theory it would just be a changed > presentation widget. They might, or might not, want to have it as a > new widget rather than a bolt-on to the calendar widget. > > I'll let you know if it gets added to the roadmap. (Note to self: > ybugzilla ticket 1557374) Great! For us, it'd be most useful as an add-on to the Calendar widget, so that both would together populate one field. But perhaps from a design perspective for YUI, the best would be for it to be a separate widget that has some good integration with the Calendar widget, so I don't have to write special code to update my input field (that is, code that parses and skips the date no matter what format it's in and then inputs the time, which could get complex depending on the date format). -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From knocte at NO-SPAM-PLEASE-gmail.com Thu Oct 25 17:32:11 2007 From: knocte at NO-SPAM-PLEASE-gmail.com (=?ISO-8859-1?Q?=22Andr=E9s_G=2E_Aragoneses=22?=) Date: Thu, 25 Oct 2007 19:32:11 +0200 Subject: New language discussion? Message-ID: Can someone tell the latest state-of-affairs from the recent(?) languages discussion to be used in Bugzilla in the future? I proposed a big section about Mono on the discussion page, but I think there has been no more news about this (neither anyone has updated the "official" part page to include the Mono section). Regards, Andr?s [ knocte ] -- P.S.: In case anyone asks, I am talking about this: http://wiki.mozilla.org/Bugzilla_Talk:Languages _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From mkanat at bugzilla.org Thu Oct 25 21:50:42 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 25 Oct 2007 14:50:42 -0700 Subject: New language discussion? In-Reply-To: References: Message-ID: <20071025145042.111ef571@es-compy> On Thu, 25 Oct 2007 19:32:11 +0200 "Andr?s G. Aragoneses" wrote: > Can someone tell the latest state-of-affairs from the recent(?) > languages discussion to be used in Bugzilla in the future? We decided that we don't have the manpower to split the team between a re-write and continuing maintenance of the current Bugzilla. > I proposed a big section about Mono on the discussion page, but I > think there has been no more news about this (neither anyone has > updated the "official" part page to include the Mono section). I don't know C#, but that doesn't mean it wouldn't be a reasonable contender. However, I think we were generally against strongly-typed languages. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From india.internet.marketing at gmail.com Sat Oct 27 12:08:21 2007 From: india.internet.marketing at gmail.com (Translation India) Date: Sat, 27 Oct 2007 05:08:21 -0700 Subject: Dutch Translation Services by Translation India .com Message-ID: <1193486901.343423.102370@z24g2000prh.googlegroups.com> Dutch Translation Services by Translation India .com . For details, please visit - http://www.translationIndia.com _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From im at satspeed.gr Sun Oct 28 17:44:38 2007 From: im at satspeed.gr (Stathis Sideris) Date: Sun, 28 Oct 2007 17:44:38 +0000 Subject: Hello, just introducing myself Message-ID: <4724CA86.6050909@satspeed.gr> Hello everyone, First of all, let me say thanks for developing Bugzilla. In accordance to the guidelines for (potential) new developers, I'm introducing myself here. My name is Stathis Sideris and I use ssideris as my irc username for irc.mozilla.org (I haven't logged in for a while now). I'm based in London and I'm currently working as a senior application developer for a scientific analytics company. I have a strong Perl and Java background because of the work I did for my PhD in Bioinformatics, and I have released a couple of personal open source projects in the past: http://ditaa.sf.net https://addons.mozilla.org/en-US/firefox/addon/1067 I would also say that I'm a bit artistic, with experience in web design and UI design. See: http://www.stathis.co.uk I have recently attempted to create a custom skin to make Bugzilla more visually appealing, (see samples at: http://www.stathis.co.uk/misc/bugzilla_home_new.png http://www.stathis.co.uk/misc/bugzilla_display_bug_new1.png http://www.stathis.co.uk/misc/bugzilla_create_bug_new1.png ) but I quickly run into some limitations. More specifically, I think that currently the generated HTML is not very CSS friendly because of the lack of class and id attributes and because of the use of tables. I would like to submit a patch which will improve the situation by adding id and class attributes where necessary (especially to form fields) and possibly wrap some parts of the generated html in named div or span elements to allow the option to hide those parts (for example, in order to hide the text title of the page reading "Bugzilla" so that it can be replaced with a graphical logo). Anything that I submit will be non-invasive in the sense that it will not change the way the default skin looks. The aim would be to provide a "foothold" for new skins. For the time being, I'm not intending to touch the table-based layouts. Do you think this is a good idea for a patch? Who is the appropriate person for reviewing any changes that I produce? Thank you, Stathis Sideris From mkanat at bugzilla.org Sun Oct 28 18:35:23 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sun, 28 Oct 2007 11:35:23 -0700 Subject: Hello, just introducing myself In-Reply-To: <4724CA86.6050909@satspeed.gr> References: <4724CA86.6050909@satspeed.gr> Message-ID: <20071028113523.78c29224@es-compy> On Sun, 28 Oct 2007 17:44:38 +0000 Stathis Sideris wrote: > Do you think this is a good idea for a patch? Who is the appropriate > person for reviewing any changes that I produce? Yeah, sure, this would be fine. Bugzilla 3.1.x already has some work in this direction--have you looked at it? Any person in this "Templates" list would be fine: http://www.bugzilla.org/docs/reviewer-list.html#templates Probably myk would be the first one you'd want to try. I'm also capable of reviewing them in a pinch, but if you ask me I might not get around to it very fast. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From julien.beti at free.fr Mon Oct 29 09:19:30 2007 From: julien.beti at free.fr (Julien BETI) Date: Mon, 29 Oct 2007 10:19:30 +0100 Subject: Hours Worked consolidated report Message-ID: <4725A5A2.6060408@free.fr> Hello, I've just released a new version of my tools which among other create an hours worked report from Bugzilla. This has been changed to offer a consolidated view of several axes, like product, component, login, date ranges, or any configured categories. You can see a screenshot here: http://albums.jujunie.com/software-jujunie_integration/Bugzilla_reports_hours_worked_daily_result Project page on Freshmeat: http://freshmeat.net/projects/jujunie-integration/?branch_id=63259&release_id=264637 Regards, Julien. From lpsolit at gmail.com Mon Oct 29 16:17:07 2007 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Mon, 29 Oct 2007 17:17:07 +0100 Subject: Bugzilla meeting postponed Message-ID: <47260783.6070902@gmail.com> Hello, Note that we won't meet tomorrow as we have mostly nothing special to discuss. Bugzilla is hibernating these days and so we decided to postpone our Bugzilla meeting till next Tuesday, November 6, 2007, same time. LpSolit From justdave at bugzilla.org Mon Oct 29 16:48:19 2007 From: justdave at bugzilla.org (David Miller) Date: Mon, 29 Oct 2007 12:48:19 -0400 Subject: Bugzilla meeting postponed In-Reply-To: <47260783.6070902@gmail.com> References: <47260783.6070902@gmail.com> Message-ID: <47260ED3.8070709@bugzilla.org> Fr?d?ric Buclin wrote on 10/29/07 12:17 PM: > Note that we won't meet tomorrow as we have mostly nothing special to > discuss. Bugzilla is hibernating these days and so we decided to > postpone our Bugzilla meeting till next Tuesday, November 6, 2007, same > time. And less ambiguous since the US will have switched out of Daylight Savings time by then (most of the rest of the world that uses it switched already this last week). -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From knocte at NO-SPAM-PLEASE-gmail.com Mon Oct 29 23:41:24 2007 From: knocte at NO-SPAM-PLEASE-gmail.com (=?UTF-8?B?IkFuZHLDqXMgRy4gQXJhZ29uZXNlcyI=?=) Date: Tue, 30 Oct 2007 00:41:24 +0100 Subject: New language discussion? In-Reply-To: References: Message-ID: Max Kanat-Alexander escribi?: > On Thu, 25 Oct 2007 19:32:11 +0200 "Andr?s G. Aragoneses" > wrote: >> Can someone tell the latest state-of-affairs from the recent(?) >> languages discussion to be used in Bugzilla in the future? > > We decided that we don't have the manpower to split the team > between a re-write and continuing maintenance of the current Bugzilla. > >> I proposed a big section about Mono on the discussion page, but I >> think there has been no more news about this (neither anyone has >> updated the "official" part page to include the Mono section). > > I don't know C#, but that doesn't mean it wouldn't be a > reasonable contender. However, I think we were generally against > strongly-typed languages. Hey, but I proposed Mono. With that, we could write things in IronPython, IronRuby... and have good stuff from contributors like C#, all languages interacting together. Well, I hope this gets discussed again. Regards, Andr?s [ knocte ] -- _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From arthur.barrett at march-hare.com Tue Oct 30 00:07:00 2007 From: arthur.barrett at march-hare.com (Arthur Barrett) Date: Tue, 30 Oct 2007 11:07:00 +1100 Subject: New language discussion? Message-ID: <946E76E38BC1E2448B68F32FAEA2BA582641B3@2ksrvr01.march-hare.local> Max et al, Sorry 'bout the cross post - but since the original post was across both newsgroups... > > Can someone tell the latest state-of-affairs from the recent(?) > > languages discussion to be used in Bugzilla in the future? > > We decided that we don't have the manpower to split the team > between a re-write and continuing maintenance of the current Bugzilla. I work for March Hare Software who are the primary contributors to the multi-platform open source CVSNT project as well as providing commercial versions and support. For our commercial products we have supported and integrated with Bugzilla for some time. We are currently working on a re-write of Bugzilla in C++ as a part of the EVS project (www.evscm.org) which is designed as a platform for CM systems rather than a version control tool. At the moment this is all happening closed source and behind doors though we are/will be releasing "free" preview versions. It has not been decided what components of evscm will be "free", what will be "open source" and what will be "commercially licensed" at the end of the project. If I evidence to support the notion that a number of people in the community would help in the development/testing/documenting of a C++ implementation of Bugzilla then it'd help the argument that we should make it open source. But while we remain the only people working on it all options will be kept open. The next preview release will be (hopefully) later this week and that'll be the first release with the bugzilla engine in it. That preview uses the Bugzilla 2.18/2.20 data model with mysql though the intention is to then switch to the 3.x data model and mysql/mssql/oracle. Please subscribe to the evs-support newsgroup (details at evscm.org) to get the announcements and to contribute. Note: whilst evs is multi platform - due to resource shortages we've had to recently abandon all builds except the windows one, so this is a windows-only effort until at least release 1, then we intend going back to resurrect the unix/linux version. However others outside of March Hare have already started picking up the slack and build the previous EVS preview for Debian. Regards, Arthur Barrett Product Manager March Hare Software From olav at bkor.dhs.org Tue Oct 30 00:32:10 2007 From: olav at bkor.dhs.org (Olav Vitters) Date: Tue, 30 Oct 2007 01:32:10 +0100 Subject: New language discussion? In-Reply-To: <946E76E38BC1E2448B68F32FAEA2BA582641B3@2ksrvr01.march-hare.local> References: <946E76E38BC1E2448B68F32FAEA2BA582641B3@2ksrvr01.march-hare.local> Message-ID: <20071030003210.GA11773@bkor.dhs.org> On Tue, Oct 30, 2007 at 11:07:00AM +1100, Arthur Barrett wrote: > We are currently working on a re-write of Bugzilla in C++ as a part of > the EVS project (www.evscm.org) which is designed as a platform for CM > systems rather than a version control tool. At the moment this is all > happening closed source and behind doors though we are/will be releasing > "free" preview versions. > > It has not been decided what components of evscm will be "free", what > will be "open source" and what will be "commercially licensed" at the > end of the project. If I evidence to support the notion that a number > of people in the community would help in the Sorry.. I don't contribute to non-open source software (in my spare time). Further, my C++ is non-existing and I have no intention to learn it. So for me I don't think I'd ever contribute. Won't C++ hurt where this can be installed upon? PHP seems easiest, then in a distance (IMO) Perl, etc. C++ would require a compiler, which seems even more restricted. > development/testing/documenting of a C++ implementation of Bugzilla then > it'd help the argument that we should make it open source. But while we > remain the only people working on it all options will be kept open. Is the intention to stay compatible with Bugzilla? > The next preview release will be (hopefully) later this week and that'll > be the first release with the bugzilla engine in it. That preview uses > the Bugzilla 2.18/2.20 data model with mysql though the intention is to > then switch to the 3.x data model and mysql/mssql/oracle. Please > subscribe to the evs-support newsgroup (details at evscm.org) to get the > announcements and to contribute. > > Note: whilst evs is multi platform - due to resource shortages we've had > to recently abandon all builds except the windows one, so this is a Many Bugzilla devs use Linux exclusively AFAIK. So Windows only will delay things. > windows-only effort until at least release 1, then we intend going back > to resurrect the unix/linux version. However others outside of March > Hare have already started picking up the slack and build the previous > EVS preview for Debian. -- Regards, Olav From cchan at mvista.com Mon Oct 29 17:45:05 2007 From: cchan at mvista.com (Clement Chan) Date: Mon, 29 Oct 2007 10:45:05 -0700 Subject: question on the state of Bugzilla WebService API Message-ID: <1193679905.16365.16.camel@localhost6.localdomain6> Would someone comment on the current state of the Bugzilla WebService API? http://www.bugzilla.org/docs/3.0/html/api/ Normally, the project state can be STABLE, EXPERIMENTAL, or UNSTABLE. We are planning to having some open source app integration with Bugzilla 3.0 via the Web Service API. TIA, - Clement From mbd at dbc.dk Tue Oct 30 07:35:22 2007 From: mbd at dbc.dk (Mads Bondo Dydensborg) Date: Tue, 30 Oct 2007 08:35:22 +0100 Subject: question on the state of Bugzilla WebService API In-Reply-To: <1193679905.16365.16.camel@localhost6.localdomain6> References: <1193679905.16365.16.camel@localhost6.localdomain6> Message-ID: <200710300835.22994.mbd@dbc.dk> mandag 29 Oktober 2007 skrev Clement Chan: > Would someone comment on the current state of the Bugzilla WebService > API? It works, but it can't really do that much (can create a bug, list some kind of information and so on, but lots of functionality still lack). We (you and I :-) need to write some more patches to introduce more functionality. Some of the issues are listed here: http://tinyurl.com/3afonu Regards Mads -- Med venlig hilsen/Regards Systemudvikler/Systemsdeveloper cand.scient.dat, Ph.d., Mads Bondo Dydensborg Dansk BiblioteksCenter A/S, Tempovej 7-11, 2750 Ballerup, Tlf. +45 44 86 77 34 From jochen.wiedmann at gmail.com Tue Oct 30 09:46:50 2007 From: jochen.wiedmann at gmail.com (Jochen Wiedmann) Date: Tue, 30 Oct 2007 10:46:50 +0100 Subject: New language discussion? In-Reply-To: <946E76E38BC1E2448B68F32FAEA2BA582641B3@2ksrvr01.march-hare.local> References: <946E76E38BC1E2448B68F32FAEA2BA582641B3@2ksrvr01.march-hare.local> Message-ID: On 10/30/07, Arthur Barrett wrote: > We are currently working on a re-write of Bugzilla in C++ as a part of > the EVS project (www.evscm.org) which is designed as a platform for CM > systems rather than a version control tool. Of all the programming languages, my top priority of least usability for a Bugzilla-like project would be: 1.) Assembler, 2.) C, 3.) C++ I am sure that choice of programming language was made due to the programmers knowledge and not with regard to the suitability for a web platform. Jochen -- Look, that's why there's rules, understand? So that you think before you break 'em. -- (Terry Pratchett, Thief of Time) From andreas.mayr at kabelkom.at Tue Oct 30 11:41:46 2007 From: andreas.mayr at kabelkom.at (Andreas Mayr) Date: Tue, 30 Oct 2007 12:41:46 +0100 Subject: question on the state of Bugzilla WebService API In-Reply-To: <200710300835.22994.mbd@dbc.dk> References: <1193679905.16365.16.camel@localhost6.localdomain6> <200710300835.22994.mbd@dbc.dk> Message-ID: <000f01c81ae9$da093dc0$0209a8c0@funkypc> Really good idea guys! I need this functionality too! As it seems, that I'm too stupid to embed the mylyn-api in my program correctly, I have to rely on the Bugzilla WebService API. And this functionality is really pretty poor :( There are a few thing, that I'm missing in this buglist: - get custom fields - similar to products there should be a get_accessible_bugs method. It's pretty long winded and slow at the moment to write a method, that retrieves all bugs in the database What do you think about that? Best Regards, Andi -----Urspr?ngliche Nachricht----- Von: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] Im Auftrag von Mads Bondo Dydensborg Gesendet: Dienstag, 30. Oktober 2007 08:35 An: developers at bugzilla.org Betreff: Re: question on the state of Bugzilla WebService API mandag 29 Oktober 2007 skrev Clement Chan: > Would someone comment on the current state of the Bugzilla WebService > API? It works, but it can't really do that much (can create a bug, list some kind of information and so on, but lots of functionality still lack). We (you and I :-) need to write some more patches to introduce more functionality. Some of the issues are listed here: http://tinyurl.com/3afonu Regards Mads -- Med venlig hilsen/Regards Systemudvikler/Systemsdeveloper cand.scient.dat, Ph.d., Mads Bondo Dydensborg Dansk BiblioteksCenter A/S, Tempovej 7-11, 2750 Ballerup, Tlf. +45 44 86 77 34 - To view or change your list settings, click here: From lpsolit at gmail.com Tue Oct 30 12:08:00 2007 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Tue, 30 Oct 2007 13:08:00 +0100 Subject: question on the state of Bugzilla WebService API In-Reply-To: <000f01c81ae9$da093dc0$0209a8c0@funkypc> References: <1193679905.16365.16.camel@localhost6.localdomain6> <200710300835.22994.mbd@dbc.dk> <000f01c81ae9$da093dc0$0209a8c0@funkypc> Message-ID: <47271EA0.8080503@gmail.com> Andreas Mayr a ?crit : > Really good idea guys! I need this functionality too! As it seems, that I'm > too stupid to embed the mylyn-api in my program correctly, I have to rely on > the Bugzilla WebService API. And this functionality is really pretty poor :( Several new methods will/should land on time for Bugzilla 3.2. mkanat is currently working on fully implementing Bug->update which will let you edit all attributes of existing bugs, which is a huge improvement. I also hope we will be able to query the DB given some criteria (e.g. using the QuickSearch syntax, despite I know mkanat is not a fan of it) and get back a list of bug objects, which would also be a significant improvement. About administrative tasks, some work has been done in the backend which would let us implement some admin methods too. Even if we freeze in a few weeks to prepare Bugzilla 3.2 RC1, I see no reason to stop the implementation of new webservice methods as they don't affect the core code itself. We could discuss this topic at our Bugzilla meeting next week. LpSolit From mbd at dbc.dk Tue Oct 30 12:33:36 2007 From: mbd at dbc.dk (Mads Bondo Dydensborg) Date: Tue, 30 Oct 2007 13:33:36 +0100 Subject: question on the state of Bugzilla WebService API In-Reply-To: <47271EA0.8080503@gmail.com> References: <1193679905.16365.16.camel@localhost6.localdomain6> <000f01c81ae9$da093dc0$0209a8c0@funkypc> <47271EA0.8080503@gmail.com> Message-ID: <200710301333.36270.mbd@dbc.dk> tirsdag 30 Oktober 2007 skrev Fr?d?ric Buclin: > Andreas Mayr a ?crit : > > Really good idea guys! I need this functionality too! As it seems, that I'm > > too stupid to embed the mylyn-api in my program correctly, I have to rely on > > the Bugzilla WebService API. And this functionality is really pretty poor :( > > > Several new methods will/should land on time for Bugzilla 3.2. mkanat is Here is, from the top of my head, a list of stuff I would like to see. I think most of it is not present: (Create bug - is possible) - Comment on a bug - Change the status of a bug (inclusive closing it). - List all open bugs, given a product - List all open bugs, given a product and a component - List all products (is implemented) - List all components for a given product I think adding these metods, where four are readonly, would hugely improve the APIs usability. Unfortunately, the focus of my company has shifted away from these tasks currently. Regards, Mads > currently working on fully implementing Bug->update which will let you > edit all attributes of existing bugs, which is a huge improvement. I > also hope we will be able to query the DB given some criteria (e.g. > using the QuickSearch syntax, despite I know mkanat is not a fan of it) > and get back a list of bug objects, which would also be a significant > improvement. About administrative tasks, some work has been done in the > backend which would let us implement some admin methods too. > > Even if we freeze in a few weeks to prepare Bugzilla 3.2 RC1, I see no > reason to stop the implementation of new webservice methods as they > don't affect the core code itself. We could discuss this topic at our > Bugzilla meeting next week. > > LpSolit > - > To view or change your list settings, click here: > > > > -- Med venlig hilsen/Regards Systemudvikler/Systemsdeveloper cand.scient.dat, Ph.d., Mads Bondo Dydensborg Dansk BiblioteksCenter A/S, Tempovej 7-11, 2750 Ballerup, Tlf. +45 44 86 77 34 From andreas.mayr at kabelkom.at Tue Oct 30 12:42:11 2007 From: andreas.mayr at kabelkom.at (Andreas Mayr) Date: Tue, 30 Oct 2007 13:42:11 +0100 Subject: question on the state of Bugzilla WebService API In-Reply-To: <200710301333.36270.mbd@dbc.dk> References: <1193679905.16365.16.camel@localhost6.localdomain6> <000f01c81ae9$da093dc0$0209a8c0@funkypc> <47271EA0.8080503@gmail.com> <200710301333.36270.mbd@dbc.dk> Message-ID: <001301c81af2$4b029f50$0209a8c0@funkypc> I agree with your suggestions. I was only listing a few things I've thought of. Eg "list all components for a given product" would be very important. For my work, I only need read-only features. Despite of this, I personally think that it is in general better, to implement first all read-features before concentrating on the modification-features. -----Urspr?ngliche Nachricht----- Von: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] Im Auftrag von Mads Bondo Dydensborg Gesendet: Dienstag, 30. Oktober 2007 13:34 An: developers at bugzilla.org Betreff: Re: question on the state of Bugzilla WebService API tirsdag 30 Oktober 2007 skrev Fr?d?ric Buclin: > Andreas Mayr a ?crit : > > Really good idea guys! I need this functionality too! As it seems, that I'm > > too stupid to embed the mylyn-api in my program correctly, I have to rely on > > the Bugzilla WebService API. And this functionality is really pretty poor :( > > > Several new methods will/should land on time for Bugzilla 3.2. mkanat is Here is, from the top of my head, a list of stuff I would like to see. I think most of it is not present: (Create bug - is possible) - Comment on a bug - Change the status of a bug (inclusive closing it). - List all open bugs, given a product - List all open bugs, given a product and a component - List all products (is implemented) - List all components for a given product I think adding these metods, where four are readonly, would hugely improve the APIs usability. Unfortunately, the focus of my company has shifted away from these tasks currently. Regards, Mads > currently working on fully implementing Bug->update which will let you > edit all attributes of existing bugs, which is a huge improvement. I > also hope we will be able to query the DB given some criteria (e.g. > using the QuickSearch syntax, despite I know mkanat is not a fan of it) > and get back a list of bug objects, which would also be a significant > improvement. About administrative tasks, some work has been done in the > backend which would let us implement some admin methods too. > > Even if we freeze in a few weeks to prepare Bugzilla 3.2 RC1, I see no > reason to stop the implementation of new webservice methods as they > don't affect the core code itself. We could discuss this topic at our > Bugzilla meeting next week. > > LpSolit > - > To view or change your list settings, click here: > > > > -- Med venlig hilsen/Regards Systemudvikler/Systemsdeveloper cand.scient.dat, Ph.d., Mads Bondo Dydensborg Dansk BiblioteksCenter A/S, Tempovej 7-11, 2750 Ballerup, Tlf. +45 44 86 77 34 - To view or change your list settings, click here: From dwilliss at microimages.com Tue Oct 30 14:29:07 2007 From: dwilliss at microimages.com (Dave Williss) Date: Tue, 30 Oct 2007 09:29:07 -0500 Subject: question on the state of Bugzilla WebService API In-Reply-To: <200710301333.36270.mbd@dbc.dk> References: <1193679905.16365.16.camel@localhost6.localdomain6> <000f01c81ae9$da093dc0$0209a8c0@funkypc> <47271EA0.8080503@gmail.com> <200710301333.36270.mbd@dbc.dk> Message-ID: <47273FB3.2030701@microimages.com> I would really like to see a Webservice API way to change a bug's status. This should be able to add a comment at the same time. We wrote an automatic distributed testing server. When a test fails, it sends out emails and somebody has to log a bugzilla item for it and log that number for the test on the test server. I could probably do this one through the webservice API, but we want to keep a human in the loop there. Later, when the test server determines that the bugzilla item is resolved as FIXED and that test is passing again, it changes its state to VERIFIED and adds a comment saying that it's now passing the auto test Currently, it does this by cheating and writing records directly to the bugzilla database. I would rather do it through the Webservice API so taht bugzilla could automatically send out the email alerting people that it's changed. Currently we do that via a cron job which runs the script that checks and sends unsent notification emails. Dave Williss MicroImages, Inc. Mads Bondo Dydensborg wrote: > tirsdag 30 Oktober 2007 skrev Fr?d?ric Buclin: > >> Andreas Mayr a ?crit : >> >>> Really good idea guys! I need this functionality too! As it seems, that >>> > I'm > >>> too stupid to embed the mylyn-api in my program correctly, I have to rely >>> > on > >>> the Bugzilla WebService API. And this functionality is really pretty >>> > poor :( > >> Several new methods will/should land on time for Bugzilla 3.2. mkanat is >> > > Here is, from the top of my head, a list of stuff I would like to see. I think > most of it is not present: > > (Create bug - is possible) > > - Comment on a bug > - Change the status of a bug (inclusive closing it). > - List all open bugs, given a product > - List all open bugs, given a product and a component > - List all products (is implemented) > - List all components for a given product > > I think adding these metods, where four are readonly, would hugely improve the > APIs usability. > > Unfortunately, the focus of my company has shifted away from these tasks > currently. > > Regards, > > Mads > > > > >> currently working on fully implementing Bug->update which will let you >> edit all attributes of existing bugs, which is a huge improvement. I >> also hope we will be able to query the DB given some criteria (e.g. >> using the QuickSearch syntax, despite I know mkanat is not a fan of it) >> and get back a list of bug objects, which would also be a significant >> improvement. About administrative tasks, some work has been done in the >> backend which would let us implement some admin methods too. >> >> Even if we freeze in a few weeks to prepare Bugzilla 3.2 RC1, I see no >> reason to stop the implementation of new webservice methods as they >> don't affect the core code itself. We could discuss this topic at our >> Bugzilla meeting next week. >> >> LpSolit >> - >> To view or change your list settings, click here: >> >> >> >> >> > > > > From kevin.benton at amd.com Tue Oct 30 19:52:15 2007 From: kevin.benton at amd.com (Benton, Kevin) Date: Tue, 30 Oct 2007 12:52:15 -0700 Subject: New language discussion? In-Reply-To: References: <946E76E38BC1E2448B68F32FAEA2BA582641B3@2ksrvr01.march-hare.local> Message-ID: > > We are currently working on a re-write of Bugzilla in C++ > as a part of > > the EVS project (www.evscm.org) which is designed as a > platform for CM > > systems rather than a version control tool. > > Of all the programming languages, my top priority of least usability > for a Bugzilla-like project would be: 1.) Assembler, 2.) C, 3.) C++ > > I am sure that choice of programming language was made due to the > programmers knowledge and not with regard to the suitability for a web > platform. IMNSHO, the question of "do we move to a new language or keep moving forward with what we have?" has been asked over and over. The rub is this: what does moving to a new language give us that we don't already have and the corrolary, what is the return on investment if we move and how will we be able to move faster because of the work done to move? It's easy to argue that we like language x better than language y, but that doesn't matter. We have a working application in Perl today. We need to ask the hard questions in order to determine if the benefits outweigh the risks, if the change will prove itself useful in a timely manner, and if the change is made, at what point do we pull the plug on changing if it hasn't happened "fast enough". A much less preferred option is to encourage those that want to work on the "new" language to do so on their own project. This would further split the resources to make Bugzilla into what it can be while it's pulling resources away to a "new" project based on the old. XEmacs and Emacs have both had this issue in the past with gains and losses seen on both sides. In my view, I think both sides lost because development was split and in some ways, has lost the benefit of the synergy between the teams. On the other hand, both sides won because each agreed to disagree and go their own separate ways. Users were given a choice on which environment they preferred. The drawback was that some wanted to pick and choose feature sets from both but couldn't because the development had diverged. In my view, the result was a net loss. As we all know, Bugzilla is implemented in Perl and the codebase is getting better as we move to a more object-oriented model where persistence is done at the proper layers. There's a lot of work to be done, but no matter what language is chosen, it's possible to wind up with the same problems we have today if we don't change the standards by which we code. So, I suggest that we look at the real issue - how do we design our code so that it doesn't look and feel like procedural spaghetti? Having SQL in the CGI, for example is a great example of why you don't want to repeat yourself again (:-). Moving the SQL into modules that deal directly with the database (DAO) makes the most sense to me because then, there is only one place to maintain with regard to the back-end and it's easy to change out if needed. This work is already in-progress. Another problem we've seen is the CGI will call the same subroutine directly and indirectly a number of times to get the same answer back each time. This too is getting better, but it's got a long way to go. We're (AMD) actively working on a radical shift in the way that "custom" fields are being done by providing a field scheme model of implementing "custom" fields. We prefer to call those "custom" fields "add-on" fields rather than custom. Once the code support them, then they truly will be add-on fields. While we're doing field schemes that allow administrators to select what fields are available by product, we're also developing workflow schemes in the same methodology so that each product can have its own workflow. There are many different workflow needs within our company based on the type of work being done. Some processes have an extra documentation step, some have an extra incorporation step, and there are many others. Not all products need the extra steps so workflow schemes will allow us to assign those workflows on a per-product basis. Frankly, our number one concern with contributing code back to the community is the length of time it takes to go from contribution to approval in combination with the risk that our change set(s) won't be accepted by the community. We're moving at the speed of business requirements here and unfortunately, it's very challenging for us to remain in sync with what the community is doing versus what our internal needs are. It's a lot of work for us to stay in sync with the tip and do our own development with the risk that a patch we submit may not be accepted by the community. There are a number of things (like the schemes discussed above) we need that really should be implemented within Bugzilla core, but we need them before the community will be ready to accept those changes (meaning more work for us to keep our changes "up-to-date" while the community catches up with us). Our business requirements state that our field and workflow schemes must be completed before the new year, yet, knowing that, there is no way we can rely on the community to accept those changes into the trunk so we don't have another issue with forking our code. We've had internal discussions that we'd be glad to contribute both code and test cases (and Selenium tests to run those test cases) to prove out our submissions, however, we've also seen resistance to our methods of making changes because we need to package things in chunks that we feel reviewers can review and approvers can approve. That burns a lot of time up because we can't insert forward-looking code in a patch moving bugs.versions to bugs.version_id. We're trying to get to a point where all the _id fields are dealt with in a uniform fashion so that custom fields become less custom and more add-on. I won't begin to hide that we have an agenda as a corporate customer and contributor. Yes, we'd like to help when helping moves us in a direction that makes sense for our company. I'm certain that there are other companies out there that would do the same. The challenge is, how do we contribute in a way that is meaningful for the community while it doesn't hog-tie us. AMD spends significant amount of money each year for Bugzilla development. AMD would love to see some ROI on that development by seeing some of that code contributed back to the core so that as Bugzilla features are added, incorporating those back into our code base is less of a "how much effort will it take to incorporate that?" to "are we ready to upgrade again?" I could go on but I'll stop here for now. --- Kevin Benton MySQL DBA #5739 Senior Software Developer CAD Global Infrastructure Flow Services Advanced Micro Devices 2950 E Harmony Rd Fort Collins, CO 80528 The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. From gerv at mozilla.org Wed Oct 31 12:12:51 2007 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 31 Oct 2007 12:12:51 +0000 Subject: New language discussion? In-Reply-To: References: <946E76E38BC1E2448B68F32FAEA2BA582641B3@2ksrvr01.march-hare.local> Message-ID: <47287143.5020201@mozilla.org> Benton, Kevin wrote: > As we all know, Bugzilla is implemented in Perl and the codebase is > getting better as we move to a more object-oriented model where > persistence is done at the proper layers. Indeed. Several years, ago, we asked the same question - rewrite or incrementally fix? The rewrite, Hixie's Bugzilla 3, didn't happen; Myk argued for incrementally fixing, and the code now is much better than it was. It seems to me that the arguments now are even more in favour of incremental improvement than they were then. > There's a lot of work to be > done, but no matter what language is chosen, it's possible to wind up > with the same problems we have today if we don't change the standards by > which we code. So, I suggest that we look at the real issue - how do we > design our code so that it doesn't look and feel like procedural > spaghetti? Having SQL in the CGI, for example is a great example of why > you don't want to repeat yourself again (:-). Moving the SQL into > modules that deal directly with the database (DAO) makes the most sense > to me because then, there is only one place to maintain with regard to > the back-end and it's easy to change out if needed. You see, five years ago, people weren't doing this - or it wasn't nearly as well known as best practice. Bugzilla is improving all the time as people's understanding of how to write web apps improves, and that can only be a good thing. But we'll never be perfect, because perfect is always changing. > We're (AMD) actively working on a radical shift in the way that "custom" > fields are being done by providing a field scheme model of implementing > "custom" fields. We prefer to call those "custom" fields "add-on" > fields rather than custom. How do they compare to the various other ways of implementing custom fields that were proposed when we originally did them? > Frankly, our number one concern with contributing code back to the > community is the length of time it takes to go from contribution to > approval in combination with the risk that our change set(s) won't be > accepted by the community. Contributing has concerns; forking has other concerns (like increased maintenance). You have to do what is right for you and your business. That's fair enough. > however, we've also seen resistance to our methods of > making changes because we need to package things in chunks that we feel > reviewers can review and approvers can approve. Do you really think this is unreasonable? It's always the case that one guy working on his own with complete freedom can work faster than when he's using a team process with checks and balances. It's one of the downsides of collaboration which have to be measured against the upsides of (hopefully) increased code quality and more future-proof design, etc. Gerv From jmdesp at alussinan.org Wed Oct 31 13:45:40 2007 From: jmdesp at alussinan.org (Jean-Marc Desperrier) Date: Wed, 31 Oct 2007 14:45:40 +0100 Subject: New language discussion? In-Reply-To: References: Message-ID: Andr?s G. Aragoneses wrote: > Hey, but I proposed Mono. With that, we could write things in > IronPython, IronRuby... and have good stuff from contributors like C#, > all languages interacting together. As well as javascript ( http://www.mono-project.com/JScript ) and perl ! (though PerlNet). _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From jmdesp at alussinan.org Wed Oct 31 14:05:17 2007 From: jmdesp at alussinan.org (Jean-Marc Desperrier) Date: Wed, 31 Oct 2007 15:05:17 +0100 Subject: New language discussion? In-Reply-To: References: <946E76E38BC1E2448B68F32FAEA2BA582641B3@2ksrvr01.march-hare.local> Message-ID: Benton, Kevin wrote: > We're (AMD) actively working on a radical shift in the way that "custom" > fields are being done by providing a field scheme model of implementing > "custom" fields. We prefer to call those "custom" fields "add-on" > fields rather than custom. Once the code support them, then they truly > will be add-on fields. While we're doing field schemes that allow > administrators to select what fields are available by product, we're > also developing workflow schemes in the same methodology so that each > product can have its own workflow. There are many different workflow > needs within our company based on the type of work being done. Some > processes have an extra documentation step, some have an extra > incorporation step, and there are many others. Not all products need > the extra steps so workflow schemes will allow us to assign those > workflows on a per-product basis. I think this is great work, and it's too bad it ends up behind closed doors only because of the difficulty to integrate it. I think you would render a great service to everybody by providing it as a fork. fork is an ugly word, but the truth is you already have that fork, and in addition to being a fork, nobody can see it. So it would be a positive move to make it a public fork instead of a private one. Then, there would be a chance that someone else does the ugly work needed to integrate it, or at least that bugzilla gets some of it's most interesting/easy to integrate elements. _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From knocte at NO-SPAM-PLEASE-gmail.com Wed Oct 31 17:47:00 2007 From: knocte at NO-SPAM-PLEASE-gmail.com (=?UTF-8?B?IkFuZHLDqXMgRy4gQXJhZ29uZXNlcyI=?=) Date: Wed, 31 Oct 2007 18:47:00 +0100 Subject: New language discussion? In-Reply-To: References: Message-ID: <4728BF94.7000301@NO-SPAM-PLEASE-gmail.com> Jean-Marc Desperrier escribi?: > Andr?s G. Aragoneses wrote: >> Hey, but I proposed Mono. With that, we could write things in >> IronPython, IronRuby... and have good stuff from contributors like C#, >> all languages interacting together. > > As well as javascript ( http://www.mono-project.com/JScript ) and perl ! > (though PerlNet). Interesting! Can you update the wiki with this info on the Mono section? Regards, Andr?s [ knocte ] -- _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From john.fisher at znyx.com Wed Oct 31 18:12:54 2007 From: john.fisher at znyx.com (John P. Fisher) Date: Wed, 31 Oct 2007 11:12:54 -0700 Subject: New language discussion? In-Reply-To: <47287143.5020201@mozilla.org> References: <946E76E38BC1E2448B68F32FAEA2BA582641B3@2ksrvr01.march-hare.local> <47287143.5020201@mozilla.org> Message-ID: <4728C5A6.1010807@znyx.com> excuse me for butting in here, as a non-contributor to the public code base. I have a bugzilla installation so modified and hacked that I gave up on updates and just forked it. This discussion sounds very professional and sensible, and illustrates, IMO, what happens with code bases that become large and mature. You guys are all smarter than I, so I won't pretend to any solution inside the main tree of bugzilla code. I'd like some feedback, on my future plans for our bugzilla. We are a small commercial software outfit ( linux - C ) with no IT department ( thank goodness). Our bug base has about 5000 bugs in the main product. We are in the telephony-aerospace biz, so customers require separate code trees sometimes, and years of support for any release. So we have features like branches and cloned bugs and version-fixed-in to accommodate. We don't use any of the whiteboard-time-tracking stuff, and I have lost track of the current feature set ( since I can't use it anymore) gab gab gab anyway, I just can't see going forward with perl for a web-based app that needs custom fields and life-cycle changes. So I looked around and PHP is very well supported, but Ruby has a far better object orientation and database support, so it looks to me like a re-write in Ruby would give the best results. In reading this thread, I am a little puzzled that it wasn't considered- perhaps I just missed the conversation? thanks for any comment John Fisher Gervase Markham wrote: > Benton, Kevin wrote: >> As we all know, Bugzilla is implemented in Perl and the codebase is >> getting better as we move to a more object-oriented model where >> persistence is done at the proper layers. > > Indeed. Several years, ago, we asked the same question - rewrite or > incrementally fix? The rewrite, Hixie's Bugzilla 3, didn't happen; Myk > argued for incrementally fixing, and the code now is much better than > it was. It seems to me that the arguments now are even more in favour > of incremental improvement than they were then. > >> There's a lot of work to be >> done, but no matter what language is chosen, it's possible to wind up >> with the same problems we have today > From mkanat at bugzilla.org Wed Oct 31 18:31:38 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 31 Oct 2007 11:31:38 -0700 Subject: In General Response to the "New Language Discussion" Message-ID: <20071031113138.20dd4065@es-compy> Bugzilla is not currently being re-written in any other language, no matter what advantages the alternatives have. It *could* be re-written in better Perl. It could use Catalyst, Moose, and DBIx::Class. Not right now, but at some point in the future. If anybody wants to *fund* a re-write of Bugzilla in some other language, that's another story. This was already discussed at a meeting many months ago and is the current official position of the Bugzilla Project. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From mkanat at bugzilla.org Wed Oct 31 18:42:41 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 31 Oct 2007 11:42:41 -0700 Subject: New language discussion? In-Reply-To: <946E76E38BC1E2448B68F32FAEA2BA582641B3@2ksrvr01.march-hare.local> References: <946E76E38BC1E2448B68F32FAEA2BA582641B3@2ksrvr01.march-hare.local> Message-ID: <20071031114241.72812f50@es-compy> On Tue, 30 Oct 2007 11:07:00 +1100 "Arthur Barrett" wrote: > We are currently working on a re-write of Bugzilla in C++ as a part of > the EVS project I think we're all honored that you like Bugzilla enough to use it as a base for your own project. However, I think a re-write, particularly in C++ is an unwise move. Here's why: 1. C++ is a much less flexible language than Perl, requiring much more work to create a successful cross-platform application. 2. C++ is rarely used for writing web applications nowadays. 3. For the type of performance that Bugzilla users require, the performance advantage is irrelevant, particularly with mod_perl support in Bugzilla 3.0. 4. Re-writing Bugzilla (particularly without consulting with us or offering to contribute to Bugzilla itself) assumes that you know just as much as we do, or more, about: * The history of bugs that people have encountered in Bugzilla. * The general needs of Bugzilla users. * The architecture and design of a bug-tracking system. 5. You're going to experience the Second System Effect quite intensely, particularly using C++, and particularly if you're basing your efforts on the code base of older versions of Bugzilla. Please also keep in mind that "Bugzilla" is a trademark of the Mozilla Foundation and that you can not use it in the name of your product, or to advertise your product. I'm actually quite unaware what advantage you gain by re-writing Bugzilla in C++. It would probably take less time for your developers to become proficient in Perl than it would take to re-write all of Bugzilla in a strongly-typed, compiled language. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From kevin.benton at amd.com Wed Oct 31 18:46:41 2007 From: kevin.benton at amd.com (Benton, Kevin) Date: Wed, 31 Oct 2007 11:46:41 -0700 Subject: Bugzilla Contribution Process (was RE: New language discussion?) In-Reply-To: <47287143.5020201@mozilla.org> References: <946E76E38BC1E2448B68F32FAEA2BA582641B3@2ksrvr01.march-hare.local> <47287143.5020201@mozilla.org> Message-ID: All, I hope that this discussion helps make others aware of some of the challenges that more than one business is facing with contributing code (sponsored code) back to the community - and if possible, that we can work together to find ways to see more sponsored code make it into the community releases. That *is* my goal in this topic. > Benton, Kevin wrote: > > As we all know, Bugzilla is implemented in Perl and the codebase is > > getting better as we move to a more object-oriented model where > > persistence is done at the proper layers. > > Indeed. Several years, ago, we asked the same question - rewrite or > incrementally fix? The rewrite, Hixie's Bugzilla 3, didn't > happen; Myk > argued for incrementally fixing, and the code now is much > better than it > was. It seems to me that the arguments now are even more in favour of > incremental improvement than they were then. If you had asked us how we felt when evaluating this question against 2.20rc1, our answer would have been fork or re-write (it wound up being fork at the time). Knowing then what I know now, I may have made a decision to switch tools. Today, however, the code is *much* better than it was and we're more likely to stick with what is already out there. > > There's a lot of work to be > > done, but no matter what language is chosen, it's possible > to wind up > > with the same problems we have today if we don't change the > standards by > > which we code. So, I suggest that we look at the real > issue - how do we > > design our code so that it doesn't look and feel like procedural > > spaghetti? Having SQL in the CGI, for example is a great > example of why > > you don't want to repeat yourself again (:-). Moving the SQL into > > modules that deal directly with the database (DAO) makes > the most sense > > to me because then, there is only one place to maintain > with regard to > > the back-end and it's easy to change out if needed. > > You see, five years ago, people weren't doing this - or it > wasn't nearly > as well known as best practice. Bugzilla is improving all the time as > people's understanding of how to write web apps improves, and > that can > only be a good thing. But we'll never be perfect, because perfect is > always changing. We agree. Best practices are getting better, though I don't know that communicating those best practices is going as well as coding to them is... That may be because I haven't been looking for them in the right places. Max and others are doing a fantastic job of making the code much more object oriented (not just having modules for the sake of modules). Hooks and the API are good things too... > > We're (AMD) actively working on a radical shift in the way > that "custom" > > fields are being done by providing a field scheme model of > implementing > > "custom" fields. We prefer to call those "custom" fields "add-on" > > fields rather than custom. > > How do they compare to the various other ways of implementing custom > fields that were proposed when we originally did them? The "add-on" fields actually use a large part of the custom field code, however, we're making sweeping changes so we utilize a small set of routines to deal with field views and changes. For example, we're getting rid of is_(active|obsolete) and isobsolete, replacing each with isactive, then updating the code so we don't have four different ways to deal with whether or not a field or value is active or obsolete. We're also converting bugs columns to store ID's rather than values to enforce referential integrity. This makes it easier to maintain code because all that's required afterward is to make sure that an insert or update was successful. Once we have a more unified way of dealing with fields generically, then we can deal with field schemes. Until then, we would have far too many exceptions to deal with. For those that don't know what field schemes are about, field schemes determine what fields are displayed based on a bug's active product. All values are stored in a bug regardless of field scheme, but this allows product Foo to include all the default fields plus fields A and B. Product Bar doesn't care about field B, but cares about A and C, so only A and C are displayed when Bar is the current product. Field schemes also set the list of available values on a per-scheme or per-product basis depending on the scheme settings. For example, field schemes using "Bug Type" will share the same set of values regardless of product, where field schemes using "First Rev Affected" will use a set of values based on the product configuration (in the one-many and many-many configurations). Workflow schemes are similar to and build on field schemes. Workflow schemes affect more than just the available options of state changes. Workflow schemes also specify when a field is required or not, when a field gets cleared automatically, and who is allowed to make certain changes. So, when an approval must be made to release code, workflow schemes allow for a list of individuals who can grant approval (as a state, not a flag) before a bug can progress to the Incorporated state (where the code is incorporated into a release). For the purpose of searching, we've made some other improvements such as adding a bug_values_cache table that stores a bug_id, and the values of many-to-many relationships for each bug (such as the CC list members by email and dependency relationships). This makes it possible to display columns of many-to-many relationship fields without expensive queries to the database. The downside is the very slight increase in time required to create and update bugs where those fields are also involved. We're also adding a description column to every table that doesn't already have one for the purpose of improving the help system so it can describe a table's values. This provides guidance when users don't understand when to use certain values versus others, especially when the labels may not be clear enough. > > Frankly, our number one concern with contributing code back to the > > community is the length of time it takes to go from contribution to > > approval in combination with the risk that our change > set(s) won't be > > accepted by the community. > > Contributing has concerns; forking has other concerns (like increased > maintenance). You have to do what is right for you and your business. > That's fair enough. > > > however, we've also seen resistance to our methods of > > making changes because we need to package things in chunks > that we feel > > reviewers can review and approvers can approve. > > Do you really think this is unreasonable? There are times when it seems reasonable, yet there are times when we feel it's not. There are times when we feel we just want to give back but we don't have the resources to integrate. There are other times when a feature set is so invasive to the core of the community code and so critical to our day-to-day development and operations that we're willing to make the extra effort. There are also times when we feel we just can't wait for the community to review and approve what we're doing. > It's always the case that one guy working on his own with complete > freedom can work faster than when he's using a team process > with checks > and balances. It's one of the downsides of collaboration > which have to > be measured against the upsides of (hopefully) increased code quality > and more future-proof design, etc. That's a given, and up to a point, there are times when it's worth the effort. The problem isn't just the size of the chunks, however. It's the extra effort that must be given to limit the scope of work in those chunks. The problem that corresponds with that, however, is do we wait for the review / approval process to complete to move on to developing a piece that builds on the chunk we just submitted for review, hoping that it will be reviewed quickly and approved or, do we make the decision to keep moving forward and backport any differences into our own code? The problem is that the review and approval process is a wildcard that we have no control over. Even though code may have completely passed our own review and approval process, the community may inject its own requirements that may or may not be compatible with our own. That risk is a real cost of doing business with open source communities and like it or not, has a negative impact on schedules. >From our perspective, the challenge is deciding if/how to contribute and when. There are pieces we've added to Bugzilla that are intellectual property that we will not contribute back to the community. There are other pieces that we've developed that we clearly want to see included, yet will take significant effort because someone has to syncronize that code with the current tip. If the review takes long enough that someone else's patch makes it into the tip before our review completes, then we end up being asked to take the burden of merging the code again. Granted, I would never ask the community to stop development just because we want to contribute, but at the same time, our current review process doesn't offer a way to protect contributors from excessive amounts of merging due to lag between submission and review. When we're done with our field scheme and workflow scheme code, it's likely to be thousands of lines each of implementation. This is a prime example of the risk versus reward situation. With large patches, a lot of work must be done to review, thus the likelihood of needing to merge increases as well. Are these features desired by the community? There is no question in my mind that in both cases, a resounding yes is appropriate. The problem on our end is that management is requiring that we complete our work long before I think the review process can complete from within the community. Once we're "done" with our implementation internally, managers want to see us continue to move forward with the next series of changes as they come to us. They don't understand when we tell them we have to go back to update our code so it'll work with the community when we've already moved beyond a feature set. It's an issue to explain that we're dealing with forward compatibility with Bugzilla. I hope that others don't get the idea that I'm complaining for the sake of complaining about this. I hope it'll help bring a bit more awareness of some of the issues corporate contributors face when deciding do I contribute or fork? Unfortunately, I continue to get responses leading me to believe that the answer often ends up being fork. If there are things that this community can do to help improve responsiveness by helping corporate contributors what kind of things will help reviews get done faster (such as submitting full sets of test cases and selenium test code to go with the developed code), then I think you'll see more sponsored contributions coming. Otherwise, the risk of being stalled by the review and approval process will remain high enough for many that it's cheaper to fork than contribute and I think that's when we all loose. Kevin --- Kevin Benton MySQL DBA #5739 Senior Software Developer CAD Global Infrastructure Flow Services Advanced Micro Devices 2950 E Harmony Rd Fort Collins, CO 80528 The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. From mkanat at bugzilla.org Wed Oct 31 19:11:49 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 31 Oct 2007 12:11:49 -0700 Subject: Bugzilla Contribution Process (was RE: New language discussion?) In-Reply-To: References: <946E76E38BC1E2448B68F32FAEA2BA582641B3@2ksrvr01.march-hare.local> <47287143.5020201@mozilla.org> Message-ID: <20071031121149.64b43cf6@es-compy> On Wed, 31 Oct 2007 11:46:41 -0700 "Benton, Kevin" wrote: > replacing > each with isactive, then updating the code so we don't have four > different ways to deal with whether or not a field or value is active > or obsolete. The only reason Bugzilla currently works that way is that isactive isn't used. > field schemes [snip] I already have code that does this. It may even get into 3.2. > For the purpose of searching, we've made some other improvements such > as adding a bug_values_cache table that stores a bug_id, and the > values of many-to-many relationships for each bug (such as the CC > list members by email and dependency relationships). See, funny, because we're actually re-writing things to eliminate those. :- > We're also adding a description column to every table that doesn't > already have one for the purpose of improving the help system so it > can describe a table's values. The help system was already improved to allow for adding help to any page. For us, we'd have to do this in a localizable way. > [snip] There are also times when we > feel we just can't wait for the community to review and approve what > we're doing. And that's reasonable. That's one of the advantages of Open Source code. > There are other pieces that we've developed that we > clearly want to see included, yet will take significant effort > because someone has to syncronize that code with the current tip. > [snip] In that case, I'd recommend hiring a contractor to help you out with the process, somebody who's a core member of the Bugzilla team or a proven Bugzilla contributor. You might think this is a subtle self-advertisement, but it's not--there are many contractors, and I really do think this is a great way to give back to the community and also see your own goals realized. > It's an issue to explain that we're dealing with forward > compatibility with Bugzilla. I'd be happy to explain this to anybody who wants to talk about it. I suspect that your managers don't understand the advantages of open source? That is, *somebody else*, who *doesn't work at your company*, is *also working on the code*. You get the work of many people for free. The solid equation to look at, that any reasonable management will accept, is how much code you're getting for free versus how much work it takes you to synchronize with upstream. Given enough time, upstream will always win, because there's more people working on it and we're adding far more new features than one person possibly could. > If there are things that this community can do to help improve > responsiveness by helping corporate contributors what kind of things > will help reviews get done faster (such as submitting full sets of > test cases and selenium test code to go with the developed code), > then I think you'll see more sponsored contributions coming. Unfortunately the problem isn't limited to corporate contributions, or even large contributions. We simply need more reviewers. Even with more reviewers, patches must be of a reviewable size. I personally can edit down a patch to reasonable size at 2-3 hours maximum. (Usually it takes far less time.) If you don't have 2-3 hours to edit a patch, then you probably won't have time to revise the patch, and as much as I'd like to be able to help, the solution to that problem just logically doesn't lie with the Bugzilla Project. I often don't read or respond to very long posts, but I read and responded to this one because the contribution process to Bugzilla is extremely important to me. I have already worked to make it easier and easier for new contributors to become known and contribute their work to the Bugzilla Project. If anybody has some reasonable ideas what can be done to further ease that process without relaxing our code quality standards, do please let me know, either here or by personal email. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From aaron.trevena at gmail.com Wed Oct 31 19:37:04 2007 From: aaron.trevena at gmail.com (Aaron Trevena) Date: Wed, 31 Oct 2007 19:37:04 +0000 Subject: New language discussion? In-Reply-To: <20071031114241.72812f50@es-compy> References: <946E76E38BC1E2448B68F32FAEA2BA582641B3@2ksrvr01.march-hare.local> <20071031114241.72812f50@es-compy> Message-ID: On 31/10/2007, Max Kanat-Alexander wrote: > I think we're all honored that you like Bugzilla enough to use > it as a base for your own project. However, I think a re-write, > particularly in C++ is an unwise move. Here's why: There are few things I agree with Max about when it comes to perl, but he is spot on in what he says about porting to C++ (and much of it applies to ruby or python). > 4. Re-writing Bugzilla (particularly without consulting with us > or offering to contribute to Bugzilla itself) assumes that you know > just as much as we do, or more, about: > > * The history of bugs that people have encountered in Bugzilla. > * The general needs of Bugzilla users. > * The architecture and design of a bug-tracking system. I thought I knew bugzilla reasonably well after customising and integrating it with an intranet in one job. Despite not liking or agreeing with some of the design decisions I didn't have any problems at all customising it to my needs, and this was a couple of years ago and so without the benefit of recent refactoring, documentation or bug fixes. I thought I'd try porting it to a perl MVC framework, the first parts were fairly simple, but Max's points about lack of domain knowledge and the reasons behind many decisions were certainly true - if I wanted it to be more than an interesting learning exersize it needed to be useful to other people, and the bugzilla (and rt) developers know more about that than me. > 5. You're going to experience the Second System Effect quite > intensely, particularly using C++, and particularly if you're basing > your efforts on the code base of older versions of Bugzilla. Even porting to an ORM and MVC application server I quickly found that in remaining compatible I lost many benefits, and that if I wasn't going to be fully compatible then I may as well spec out the project and design from scratch, which is certainly more work than I really wanted, particularly when there several perl bug / request tracking systems that I can customise anyway. > I'm actually quite unaware what advantage you gain by > re-writing Bugzilla in C++. It would probably take less time for your > developers to become proficient in Perl than it would take to re-write > all of Bugzilla in a strongly-typed, compiled language. The same applies to pretty much any other language. I don't believe you would get any noticable benefit in speed - in every web application I've worked on perl has never been a bottleneck, query optimisation, resource contention, and architecture of the database schema, cluster and network all inevitable the bottlenecks in any such system. On the other hand, writing a first person shooter : C++ would probably be my first choice A. -- http://www.aarontrevena.co.uk LAMP System Integration, Development and Hosting From arthur.barrett at march-hare.com Wed Oct 31 19:40:19 2007 From: arthur.barrett at march-hare.com (Arthur Barrett) Date: Thu, 1 Nov 2007 06:40:19 +1100 Subject: New language discussion? Message-ID: <946E76E38BC1E2448B68F32FAEA2BA5858ED5C@2ksrvr01.march-hare.local> Hi All, Thanks to all who have replied. I'd like to address a couple of the main Q's that everyone seems to be asking without replying to each post separately. 1. Why C++? It solves a particular business problem for us. As a commercial software vendor our interest is in what our customers can deploy easily and (particularly for large customers) software that has as few dependencies as possible. We found this with our core open source CVSNT as well - commercial customers do NOT want perl script triggers - they want them in a DLL/.so. If you've ever tried installing MySQL and Perl on HPUX or Windows then you'd know why, or if you've ever dealt with security audits... We've had a lot of customers reject using our Bugzilla integration because Bugzilla needs Perl (usually windows customers) or the need to install MySQL (usually unix/linux customers who want to keep an oracle only, or DB2 only shop - I know some progress is being made in bugzilla towards database independance). And yes - since CVSNT and EVS are both written in C++ we have lots of C++ skills available to do this (and very few perl skills). 2. Why Windows as the first target. Our customers when counted "by numbers" are split evenly across windows and unix/linux however the biggest complaints that we have about Bugzilla is from the windows customers. I'd like to stress though that CVSNT and EVS runs cross platform - it's just a project management decision to kill the linux/unix builds until after release 1 to concentrate resources. 3. Asking for help to write non-open source This is/was NOT my intention. What I am saying is that LOTS of our (other) code is LGPL, and the bugzilla rewrite could be too IF I had evidence to suggest that it would represent less work (ie: there are people with time/skills clamouring to help but cannot/will not due to the licnese). Responses this far suggest that we are currently following the best path in keeping development closed. 4. rewrite I am not a fan of rewrites, and I'd only marginally call what we are doing a rewrite. Release 1 will not re-implement the full feature set of bugzilla, but it will use the (latest) Bugzilla data model. This means that for people who want a bug tracking system that "can grow" then they can start with ours that works "out of the box" and later install the "full" Bugzilla on top. Yes our next beta will use an old data model, but the intention is to change that ASAP. We'll most likely start with a VERY minor subset of implemented functionality and let our customers decide which are the "critical" missing features. 5. name I'm not even sure if we have a name - the idea of EVS is it is a CM system, rather than needing SCM+defect tracking+audit+build+etc etc, it's just all in one. I'm sure we'll market it as "data model compatible with Bugzilla, but that doesn't infringe any trademark I don't think. 6. if we did go open source... Our main open source project is CVSNT, which was essentially a fork from CVS. One of the main things that drew people to CVSNT initially was that the developers would accept almost any change and put it right into the next build within a few days. We still give out write access to our repo very quickly... If we did go open source with this "rewrite", then that would be the same. I hate to see a company the size of AMD want to contribute but not able to contribute due to the perception that the open source management gets in the way. 7. bugzilla project I personally think the bugzilla project is a great one - a true open source success story. I am hoping our work means more people adopt it because our software is "an easy way to start" (see point 4 above). As I wrote earlier - we don't have much in the way of Perl expertise in house, so contributing to a Perl based Bugzilla has never really been an option for us. On the up side - by only supporting defect integration to Bugzilla I know a lot of companies that have gone ahead with Bugzilla... Feel free to ask me any questions that you don't feel I've answered adequately. Regards, Arthur Barrett From mkanat at bugzilla.org Wed Oct 31 19:50:58 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 31 Oct 2007 12:50:58 -0700 Subject: New language discussion? In-Reply-To: <946E76E38BC1E2448B68F32FAEA2BA5858ED5C@2ksrvr01.march-hare.local> References: <946E76E38BC1E2448B68F32FAEA2BA5858ED5C@2ksrvr01.march-hare.local> Message-ID: <20071031125058.6c6c07cd@es-compy> On Thu, 1 Nov 2007 06:40:19 +1100 "Arthur Barrett" wrote: > It solves a particular business problem for us. [snip] Okay, this makes sense. For what it's worth, here's how I'd solve that problem and still stay with Perl: 1. Bugzilla could support SQLite, which would mean not having to install MySQL. 2. It's actually possible to compile perl apps to an .exe using some applications. You could do this with every CGI. I have no idea if it works with CGIs, but it couldn't hurt to try, I suppose. :-) > I am not a fan of rewrites, and I'd only marginally call what we are > doing a rewrite. Release 1 will not re-implement the full feature set > of bugzilla, but it will use the (latest) Bugzilla data model. This > means that for people who want a bug tracking system that "can grow" > then they can start with ours that works "out of the box" and later > install the "full" Bugzilla on top. Okay. So it's kind of like "mini-Bugzilla in a box". :-) > I'm sure we'll market it as "data model > compatible with Bugzilla, but that doesn't infringe any trademark I > don't think. Yes, that is probably OK, although I'm not a trademark authority for MoFo. > Our main open source project is CVSNT, which was essentially a fork > from CVS. One of the main things that drew people to CVSNT initially > was that the developers would accept almost any change and put it > right into the next build within a few days. And the code hasn't gotten unmanageable? Perhaps CVS was architected better than Bugzilla was architected some years ago. > On the up side - by only supporting defect > integration to Bugzilla I know a lot of companies that have gone > ahead with Bugzilla... Yeah, and we often point people at your software. :-) I know that I'm certainly appreciative. :-) -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. From arthur.barrett at march-hare.com Wed Oct 31 23:17:50 2007 From: arthur.barrett at march-hare.com (Arthur Barrett) Date: Thu, 1 Nov 2007 10:17:50 +1100 Subject: New language discussion? Message-ID: <946E76E38BC1E2448B68F32FAEA2BA5858ED60@2ksrvr01.march-hare.local> Max, > 1. Bugzilla could support SQLite, which would mean not having > to install MySQL. It's only single user though - which may work since Bugzilla is stateless but could easily bite at 9a in the morning when everyone logs in, or at 6p when everyone is finishing for the day - particularly when integrated with CVSNT so checkin comments are going to the Bugzilla db... Its far more common though that "customers" request "will it work with Oracle" though DB2 is also reasonably frequent... > > 2. It's actually possible to compile perl apps to an .exe using > some applications. You could do this with every CGI. I have no idea if > it works with CGIs, but it couldn't hurt to try, I suppose. :-) I have seen this, but hadn't really connected the two. I suspect that since no one else has done it already it may be harder than it sounds - and for now limiting the scope to a few functions and limited optios is easier to deliver and test. But it's an interesting option - thanks for that suggestion. > > Okay. So it's kind of like "mini-Bugzilla in a box". :-) > Yes - though it has scope to grow based on demand - I guess I'd eventually like to see 80% coverage of the top 80% used functions. > And the code hasn't gotten unmanageable? Perhaps CVS was > architected better than Bugzilla was architected some years ago. We find that most peoples changes are fairly isolated - and they just want "their change" added. Giving write access to the repo means they are more likely to stay up to date with the project later since their change remains in there. I am trying to encourage greater use of "enable my feature with preference x". Since 2.5.01 we've introduced some very nice 3GL triggers that can do a lot more than the Perl ones previously could - so that's a solution that's easily isolatable, but usually peoples changes are in the core. > Yeah, and we often point people at your software. :-) I know > that I'm certainly appreciative. :-) Always appreciated! Regards, Arthur Barrett