From ed.fuentetaja at ttu.edu Sat Jan 3 18:21:44 2004 From: ed.fuentetaja at ttu.edu (Fuentetaja, Ed) Date: Sat, 3 Jan 2004 12:21:44 -0600 Subject: your mail Message-ID: <55CA02C1ECF1CB40B2A0AF7B32F0DFDD15F4A7@BRONTES.net.ttu.edu> Yes, Bugzilla Test Runner is still alive. Prasad, for more information please go to: http://www.willowriver.net/products/testrunner.php A helping hand is more than welcomed, so far I'm the only developer :( I'm about to release a new version with some important improvements. The major one is that test cases won't be tied to particular testers. Myk rightly suggested than for open-source projects would be much better to let anybody run a test case. I'm also busy brushing up the interface and improving the usability. Speaking of open source, I recently moved the project to sourceforge: http://sourceforge.net/projects/testrunner/ Thanks and happy new year to everyone, Ed > -----Original Message----- > From: Christian Robottom Reis [mailto:kiko at async.com.br] > Sent: Tuesday, December 30, 2003 7:19 AM > To: developers at bugzilla.org > Cc: prasad kadbane > Subject: Re: your mail > > > On Tue, Dec 30, 2003 at 09:07:14AM +0100, Jeroen > Ruigrok/asmodai wrote: > > -On [20031230 08:52], prasad kadbane (prasad_kadbane at hotmail.com) > > wrote: > > >I am a student doing Bachelor of computer Engg in Pune university, > > >India. I am in the final year of degree course and I am doing a > > >project based on Bugzilla software. The aim of my project > is to link > > >Bugzilla with test case repository. Every bug entered in > the Bugzilla > > >will have a corresponding test case associated with it. > The bug can > > >be reproduced or demonstrated by running the associated test case. > > > > I am speaking from memory here since I haven't had a chance to mess > > with the codebase in a while now (should hopefully change soon): > > There have been two [separate?] testcase efforts discussed > here on the list; in particular Ed Fuentetaja and Myk have > been looking at this. It might make sense to look at their > work before starting anew. > > Take care, > -- > Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 > 16] 261 2331 > - > To view or change your list settings, click here: From jimw at bugopolis.com Mon Jan 5 21:47:15 2004 From: jimw at bugopolis.com (Jim Walters) Date: Mon, 05 Jan 2004 13:47:15 -0800 Subject: SOAP In-Reply-To: <3FE870D1.1030106@peshkin.net> References: <3FE79CCC.3040301@peshkin.net> <3FE7FF1E.5000905@mozilla.org> <20031223151603.GB1027@async.com.br> <3FE870D1.1030106@peshkin.net> Message-ID: <1073339235.18213.104.camel@new-control> Have gotten back to working on the SOAP API (using SOAP::Lite) but am in Perl module hell. Actually, its sort of a rookie problem. In the bugzilla directory I've created a .cgi file which sort of looks like this: #!/usr/bin/perl -w use strict; use lib qw(.); use SOAP::Transport::HTTP; use Bugzilla::DB; use Bugzilla::Demo; SOAP::Transport::HTTP::CGI -> dispatch_to('Demo') -> handle; And in the Bugzilla directory I stuck a .pm file that looks like this: use strict; package Demo; use Bugzilla; use Bugzilla::Constants; use Bugzilla::DB; use Bug; sub hi { return new Bug(1,1); #return "hello, world "; } sub bye { return "goodbye, cruel world"; } sub languages { return ("Perl", "C", "sh"); } 1; The error message coming back in SOAP to the JavaScript SOAP API in Mozilla (which is really nice, since in this case I don't have to tail error_log) is: "Undefined subroutine &main::SendSQL called at Bug.pm line 153". OK, I know the new Bug() object isn't the way to do this, but I just want to get the function name resolutions to work reasonably well. I get a returned "hello world" fine. I can actually call the Bugzilla->login sub and get the hash (?) back in my browser through the SOAP APIs. But what am I doing wrong that is causing SendSQL not to resolve. Is it because it has been depricated? I'm sure the problem has to do with the way I am including things rather than with the SOAP module. Well, maybe. Jim On Tue, 2003-12-23 at 08:44, Joel Peshkin wrote: > I guess I should broaden the question a bit and not focus so narrowly on > SOAP. > From vijayan.reddy at tavant.com Tue Jan 6 11:51:58 2004 From: vijayan.reddy at tavant.com (Vijayan.R.A.Reddy) Date: Tue, 06 Jan 2004 17:21:58 +0530 Subject: your mail In-Reply-To: <55CA02C1ECF1CB40B2A0AF7B32F0DFDD15F4A7@BRONTES.net.ttu.edu> References: <55CA02C1ECF1CB40B2A0AF7B32F0DFDD15F4A7@BRONTES.net.ttu.edu> Message-ID: <1073389917.30674.32.camel@tools.india.tavant.com> Hi Ed, Thanks to your tool, I have successfully held off a decision to procure pricey tools like Mercury Interactive's TestDirector for our company. We are looking at deploying TestRunner as a complete end-to-end Test Management Tool. From requirements to func.spec to test plan to testcase documents to test results to bugs. So the traceability matrix is completely supported by this tool. The feedback from our QA management is that while TestRunner is rich in features, the ease of use is missing a bit. The navigation through the tool is quite tough. We may start development shortly to cater to our internal requirements. We will be happy to share our requirements and also any customization patch when we are at it. Thanks, Vijayan. On Sat, 2004-01-03 at 23:51, Fuentetaja, Ed wrote: > Yes, Bugzilla Test Runner is still alive. Prasad, for more information > please go to: > > http://www.willowriver.net/products/testrunner.php > > A helping hand is more than welcomed, so far I'm the only developer :( > > I'm about to release a new version with some important improvements. The > major one is that test cases won't be tied to particular testers. Myk > rightly suggested than for open-source projects would be much better to > let anybody run a test case. I'm also busy brushing up the interface and > improving the usability. > > Speaking of open source, I recently moved the project to sourceforge: > http://sourceforge.net/projects/testrunner/ > > Thanks and happy new year to everyone, > > Ed > > > -----Original Message----- > > From: Christian Robottom Reis [mailto:kiko at async.com.br] > > Sent: Tuesday, December 30, 2003 7:19 AM > > To: developers at bugzilla.org > > Cc: prasad kadbane > > Subject: Re: your mail > > > > > > On Tue, Dec 30, 2003 at 09:07:14AM +0100, Jeroen > > Ruigrok/asmodai wrote: > > > -On [20031230 08:52], prasad kadbane (prasad_kadbane at hotmail.com) > > > wrote: > > > >I am a student doing Bachelor of computer Engg in Pune university, > > > >India. I am in the final year of degree course and I am doing a > > > >project based on Bugzilla software. The aim of my project > > is to link > > > >Bugzilla with test case repository. Every bug entered in > > the Bugzilla > > > >will have a corresponding test case associated with it. > > The bug can > > > >be reproduced or demonstrated by running the associated test case. > > > > > > I am speaking from memory here since I haven't had a chance to mess > > > with the codebase in a while now (should hopefully change soon): > > > > There have been two [separate?] testcase efforts discussed > > here on the list; in particular Ed Fuentetaja and Myk have > > been looking at this. It might make sense to look at their > > work before starting anew. > > > > Take care, > > -- > > Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 > > 16] 261 2331 > > - > > To view or change your list settings, click here: > > > - > To view or change your list settings, click here: > From vijayan.reddy at tavant.com Tue Jan 6 11:54:28 2004 From: vijayan.reddy at tavant.com (Vijayan.R.A.Reddy) Date: Tue, 06 Jan 2004 17:24:28 +0530 Subject: CVS - Bugzilla integration Message-ID: <1073390067.30674.35.camel@tools.india.tavant.com> Hi All, We have a requirement to integrate CVS with Bugzilla, ie, with a checkin comment, if the engineer mentions the bugId, it should reflect the change in the bug status in Bugzilla, and then copy the check-in message to Bugzilla, and also, attach the diff as a patch in the bug report. This is something we are planning to have, shortly. Has anyone done any work on these lines ? Thanks, Vijayan. From dswegen at software.plasmon.com Tue Jan 6 12:35:04 2004 From: dswegen at software.plasmon.com (Dave Swegen) Date: Tue, 6 Jan 2004 12:35:04 +0000 Subject: CVS - Bugzilla integration In-Reply-To: <1073390067.30674.35.camel@tools.india.tavant.com> References: <1073390067.30674.35.camel@tools.india.tavant.com> Message-ID: <20040106123504.GA32247@software.plasmon> On Tue, Jan 06, 2004 at 05:24:28PM +0530, Vijayan.R.A.Reddy wrote: > Hi All, > > We have a requirement to integrate CVS with Bugzilla, ie, with a checkin > comment, if the engineer mentions the bugId, it should reflect the > change in the bug status in Bugzilla, and then copy the check-in message > to Bugzilla, and also, attach the diff as a patch in the bug report. > > This is something we are planning to have, shortly. Has anyone done any > work on these lines ? We have something similiar working here. It doesn't do the bug status changing thing, but does append commit messages to one or more specified bugs. Neither does it append the diff as an attachments, but uses ViewCVS to provide that (and more) functionality (see below). The bug comment in bugzilla ends up containing the message, the module name, the filename(s), old version number and new version numbers, as well as any tag/branch info. We also have implemented autolinkification to ViewCVS, such that the filename links to file info in ViewCVS, version numbers will show the relevant revisions of the files, and an extra link that points to the diff is added. Patches against bugzilla 2.17.1 can be found here: http://bugzilla.mozilla.org/show_bug.cgi?id=199116 As can be seen from the comments I'm slowly working on a) making it work against tip, and b) drop the email requirement. Thinking about it, adding the code to deal with status changes shouldn't be too hard. It would probably involve parsing one more line, and a bit more sql. Anyway, take a look at it and shout if something is unclear. Cheers Dave From gerv at mozilla.org Tue Jan 6 22:36:28 2004 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 06 Jan 2004 22:36:28 +0000 Subject: your mail In-Reply-To: <1073389917.30674.32.camel@tools.india.tavant.com> References: <55CA02C1ECF1CB40B2A0AF7B32F0DFDD15F4A7@BRONTES.net.ttu.edu> <1073389917.30674.32.camel@tools.india.tavant.com> Message-ID: <3FFB386C.5040409@mozilla.org> Vijayan.R.A.Reddy wrote: > The feedback from our QA management is that while TestRunner is rich in > features, the ease of use is missing a bit. The navigation through the > tool is quite tough. Note that Myk is working on a version of TestRunner for mozilla.org and has made significant changes to it. You may want to coordinate with him before starting work. Gerv From david_obler at ssaihq.com Tue Jan 6 13:33:30 2004 From: david_obler at ssaihq.com (David Obler) Date: Tue, 06 Jan 2004 08:33:30 -0500 Subject: your mail In-Reply-To: <1073389917.30674.32.camel@tools.india.tavant.com> References: <55CA02C1ECF1CB40B2A0AF7B32F0DFDD15F4A7@BRONTES.net.ttu.edu> <1073389917.30674.32.camel@tools.india.tavant.com> Message-ID: <3FFAB92A.209@ssaihq.com> Vijay, Please don't just rely on the on-line demo. Take a stab at cloning your Bugzilla database and creating test case scenarios. If you present a compelling demonstration against your own database - your reviewers may me more receptive to using TestRunner. I found it to be a great tool, that takes some getting used to - Just like Bugzilla. That is why I remain a proponent of TestRunner. Either way - good luck in your endeavors. Dave Vijayan.R.A.Reddy wrote: >Hi Ed, > >Thanks to your tool, I have successfully held off a decision to procure >pricey tools like Mercury Interactive's TestDirector for our company. > >We are looking at deploying TestRunner as a complete end-to-end Test >Management Tool. From requirements to func.spec to test plan to testcase >documents to test results to bugs. So the traceability matrix is >completely supported by this tool. > >The feedback from our QA management is that while TestRunner is rich in >features, the ease of use is missing a bit. The navigation through the >tool is quite tough. > >We may start development shortly to cater to our internal requirements. >We will be happy to share our requirements and also any customization >patch when we are at it. > >Thanks, >Vijayan. > >On Sat, 2004-01-03 at 23:51, Fuentetaja, Ed wrote: > > >>Yes, Bugzilla Test Runner is still alive. Prasad, for more information >>please go to: >> >>http://www.willowriver.net/products/testrunner.php >> >>A helping hand is more than welcomed, so far I'm the only developer :( >> >>I'm about to release a new version with some important improvements. The >>major one is that test cases won't be tied to particular testers. Myk >>rightly suggested than for open-source projects would be much better to >>let anybody run a test case. I'm also busy brushing up the interface and >>improving the usability. >> >>Speaking of open source, I recently moved the project to sourceforge: >>http://sourceforge.net/projects/testrunner/ >> >>Thanks and happy new year to everyone, >> >> Ed >> >> >> >>>-----Original Message----- >>>From: Christian Robottom Reis [mailto:kiko at async.com.br] >>>Sent: Tuesday, December 30, 2003 7:19 AM >>>To: developers at bugzilla.org >>>Cc: prasad kadbane >>>Subject: Re: your mail >>> >>> >>>On Tue, Dec 30, 2003 at 09:07:14AM +0100, Jeroen >>>Ruigrok/asmodai wrote: >>> >>> >>>>-On [20031230 08:52], prasad kadbane (prasad_kadbane at hotmail.com) >>>>wrote: >>>> >>>> >>>>>I am a student doing Bachelor of computer Engg in Pune university, >>>>>India. I am in the final year of degree course and I am doing a >>>>>project based on Bugzilla software. The aim of my project >>>>> >>>>> >>>is to link >>> >>> >>>>>Bugzilla with test case repository. Every bug entered in >>>>> >>>>> >>>the Bugzilla >>> >>> >>>>>will have a corresponding test case associated with it. >>>>> >>>>> >>>The bug can >>> >>> >>>>>be reproduced or demonstrated by running the associated test case. >>>>> >>>>> >>>>I am speaking from memory here since I haven't had a chance to mess >>>>with the codebase in a while now (should hopefully change soon): >>>> >>>> >>>There have been two [separate?] testcase efforts discussed >>>here on the list; in particular Ed Fuentetaja and Myk have >>>been looking at this. It might make sense to look at their >>>work before starting anew. >>> >>>Take care, >>>-- >>>Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 >>>16] 261 2331 >>>- >>>To view or change your list settings, click here: >>> >>> >> >> >>- >>To view or change your list settings, click here: >> >> >> > >- >To view or change your list settings, click here: > > > > > From jon at vmware.com Tue Jan 6 23:58:31 2004 From: jon at vmware.com (Jonathan Schatz) Date: Tue, 06 Jan 2004 15:58:31 -0800 Subject: SOAP In-Reply-To: <1073339235.18213.104.camel@new-control> References: <3FE79CCC.3040301@peshkin.net> <3FE7FF1E.5000905@mozilla.org> <20031223151603.GB1027@async.com.br> <3FE870D1.1030106@peshkin.net> <1073339235.18213.104.camel@new-control> Message-ID: <1073433511.21020.7.camel@jonschatz-lx.vmware.com> On Mon, 2004-01-05 at 13:47, Jim Walters wrote: > The error message coming back in SOAP to the JavaScript SOAP API in > Mozilla (which is really nice, since in this case I don't have to tail > error_log) is: "Undefined subroutine &main::SendSQL called at Bug.pm > line 153". add this line after your "use lib" line: require "globals.pl" at least, on the forked bugzilla i have here, that's where SendSQL lives. and yes, the old db functionality has been deprecated... -jon -jon -- Jonathan Schatz Engineering System Administrator VMware, Inc "Te occidere possunt sed te edere non possunt nefas est." From jimw at bugopolis.com Wed Jan 7 00:53:36 2004 From: jimw at bugopolis.com (Jim Walters) Date: Tue, 06 Jan 2004 16:53:36 -0800 Subject: SOAP In-Reply-To: <1073433511.21020.7.camel@jonschatz-lx.vmware.com> References: <3FE79CCC.3040301@peshkin.net> <3FE7FF1E.5000905@mozilla.org> <20031223151603.GB1027@async.com.br> <3FE870D1.1030106@peshkin.net> <1073339235.18213.104.camel@new-control> <1073433511.21020.7.camel@jonschatz-lx.vmware.com> Message-ID: <1073436816.18213.367.camel@new-control> Thanks. I had tried that but there is something about CGI.pl that the SOAP module doesn't appear to get along with very well. I guess I'm not understanding the new architecture (or maybe the old architecture). I'm assuming Bug.pm is implementing the "Bug" class but it appears to be dependent on the SendSQL code. What is the new improved way of just getting an object representing a bug? Thanks Jim On Tue, 2004-01-06 at 15:58, Jonathan Schatz wrote: > On Mon, 2004-01-05 at 13:47, Jim Walters wrote: > > The error message coming back in SOAP to the JavaScript SOAP API in > > Mozilla (which is really nice, since in this case I don't have to tail > > error_log) is: "Undefined subroutine &main::SendSQL called at Bug.pm > > line 153". > > add this line after your "use lib" line: > > require "globals.pl" > > at least, on the forked bugzilla i have here, that's where SendSQL > lives. and yes, the old db functionality has been deprecated... > > -jon > > -jon From jimw at bugopolis.com Wed Jan 7 03:16:06 2004 From: jimw at bugopolis.com (Jim Walters) Date: Tue, 06 Jan 2004 19:16:06 -0800 Subject: SOAP In-Reply-To: <1073436816.18213.367.camel@new-control> References: <3FE79CCC.3040301@peshkin.net> <3FE7FF1E.5000905@mozilla.org> <20031223151603.GB1027@async.com.br> <3FE870D1.1030106@peshkin.net> <1073339235.18213.104.camel@new-control> <1073433511.21020.7.camel@jonschatz-lx.vmware.com> <1073436816.18213.367.camel@new-control> Message-ID: <1073445366.18213.369.camel@new-control> Was wrong. Was requiring "CGI.pl". With globals.pl its working fine and I'm getting bugs back. Thanks On Tue, 2004-01-06 at 16:53, Jim Walters wrote: > Thanks. I had tried that but there is something about CGI.pl that the > SOAP module doesn't appear to get along with very well. I guess I'm not > understanding the new architecture (or maybe the old architecture). I'm > assuming Bug.pm is implementing the "Bug" class but it appears to be > dependent on the SendSQL code. What is the new improved way of just > getting an object representing a bug? > > Thanks > > Jim > > On Tue, 2004-01-06 at 15:58, Jonathan Schatz wrote: > > On Mon, 2004-01-05 at 13:47, Jim Walters wrote: > > > The error message coming back in SOAP to the JavaScript SOAP API in > > > Mozilla (which is really nice, since in this case I don't have to tail > > > error_log) is: "Undefined subroutine &main::SendSQL called at Bug.pm > > > line 153". > > > > add this line after your "use lib" line: > > > > require "globals.pl" > > > > at least, on the forked bugzilla i have here, that's where SendSQL > > lives. and yes, the old db functionality has been deprecated... > > > > -jon > > > > -jon > > > - > To view or change your list settings, click here: > __________________________ Jim Walters Director of Technology Bugopolis, Inc. phone: +1 206 447 8315 email: jimw at bugopolis.com web: http://www.bugopolis.com _________________________ From akalaveshi at rsasecurity.com Wed Jan 7 20:19:01 2004 From: akalaveshi at rsasecurity.com (Kalaveshi, Adrian) Date: Wed, 7 Jan 2004 15:19:01 -0500 Subject: Ability to query on role field contains user with specific group membership Message-ID: <8E883DEEED068E479A8900161D80DB1C856A4D@exsf01.na.rsa.net> Hello -- I've been racking my brains all morning trying to come up with a SQL query to give me a list of bugs who's "assigned_to" value is equal to a member of group "x". I know that this probably isn't the proper forum, but I was hoping that one of you SQL experts might be able to help me out. FYI, I also filed a bug so that this might become a feature. http://bugzilla.mozilla.org/show_bug.cgi?id=230225 select bugs.bug_id, profiles.login_name from bugs, profiles ... Thanks for any help... -adrian- From gerv at mozilla.org Thu Jan 8 21:47:49 2004 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 08 Jan 2004 21:47:49 +0000 Subject: Ability to query on role field contains user with specific group In-Reply-To: <8E883DEEED068E479A8900161D80DB1C856A4D@exsf01.na.rsa.net> References: <8E883DEEED068E479A8900161D80DB1C856A4D@exsf01.na.rsa.net> Message-ID: <3FFDD005.7090601@mozilla.org> Kalaveshi, Adrian wrote: > I've been racking my brains all morning trying to come up with a SQL query > to give me a list of bugs who's "assigned_to" value is equal to a member of > group "x". I know that this probably isn't the proper forum, but I was > hoping that one of you SQL experts might be able to help me out. I'm no SQL expert, but: SELECT bugs.bug_id FROM bugs, user_group_map, groups WHERE bugs.assigned_to = user_group_map.user_id AND user_group_map.group_id = groups.id AND groups.name = 'gervgroup' GROUP BY bugs.bug_id; Gerv From chee at SLAC.Stanford.EDU Fri Jan 9 17:22:50 2004 From: chee at SLAC.Stanford.EDU (Charlotte Hee) Date: Fri, 09 Jan 2004 09:22:50 -0800 (PST) Subject: problems modifying Priority values in localconfig (fwd) Message-ID: Hello, I'm a newbie to bugzilla and have created a problem for myself which I'm not sure how to solve. Version 2.16.1 was installed onto a linux box by one of my colleagues and I'm teaching myself how bugzilla works. I am trying to modify the "Priority" values in the file localconfig. I wanted to change the values P1-P5 to a more descriptive text such as very low, low, medium, high, very high. I edited localconfig, putting in the text that I wanted, then ran checksetup.pl. This didn't work so I put the P1-P5 back and ran checksetup.pl again. Now when I try to enter a new bug I get the error: Can't use an undefined value as an ARRAY reference at /opt/babar-bugzilla/enter_bug.cgi line 243 Looking at enter_bug.cgi, line 243 it shows this code snippet: if (0 == @{$::components{$product}}) { my $error = "Sorry; there needs to be at least one component for this" . "product in order to create a new bug. "; if (UserInGroup('editcomponents')) { $error .= "" . "Create a new component\n"; } . . . I'm not sure how my minor modification caused any undefined references, especially since I put things back the way they were initially. Any ideas on what I've done wrong and how I can fix this? thanks, Chee From jon at vmware.com Tue Jan 13 00:01:19 2004 From: jon at vmware.com (Jonathan Schatz) Date: Mon, 12 Jan 2004 16:01:19 -0800 Subject: mysql performance + bugzilla Message-ID: <1073952079.2677.14.camel@jonschatz-lx.vmware.com> I've gotten a few complaints here that our bugzilla is "too slow". most of the complaints come from people who weren't around to witness the horror of our old gnats installation, or the horror of bugzilla running in a vm on my desktop. one of the complaints is that the bugs table will continuously grow (and therefore become inefficient). i checked on b.m.o and saw that there are > 200k bugs filed there (we're still under 40k here). so my questions are: 1) does mysql performance degrade linearly with the size of a table? 2) is there any fancy reindexing i could do to speed up queries? 3) what hardware + software (specifically, db + httpd) is b.m.o running? thanks, -jon From kiko at async.com.br Tue Jan 13 00:52:18 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Mon, 12 Jan 2004 22:52:18 -0200 Subject: problems modifying Priority values in localconfig (fwd) In-Reply-To: References: Message-ID: <20040113005218.GA4786@async.com.br> On Fri, Jan 09, 2004 at 09:22:50AM -0800, Charlotte Hee wrote: > by one of my colleagues and I'm teaching myself how bugzilla works. I am > trying to modify the "Priority" values in the file localconfig. I wanted > to change the values P1-P5 to a more descriptive text such as very low, > low, medium, high, very high. I edited localconfig, putting in the text > that I wanted, then ran checksetup.pl. This didn't work so I put the When you say "didn't work", what do you mean? > Can't use an undefined value as an ARRAY reference at > /opt/babar-bugzilla/enter_bug.cgi line 243 > > Looking at enter_bug.cgi, line 243 it shows this code snippet: > if (0 == @{$::components{$product}}) { > my $error = "Sorry; there needs to be at least one component for this" . > "product in order to create a new bug. "; > if (UserInGroup('editcomponents')) { > $error .= "" . > "Create a new component\n"; > } > . > . > . > > I'm not sure how my minor modification caused any undefined references, > especially since I put things back the way they were initially. > Any ideas on what I've done wrong and how I can fix this? It *seems* that these problems are unrelated. I'd suggest -- before spending any more time on this -- updating to the latest 2.16 release, which is currently 2.16.4. It shouldn't have any outstanding problems, and if it does, we'll be in good shape to fix it, too! Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From bruce.armstrong at teamsybase.com Tue Jan 13 01:36:18 2004 From: bruce.armstrong at teamsybase.com (Bruce Armstrong [TeamSybase]) Date: Mon, 12 Jan 2004 17:36:18 -0800 (PST) Subject: mysql performance + bugzilla In-Reply-To: <1073952079.2677.14.camel@jonschatz-lx.vmware.com> Message-ID: <20040113013618.99709.qmail@web12504.mail.yahoo.com> Try turning off the sendmailnow attribute. In my experience most of the time there's a delay in the system it's not with Bugzilla updating the MySQL database, it's with Bugzilla waiting for the SMTP server to acknowledge the transmission of the emails. If you turn that parameter off, the email generation is handled seperately from the bug update. Jonathan Schatz wrote:I've gotten a few complaints here that our bugzilla is "too slow". most of the complaints come from people who weren't around to witness the horror of our old gnats installation, or the horror of bugzilla running in a vm on my desktop. one of the complaints is that the bugs table will continuously grow (and therefore become inefficient). i checked on b.m.o and saw that there are > 200k bugs filed there (we're still under 40k here). so my questions are: 1) does mysql performance degrade linearly with the size of a table? 2) is there any fancy reindexing i could do to speed up queries? 3) what hardware + software (specifically, db + httpd) is b.m.o running? thanks, -jon - To view or change your list settings, click here: Bruce Armstrong [TeamSybase] --------------------------------- http://www.teamsybase.com Preach the gospel at all times. If necessary, use words. -- Francis of Assisi http://www.needhim.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at vmware.com Tue Jan 13 02:06:32 2004 From: jon at vmware.com (Jonathan Schatz) Date: Mon, 12 Jan 2004 18:06:32 -0800 Subject: mysql performance + bugzilla In-Reply-To: <20040113013618.99709.qmail@web12504.mail.yahoo.com> References: <20040113013618.99709.qmail@web12504.mail.yahoo.com> Message-ID: <1073959591.7043.4.camel@jonschatz-lx.vmware.com> On Mon, 2004-01-12 at 17:36 -0800, Bruce Armstrong [TeamSybase] wrote: > Try turning off the sendmailnow attribute. In my experience most of > the time there's a delay in the system it's not with Bugzilla updating > the MySQL database, it's with Bugzilla waiting for the SMTP server to > acknowledge the transmission of the emails. If you turn that > parameter off, the email generation is handled seperately from the bug > update. yeah, i've already done that. i should point out that i don't think bz is slow; my new manager does. i've poked around online some more and still haven't found any hard evidence regarding performance degredation with large tables. i just need something to return back to my boss to justify not changing anything... -jon -- Jonathan Schatz QA Engineer VMware, Inc "Te occidere possunt sed te edere non possunt nefas est." From myk at mozilla.org Tue Jan 13 07:29:59 2004 From: myk at mozilla.org (Myk Melez) Date: Mon, 12 Jan 2004 23:29:59 -0800 Subject: mysql performance + bugzilla In-Reply-To: <1073952079.2677.14.camel@jonschatz-lx.vmware.com> References: <1073952079.2677.14.camel@jonschatz-lx.vmware.com> Message-ID: <40039E77.8030301@mozilla.org> Jonathan Schatz wrote: >1) does mysql performance degrade linearly with the size of a table? > > Depends on the type of query. In general, queries doing full table scans should degrade linearly, while queries using indexes shouldn't degrade at all. >2) is there any fancy reindexing i could do to speed up queries? > > Yes, there's lots of fancy (and not so fancy) indexing you can do to speed up queries. Your first step is to figure out what's taking so long. It might not be the queries themselves but rather the CGI script instantiation or, as another respondent pointed out, bug mail sending. If it is the queries, the next step is to identify the queries that are taking too long. Add &debug=1 to buglist.cgi URLs to see the query being run, then run "EXPLAIN " in mysql to see what indexes MySQL thinks it should be using. If those indexes are insufficient, add some. If the appropriate indexes are there, but MySQL isn't using them, your database may be corrupt, or the query itself may be structured inefficiently. In general, there's no reason to thow away Bugzilla for poor DB performance. The database itself is fairly well designed, and almost all performance problems in it should be fixable bugs. >3) what hardware + software (specifically, db + httpd) is b.m.o running? > > The hardware is a Compaq PowerEdge 1750 with two 2.4Ghz Intel Xeon hyperthreaded processors, 4GB memory, and some 10K RPM Ultra320 SCSI hard drives in a RAID 10 mirrored/striped configuration. The software is MySQL 4.0.14 + Apache 1.3.27. We're running other things besides Bugzilla on that server. This thread really belongs in the newsgroup. cc:ing it. -myk From asmodai at wxs.nl Wed Jan 14 18:09:47 2004 From: asmodai at wxs.nl (Jeroen Ruigrok/asmodai) Date: Wed, 14 Jan 2004 19:09:47 +0100 Subject: Charset encoding of pages Message-ID: <20040114180947.GH6705@nexus.ninth-circle.org> Guys ('n gals), what's the latest status on the character set encoding issues? Right now I am fixing header.html.tmpl to just use English by using: [% title FILTER html %] It would be nice if I didn't have to fix this up. Seems like http://bugzilla.mozilla.org/show_bug.cgi?id=126266 is a neverending story when it comes to the issue. Sidecomment: 8859-1 is deprecated, use -15 please. Us Europeans like to be able to use the Euro. (yes, I'm back on Bugzilla, time to spare now :P) -- Jeroen Ruigrok van der Werven / asmodai / kita no mono PGP fingerprint: 2D92 980E 45FE 2C28 9DB7 9D88 97E6 839B 2EAC 625B http://www.tendra.org/ | http://diary.in-nomine.org/ Come make me pure, bleed me a cure, I'm caught, I'm caught, I'm caught under... From kiko at async.com.br Wed Jan 14 18:17:09 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Wed, 14 Jan 2004 16:17:09 -0200 Subject: Charset encoding of pages In-Reply-To: <20040114180947.GH6705@nexus.ninth-circle.org> References: <20040114180947.GH6705@nexus.ninth-circle.org> Message-ID: <20040114181709.GA2729@async.com.br> On Wed, Jan 14, 2004 at 07:09:47PM +0100, Jeroen Ruigrok/asmodai wrote: > It would be nice if I didn't have to fix this up. Seems like > http://bugzilla.mozilla.org/show_bug.cgi?id=126266 is a neverending > story when it comes to the issue. I'd ignore everything but comment #123 when looking at that bug -- it's a beacon of sanity amidst madness. I'll be happy to help review a patch and even nudge more reviewers to look at it if you can produce one. http://bugzilla.mozilla.org/show_bug.cgi?id=126266#c123 Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From asmodai at wxs.nl Wed Jan 14 18:49:29 2004 From: asmodai at wxs.nl (Jeroen Ruigrok/asmodai) Date: Wed, 14 Jan 2004 19:49:29 +0100 Subject: Charset encoding of pages In-Reply-To: <20040114181709.GA2729@async.com.br> References: <20040114180947.GH6705@nexus.ninth-circle.org> <20040114181709.GA2729@async.com.br> Message-ID: <20040114184929.GK6705@nexus.ninth-circle.org> -On [20040114 19:42], Christian Robottom Reis (kiko at async.com.br) wrote: >I'd ignore everything but comment #123 when looking at that bug -- it's >a beacon of sanity amidst madness. I'll be happy to help review a patch >and even nudge more reviewers to look at it if you can produce one. > > http://bugzilla.mozilla.org/show_bug.cgi?id=126266#c123 Mmm, OK, let's see if I can whip something up. Lots of code and patches in that report already, so shouldn't take too long (famous last words). -- Jeroen Ruigrok van der Werven / asmodai / kita no mono PGP fingerprint: 2D92 980E 45FE 2C28 9DB7 9D88 97E6 839B 2EAC 625B http://www.tendra.org/ | http://diary.in-nomine.org/ If you are not happy here and now, you never will be... From justdave at bugzilla.org Thu Jan 15 09:37:10 2004 From: justdave at bugzilla.org (David Miller) Date: Thu, 15 Jan 2004 04:37:10 -0500 Subject: 2.16.5/2.17.7 release prep Message-ID: We're planning a developer's release (2.17.7) for Monday, December 19. Anyone who has contributed anything new since 2.17.5 that hasn't yet been documented, let's please get some documentation contributed. :) (That's 4 days from now, for those that don't have their calendar handy). For those of you that are now helping with the docs, this weekend would be a REALLY good time to get some of the existing pending documentation bugs cleaned up and checked in. :) We also need to do a 2.16.5 release, which would be nice to do at the same time, but won't necessarily happen if the bugs aren't checked in by then. No security updates planned this time, but there are other bugs to fix. You can look for bugs with 2.16.5 on the status whiteboard (any bugs, not just open ones - status whiteboard also says whether it's fixed on the branch or not, so having the status whiteboard in your column list will help). Please help if you can. :) (there aren't many - I count 5 not counting docs) -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From justdave at bugzilla.org Thu Jan 15 09:47:21 2004 From: justdave at bugzilla.org (David Miller) Date: Thu, 15 Jan 2004 04:47:21 -0500 Subject: 2.16.5/2.17.7 release prep In-Reply-To: References: Message-ID: On 1/15/2004 4:37 AM -0500, David Miller wrote: > We're planning a developer's release (2.17.7) for Monday, December 19. Errr... *JANUARY* 19. ::Dave walks away mumbling something about copy/pasting off a bug:: -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From asmodai at wxs.nl Thu Jan 15 09:54:29 2004 From: asmodai at wxs.nl (Jeroen Ruigrok/asmodai) Date: Thu, 15 Jan 2004 10:54:29 +0100 Subject: 2.16.5/2.17.7 release prep In-Reply-To: References: Message-ID: <20040115095429.GI776@nexus.ninth-circle.org> -On [20040115 10:42], David Miller (justdave at bugzilla.org) wrote: >For those of you that are now helping with the docs, this weekend would be >a REALLY good time to get some of the existing pending documentation bugs >cleaned up and checked in. :) Is somebody already working on revamping the layout of the documentation? For people wanting to install a new installation of Bugzilla it is absolutely horrendous, unfortunately. If not, I'm willing to start work on this. -- Jeroen Ruigrok van der Werven / asmodai / kita no mono PGP fingerprint: 2D92 980E 45FE 2C28 9DB7 9D88 97E6 839B 2EAC 625B http://www.tendra.org/ | http://diary.in-nomine.org/ Don't try to find the Answer where there ain't no Question here... From justdave at bugzilla.org Thu Jan 15 09:58:32 2004 From: justdave at bugzilla.org (David Miller) Date: Thu, 15 Jan 2004 04:58:32 -0500 Subject: 2.16.5/2.17.7 release prep In-Reply-To: <20040115095429.GI776@nexus.ninth-circle.org> References: <20040115095429.GI776@nexus.ninth-circle.org> Message-ID: On 1/15/2004 10:54 AM +0100, Jeroen Ruigrok/asmodai wrote: > -On [20040115 10:42], David Miller (justdave at bugzilla.org) wrote: >>For those of you that are now helping with the docs, this weekend would be >>a REALLY good time to get some of the existing pending documentation bugs >>cleaned up and checked in. :) > > Is somebody already working on revamping the layout of the > documentation? > > For people wanting to install a new installation of Bugzilla it is > absolutely horrendous, unfortunately. > > If not, I'm willing to start work on this. Not that I know of. I would welcome anything that makes it easier to follow. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From gerv at mozilla.org Thu Jan 15 11:11:25 2004 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 15 Jan 2004 11:11:25 +0000 Subject: 2.16.5/2.17.7 release prep In-Reply-To: <20040115095429.GI776@nexus.ninth-circle.org> References: <20040115095429.GI776@nexus.ninth-circle.org> Message-ID: <4006755D.6000002@mozilla.org> Jeroen Ruigrok/asmodai wrote: > -On [20040115 10:42], David Miller (justdave at bugzilla.org) wrote: > >>For those of you that are now helping with the docs, this weekend would be >>a REALLY good time to get some of the existing pending documentation bugs >>cleaned up and checked in. :) > > Is somebody already working on revamping the layout of the > documentation? Yes. As it happens, on the train last night for an hour I scribbled on a printout of our current docs. I have a _load_ of markups to make. I will do them tonight, GMT, in between responding to review comments on the Component Watching and Component Default CC patch, which I hope to get checked in for this release, as b.m.o. needs it. (Dave: see my mail on the subject.) Please could people leave the docs alone until midnight GMT tonight, so I don't have to deal with merge conflicts? Thanks. Gerv From asmodai at wxs.nl Thu Jan 15 11:20:41 2004 From: asmodai at wxs.nl (Jeroen Ruigrok/asmodai) Date: Thu, 15 Jan 2004 12:20:41 +0100 Subject: 2.16.5/2.17.7 release prep In-Reply-To: <4006755D.6000002@mozilla.org> References: <20040115095429.GI776@nexus.ninth-circle.org> <4006755D.6000002@mozilla.org> Message-ID: <20040115112040.GK776@nexus.ninth-circle.org> -On [20040115 12:12], Gervase Markham (gerv at mozilla.org) wrote: >Yes. As it happens, on the train last night for an hour I scribbled on a >printout of our current docs. I have a _load_ of markups to make. I will >do them tonight, GMT, in between responding to review comments on the >Component Watching and Component Default CC patch, which I hope to get >checked in for this release, as b.m.o. needs it. OK cool. I'd be happy to do a review for you (I've done professional technical writing in the past). -- Jeroen Ruigrok van der Werven / asmodai / kita no mono PGP fingerprint: 2D92 980E 45FE 2C28 9DB7 9D88 97E6 839B 2EAC 625B http://www.tendra.org/ | http://diary.in-nomine.org/ Don't try to find the Answer where there ain't no Question here... From kiko at async.com.br Thu Jan 15 13:32:38 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Thu, 15 Jan 2004 11:32:38 -0200 Subject: 2.16.5/2.17.7 release prep In-Reply-To: <20040115095429.GI776@nexus.ninth-circle.org> References: <20040115095429.GI776@nexus.ninth-circle.org> Message-ID: <20040115133238.GB538@async.com.br> On Thu, Jan 15, 2004 at 10:54:29AM +0100, Jeroen Ruigrok/asmodai wrote: > Is somebody already working on revamping the layout of the > documentation? > > For people wanting to install a new installation of Bugzilla it is > absolutely horrendous, unfortunately. Have you had a look at the QUICKSTART file I contributed? Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From asmodai at wxs.nl Thu Jan 15 13:48:31 2004 From: asmodai at wxs.nl (Jeroen Ruigrok/asmodai) Date: Thu, 15 Jan 2004 14:48:31 +0100 Subject: 2.16.5/2.17.7 release prep In-Reply-To: <20040115133238.GB538@async.com.br> References: <20040115095429.GI776@nexus.ninth-circle.org> <20040115133238.GB538@async.com.br> Message-ID: <20040115134831.GO776@nexus.ninth-circle.org> -On [20040115 14:42], Christian Robottom Reis (kiko at async.com.br) wrote: >Have you had a look at the QUICKSTART file I contributed? Tp be honest: no. Didn't even notice it existed, since I was going by the information on the web. And that's also where I was directing my comments towards. Perhaps parts of the QUICKSTART can be incorporated into the documentation online. -- Jeroen Ruigrok van der Werven / asmodai / kita no mono PGP fingerprint: 2D92 980E 45FE 2C28 9DB7 9D88 97E6 839B 2EAC 625B http://www.tendra.org/ | http://diary.in-nomine.org/ Don't try to find the Answer where there ain't no Question here... From kiko at async.com.br Thu Jan 15 14:37:02 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Thu, 15 Jan 2004 12:37:02 -0200 Subject: 2.16.5/2.17.7 release prep In-Reply-To: References: Message-ID: <20040115143701.GF891@async.com.br> On Thu, Jan 15, 2004 at 04:37:10AM -0500, David Miller wrote: > We're planning a developer's release (2.17.7) for Monday, December 19. > Anyone who has contributed anything new since 2.17.5 that hasn't yet been > documented, let's please get some documentation contributed. :) (That's 4 > days from now, for those that don't have their calendar handy). Looking at the checkin list (handy link: http://tinderbox.mozilla.org/bonsai/cvsquery.cgi?treeid=default&module=Bugzilla&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=11%2F09%2F2003&maxdate=&cvsroot=%2Fcvsroot ) it seems that the important documentation additions would be: - Gerv's update to charting - Myk's extension hooks - My checkin of Joe Heenan's change that whines about REOPENED - [Perhaps] Bradley's configurable data/template dir > For those of you that are now helping with the docs, this weekend would be > a REALLY good time to get some of the existing pending documentation bugs > cleaned up and checked in. :) I've attached a patch with my bits -- Gerv, I'll let you apply it at your leisure as you're touching that today (which means I *won't* check it in and that it will be lost in limbo if you don't :-). (OK, Gerv?) > You can look for bugs with 2.16.5 on the status whiteboard (any bugs, not > just open ones - status whiteboard also says whether it's fixed on the > branch or not, so having the status whiteboard in your column list will > help). Please help if you can. :) (there aren't many - I count 5 not > counting docs) If somebody needs reviews, I may be able to fit some in today, so send them my way -- I'll cancel the requests if I couldn't. Index: faq.xml =================================================================== RCS file: /cvsroot/mozilla/webtools/bugzilla/docs/xml/faq.xml,v retrieving revision 1.21 diff -u -p -r1.21 faq.xml --- faq.xml 1 Nov 2003 09:51:41 -0000 1.21 +++ faq.xml 15 Jan 2004 14:36:23 -0000 @@ -714,8 +714,8 @@ perl -pi -e 's@#\!/usr/bin/perl@#\!/usr/ - I want whineatnews.pl to whine at something more, or other than, only new - bugs. How do I do it? + I want whineatnews.pl to whine at something more (or different) than + new and reopened bugs. How do I do it? Index: installation.xml =================================================================== RCS file: /cvsroot/mozilla/webtools/bugzilla/docs/xml/installation.xml,v retrieving revision 1.55 diff -u -p -r1.55 installation.xml --- installation.xml 30 Oct 2003 18:42:21 -0000 1.55 +++ installation.xml 15 Jan 2004 14:36:29 -0000 @@ -931,7 +931,7 @@ ReadLine support enabled By now you have a fully functional Bugzilla, but what good are bugs if they're not annoying? To help make those bugs more annoying you can set up Bugzilla's automatic whining system to complain at engineers - which leave their bugs in the NEW state without triaging them. + which leave their bugs in the NEW or REOPENED state without triaging them. This can be done by Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From asmodai at wxs.nl Thu Jan 15 16:33:48 2004 From: asmodai at wxs.nl (Jeroen Ruigrok/asmodai) Date: Thu, 15 Jan 2004 17:33:48 +0100 Subject: CVS or SVN integration with Bugzilla Message-ID: <20040115163348.GR776@nexus.ninth-circle.org> Has anybody done any work on this? I am most interested in SVN (Subversion), but I find CVS interesting as well. -- Jeroen Ruigrok van der Werven / asmodai / kita no mono PGP fingerprint: 2D92 980E 45FE 2C28 9DB7 9D88 97E6 839B 2EAC 625B http://www.tendra.org/ | http://diary.in-nomine.org/ Don't try to find the Answer where there ain't no Question here... From dswegen at software.plasmon.com Thu Jan 15 17:29:46 2004 From: dswegen at software.plasmon.com (Dave Swegen) Date: Thu, 15 Jan 2004 17:29:46 +0000 Subject: CVS or SVN integration with Bugzilla In-Reply-To: <20040115163348.GR776@nexus.ninth-circle.org> References: <20040115163348.GR776@nexus.ninth-circle.org> Message-ID: <20040115172946.GF26392@software.plasmon> On Thu, Jan 15, 2004 at 05:33:48PM +0100, Jeroen Ruigrok/asmodai wrote: > Has anybody done any work on this? > > I am most interested in SVN (Subversion), but I find CVS interesting as > well. Take a look at bug 199116 (http://bugzilla.mozilla.org/show_bug.cgi?id=199116). It provides the ability to append commit messages to one or more bugs, and optionally link the messages to a ViewCVS installation in various useful ways. Currently it only works with CVS, but since I'd be surprised if Subversion doesn't allow a script to handle commit messages it shouldn't be too hard too make it work with SVN too. Cheers Dave From kiko at async.com.br Thu Jan 15 17:31:46 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Thu, 15 Jan 2004 15:31:46 -0200 Subject: CVS or SVN integration with Bugzilla In-Reply-To: <20040115163348.GR776@nexus.ninth-circle.org> References: <20040115163348.GR776@nexus.ninth-circle.org> Message-ID: <20040115173146.GA1944@async.com.br> On Thu, Jan 15, 2004 at 05:33:48PM +0100, Jeroen Ruigrok/asmodai wrote: > I am most interested in SVN (Subversion), but I find CVS interesting as > well. For CVS, see Dave's work at http://bugzilla.mozilla.org/show_bug.cgi?id=199116 Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From john.fisher at znyx.com Thu Jan 15 19:20:07 2004 From: john.fisher at znyx.com (John P. Fisher) Date: Thu, 15 Jan 2004 11:20:07 -0800 Subject: Multiple bug reports for a single problem In-Reply-To: <20040115143701.GF891@async.com.br> References: Message-ID: <5.2.0.9.0.20040115110127.03e765d8@208.2.156.7> Apologies in advance if this was covered, and I just failed to find it.... Has there been discussion or solution of this issue? We have several branches of code in CVS. Frequently an issue arises that needs to be fixed on multiple branches, but can't all be done at the same time, because of dependencies or contractual issues. (At present we use an old, modified ver of Bugzilla based on 2.13.) Our workaround is to file multiple bug reports with similar summaries. While I think this workaround is theoretically adequate, though inelegant, it turns out it fails due to lack of discipline and enthusiasm. To put it differently, its a PITA so the developers don't do it. Further, it tends to fall between the duties of Test and Development. Ideal solution: Bug reports would have the concept of siblings - bugs not dependent yet similar. One would be able to say the same bug occurs in multiple versions ( and in our system, track that its fixed in multiple versions). One bug report would be linked to many underlying bugs with differing status. They could show up either way on reports. Thanks John John P. Fisher at ZNYX Networks 805 683 1488 x 3245 john.fisher at znyx.com From gerv at mozilla.org Thu Jan 15 19:53:57 2004 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 15 Jan 2004 19:53:57 +0000 Subject: Proper test installation? Message-ID: <4006EFD5.4090409@mozilla.org> I had an idea while doing the docs: How about another Bugzilla installation on Landfill: http://landfill.bugzilla.org/demo/ It would run the tip, but differ from bugzilla-tip/ in one key respect: there would be a clean database with a few sensible bugs in various states, a few accounts, products and components with sensible-looking default owners (but listed in "nomail"), a decent history of reporting data - i.e. a typical "small Bugzilla" - which it would reset to every weekend. So user accounts and bug changes would be removed. Additionally, unlike bugzilla-tip, it would have all features enabled. Then, we could reference this system in the documentation for demo and example, without fear that it'll have changed beyond recognition, or a documented feature won't be present. Is this worth having? Is it too much work? What do people think? Gerv From tree at basistech.com Thu Jan 15 20:04:49 2004 From: tree at basistech.com (Tom Emerson) Date: Thu, 15 Jan 2004 15:04:49 -0500 Subject: Multiple bug reports for a single problem In-Reply-To: <5.2.0.9.0.20040115110127.03e765d8@208.2.156.7> References: <5.2.0.9.0.20040115110127.03e765d8@208.2.156.7> Message-ID: <16390.62049.164721.402819@magrathea.basistech.com> John P. Fisher writes: > We have several branches of code in CVS. Frequently an issue arises that > needs to be fixed on multiple branches, but can't all be done at the same > time, because of dependencies or contractual issues. (At present we use an > old, modified ver of Bugzilla based on 2.13.) Our workaround is to file > multiple bug reports with similar summaries. > While I think this workaround is theoretically adequate, though inelegant, > it turns out it fails due to lack of discipline and enthusiasm. To put it > differently, its a PITA so the developers don't do it. Further, it tends to > fall between the duties of Test and Development. We have had a similar issue here: multiple products or components sharing a similar bug. The way I "solved" it was to create a project called "Meta", into which the "master" bug is filed. Then separate bugs are filed against each project and set to block the master meta bug. To make this easier to stomach for people, I wrote a command-line script that would handle distributing the 'meta' bug to the other components and setting up the appropriate dependencies. Hence they just had to create the meta bug, then run the script specifying which components should be dependent on it. This could have been added to our Bugzilla installation, but I've tried to avoid making local customisations as much as possible. > Bug reports would have the concept of siblings - bugs not dependent yet > similar. This is almost something else: I've often though it would be useful to have another category of bug relationship that isn't hierarchical but more of a "see also". -- Tom Emerson Basis Technology Corp. Software Architect http://www.basistech.com "Beware the lollipop of mediocrity: lick it once and you suck forever" From kiko at async.com.br Thu Jan 15 20:12:58 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Thu, 15 Jan 2004 18:12:58 -0200 Subject: Multiple bug reports for a single problem In-Reply-To: <16390.62049.164721.402819@magrathea.basistech.com> References: <5.2.0.9.0.20040115110127.03e765d8@208.2.156.7> <16390.62049.164721.402819@magrathea.basistech.com> Message-ID: <20040115201258.GD2916@async.com.br> On Thu, Jan 15, 2004 at 03:04:49PM -0500, Tom Emerson wrote: > > Bug reports would have the concept of siblings - bugs not dependent yet > > similar. > > This is almost something else: I've often though it would be useful to > have another category of bug relationship that isn't hierarchical but > more of a "see also". See the venerable bug 12287: "Related bugs" feature. http://bugzilla.mozilla.org/show_bug.cgi?id=12286 Note that there is no patch [yet] attached; help *wanted*! Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From john.fisher at znyx.com Thu Jan 15 21:45:29 2004 From: john.fisher at znyx.com (John P. Fisher) Date: Thu, 15 Jan 2004 13:45:29 -0800 Subject: Multiple bug reports for a single problem In-Reply-To: <20040115201258.GD2916@async.com.br> References: <16390.62049.164721.402819@magrathea.basistech.com> <5.2.0.9.0.20040115110127.03e765d8@208.2.156.7> <16390.62049.164721.402819@magrathea.basistech.com> Message-ID: <5.2.0.9.0.20040115133748.029bad48@208.2.156.7> Thanks, thats it ( 12286 ) The first and maybe best help I can provide is to add my functionality requirements as a suggestion to the bug comments. After I bring my own Bugzilla up to date, I may *have* to develop a solution for this problem. thanks John >See the venerable bug 12287: "Related bugs" feature. > > http://bugzilla.mozilla.org/show_bug.cgi?id=12286 > >Note that there is no patch [yet] attached; help *wanted*! > >Take care, >-- >Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 >- >To view or change your list settings, click here: > John P. Fisher at ZNYX Networks 805 683 1488 x 3245 john.fisher at znyx.com From akalaveshi at rsasecurity.com Thu Jan 15 21:49:12 2004 From: akalaveshi at rsasecurity.com (Kalaveshi, Adrian) Date: Thu, 15 Jan 2004 16:49:12 -0500 Subject: Multiple bug reports for a single problem Message-ID: <8E883DEEED068E479A8900161D80DB1C856AEB@exsf01.na.rsa.net> In addition to loosely tying them together, it may be beneficial to offer an easy way to offer an easy way to create these orthogonal bugs. Here we've implemented a "Branch bug to version " action that creates an identical bug with a new version. > -----Original Message----- > From: John P. Fisher [mailto:john.fisher at znyx.com] > Sent: Thursday, January 15, 2004 1:45 PM > To: developers at bugzilla.org > Subject: Re: Multiple bug reports for a single problem > > > Thanks, thats it ( 12286 ) > The first and maybe best help I can provide is to add my > functionality > requirements as a suggestion to the bug comments. After I > bring my own > Bugzilla up to date, I may *have* to develop a solution for > this problem. > > thanks > John > > > > > >See the venerable bug 12287: "Related bugs" feature. > > > > http://bugzilla.mozilla.org/show_bug.cgi?id=12286 > > > >Note that there is no patch [yet] attached; help *wanted*! > > > >Take care, > >-- > >Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 > 16] 261 2331 > >- > >To view or change your list settings, click here: > > > > John P. Fisher > at ZNYX Networks > 805 683 1488 x 3245 > john.fisher at znyx.com > > - > To view or change your list settings, click here: > From tree at basistech.com Thu Jan 15 21:55:27 2004 From: tree at basistech.com (Tom Emerson) Date: Thu, 15 Jan 2004 16:55:27 -0500 Subject: Multiple bug reports for a single problem In-Reply-To: <5.2.0.9.0.20040115133748.029bad48@208.2.156.7> References: <16390.62049.164721.402819@magrathea.basistech.com> <5.2.0.9.0.20040115110127.03e765d8@208.2.156.7> <5.2.0.9.0.20040115133748.029bad48@208.2.156.7> Message-ID: <16391.3151.620345.963563@magrathea.basistech.com> John P. Fisher writes: > Thanks, thats it ( 12286 ) > The first and maybe best help I can provide is to add my functionality > requirements as a suggestion to the bug comments. Yes, that would be really useful. Since this is an itch of mine, and I have some cycles, I think I may work on a fix to 12286. -tree -- Tom Emerson Basis Technology Corp. Software Architect http://www.basistech.com "Beware the lollipop of mediocrity: lick it once and you suck forever" From john.fisher at znyx.com Thu Jan 15 23:22:35 2004 From: john.fisher at znyx.com (John P. Fisher) Date: Thu, 15 Jan 2004 15:22:35 -0800 Subject: Multiple bug reports for a single problem In-Reply-To: <16391.3151.620345.963563@magrathea.basistech.com> References: <5.2.0.9.0.20040115133748.029bad48@208.2.156.7> <16390.62049.164721.402819@magrathea.basistech.com> <5.2.0.9.0.20040115110127.03e765d8@208.2.156.7> <5.2.0.9.0.20040115133748.029bad48@208.2.156.7> Message-ID: <5.2.0.9.0.20040115151809.0454fe98@208.2.156.7> Tom: At 04:55 PM 1/15/2004 -0500, you wrote: > > add my functionality > > requirements as a suggestion to the bug comments. > >Yes, that would be really useful. Since this is an itch of mine, and I >have some cycles, I think I may work on a fix to 12286. ok done If it helps any I *think* an extra field in the bugs table with associated bug_ids would be enough db change. Then a list box for show_bug that includes hrefs to the associated bugs Then something in queries and reports.... feel free to email me and discuss. John > -tree > >-- >Tom Emerson Basis Technology Corp. John P. Fisher at ZNYX Networks 805 683 1488 x 3245 john.fisher at znyx.com From tree at basistech.com Thu Jan 15 23:29:41 2004 From: tree at basistech.com (Tom Emerson) Date: Thu, 15 Jan 2004 18:29:41 -0500 Subject: Multiple bug reports for a single problem In-Reply-To: <5.2.0.9.0.20040115151809.0454fe98@208.2.156.7> References: <5.2.0.9.0.20040115133748.029bad48@208.2.156.7> <16390.62049.164721.402819@magrathea.basistech.com> <5.2.0.9.0.20040115110127.03e765d8@208.2.156.7> <5.2.0.9.0.20040115151809.0454fe98@208.2.156.7> Message-ID: <16391.8805.213716.221286@magrathea.basistech.com> John P. Fisher writes: > If it helps any I *think* an extra field in the bugs table with associated > bug_ids would be enough db change. On the surface I agree: however I want to go through all the comments on 12286 and see what will be needed to address the suggestions there. -tree -- Tom Emerson Basis Technology Corp. Software Architect http://www.basistech.com "Beware the lollipop of mediocrity: lick it once and you suck forever" From gerv at mozilla.org Fri Jan 16 00:05:48 2004 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 16 Jan 2004 00:05:48 +0000 Subject: Docs status Message-ID: <40072ADC.5060406@mozilla.org> Phew :-) I've spanked them good and proper, in an effort to reduce verbiage and increase clarity and correctness. Most of what's there is in pretty good shape, with the exception of the gargantuan Install section, which I've done some work on but isn't finished. Please feel free to hack on it a bit more yourselves. The other thing that's missing is documentation for new stuff, including but not limited to: - Request Tracker - Wildcard matching - Time tracking - Autolinkification page - End-user documentation for the new reporting and charting - Full text search - Insiders - JS-powered comment reply - Alternative formats of various templates, e.g. CSV, JS, RDF - requirelogin - Various cool customisation features: - Term customisation - Hooks I don't expect to get this for 2.17.7, but we need it for 2.18. Gerv From kiko at async.com.br Fri Jan 16 00:10:04 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Thu, 15 Jan 2004 22:10:04 -0200 Subject: Docs status In-Reply-To: <40072ADC.5060406@mozilla.org> References: <40072ADC.5060406@mozilla.org> Message-ID: <20040116001004.GG3910@async.com.br> On Fri, Jan 16, 2004 at 12:05:48AM +0000, Gervase Markham wrote: > I've spanked them good and proper, in an effort to reduce verbiage and > increase clarity and correctness. Most of what's there is in pretty good > shape, with the exception of the gargantuan Install section, which I've > done some work on but isn't finished. Please feel free to hack on it a > bit more yourselves. You ignored my patch! :-P I'll just go ahead and apply it, I guess. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From jpyeron at pyerotechnics.com Fri Jan 16 00:58:25 2004 From: jpyeron at pyerotechnics.com (Jason Pyeron) Date: Thu, 15 Jan 2004 19:58:25 -0500 (EST) Subject: Proper test installation? In-Reply-To: <4006EFD5.4090409@mozilla.org> Message-ID: yes that would be a spectacular idea. The one problem we have always encountered was a prospective user wants to look at a product but, it configuration has gone all phooey to quickly. There should be a "schedule a reset" option or "schedule an admin login time" feature. It would be a extremely simple add on. On Thu, 15 Jan 2004, Gervase Markham wrote: > I had an idea while doing the docs: > > How about another Bugzilla installation on Landfill: > http://landfill.bugzilla.org/demo/ > > It would run the tip, but differ from bugzilla-tip/ in one key respect: > there would be a clean database with a few sensible bugs in various > states, a few accounts, products and components with sensible-looking > default owners (but listed in "nomail"), a decent history of reporting > data - i.e. a typical "small Bugzilla" - which it would reset to every > weekend. So user accounts and bug changes would be removed. > > Additionally, unlike bugzilla-tip, it would have all features enabled. > > Then, we could reference this system in the documentation for demo and > example, without fear that it'll have changed beyond recognition, or a > documented feature won't be present. > > Is this worth having? Is it too much work? What do people think? > > Gerv > - > To view or change your list settings, click here: > > -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron http://www.pyerotechnics.com - - Partner & Sr. Manager Pyerotechnics Development, Inc. - - +1 (443) 451-2697 500 West University Parkway #1S - - +1 (410) 808-6646 (c) Baltimore, Maryland 21210-3253 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, purge the message from your system and notify the sender immediately. Any other use of the email by you is prohibited. From bbaetz at acm.org Fri Jan 16 05:20:56 2004 From: bbaetz at acm.org (Bradley Baetz) Date: Fri, 16 Jan 2004 16:20:56 +1100 Subject: Docs status Message-ID: <200401160520.i0G5Ku710113@mail017.syd.optusnet.com.au> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From andreas.hoefler at bearingpoint.com Fri Jan 16 05:34:40 2004 From: andreas.hoefler at bearingpoint.com (=?ISO-8859-1?Q?Andreas_H=F6fler?=) Date: Fri, 16 Jan 2004 06:34:40 +0100 Subject: Proper test installation? In-Reply-To: <4006EFD5.4090409@mozilla.org> References: <4006EFD5.4090409@mozilla.org> Message-ID: <400777F0.8020601@bearingpoint.com> An HTML attachment was scrubbed... URL: From bbaetz at acm.org Fri Jan 16 05:36:16 2004 From: bbaetz at acm.org (Bradley Baetz) Date: Fri, 16 Jan 2004 16:36:16 +1100 Subject: MySQL improvements Message-ID: <200401160536.i0G5aGw23966@mail016.syd.optusnet.com.au> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From bbaetz at acm.org Fri Jan 16 05:37:48 2004 From: bbaetz at acm.org (Bradley Baetz) Date: Fri, 16 Jan 2004 16:37:48 +1100 Subject: MySQL improvements Message-ID: <200401160537.i0G5bml01007@mail010.syd.optusnet.com.au> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From asmodai at wxs.nl Fri Jan 16 05:48:46 2004 From: asmodai at wxs.nl (Jeroen Ruigrok/asmodai) Date: Fri, 16 Jan 2004 06:48:46 +0100 Subject: MySQL improvements In-Reply-To: <200401160537.i0G5bml01007@mail010.syd.optusnet.com.au> References: <200401160537.i0G5bml01007@mail010.syd.optusnet.com.au> Message-ID: <20040116054846.GZ776@nexus.ninth-circle.org> -On [20040116 06:42], Bradley Baetz (bbaetz at acm.org) wrote: >Oh, and I should have mentioned - it starts >in an hour, so be quick :) I often found that updating the bug was slow in returning. Might be the email sending, but I am sure that option is set off on the main bugzilla.org configuration. -- Jeroen Ruigrok van der Werven / asmodai / kita no mono PGP fingerprint: 2D92 980E 45FE 2C28 9DB7 9D88 97E6 839B 2EAC 625B http://www.tendra.org/ | http://diary.in-nomine.org/ Don't try to find the Answer where there ain't no Question here... From gerv at mozilla.org Fri Jan 16 08:05:02 2004 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 16 Jan 2004 08:05:02 +0000 Subject: Docs status In-Reply-To: <20040116001004.GG3910@async.com.br> References: <40072ADC.5060406@mozilla.org> <20040116001004.GG3910@async.com.br> Message-ID: <40079B2E.60406@mozilla.org> Christian Robottom Reis wrote: > On Fri, Jan 16, 2004 at 12:05:48AM +0000, Gervase Markham wrote: > >>I've spanked them good and proper, in an effort to reduce verbiage and >>increase clarity and correctness. Most of what's there is in pretty good >>shape, with the exception of the gargantuan Install section, which I've >>done some work on but isn't finished. Please feel free to hack on it a >>bit more yourselves. > > You ignored my patch! :-P I'll just go ahead and apply it, I guess. No... I altered one half, and removed the code the other half related to. I think. Gerv From mattyt-spam at tpg.com.au Fri Jan 16 11:53:36 2004 From: mattyt-spam at tpg.com.au (MattyT) Date: Fri, 16 Jan 2004 22:23:36 +1030 Subject: Docs status In-Reply-To: <200401160520.i0G5Ku710113@mail017.syd.optusnet.com.au> References: <200401160520.i0G5Ku710113@mail017.syd.optusnet.com.au> Message-ID: <1074254015.19481.5.camel@megagerbil> On Fri, 2004-01-16 at 15:50, Bradley Baetz wrote: > Mattyt nagged me about these (and even gave > me a printed out copy to edit while at LCA....) I think this thread is about the Bugzilla Guide, not the Developers' Guide. -- Matthew Tuck: Software Developer & All-Round Nice Guy My Short Autobiography: 1985 Grade Bin Monitor 1990 Class Clown Award 1992 Awarded Most Likely To Spontaneously Combust 1996 Crowned Galactic Emperor 1998 Released From Smith Psychiatric Hospital From kiko at async.com.br Fri Jan 16 12:06:08 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Fri, 16 Jan 2004 10:06:08 -0200 Subject: Doc updates, Approval queue In-Reply-To: <4006EFD5.4090409@mozilla.org> References: <4006EFD5.4090409@mozilla.org> Message-ID: <20040116120608.GB6727@async.com.br> I comitted updates to faq.xml and installation.xml, which would require rebuilding the docs -- just a reminder to whoever does the final doc whack. Also, can "somebody" take a look at my approval requests? http://bugzilla.mozilla.org/show_bug.cgi?id=228894 http://bugzilla.mozilla.org/show_bug.cgi?id=90468 http://bugzilla.mozilla.org/show_bug.cgi?id=229998 Thanks! Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From cbendell at point2.com Fri Jan 16 13:56:04 2004 From: cbendell at point2.com (Colin Bendell) Date: Fri, 16 Jan 2004 07:56:04 -0600 Subject: MySQL improvements Message-ID: I know this will miss your presentation, but I wonder if the latest version of MySQL can do scheduled tasks and emailing? Most popular db's can do both. It would be a nice feature to move the emailing to the realm of the DB instead of the internal bugzilla system have to interface to sendmail or some such configuration. This way bugzilla could be agnostic about emailing, while the sys admin simply configures the db appropriately. Anyway, that was just a thought off the top of my head. /colin -----Original Message----- From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] On Behalf Of Jeroen Ruigrok/asmodai Sent: Thursday, January 15, 2004 11:49 PM To: Bradley Baetz Cc: developers @ bugzilla . org Subject: Re: MySQL improvements -On [20040116 06:42], Bradley Baetz (bbaetz at acm.org) wrote: >Oh, and I should have mentioned - it starts >in an hour, so be quick :) I often found that updating the bug was slow in returning. Might be the email sending, but I am sure that option is set off on the main bugzilla.org configuration. -- Jeroen Ruigrok van der Werven / asmodai / kita no mono PGP fingerprint: 2D92 980E 45FE 2C28 9DB7 9D88 97E6 839B 2EAC 625B http://www.tendra.org/ | http://diary.in-nomine.org/ Don't try to find the Answer where there ain't no Question here... - To view or change your list settings, click here: From louie at ximian.com Fri Jan 16 15:56:19 2004 From: louie at ximian.com (Luis Villa) Date: Fri, 16 Jan 2004 10:56:19 -0500 Subject: 2.17? Message-ID: <1074268579.14566.97.camel@localhost.localdomain> Hey, guys- Looks like a couple of bugzilla 'core' folks were looking for me and aes last night to discuss b.g.o moving to 2.17 instead of 2.16. And of course we totally missed each other, since I was on the plane and I suppose aes was still recovering from exams. :) What's the situation? Greg mentioned specific features you think will help us upgrade... I'd been listening for such things but had missed them :) What specific things did you have in mind? I personally would definitely love lots of the stuff that is in 2.17, but I think aes had thought (and I agreed, since I'm not doing the work, he is) that the delta was big enough that we'd have to throw out most of our current work to do it. Anyway, if you guys want me involved, email might be better for this conversation, since I'll be basically in IRC today and then not again until next Monday, the 26th. Luis From myk at mozilla.org Fri Jan 16 16:54:12 2004 From: myk at mozilla.org (Myk Melez) Date: Fri, 16 Jan 2004 08:54:12 -0800 Subject: Doc updates, Approval queue In-Reply-To: <20040116120608.GB6727@async.com.br> References: <4006EFD5.4090409@mozilla.org> <20040116120608.GB6727@async.com.br> Message-ID: <40081734.50404@mozilla.org> Christian Robottom Reis wrote: >I comitted updates to faq.xml and installation.xml, which would require >rebuilding the docs -- just a reminder to whoever does the final doc >whack. > >Also, can "somebody" take a look at my approval requests? > > http://bugzilla.mozilla.org/show_bug.cgi?id=228894 > http://bugzilla.mozilla.org/show_bug.cgi?id=90468 > http://bugzilla.mozilla.org/show_bug.cgi?id=229998 > > Latter two done. I defer to Dave on the first one per comments about him seeming to support the change and you wanting to let him "confirm" it. -myk From aes at gnome.org Fri Jan 16 17:07:20 2004 From: aes at gnome.org (Andrew Sobala) Date: Fri, 16 Jan 2004 17:07:20 +0000 Subject: 2.17? In-Reply-To: <1074268579.14566.97.camel@localhost.localdomain> References: <1074268579.14566.97.camel@localhost.localdomain> Message-ID: <1074272840.7854.4.camel@gondor.localdomain> On Fri, 2004-01-16 at 15:56, Luis Villa wrote: > Hey, guys- > > Looks like a couple of bugzilla 'core' folks were looking for me and aes > last night to discuss b.g.o moving to 2.17 instead of 2.16. And of > course we totally missed each other, since I was on the plane and I > suppose aes was still recovering from exams. :) > > What's the situation? Greg mentioned specific features you think will > help us upgrade... I'd been listening for such things but had missed > them :) What specific things did you have in mind? I personally would > definitely love lots of the stuff that is in 2.17, but I think aes had > thought (and I agreed, since I'm not doing the work, he is) that the > delta was big enough that we'd have to throw out most of our current > work to do it. > Hey :-), If upgrading to 2.17 is quite painless, I'd be happy to do it. The thing is, to upgrade to 2.16, all we need to do is minor templatisation. That's _it_. I was going to do the final template stuff over the weekend, and I tested importing our database into the 2.16 system a couple of weeks ago, and it worked. My personal opinion is we should go for 2.16, then maybe look immediately at what we'd need to change for 2.17 since I presume that will be released as a stable 2.18 soon-ish. I might be making that up. However, I'd really like to hear what the bugzilla people have to say. Thanks, -- Andrew Sobala -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From aes at gnome.org Fri Jan 16 17:23:57 2004 From: aes at gnome.org (Andrew Sobala) Date: Fri, 16 Jan 2004 17:23:57 +0000 Subject: 2.17? In-Reply-To: <1074272840.7854.4.camel@gondor.localdomain> References: <1074268579.14566.97.camel@localhost.localdomain> <1074272840.7854.4.camel@gondor.localdomain> Message-ID: <1074273837.7854.6.camel@gondor.localdomain> On Fri, 2004-01-16 at 17:07, Andrew Sobala wrote: > all we need to do is minor templatisation. "and testing the mail hack", it appears from my TODO. But I am quite confident about it. -- Andrew Sobala -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From justdave at bugzilla.org Fri Jan 16 17:59:44 2004 From: justdave at bugzilla.org (David Miller) Date: Fri, 16 Jan 2004 12:59:44 -0500 Subject: MySQL improvements In-Reply-To: <20040116054846.GZ776@nexus.ninth-circle.org> References: <200401160537.i0G5bml01007@mail010.syd.optusnet.com.au> <20040116054846.GZ776@nexus.ninth-circle.org> Message-ID: On 1/16/2004 6:48 AM +0100, Jeroen Ruigrok/asmodai wrote: > -On [20040116 06:42], Bradley Baetz (bbaetz at acm.org) wrote: >>Oh, and I should have mentioned - it starts >>in an hour, so be quick :) > > I often found that updating the bug was slow in returning. Might be the > email sending, but I am sure that option is set off on the main > bugzilla.org configuration. Also involved in that timing is the cost of spawning off a new Perl interpreter for each email sent. 2.17.3ish introduced a perl module to handle the mailing (replacing the processmail script), which runs in the same process with the web CGI instead of spawning a new Perl interpreter, and it's a quite dramatic speed improvement. Note that bugzilla.mozilla.org is (until next weekend) still running 2.17.1. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From justdave at bugzilla.org Fri Jan 16 23:28:01 2004 From: justdave at bugzilla.org (David Miller) Date: Fri, 16 Jan 2004 18:28:01 -0500 Subject: CVS commit messages Message-ID: There's been several violations of this lately, so I figure this is a good time to remind everyone what a good CVS commit log message looks like. Please do NOT just copy/paste the summary of the bug you're fixing into the cvs comment, unless that summary happens to be clear and concise. People use the cvs checkin messages to determine what changes have been made to Bugzilla (there's a cvs-commit mailing list which those get mailed to, aside from viewing the list on Bonsai), and we also use it to generate the change log that's put in the status updates that we do from time to time. Many of our bug summaries describe a problem. Many times the bugs fix more than just that problem. Most of the bug summaries don't describe what to do to fix the problem. A checkin comment should contain a *short* description of what the patch does. NOT the summary of the bug, unless that bug summary happens to describe that adequately. Bad example: (sorry for singling this one out, it's not the only offender lately, but it's an example of this) -------- Fix for bug 90468: Bugzilla does not log out automatically when closing the session. Patch by toms at myrealbox.com (Toms Baugis), with minor cleanups by me. r=kiko, a=myk. -------- Why it's bad: this seems to imply that the checkin will cause Bugzilla to only keep logins around for a session. Period. This scares me, and will scare lots of other people because they like having permanent (or long duration) logins. Looking at the patch, this is, in fact, not what it does. This would have been better written as: -------- Bug 90468: Add a parameter 'rememberlogin', which allows the admin to choose whether the login cookie will be permanent, expire when the session is closed, or to let the user choose on the login screen. Patch by toms at myrealbox.com (Toms Baugis), with minor cleanups by me. r=kiko, a=myk -------- -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From mattyt-spam at tpg.com.au Sun Jan 18 10:45:58 2004 From: mattyt-spam at tpg.com.au (MattyT) Date: Sun, 18 Jan 2004 21:15:58 +1030 Subject: 2.17? In-Reply-To: <1074268579.14566.97.camel@localhost.localdomain> References: <1074268579.14566.97.camel@localhost.localdomain> Message-ID: <1074422756.9069.3.camel@megagerbil> On Sat, 2004-01-17 at 02:26, Luis Villa wrote: > What's the situation? Greg mentioned specific features you think will > help us upgrade... I'd been listening for such things but had missed > them :) The primary one I had identified was generic reports, which probably render at least some of your specific reports obsolete. I saw at least one report that was a 2D bug count table, which as I understand it, is bread and butter for generic reports. There was also one, that was a differential 2D bug count table, that I don't believe we support (although I could be wrong). Greg was saying some of them were getting rewritten, and I said it would be less work if you went to 2.17, since at least some are probably just a matter of constructing a suitable URL. -- Matthew Tuck: Software Developer & All-Round Nice Guy My Short Autobiography: 1985 Grade Bin Monitor 1990 Class Clown Award 1992 Awarded Most Likely To Spontaneously Combust 1996 Crowned Galactic Emperor 1998 Released From Smith Psychiatric Hospital From mattyt-spam at tpg.com.au Sun Jan 18 12:22:14 2004 From: mattyt-spam at tpg.com.au (MattyT) Date: Sun, 18 Jan 2004 22:52:14 +1030 Subject: Too Many Bugs Message-ID: <1074428533.9093.38.camel@megagerbil> A quick scan of the Bugzilla product shows we have 868 open bug reports. There's a chart here of our reports: http://bugzilla.mozilla.org/reports.cgi?product=Bugzilla&datasets=NEW%3A&datasets=ASSIGNED%3A&datasets=REOPENED%3A&datasets=UNCONFIRMED%3A This is RFEs too, but I'd expect them to only increase in proportion to bugs slowly (it's a bit less than 50% RFEs ATM), so this chart assumedly shows a dramatic increase in bugs. While one would expect more bugs from more features, it is still way too high. And no, being able to track so many bugs does not make it a good advertisement for us. So anything you could do to help this situation would be good. If one day we could institute a no-known-bugs policy for releases because of this, well that would be even better. There are lots of options here to help the situation: - fix bugs - find bug reports that are really RFEs and change their severity - find bugs that have been fixed in the mean time and mark them as such (please, not as WORKSFORME if there's any evidence they were confirmed) - find dupes and mark them as such - find bugs that are still active and pester people that when you insert a feature, bug fixing is a responsibility, not a optional extra Any of the above would be mucho cool, and hopefully I'll be doing some of this in the near future myself. With any luck, the architectural work that has gone into 2.16 and 2.18 will stand us in good stead to reduce this more easily, rather than just increasing it in the short term as new code is introduced. Does anyone have any ideas about how we can arrest the upward trend and hopefully reverse it? It would be good if we can get a chart of bugs and no RFES, once bmo upgrades to customised charting. Another possibility is requiring every release to have 100 (or so) less bugs than the one before and just before release leaving the tree closed to features until it does. I can predict the response to this, but something needs to be done. If you've got any better ideas, let's hear them. -- Matthew Tuck: Software Developer & All-Round Nice Guy My Short Autobiography: 1985 Grade Bin Monitor 1990 Class Clown Award 1992 Awarded Most Likely To Spontaneously Combust 1996 Crowned Galactic Emperor 1998 Released From Smith Psychiatric Hospital From bbaetz at acm.org Sun Jan 18 13:00:34 2004 From: bbaetz at acm.org (Bradley Baetz) Date: Mon, 19 Jan 2004 00:00:34 +1100 Subject: MySQL improvements In-Reply-To: References: Message-ID: <20040118130034.GA3014@mango.home> They claimed triggers would probably be 5.1, IIRC (I haven't unpacked my notes yet0 I wouldn't use those, though - I'd write main into a table, and havea daemon scan that table and send mail from that. Which is effectively what Oracle does, but asynchronously, rather than synchronously. You could get sync behaviour quite nicely using NOTIFY under postgres, but thats not portable Bradley From asmodai at wxs.nl Sun Jan 18 15:47:56 2004 From: asmodai at wxs.nl (Jeroen Ruigrok/asmodai) Date: Sun, 18 Jan 2004 16:47:56 +0100 Subject: Too Many Bugs In-Reply-To: <1074428533.9093.38.camel@megagerbil> References: <1074428533.9093.38.camel@megagerbil> Message-ID: <20040118154756.GD72437@nexus.ninth-circle.org> -On [20040118 13:22], MattyT (mattyt-spam at tpg.com.au) wrote: >Does anyone have any ideas about how we can arrest the upward trend and >hopefully reverse it? Put our code where our mouth is. One problem I see with most bugs is that there's too much debate and not enough implementation. Some discussions are from 2001 or 2002 and still going on! Also some bugs tend to drift off into other nice-to-have categories, which means a certain bug report will never be closed. I intend to go scourging the bugs in the coming periods, since I finally got more time again. -- Jeroen Ruigrok van der Werven / asmodai / kita no mono PGP fingerprint: 2D92 980E 45FE 2C28 9DB7 9D88 97E6 839B 2EAC 625B http://www.tendra.org/ | http://diary.in-nomine.org/ Don't try to find the Answer where there ain't no Question here... From gerv at mozilla.org Sun Jan 18 16:10:51 2004 From: gerv at mozilla.org (Gervase Markham) Date: Sun, 18 Jan 2004 16:10:51 +0000 Subject: Too Many Bugs In-Reply-To: <20040118154756.GD72437@nexus.ninth-circle.org> References: <1074428533.9093.38.camel@megagerbil> <20040118154756.GD72437@nexus.ninth-circle.org> Message-ID: <400AB00B.5050803@mozilla.org> Jeroen Ruigrok/asmodai wrote: > Put our code where our mouth is. > > One problem I see with most bugs is that there's too much debate and not > enough implementation. Some discussions are from 2001 or 2002 and > still going on! Just because a bug is filed doesn't necessarily mean that a patch will result - for example, it could be an RFE for what, after discussion, turns out to be a bad idea. But I agree that two-year discussions aren't very productive. What we actually need is strong ownership of components - so the module owner will decide "no, we're definitely not going to do this", and close the bug as WONTFIX, or decide "yes, we would like to do this", and say so on the bug - at which point anyone who wishes can start coding. I suggest, though, that before everyone goes off in a triaging frenzy, we wait until the upcoming releases are out the door, b.m.o. is upgraded, the regressions are crushed, b.m.o. does its CVS update, and is back on an even keel again. I expect that to take a couple of weeks. Gerv From asmodai at wxs.nl Sun Jan 18 16:21:10 2004 From: asmodai at wxs.nl (Jeroen Ruigrok/asmodai) Date: Sun, 18 Jan 2004 17:21:10 +0100 Subject: Too Many Bugs In-Reply-To: <400AB00B.5050803@mozilla.org> References: <1074428533.9093.38.camel@megagerbil> <20040118154756.GD72437@nexus.ninth-circle.org> <400AB00B.5050803@mozilla.org> Message-ID: <20040118162110.GE72437@nexus.ninth-circle.org> -On [20040118 17:12], Gervase Markham (gerv at mozilla.org) wrote: >Just because a bug is filed doesn't necessarily mean that a patch will >result - for example, it could be an RFE for what, after discussion, >turns out to be a bad idea. But I agree that two-year discussions aren't >very productive. OK, what I might have generalised was meant (implicitly) to mean: resolve the reports in question. >What we actually need is strong ownership of components - so the module >owner will decide "no, we're definitely not going to do this", and close >the bug as WONTFIX, or decide "yes, we would like to do this", and say >so on the bug - at which point anyone who wishes can start coding. Yes, this was also what I meant. Apologies for not being so clear first time around. -- Jeroen Ruigrok van der Werven / asmodai / kita no mono PGP fingerprint: 2D92 980E 45FE 2C28 9DB7 9D88 97E6 839B 2EAC 625B http://www.tendra.org/ | http://diary.in-nomine.org/ Don't try to find the Answer where there ain't no Question here... From gerv at mozilla.org Sun Jan 18 22:39:59 2004 From: gerv at mozilla.org (Gervase Markham) Date: Sun, 18 Jan 2004 22:39:59 +0000 Subject: Too Many Bugs In-Reply-To: <1074428533.9093.38.camel@megagerbil> References: <1074428533.9093.38.camel@megagerbil> Message-ID: <400B0B3F.5000302@mozilla.org> A few points relating to the original post: MattyT wrote: > There's a chart here of our reports: > > http://bugzilla.mozilla.org/reports.cgi?product=Bugzilla&datasets=NEW%3A&datasets=ASSIGNED%3A&datasets=REOPENED%3A&datasets=UNCONFIRMED%3A Hopefully new charts will make analysis of this sort of thing easier in future :-) > This is RFEs too, but I'd expect them to only increase in proportion to > bugs slowly (it's a bit less than 50% RFEs ATM), so this chart assumedly > shows a dramatic increase in bugs. Not that dramatic. The number of NEW bugs has doubled in about two years (Aug 01 -> Aug 03). And it's a flatter line now than it was. > While one would expect more bugs from more features, it is still way too > high. And no, being able to track so many bugs does not make it a good > advertisement for us. What number would not be "way too high"? You shouldn't judge the quality of a product (or anything else about it) by the number of bugs open against it. > So anything you could do to help this situation would be good. If one > day we could institute a no-known-bugs policy for releases because of > this, well that would be even better. I think it's dangerous even to aim at that goal. It leads to never releasing anything, not to better software. At some point, the cost of fixing the remaining bugs (in delay, effort and possible regressions) outweighs the benefit of having them fixed. Having said all that, I wholeheartedly agree that it would be great to sweep all the open Bugzilla bugs and triage them. Gerv From ed.fuentetaja at ttu.edu Mon Jan 19 08:57:12 2004 From: ed.fuentetaja at ttu.edu (Fuentetaja, Ed) Date: Mon, 19 Jan 2004 02:57:12 -0600 Subject: Test runner Message-ID: <55CA02C1ECF1CB40B2A0AF7B32F0DFDD15F4CB@BRONTES.net.ttu.edu> Just a word to let this list know that I've released a new version of Bugzilla Test Runner, version 0.4.5. Go to http://www.willowriver.net/products/testrunner.php for more info as well as an online demo. >From now on I'll send this emails only to the test runner mailing list: testrunner-users at lists.sourceforge.net, which I welcome you to join. Thanks, Ed From mattyt-spam at tpg.com.au Mon Jan 19 11:49:24 2004 From: mattyt-spam at tpg.com.au (MattyT) Date: Mon, 19 Jan 2004 22:19:24 +1030 Subject: Too Many Bugs In-Reply-To: <400AB00B.5050803@mozilla.org> References: <1074428533.9093.38.camel@megagerbil> <20040118154756.GD72437@nexus.ninth-circle.org> <400AB00B.5050803@mozilla.org> Message-ID: <1074512963.20908.12.camel@megagerbil> On Mon, 2004-01-19 at 02:40, Gervase Markham wrote: > > One problem I see with most bugs is that there's too much debate and not > > enough implementation. Some discussions are from 2001 or 2002 and > > still going on! > Just because a bug is filed doesn't necessarily mean that a patch will > result - for example, it could be an RFE for what, after discussion, > turns out to be a bad idea. But I agree that two-year discussions aren't > very productive. I don't think that two year discussions are particularly relevant to bugs (moreso to RFEs). There might be the odd one, and that would stand out, but I'm sure the 98% of our bugs are just sitting there without this. > What we actually need is strong ownership of components - so the module > owner will decide "no, we're definitely not going to do this", and close > the bug as WONTFIX, or decide "yes, we would like to do this", and say > so on the bug - at which point anyone who wishes can start coding. Again, WONTFIX should not be relevant to bugs, there is no such thing as a bug that should be WONTFIX. Strong ownership would perhaps be useful in another way however, in that people currently feel no responsibility to fix bugs. Perhaps if we had more ownership people might feel as such. > I suggest, though, that before everyone goes off in a triaging frenzy, > we wait until the upcoming releases are out the door, b.m.o. is > upgraded, the regressions are crushed, b.m.o. does its CVS update, and > is back on an even keel again. I expect that to take a couple of weeks. I don't really see how this matters. Screening and triaging is doubly important in clearing off the bug list for an impending release, the upgrade won't dramatically help, regressions are bugs to fix, and being on an even keel isn't where you want to be if you're drifting further away from land. -- Matthew Tuck: Software Developer & All-Round Nice Guy My Short Autobiography: 1985 Grade Bin Monitor 1990 Class Clown Award 1992 Awarded Most Likely To Spontaneously Combust 1996 Crowned Galactic Emperor 1998 Released From Smith Psychiatric Hospital From gerv at mozilla.org Mon Jan 19 11:59:59 2004 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 19 Jan 2004 11:59:59 +0000 Subject: Too Many Bugs In-Reply-To: <1074512963.20908.12.camel@megagerbil> References: <1074428533.9093.38.camel@megagerbil> <20040118154756.GD72437@nexus.ninth-circle.org> <400AB00B.5050803@mozilla.org> <1074512963.20908.12.camel@megagerbil> Message-ID: <400BC6BF.3000101@mozilla.org> MattyT wrote: > On Mon, 2004-01-19 at 02:40, Gervase Markham wrote: >>What we actually need is strong ownership of components - so the module >>owner will decide "no, we're definitely not going to do this", and close >>the bug as WONTFIX, or decide "yes, we would like to do this", and say >>so on the bug - at which point anyone who wishes can start coding. > > Again, WONTFIX should not be relevant to bugs, there is no such thing as > a bug that should be WONTFIX. Yes there is :-) You may decide that fixing it would be too disruptive for too little gain, and so you're going to live with it indefinitely. I can think of at least two examples of this recently. One is the renaming of database fields. > Strong ownership would perhaps be useful in another way however, in that > people currently feel no responsibility to fix bugs. That's somewhat of a generalisation. I invite you to look through the Reporting and Charting component as a counter-example. :-) >>I suggest, though, that before everyone goes off in a triaging frenzy, >>we wait until the upcoming releases are out the door, b.m.o. is >>upgraded, the regressions are crushed, b.m.o. does its CVS update, and >>is back on an even keel again. I expect that to take a couple of weeks. > > I don't really see how this matters. It matters because people can only be doing one thing at once, and you can't focus your resources across the board. IMO it's important to be focussed on getting a high-quality upgraded b.m.o. up and running ASAP. Triaging old bugs helps this goal only in a very indirect way. Gerv From mattyt-spam at tpg.com.au Mon Jan 19 12:44:04 2004 From: mattyt-spam at tpg.com.au (MattyT) Date: Mon, 19 Jan 2004 23:14:04 +1030 Subject: Too Many Bugs In-Reply-To: <400BC6BF.3000101@mozilla.org> References: <1074428533.9093.38.camel@megagerbil> <20040118154756.GD72437@nexus.ninth-circle.org> <400AB00B.5050803@mozilla.org> <1074512963.20908.12.camel@megagerbil> <400BC6BF.3000101@mozilla.org> Message-ID: <1074516244.24334.43.camel@megagerbil> On Mon, 2004-01-19 at 22:29, Gervase Markham wrote: > Yes there is :-) You may decide that fixing it would be too disruptive > for too little gain, and so you're going to live with it indefinitely. I > can think of at least two examples of this recently. One is the renaming > of database fields. Then suspension *might* be warranted, but WONTFIX certainly isn't. And things like renaming database fields are "bugs" only in a loose sense. This threads is about bugs, not what lies in the grey area between bugs and enhancements. They are the vast majority, and there is no room for interpretation or WONTFIXing. And this is about practical solutions for the majority. > > Strong ownership would perhaps be useful in another way however, in that > > people currently feel no responsibility to fix bugs. > That's somewhat of a generalisation. I invite you to look through the > Reporting and Charting component as a counter-example. :-) Loose language perhaps, but the generalisation is relevant in that clearly true to a large extent. I feel that I keep sanity check in pretty good shape too. Some of the problems have been caused by component owners who were never really very involved with their components. I don't mean this in a derogatory way, it may be they have too many responsibilities, or too little time, in the first place. And a half-hearted component owner is better than none. But I do think it means we need to think about how components are assigned to owners, and some components might do with an official deputy. I think smaller components are better from this perspective, although perhaps not from a bug reporting one. I can imagine it would be hard to get a perspective on a component that has 150 bugs. Obviously the solution is to work away at it, but if we split up the components, at least in spirit, it can feel like an easier task. For example, although justdave is the official owner of the administration component (at least last I checked), which includes sanity check, I am the de facto owner of sanity check. I have rewritten copious quantities of this since I started with it. With a smaller component, it is easier to take control, have pride in "your" component. At the moment, no one really owns anything, and hence no one feels any bugs are their responsibility. When you have pride, you will feel it's your responsibility to fix even if its not your fault. And no one needs to tell you any of this. Pride as a greater motivator than money is supposed to be part of the reason individual volunteers are supposed to often produce better quality software than businesses. And I feel that people's lack of connection with the Bugzilla code is in part responsible for some bugs sitting around for years. A great example of this is the bug in the notifications of status changes on dependent bugs. When you add a dependency, you get all the status changes the bug has ever been through. Or something like that. I'm pretty sure this bug has been in Bugzilla since dependencies were introduced before even I was involved with Bugzilla. And I'm sure most of you have seen these notifications that come through periodically and thought someone should fix it some day, but everyone's hoping someone else will do it. There's few feelings of responsibility, because there's few feelings of true ownership. > > I don't really see how this matters. > It matters because people can only be doing one thing at once, and you > can't focus your resources across the board. IMO it's important to be > focussed on getting a high-quality upgraded b.m.o. up and running ASAP. > Triaging old bugs helps this goal only in a very indirect way. Part of the problem is there is never a time. I don't doubt getting a release out is more important in comparison to adding the next feature. But this thread isn't just about being reactionary and triaging the bug system. It's about being proactive, and to do this it has to be kept in people's minds, even if nothing is done about it today. -- Matthew Tuck: Software Developer & All-Round Nice Guy My Short Autobiography: 1985 Grade Bin Monitor 1990 Class Clown Award 1992 Awarded Most Likely To Spontaneously Combust 1996 Crowned Galactic Emperor 1998 Released From Smith Psychiatric Hospital From mattyt-spam at tpg.com.au Mon Jan 19 12:53:21 2004 From: mattyt-spam at tpg.com.au (MattyT) Date: Mon, 19 Jan 2004 23:23:21 +1030 Subject: Number of Bugs per product Message-ID: <1074516800.20908.51.camel@megagerbil> Here are statistics as to the distribution of bugs: Administration 73 Attachments & Requests 94 Bug Import/Export & Moving 8 Bugzilla-General 133 Creating/Changing Bugs 145 Documentation 38 Email Notifications 35 Installation & Upgrading 45 Query/Bug List 125 Reporting/Charting 22 Testing Suite 8 User Accounts 30 User Interface 83 bugzilla.org 11 These aren't supposed to rail upon any component owners - components have different sizes and are in different states of redesign. But they should be useful in discussion. Now for assignee (I skipped people < 5): bbaetz at acm.org 13 bugreport at peshkin.net 6 documentation at bugzilla.org 36 endico at mozilla.org 88 gerv at mozilla.org 22 john at johnkeiser.com 5 justdave at bugzilla.org 197 kiko at async.com.br 10 mattyt-bugzilla at tpg.com.au 16 myk at mozilla.org 324 nobody 10 preed at sigkill.com 34 timeless at bemail.org 6 vlad987 at home.ro 5 zach at zachlipton.com 46 Total 850 Does anyone want to guess what's wrong the above picture? -- Matthew Tuck: Software Developer & All-Round Nice Guy My Short Autobiography: 1985 Grade Bin Monitor 1990 Class Clown Award 1992 Awarded Most Likely To Spontaneously Combust 1996 Crowned Galactic Emperor 1998 Released From Smith Psychiatric Hospital From ed.fuentetaja at ttu.edu Mon Jan 19 17:39:56 2004 From: ed.fuentetaja at ttu.edu (Fuentetaja, Ed) Date: Mon, 19 Jan 2004 11:39:56 -0600 Subject: [Testrunner-users] Test runner Message-ID: <55CA02C1ECF1CB40B2A0AF7B32F0DFDD06AA2098@BRONTES.net.ttu.edu> Sorry to interrupt the discussion again. To join the Test Runner mailing list, visit the project on source forge: http://sourceforge.net/projects/testrunner/ And click on "Lists" Thanks, Ed > -----Original Message----- > From: Fuentetaja, Ed > Sent: Monday, January 19, 2004 2:57 AM > To: testrunner-users at lists.sourceforge.net; developers at bugzilla.org > Subject: [Testrunner-users] Test runner > > > Just a word to let this list know that I've released a new > version of Bugzilla Test Runner, version 0.4.5. Go to > http://www.willowriver.net/products/testrunner.php for more > info as well as an online demo. > > From now on I'll send this emails only to the test runner > mailing list: testrunner-users at lists.sourceforge.net, which I > welcome you to join. > > Thanks, > > Ed > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, > CA. http://www.eclipsecon.org/osdn > _______________________________________________ > Testrunner-users mailing list Testrunner-users at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/testrunner-users > From gerv at mozilla.org Mon Jan 19 18:16:36 2004 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 19 Jan 2004 18:16:36 +0000 Subject: Multiple bug reports for a single problem In-Reply-To: <5.2.0.9.0.20040115151809.0454fe98@208.2.156.7> References: <5.2.0.9.0.20040115133748.029bad48@208.2.156.7> <16390.62049.164721.402819@magrathea.basistech.com> <5.2.0.9.0.20040115110127.03e765d8@208.2.156.7> <5.2.0.9.0.20040115133748.029bad48@208.2.156.7> <5.2.0.9.0.20040115151809.0454fe98@208.2.156.7> Message-ID: <400C1F04.8020702@mozilla.org> John P. Fisher wrote: > ok done > If it helps any I *think* an extra field in the bugs table with > associated bug_ids would be enough db change. What you actually want is a related bugs table, with bug_id1, bug_id2, and relationship. This can subsume the dependencies tables and allow for any other sorts of relationship (like clones, which might well come along in the future.) Gerv From gerv at mozilla.org Mon Jan 19 18:24:02 2004 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 19 Jan 2004 18:24:02 +0000 Subject: 2.17? In-Reply-To: <1074272840.7854.4.camel@gondor.localdomain> References: <1074268579.14566.97.camel@localhost.localdomain> <1074272840.7854.4.camel@gondor.localdomain> Message-ID: <400C20C2.2050700@mozilla.org> Andrew Sobala wrote: > If upgrading to 2.17 is quite painless, I'd be happy to do it. The thing > is, to upgrade to 2.16, all we need to do is minor templatisation. > That's _it_. I was going to do the final template stuff over the > weekend, and I tested importing our database into the 2.16 system a > couple of weeks ago, and it worked. If you're that close, then go for 2.16. b.g.o. is too big and important to risk picking up a nasty regression IMO. That's what b.m.o.'s for ;-) Gerv From gerv at mozilla.org Mon Jan 19 18:27:17 2004 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 19 Jan 2004 18:27:17 +0000 Subject: CVS commit messages In-Reply-To: References: Message-ID: <400C2185.6000702@mozilla.org> David Miller wrote: > There's been several violations of this lately, so I figure this is a good > time to remind everyone what a good CVS commit log message looks like. > > Please do NOT just copy/paste the summary of the bug you're fixing into the > cvs comment, unless that summary happens to be clear and concise. All of what Dave said - but also, if your summary isn't clear and concise, make it so as you fix the bug :-) Gerv From kiko at async.com.br Mon Jan 19 18:19:17 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Mon, 19 Jan 2004 16:19:17 -0200 Subject: Number of Bugs per product In-Reply-To: <1074516800.20908.51.camel@megagerbil> References: <1074516800.20908.51.camel@megagerbil> Message-ID: <20040119181917.GE967@async.com.br> On Mon, Jan 19, 2004 at 11:23:21PM +1030, MattyT wrote: > Now for assignee (I skipped people < 5): > > bbaetz at acm.org 13 > bugreport at peshkin.net 6 > documentation at bugzilla.org 36 > endico at mozilla.org 88 > gerv at mozilla.org 22 > john at johnkeiser.com 5 > justdave at bugzilla.org 197 > kiko at async.com.br 10 > mattyt-bugzilla at tpg.com.au 16 > myk at mozilla.org 324 > nobody 10 > preed at sigkill.com 34 > timeless at bemail.org 6 > vlad987 at home.ro 5 > zach at zachlipton.com 46 > Total 850 > > Does anyone want to guess what's wrong the above picture? That's easy. We lack developers, and most of the developers we have are too busy to commit significant time to fix their assigned bugs :-) One thing that *would* help would be a mass reassign of bugs we're *not working on* to nobody at bugzilla.org. I'd be a lot more comfortable rediscussing this list once we stopped listing bugs assigned to default owners indiscriminately. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From kiko at async.com.br Mon Jan 19 18:34:13 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Mon, 19 Jan 2004 16:34:13 -0200 Subject: CVS commit messages In-Reply-To: References: Message-ID: <20040119183413.GF967@async.com.br> On Fri, Jan 16, 2004 at 06:28:01PM -0500, David Miller wrote: > A checkin comment should contain a *short* description of what the patch > does. NOT the summary of the bug, unless that bug summary happens to > describe that adequately. > > Bad example: (sorry for singling this one out, it's not the only offender > lately, but it's an example of this) Sorry boss, won't happen [*] again. [*] This is specially painful since I normally describe *what* the change did along with the bug summary (honest!). I don't think that including the bug summary is a bad thing (it helps a quick-scan of a checkin list, for instance), but I agree that the essential bit is a summary of the changes themselves. I was in a hurry this Friday -- I was worried I wouldn't make the 2.17.7 cut so I guess I just forgot this one time. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From justdave at bugzilla.org Mon Jan 19 18:55:30 2004 From: justdave at bugzilla.org (David Miller) Date: Mon, 19 Jan 2004 13:55:30 -0500 Subject: Number of Bugs per product In-Reply-To: <20040119181917.GE967@async.com.br> References: <1074516800.20908.51.camel@megagerbil> <20040119181917.GE967@async.com.br> Message-ID: On 1/19/2004 4:19 PM -0200, Christian Robottom Reis wrote: > One thing that *would* help would be a mass reassign of bugs we're > *not working on* to nobody at bugzilla.org. I'd be a lot more comfortable > rediscussing this list once we stopped listing bugs assigned to default > owners indiscriminately. This would be a good thing. The "Real Name" description on the nobody at bugzilla.org has a big "help wanted" advertisement in it, too, so it makes it very clear that anyone can feel free to post a patch. :) -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From kiko at async.com.br Mon Jan 19 19:28:40 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Mon, 19 Jan 2004 17:28:40 -0200 Subject: Number of Bugs per product In-Reply-To: References: <1074516800.20908.51.camel@megagerbil> <20040119181917.GE967@async.com.br> Message-ID: <20040119192840.GM967@async.com.br> On Mon, Jan 19, 2004 at 01:55:30PM -0500, David Miller wrote: > On 1/19/2004 4:19 PM -0200, Christian Robottom Reis wrote: > > > One thing that *would* help would be a mass reassign of bugs we're > > *not working on* to nobody at bugzilla.org. I'd be a lot more comfortable > > rediscussing this list once we stopped listing bugs assigned to default > > owners indiscriminately. > > This would be a good thing. The "Real Name" description on the > nobody at bugzilla.org has a big "help wanted" advertisement in it, too, so it > makes it very clear that anyone can feel free to post a patch. :) Let's make it official then and do the reassign before 2.17.7 hits the streets (and provides us with advertising)? Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From mattyt-spam at tpg.com.au Tue Jan 20 05:55:37 2004 From: mattyt-spam at tpg.com.au (MattyT) Date: Tue, 20 Jan 2004 16:25:37 +1030 Subject: Date Based Releases Message-ID: <1074578136.861.18.camel@megagerbil> For those of you who didn't see the webtools thread, Bugzilla will probably be moving to date-based releases for 2.20 and beyond, in response to the enormously long periods for the feature-based releases 2.16 and 2.18. The current plan is as follows: The releases will be approximately six-monthly to start with. This I think should be an upper limit, and we could perhaps consider to go to four-monthly later if things runs smoothly. More releases means code gets out faster and developers have less pain missing a release, and I don't think there's much overhead from extra releases, given pretty much all work before and after a release will be proportionately smaller. There will be no promises of features appearing in releases, on behalf of the Bugzilla project. We have no way of guaranteeing features in a given or reasonable time frame. If you want to make an individual promise to someone, it's on your head. =) The date-based part of the release process will be the feature freeze. All other aspects of development will stay "when they're ready". This in particular means the releases will only be approximately six months apart. When the tree opens for 2.19, there will be six months of development time. Once this elapses, a feature freeze will be declared, at which point the tree will be closed to anything that is not a user or administrator-visible bug fix, docs updates or an otherwise freeze-approved checkin. This will continue until the tree is declared fit for RC1. At this point, the tree will branch, and HEAD will reopen for development. The branch will continue the RC cycle until it's ready for release. Note that the tree closed time will be deducted from the development time for the next release, which will mean the feature freezes will stay exactly every six months. One would not expect this to be greater than 1-2 weeks, if which case the development time would be about 5 months 2-3 weeks. -- Matthew Tuck: Software Developer & All-Round Nice Guy My Short Autobiography: 1985 Grade Bin Monitor 1990 Class Clown Award 1992 Awarded Most Likely To Spontaneously Combust 1996 Crowned Galactic Emperor 1998 Released From Smith Psychiatric Hospital From mattyt-spam at tpg.com.au Tue Jan 20 06:32:36 2004 From: mattyt-spam at tpg.com.au (MattyT) Date: Tue, 20 Jan 2004 17:02:36 +1030 Subject: Number of Bugs per product In-Reply-To: <20040119181917.GE967@async.com.br> References: <1074516800.20908.51.camel@megagerbil> <20040119181917.GE967@async.com.br> Message-ID: <1074580355.1717.50.camel@megagerbil> On Tue, 2004-01-20 at 04:49, Christian Robottom Reis wrote: > That's easy. We lack developers, and most of the developers we have > are too busy to commit significant time to fix their assigned bugs :-) Bzzzt. Wrong answer. > One thing that *would* help would be a mass reassign of bugs we're > *not working on* to nobody at bugzilla.org. I'd be a lot more comfortable > rediscussing this list once we stopped listing bugs assigned to default > owners indiscriminately. That's certainly true for enhancements, but I don't think cleaning up the bulk of 850 bugs is out of reach *if divided up more evenly*, remembering a lot of those are probably enhancements. While assigning off to nobody is a gain in transparency and perhaps might help others to see what needs to be done, it's also a continued cop-out, and that's what I'm trying to avoid. The bug distribution should be reasonably uniform. Given 850 bugs to 12 developers, that's an average of about 70 bugs. A reasonable range is therefore 35-140 bugs per developer, we have two developers in that range, one of whom hasn't done much coding at all in the past few years. Everyone else is either below it, or way above it with no hope of ever fixing all their bugs. I think if the bugs were more evenly distributed across the developers, we'd each have a more manageable task to work at. We already have NEW versus ASSIGNED to distinguish in progress reports, let's not reinvent the wheel. Assigning bugs to nobody smells to me like a black hole, much like REMIND and LATER were. Sure, it might help non-core developers find issues to take, but the bugs are more likely to be fixed by core developers, and this is just going to take these bugs further off their radar. At least at the moment, the component owner is at least partly responsible for their bugs. I don't believe the problem isn't that we don't have enough time, but that we're spending too much time writing features and not enough fixing the bugs with them. We have enough time to fix these bugs, we just need to *want* to. And I think with gentle reminders we can make people want to. At the moment it's just "out of sight, out of mind". No one here doesn't care about these bugs, we just all get dispirited and take it as too much work. If we were reminded more often of these bugs, I think we'd get them fixed more often. I'm not asking for some enormous effort to reduce the bug count down to zero, I'm asking for ways in which we can turn the upward trend to a downward trend. Assigning to nobody isn't going to have a significant impact on that. I don't want to be standing here in three years time complaining about our 1500 bugs. Do we need to shame people into fixing their bugs? CVS blame and work out who inserted the most bugs? Most bugs per LOC? What reviewers let through the most bugs? I don't really want to go down that road, as I'm sure everyone wouldn't, I'd rather people just took responsibility for their fault and/or pride for their areas. However, at the moment it seems to me that there aren't too many other roads that fix the problem, and some good statistics could help us understand what's going on. -- Matthew Tuck: Software Developer & All-Round Nice Guy My Short Autobiography: 1985 Grade Bin Monitor 1990 Class Clown Award 1992 Awarded Most Likely To Spontaneously Combust 1996 Crowned Galactic Emperor 1998 Released From Smith Psychiatric Hospital From louie at ximian.com Tue Jan 20 20:18:37 2004 From: louie at ximian.com (Luis Villa) Date: Tue, 20 Jan 2004 15:18:37 -0500 Subject: Date Based Releases In-Reply-To: <1074578136.861.18.camel@megagerbil> References: <1074578136.861.18.camel@megagerbil> Message-ID: <1074610790.14799.7.camel@localhost.localdomain> On Tue, 2004-01-20 at 00:55, MattyT wrote: > For those of you who didn't see the webtools thread, Bugzilla will > probably be moving to date-based releases for 2.20 and beyond I really think that this is great news for everyone involved. Congrats- the growing pains will be worth it. Luis From JWilmoth at starbucks.com Tue Jan 20 21:17:59 2004 From: JWilmoth at starbucks.com (Jon Wilmoth) Date: Tue, 20 Jan 2004 13:17:59 -0800 Subject: $ipaddr vs $netaddr Message-ID: <72AB874F99785949A2898773AEDB5ED8B932D6@seams043.starbucks.net> What's the difference between these two variables? They are populated in the CGI.pl from 2.17.3 in the following manner. my $ipaddr = $ENV{'REMOTE_ADDR'}; my $netaddr = get_netaddr($ipaddr); From justdave at bugzilla.org Tue Jan 20 22:05:54 2004 From: justdave at bugzilla.org (David Miller) Date: Tue, 20 Jan 2004 17:05:54 -0500 Subject: $ipaddr vs $netaddr In-Reply-To: <72AB874F99785949A2898773AEDB5ED8B932D6@seams043.starbucks.net> References: <72AB874F99785949A2898773AEDB5ED8B932D6@seams043.starbucks.net> Message-ID: On 1/20/2004 1:17 PM -0800, Jon Wilmoth wrote: > What's the difference between these two variables? > > They are populated in the CGI.pl from 2.17.3 in the following manner. > > my $ipaddr = $ENV{'REMOTE_ADDR'}; > my $netaddr = get_netaddr($ipaddr); get_netaddr uses the loginnetmask param to mask the address for the allowed subnet the user can access from and still keep their cookies. So if your loginnetmask is set to 24, get_netaddr will return the user's IP address with the last 8 bits removed. If loginnetmask is 32, it'll return the IP address unchanged. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From JWilmoth at starbucks.com Tue Jan 20 22:37:25 2004 From: JWilmoth at starbucks.com (Jon Wilmoth) Date: Tue, 20 Jan 2004 14:37:25 -0800 Subject: $ipaddr vs $netaddr Message-ID: <72AB874F99785949A2898773AEDB5ED8B932DB@seams043.starbucks.net> If the loginnetmask is 24, will get_netaddr will return nnn.nnn.nnn or nnn.nnn.nnn.000? Perhaps I should rephrase the question as "is the number of bits chopped or substituted?" If substituted, what's the substitution value? -----Original Message----- From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] On Behalf Of David Miller Sent: Tuesday, January 20, 2004 2:06 PM To: developers at bugzilla.org Subject: Re: $ipaddr vs $netaddr On 1/20/2004 1:17 PM -0800, Jon Wilmoth wrote: > What's the difference between these two variables? > > They are populated in the CGI.pl from 2.17.3 in the following manner. > > my $ipaddr = $ENV{'REMOTE_ADDR'}; > my $netaddr = get_netaddr($ipaddr); get_netaddr uses the loginnetmask param to mask the address for the allowed subnet the user can access from and still keep their cookies. So if your loginnetmask is set to 24, get_netaddr will return the user's IP address with the last 8 bits removed. If loginnetmask is 32, it'll return the IP address unchanged. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ - To view or change your list settings, click here: From justdave at bugzilla.org Tue Jan 20 22:42:01 2004 From: justdave at bugzilla.org (David Miller) Date: Tue, 20 Jan 2004 17:42:01 -0500 Subject: $ipaddr vs $netaddr In-Reply-To: <72AB874F99785949A2898773AEDB5ED8B932DB@seams043.starbucks.net> References: <72AB874F99785949A2898773AEDB5ED8B932DB@seams043.starbucks.net> Message-ID: On 1/20/2004 2:37 PM -0800, Jon Wilmoth wrote: > If the loginnetmask is 24, will get_netaddr will return nnn.nnn.nnn or > nnn.nnn.nnn.000? Perhaps I should rephrase the question as "is the > number of bits chopped or substituted?" If substituted, what's the > substitution value? substituted. What it returns still looks like an IP address, with no leading zeros. So if you give it xxx.yyy.zzz.www with a loginnetmask of 24, it'll return xxx.yyy.zzz.0 -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From JWilmoth at starbucks.com Tue Jan 20 22:47:23 2004 From: JWilmoth at starbucks.com (Jon Wilmoth) Date: Tue, 20 Jan 2004 14:47:23 -0800 Subject: $ipaddr vs $netaddr Message-ID: <72AB874F99785949A2898773AEDB5ED8B932DC@seams043.starbucks.net> Great...I think this will solve the problem some of our users are experiencing where they're being prompted multiple times/session for login info. The logincookies table shows different values for the last 8 bits even from a stationary machine. -----Original Message----- From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] On Behalf Of David Miller Sent: Tuesday, January 20, 2004 2:42 PM To: developers at bugzilla.org Subject: Re: $ipaddr vs $netaddr On 1/20/2004 2:37 PM -0800, Jon Wilmoth wrote: > If the loginnetmask is 24, will get_netaddr will return nnn.nnn.nnn or > nnn.nnn.nnn.000? Perhaps I should rephrase the question as "is the > number of bits chopped or substituted?" If substituted, what's the > substitution value? substituted. What it returns still looks like an IP address, with no leading zeros. So if you give it xxx.yyy.zzz.www with a loginnetmask of 24, it'll return xxx.yyy.zzz.0 -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ - To view or change your list settings, click here: From NidalBaydoun at citect.com Tue Jan 20 22:52:55 2004 From: NidalBaydoun at citect.com (Nidal Baydoun) Date: Wed, 21 Jan 2004 09:52:55 +1100 Subject: SilkTest to bugzilla Message-ID: <7BD60084A7136944B8F8AC3062CBDE75039E9E88@syd-mail.syd.cit.com.au> Hi guys, I would like to automate logging bugs into bugzilla while running SilkTest scripts. Any idea on the best way to approach that will be highly appreciated. Regards Nidal ---------------------------------------------------------------------------- ------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From justdave at bugzilla.org Tue Jan 20 23:06:35 2004 From: justdave at bugzilla.org (David Miller) Date: Tue, 20 Jan 2004 18:06:35 -0500 Subject: SilkTest to bugzilla In-Reply-To: <7BD60084A7136944B8F8AC3062CBDE75039E9E88@syd-mail.syd.cit.com.au> References: <7BD60084A7136944B8F8AC3062CBDE75039E9E88@syd-mail.syd.cit.com.au> Message-ID: On 1/21/2004 9:52 AM +1100, Nidal Baydoun wrote: > I would like to automate logging bugs into bugzilla while running >SilkTest scripts. >Any idea on the best way to approach that will be highly appreciated. We've used it where I work... unfortunately, the person who had it set up got laid off in December, and they took away her computer before we could retreive the scripts... -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From kiko at async.com.br Wed Jan 21 11:31:44 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Wed, 21 Jan 2004 09:31:44 -0200 Subject: Number of Bugs per product In-Reply-To: <1074580355.1717.50.camel@megagerbil> References: <1074516800.20908.51.camel@megagerbil> <20040119181917.GE967@async.com.br> <1074580355.1717.50.camel@megagerbil> Message-ID: <20040121113144.GH739@async.com.br> On Tue, Jan 20, 2004 at 05:02:36PM +1030, MattyT wrote: > On Tue, 2004-01-20 at 04:49, Christian Robottom Reis wrote: > > > That's easy. We lack developers, and most of the developers we have > > are too busy to commit significant time to fix their assigned bugs :-) > > Bzzzt. Wrong answer. Because that's what you think, or is that a statement of fact? :) > While assigning off to nobody is a gain in transparency and perhaps > might help others to see what needs to be done, it's also a continued > cop-out, and that's what I'm trying to avoid. We're not copping out, AFAIK. We're overburdened. I've been putting in 60 hour weeks for as long as I can remember (with less that 20% of that devoted to Bugzilla), and last I checked many of the other regulars were too. That doesn't make for a very productive team. Making it easier for newcomers to help and nudging them forward when we do get some is, in my opinion, the best way to make sure bugs are fixed (and QA even) given this situation. > The bug distribution should be reasonably uniform. Given 850 bugs to 12 > developers, that's an average of about 70 bugs. A reasonable range is > therefore 35-140 bugs per developer, we have two developers in that > range, one of whom hasn't done much coding at all in the past few > years. Everyone else is either below it, or way above it with no hope > of ever fixing all their bugs. I'm not above that line because I simply can't handle more than what I'm assigned to. I can't have 35 bugs or more assigned to myself -- I'd end up not doing anything. > I don't believe the problem isn't that we don't have enough time, but > that we're spending too much time writing features and not enough fixing > the bugs with them. We have enough time to fix these bugs, we just need Err, what new features have been holding up bugfixing? I fail to see "major new features" landing on the trunk -- and we *do* have some that could have been landed in the period stated. Have you had a look at the bonsai logs for the past months? > downward trend. Assigning to nobody isn't going to have a significant > impact on that. I don't want to be standing here in three years time > complaining about our 1500 bugs. In my opinion, it will to an extent, in the sense that it helps attract community participation. If all the main developers are overburdened, it's great to attract and stimulate outside help. Of course, there's the other, appropriate, remark: if you want to help the bug count, you might want to join us in providing patches that fix some . > their fault and/or pride for their areas. However, at the moment it > seems to me that there aren't too many other roads that fix the problem, > and some good statistics could help us understand what's going on. I'm actually in favor of getting statistics that tell me how many bugs I regressed when checking in any new features developed; if you want to provide some, I think it would be generally appreciated. I just don't think that will help me squeeze in an extra 20h or so every week to fix bugs. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From bugreport at peshkin.net Wed Jan 21 14:33:26 2004 From: bugreport at peshkin.net (Joel Peshkin) Date: Wed, 21 Jan 2004 06:33:26 -0800 Subject: Optimizing searches on short_desc Message-ID: <400E8DB6.9070509@peshkin.net> I noticed that most searches for strings in short_desc do not take advantage of the fulltext index. 3 questions: 1) myk - Do you have any data showing what fraction of all BMO searches are "contains all words/strings" on the summrary? 2) bbaetz - would this be better using MATCH (short_desc) AGAINST ('+word +word' IN BOOLEAN MODE) instead of the current index-confounding query? 3) should we change it? From mattyt-spam at tpg.com.au Fri Jan 23 12:05:21 2004 From: mattyt-spam at tpg.com.au (MattyT) Date: Fri, 23 Jan 2004 22:35:21 +1030 Subject: Directions In Architectural Redesign Message-ID: <1074859520.5902.29.camel@megagerbil> Just thought I'd make a quick list where we are probably (possibly?) looking at going architecture wise. It's not complete, but it might interest some people. Email Templatisation, maybe accompanied by notification redesign (bulk changes?) mod_perl support. Use of DBI/CGI. Use of SQL placeholders. Use of database transactions, where available. Cross database compatibility - schema, sql, kill/shield db-specific features. Consistency of fields - administration interface, features (sortkeys, isactive, etc), product specific policy. Separated back end API - integrate Bug.pm, use modules/OOP, use exceptions. Also for checksetup.pl. Get test suite to test this API. Use subselects/unions/intersection, once we require MySQL version that supports them. Schema data structure - store referential integrity info (and possibly reuse for other things), support best data type selection for current database, automate checksetup.pl (required additions and deletions get autodetected). More capability to "hook" into Bugzilla at various places. Less hardcoding - customised statuses/resolutions, easier to add customised fields. Alternative user interfaces, web services support. -- Matthew Tuck: Software Developer & All-Round Nice Guy My Short Autobiography: 1985 Grade Bin Monitor 1990 Class Clown Award 1992 Awarded Most Likely To Spontaneously Combust 1996 Crowned Galactic Emperor 1998 Released From Smith Psychiatric Hospital From myk at mozilla.org Fri Jan 23 12:43:22 2004 From: myk at mozilla.org (Myk Melez) Date: Fri, 23 Jan 2004 04:43:22 -0800 Subject: Optimizing searches on short_desc In-Reply-To: <400E8DB6.9070509@peshkin.net> References: <400E8DB6.9070509@peshkin.net> Message-ID: <401116EA.9040505@mozilla.org> Joel Peshkin wrote: > I noticed that most searches for strings in short_desc do not take > advantage of the fulltext index. None do on b.m.o, but after the upgrade we'll be in a position to find out how many people take advantage of that search option. > 3 questions: > > 1) myk - Do you have any data showing what fraction of all BMO > searches are "contains all words/strings" on the summrary? Here's what the current access log says: [root at mecha httpd]# grep 'GET \/buglist\.cgi' access_log | wc; grep 'GET \/buglist\.cgi' access_log | grep 'short_desc=[^&]' | wc; grep 'GET \/buglist\.cgi' access_log | grep 'short_desc=[^&]' | grep allwordssubstr | wc; 40244 790696 26393924 5649 113366 4929319 5509 110491 4832808 (i.e. of 40K searches, only 5K or so are summary searches, but most of those are "contains all words/strings" searches) -myk From tobias.burnus at physik.fu-berlin.de Fri Jan 23 12:49:31 2004 From: tobias.burnus at physik.fu-berlin.de (Tobias Burnus) Date: Fri, 23 Jan 2004 13:49:31 +0100 Subject: Directions In Architectural Redesign In-Reply-To: <1074859520.5902.29.camel@megagerbil> References: <1074859520.5902.29.camel@megagerbil> Message-ID: <20040123124930.GA18517@physik.fu-berlin.de> Hello, On Fri, Jan 23, 2004 at 10:35:21PM +1030, MattyT wrote: > Just thought I'd make a quick list where we are probably (possibly?) > looking at going architecture wise. It's not complete, but it might > interest some people. What I would like to see is the reduction of hardwired strings which are inserted as comment like 'This bug has been marked as duplicate of ...' etc. I would prefer to have those in a different form in the database than as comment. This allows for (a) localization of the output string and (b) such texts could be put into e.g. in a box and thus made be more visible. > Less hardcoding - customised statuses/resolutions, easier to add > customised fields. The problem with those strings is how this can be localized best. Tobias From gerv at mozilla.org Fri Jan 23 13:17:11 2004 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 23 Jan 2004 13:17:11 +0000 Subject: Directions In Architectural Redesign In-Reply-To: <20040123124930.GA18517@physik.fu-berlin.de> References: <1074859520.5902.29.camel@megagerbil> <20040123124930.GA18517@physik.fu-berlin.de> Message-ID: <40111ED7.2090801@mozilla.org> Tobias Burnus wrote: > What I would like to see is the reduction of hardwired strings which are > inserted as comment like 'This bug has been marked as duplicate of ...' > etc. I would prefer to have those in a different form in the database > than as comment. This allows for (a) localization of the output string > and (b) such texts could be put into e.g. in a box and thus made be more > visible. Indeed. All such text should be in templates. The actual example you give should probably go away, in favour of displaying the dupe number next to the resolution. >>Less hardcoding - customised statuses/resolutions, easier to add >>customised fields. > > The problem with those strings is how this can be localized best. We probably want to be using numbers internally for each status and resolution, and translating them to strings at display time: [% status_descs.$status %] Gerv From tobias.burnus at physik.fu-berlin.de Fri Jan 23 13:31:18 2004 From: tobias.burnus at physik.fu-berlin.de (Tobias Burnus) Date: Fri, 23 Jan 2004 14:31:18 +0100 Subject: Directions In Architectural Redesign In-Reply-To: <40111ED7.2090801@mozilla.org> References: <1074859520.5902.29.camel@megagerbil> <20040123124930.GA18517@physik.fu-berlin.de> <40111ED7.2090801@mozilla.org> Message-ID: <20040123133118.GA19939@physik.fu-berlin.de> Hellom On Fri, Jan 23, 2004 at 01:17:11PM +0000, Gervase Markham wrote: > >What I would like to see is the reduction of hardwired strings which are > >inserted as comment like 'This bug has been marked as duplicate of ...' > >etc. I would prefer to have those in a different form in the database > >than as comment. This allows for (a) localization of the output string > >and (b) such texts could be put into e.g. in a box and thus made be more > >visible. > Indeed. All such text should be in templates. The actual example you > give should probably go away, in favour of displaying the dupe number > next to the resolution. Well, at least in one direction it works: 'Solution: DUPLICATE of bug xxx', but it would be nice to have a list: 'Bugs marked as duplicate: ... (show buglist)'. But for the bug which is marked as duplicate, a box containing [ This bug has been marked a duplicate of bug xxx (current title) ] followed by the comments why, or having such a box for attachments would still be nice. > >>Less hardcoding - customised statuses/resolutions, easier to add > >>customised fields. > >The problem with those strings is how this can be localized best. > We probably want to be using numbers internally for each status and > resolution, and translating them to strings at display time: > [% status_descs.$status %] Hmm, if we manage to get this working well and easily maintainable with custom resultions/status, why not. Tobias From myk at mozilla.org Fri Jan 23 13:40:43 2004 From: myk at mozilla.org (Myk Melez) Date: Fri, 23 Jan 2004 05:40:43 -0800 Subject: Directions In Architectural Redesign In-Reply-To: <40111ED7.2090801@mozilla.org> References: <1074859520.5902.29.camel@megagerbil> <20040123124930.GA18517@physik.fu-berlin.de> <40111ED7.2090801@mozilla.org> Message-ID: <4011245B.3060201@mozilla.org> Gervase Markham wrote: > We probably want to be using numbers internally for each status and > resolution, and translating them to strings at display time: > > [% status_descs.$status %] We may instead want to use unique strings, which can still be translated to other strings at display time but make more sense to developers (i.e. the equivalent of entities when used for localization in Mozilla). They also serve as a fallback when a localized string is unavailable. -myk From myk at mozilla.org Fri Jan 23 14:10:27 2004 From: myk at mozilla.org (Myk Melez) Date: Fri, 23 Jan 2004 06:10:27 -0800 Subject: bugzilla.mozilla.org upgrade this Sunday, January 25 at noon PST (UTC-08:00) Message-ID: <40112B53.5080303@mozilla.org> This Sunday, January 25 at noon PST (UTC-08:00) we will be upgrading bugzilla.mozilla.org (b.m.o) to a newer version of Bugzilla. b.m.o will be unavailable for up to several hours while we perform the upgrade. The newer version comes with a number of enhancements, including relevance-ranked summary and comment searches; flexible charts based on configurable data sets; and contextual patch viewing and comparison. For more information about enhancements and bug fixes, see the following Bugzilla status updates: http://www.bugzilla.org/status_updates/2003-04-24.html http://www.bugzilla.org/status_updates/2003-11-02.html As with all upgrades, this one also brings with it the possibility of regressions, data loss, and other problems. If after the upgrade you notice a severe problem with b.m.o that requires immediate attention (data loss, security vulnerability, etc.), please contact us immediately by email to sysadmins at mozilla.org. For all other regressions, file a bug and make it block the regressions meta-bug: http://bugzilla.mozilla.org/show_bug.cgi?id=bmo-regressions For additional information about the upgrade, see the upgrade bug: http://bugzilla.mozilla.org/show_bug.cgi?id=bmo-upgrade To test the newer version of Bugzilla with a copy of the b.m.o data, visit the following test installation: http://mecha.mozilla.org/bzupgrade/ Note that the data in this installation is not the same as the data currently on b.m.o. It is a copy of the b.m.o data that was made on Friday, January 23 at around 2:00AM PST. We may synchronize this copy with the original periodically before the upgrade, but it is not a 100% accurate representation of the data on b.m.o and should not be relied upon. Note also that changes to this database will not change the original data on b.m.o and will not send bug mail, so feel free to test the newer version by making changes to bugs in it. Report any regressions using the instructions above. To watch the progress of the upgrade on Sunday, join the #bmo channel on the irc.mozilla.org IRC server. -myk -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerv at mozilla.org Fri Jan 23 15:00:52 2004 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 23 Jan 2004 15:00:52 +0000 Subject: Directions In Architectural Redesign In-Reply-To: <4011245B.3060201@mozilla.org> References: <1074859520.5902.29.camel@megagerbil> <20040123124930.GA18517@physik.fu-berlin.de> <40111ED7.2090801@mozilla.org> <4011245B.3060201@mozilla.org> Message-ID: <40113724.1010906@mozilla.org> Myk Melez wrote: > We may instead want to use unique strings, which can still be translated > to other strings at display time but make more sense to developers (i.e. > the equivalent of entities when used for localization in Mozilla). We could do that. I opted for numbers in the emailprefs rewrite. Do you think strings would have been a better choice? (This can still change, of course.) > They > also serve as a fallback when a localized string is unavailable. Generally, our localisations are all-or-nothing, aren't they? Gerv From jth at mikrobitti.fi Fri Jan 23 15:09:00 2004 From: jth at mikrobitti.fi (Jouni Heikniemi) Date: Fri, 23 Jan 2004 17:09:00 +0200 Subject: Directions In Architectural Redesign In-Reply-To: <40113724.1010906@mozilla.org> References: <4011245B.3060201@mozilla.org> <1074859520.5902.29.camel@megagerbil> <20040123124930.GA18517@physik.fu-berlin.de> <40111ED7.2090801@mozilla.org> <4011245B.3060201@mozilla.org> Message-ID: <5.1.0.14.2.20040123170617.0517edf0@mikrobitti.fi> At 15:00 23.1.2004 +0000, you wrote: >>They also serve as a fallback when a localized string is unavailable. >Generally, our localisations are all-or-nothing, aren't they? Yes, but it's extremely hard to patch up an existing localization (after a new Bugzilla release, for example) - or create a new one - unless you can do it bit by bit, translating one string to whateverlanguage, spotting another English phrase, translating it and so on. Of course, fallback strings aren't the only way to achieve this, but they are one good approach. Jouni From mkanat at kerio.com Fri Jan 23 20:01:48 2004 From: mkanat at kerio.com (Maxwell Kanat-Alexander) Date: Fri, 23 Jan 2004 12:01:48 -0800 Subject: Directions In Architectural Redesign In-Reply-To: <4011245B.3060201@mozilla.org> References: <1074859520.5902.29.camel@megagerbil> <20040123124930.GA18517@physik.fu-berlin.de> <40111ED7.2090801@mozilla.org> <4011245B.3060201@mozilla.org> Message-ID: <1074888107.5261.11.camel@localhost.localdomain> On Fri, 2004-01-23 at 05:40, Myk Melez wrote: > We may instead want to use unique strings, which can still be translated > to other strings at display time but make more sense to developers (i.e. > the equivalent of entities when used for localization in Mozilla). They > also serve as a fallback when a localized string is unavailable. I think it would be better to use numbers for the statuses, but also provide a default string for each status. The system that displayed the statuses would understand that there was a default. It's generally easier to deal with numbers as enumerations than strings. -Max -- Maxwell Kanat-Alexander 2nd Level Tech Support Engineer, USA Kerio Technologies, Inc. 2041 Mission College Blvd. Suite 100 Santa Clara, CA 95054 Phone: (408) 496-4500 x23 Fax: (408) 496-6902 Web: http://www.kerio.com/support.html From suson at TuckerEnergy.com Fri Jan 23 20:23:04 2004 From: suson at TuckerEnergy.com (Steven Suson) Date: Fri, 23 Jan 2004 14:23:04 -0600 Subject: 2.16.5/2.17.7 release prep In-Reply-To: References: Message-ID: <401182A8.9010308@TuckerEnergy.com> Greetings, What is the status of Custom Fields (`a la the previously available Custom Fields patch)? Will this be making it into a Stable or Development version soon? For the record, it certainly gets my vote! ;-) TIA, Steven Suson David Miller wrote: >We're planning a developer's release (2.17.7) for Monday, December 19. >Anyone who has contributed anything new since 2.17.5 that hasn't yet been >documented, let's please get some documentation contributed. :) (That's 4 >days from now, for those that don't have their calendar handy). > >For those of you that are now helping with the docs, this weekend would be >a REALLY good time to get some of the existing pending documentation bugs >cleaned up and checked in. :) > >We also need to do a 2.16.5 release, which would be nice to do at the same >time, but won't necessarily happen if the bugs aren't checked in by then. >No security updates planned this time, but there are other bugs to fix. >You can look for bugs with 2.16.5 on the status whiteboard (any bugs, not >just open ones - status whiteboard also says whether it's fixed on the >branch or not, so having the status whiteboard in your column list will >help). Please help if you can. :) (there aren't many - I count 5 not >counting docs) > > From gerv at mozilla.org Fri Jan 23 20:54:15 2004 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 23 Jan 2004 20:54:15 +0000 Subject: 2.16.5/2.17.7 release prep In-Reply-To: <401182A8.9010308@TuckerEnergy.com> References: <401182A8.9010308@TuckerEnergy.com> Message-ID: <401189F7.9030406@mozilla.org> Steven Suson wrote: > What is the status of Custom Fields (`a la the previously available > Custom Fields patch)? Will this be making it into a Stable or > Development version soon? For the record, it certainly gets my vote! ;-) It still has the same status - as an unofficial patch. Concerns have been raised about its architecture; it's quite possible than any custom fields function Bugzilla acquires in the future will work quite differently. No-one is working on custom fields as far as I know. Gerv From JWilmoth at starbucks.com Fri Jan 23 21:18:22 2004 From: JWilmoth at starbucks.com (Jon Wilmoth) Date: Fri, 23 Jan 2004 13:18:22 -0800 Subject: 2.16.5/2.17.7 release prep Message-ID: <72AB874F99785949A2898773AEDB5ED8B9330A@seams043.starbucks.net> >From what I know, there have been two different custom field patches. The second one contributed by Sean McAfee [etzwane at schwag.org] seemed to have approval from the powers that be. Has that effort stalled? -----Original Message----- From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] On Behalf Of Gervase Markham Sent: Friday, January 23, 2004 12:54 PM To: developers at bugzilla.org Subject: Re: 2.16.5/2.17.7 release prep Steven Suson wrote: > What is the status of Custom Fields (`a la the previously available > Custom Fields patch)? Will this be making it into a Stable or > Development version soon? For the record, it certainly gets my vote! ;-) It still has the same status - as an unofficial patch. Concerns have been raised about its architecture; it's quite possible than any custom fields function Bugzilla acquires in the future will work quite differently. No-one is working on custom fields as far as I know. Gerv - To view or change your list settings, click here: From gerv at mozilla.org Fri Jan 23 22:39:58 2004 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 23 Jan 2004 22:39:58 +0000 Subject: Directions In Architectural Redesign In-Reply-To: <1074859520.5902.29.camel@megagerbil> References: <1074859520.5902.29.camel@megagerbil> Message-ID: <4011A2BE.3030601@mozilla.org> MattyT wrote: > Just thought I'd make a quick list where we are probably (possibly?) > looking at going architecture wise. It's not complete, but it might > interest some people. > > Email Templatisation, maybe accompanied by notification redesign (bulk > changes?) Actually, full templatisation is a goal - at least, for Tobias and me, if not anyone else :-) But user-facing templatisation is a sub goal, which is blocked on email templatisation, which is (effectively) blocked on bug 84876. > automate checksetup.pl (required additions and deletions get > autodetected). I'm not convinced this is feasible, because things often require migration code as well as simple field adds and deletes. But I'm willing to wait to have the discussion until I see a patch. :-) Gerv From mattyt-spam at tpg.com.au Sat Jan 24 05:44:57 2004 From: mattyt-spam at tpg.com.au (MattyT) Date: Sat, 24 Jan 2004 16:14:57 +1030 Subject: The Future Of Resolutions Message-ID: <1074923096.1830.16.camel@megagerbil> I'm still looking at getting customised resolutions in early in the 2.19 cycle, so I thought I'd solicit feedback on the new resolution set. Existing installations should have their resolution sets maintained (even if they've changed the hardcoding), but new installations will receive an updated set to reflect years of Bugzilla experience. Without further ado, the following is my current plan: FIXED A fix for this bug is checked into the tree and tested. WORKSNOW The problem was reproduced, but seems to have disappeared by changes not made on this bug. INVALID This is not a proper report. FEATURENOTBUG This is not a bug, it's a feature. NOTWORTHIT It should be fixed in a perfect world, but this isn't a perfect world, so it won't be. (probably should be deleted by OSS) DUPLICATE The problem is a duplicate of an existing bug. WORKSFORME All attempts at reproducing this bug were futile, reading the code produces no clues as to why this behavior would occur. MOVED The bug has been moved to another Bugzilla installation. MISSING When a bug report can't be dealt with because an external resource (eg a page at a URL) is missing. (NOINFO maybe, after sitting in NEEDINFO status) CAREFACTORZERO When the person responsible really just does not care. MUPPET The reporter is a muppet. In particular, WONTFIX, REMIND and LATER are gone, and good riddance. -- Matthew Tuck: Software Developer & All-Round Nice Guy My Short Autobiography: 1985 Grade Bin Monitor 1990 Class Clown Award 1992 Awarded Most Likely To Spontaneously Combust 1996 Crowned Galactic Emperor 1998 Released From Smith Psychiatric Hospital From mattyt-spam at tpg.com.au Sat Jan 24 05:56:46 2004 From: mattyt-spam at tpg.com.au (MattyT) Date: Sat, 24 Jan 2004 16:26:46 +1030 Subject: Directions In Architectural Redesign In-Reply-To: <20040123124930.GA18517@physik.fu-berlin.de> References: <1074859520.5902.29.camel@megagerbil> <20040123124930.GA18517@physik.fu-berlin.de> Message-ID: <1074923805.1816.25.camel@megagerbil> On Fri, 2004-01-23 at 23:19, Tobias Burnus wrote: > What I would like to see is the reduction of hardwired strings which are > inserted as comment like 'This bug has been marked as duplicate of ...' > etc. I would prefer to have those in a different form in the database > than as comment. This allows for (a) localization of the output string > and (b) such texts could be put into e.g. in a box and thus made be more > visible. Definitely, this is already stored in the bugs activity table so it's probably just a matter of extracting from there and deleting these comments. > > Less hardcoding - customised statuses/resolutions, easier to add > > customised fields. > The problem with those strings is how this can be localized best. This is definitely an issue, but not unique to statuses and resolutions. This I believe is a "configuration", and not a "customisation" issue, and not really appropriate for doing in templates. The difference here is configuration is normal, customisation isn't. Sure, it's fine to hack this in templates, but it shouldn't be the solution long term. Administrators need to be able to edit the field values of products, severities and resolutions through the administration interface, and then having to go into the templates isn't an appropriate solution for such a common action. As best as I can tell, the only real solution is to put this information into the database and let the administration system edit it. A separate table for names against language is one solution. Alternatively, we might try packing the name field. -- Matthew Tuck: Software Developer & All-Round Nice Guy My Short Autobiography: 1985 Grade Bin Monitor 1990 Class Clown Award 1992 Awarded Most Likely To Spontaneously Combust 1996 Crowned Galactic Emperor 1998 Released From Smith Psychiatric Hospital From mattyt-spam at tpg.com.au Sat Jan 24 06:16:34 2004 From: mattyt-spam at tpg.com.au (MattyT) Date: Sat, 24 Jan 2004 16:46:34 +1030 Subject: Bug Activity Type Message-ID: <1074924994.1830.35.camel@megagerbil> I think it would be good for us to have a "bug activity" type field on the activity table. Here are some examples: Normal - Normal bug change. Bulk - Change made to one or more bugs. Rename - Change made by the administrator renaming a field value. PopVote - Confirmation (status change) made by automatically popular vote. DepWake - When we have an ASLEEP (waiting for deps) status, this would indicate an automatic waking (status change) on all deps fixed. Unknown - Backward compatibility. Firstly that might help people realise why something happened (ie how did that guy without editbugs change the status? - it was PopVote). Also, it might be useful for filtering, either in the UI or notifications (server or client side). It could also help us for debugging later - when we see a suspicious change we can get a better idea where it can from. -- Matthew Tuck: Software Developer & All-Round Nice Guy My Short Autobiography: 1985 Grade Bin Monitor 1990 Class Clown Award 1992 Awarded Most Likely To Spontaneously Combust 1996 Crowned Galactic Emperor 1998 Released From Smith Psychiatric Hospital From gerv at mozilla.org Sat Jan 24 09:08:38 2004 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 24 Jan 2004 09:08:38 +0000 Subject: Directions In Architectural Redesign In-Reply-To: <1074923805.1816.25.camel@megagerbil> References: <1074859520.5902.29.camel@megagerbil> <20040123124930.GA18517@physik.fu-berlin.de> <1074923805.1816.25.camel@megagerbil> Message-ID: <40123616.4080507@mozilla.org> MattyT wrote: > As best as I can tell, the only real solution is to put this information > into the database and let the administration system edit it. A separate > table for names against language is one solution. Alternatively, we > might try packing the name field. I'm sure we've had this discussion before, either on this list or in a bug. But I'm summarise my points again :-) One of the very good things about our current localisation architecture is that installing new localisations is very simple. You drop a set of templates into template//, add the value to the param list, and you are off to the races. Whatever solution we come up with needs to preserve this. We can't put translations in the database. However, I can see your point that, in the usual case of a single language, the admin does not want to edit templates when he adds or removed customised whatevers (hereafter known as "thingys"). How about this: When you define a new thingy, you give it a name. This is a string, e.g. WORKSFORME. The thingy can be translated in templates via an override: [% thingy_descriptions.thingy || thingy %] The default Bugzilla thingys are well-known, and translations for them (and perhaps a few common alternatives) will ship in translation packs. If you add a new thingy, and are only using one language, you just make the name of the thingy the name that you want displayed. However, if you add a new thingy, _and_ are using multiple languages, you need to translate that thingy and add it to the description list; otherwise, when using any language for which you haven't done a translation, you'll get the bare name displayed. Gerv From gerv at mozilla.org Sat Jan 24 09:10:51 2004 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 24 Jan 2004 09:10:51 +0000 Subject: Bug Activity Type In-Reply-To: <1074924994.1830.35.camel@megagerbil> References: <1074924994.1830.35.camel@megagerbil> Message-ID: <4012369B.1020604@mozilla.org> MattyT wrote: > Normal - Normal bug change. > Bulk - Change made to one or more bugs. > Rename - Change made by the administrator renaming a field value. > PopVote - Confirmation (status change) made by automatically popular > vote. In my view, this feature sucks rocks, and is a maintenance hassle. The number of bugs which have ever taken advantage of it can be counted on the fingers of one hand. I say we remove it entirely. Having said that, I don't see great value in this idea generally - but I'm not going to stop someone else coding it :-) Gerv From gerv at mozilla.org Sat Jan 24 09:20:29 2004 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 24 Jan 2004 09:20:29 +0000 Subject: The Future Of Resolutions In-Reply-To: <1074923096.1830.16.camel@megagerbil> References: <1074923096.1830.16.camel@megagerbil> Message-ID: <401238DD.5050507@mozilla.org> MattyT wrote: > I'm still looking at getting customised resolutions in early in the 2.19 > cycle, so I thought I'd solicit feedback on the new resolution set. Again, I'm sure you've solicited it before :-) > Without further ado, the following is my current plan: > > FIXED A fix for this bug is checked into the tree and tested. > WORKSNOW The problem was reproduced, but seems to have disappeared by > changes not made on this bug. Is the semantic difference between this and WORKSFORME great enough to justify having two resolutions? I think it's important that we keep the default set as small as practicable; the more there are, the more people will be scared of choosing the wrong one. > INVALID This is not a proper report. > FEATURENOTBUG This is not a bug, it's a feature. I'd just call this "FEATURE". After all, "it's not a bug, it's a feature" is a well-known phrase. So let's call it that. > NOTWORTHIT It should be fixed in a perfect world, but this isn't a > perfect world, so it won't be. (probably should be deleted by OSS) In what way is this different to the WONTFIX that you hate so much? ;-) In my view the default Bugzilla settings should encourage good development practice; and I think that good development practice doesn't resolve bugs like this. We learnt that with REMIND, LATER etc. I say we ditch this one. > DUPLICATE The problem is a duplicate of an existing bug. > WORKSFORME All attempts at reproducing this bug were futile, reading the > code produces no clues as to why this behavior would occur. > MOVED The bug has been moved to another Bugzilla installation. > MISSING When a bug report can't be dealt with because an external > resource (eg a page at a URL) is missing. (NOINFO maybe, after sitting > in NEEDINFO status) I'd prefer NOINFO - "this bug cannot be dealt with due to missing and unobtainable information." MISSING on its own isn't very descriptive. "What's missing?" MISSINGINFO might be OK. > CAREFACTORZERO When the person responsible really just does not care. Then someone else should be made responsible. Again, this is not a _resolution_. I also think that, unlike some of the other choices, many non-Americans will have trouble understanding this one. > MUPPET The reporter is a muppet. Ha ha :-) So I'd go for (in the default set; remember, people can always add more, and we could maintain a page of suggestions): FIXED WORKSFORME - the problem is no longer reproducible. FEATURE - the "problem" is meant to be that way. INVALID - the "problem" was never a problem in the first place. NOINFO - diagnosing the problem requires missing and unobtainable info. DUPLICATE MOVED Gerv From mattyt-spam at tpg.com.au Sat Jan 24 10:41:25 2004 From: mattyt-spam at tpg.com.au (MattyT) Date: Sat, 24 Jan 2004 21:11:25 +1030 Subject: The Future Of Resolutions In-Reply-To: <401238DD.5050507@mozilla.org> References: <1074923096.1830.16.camel@megagerbil> <401238DD.5050507@mozilla.org> Message-ID: <1074940884.7777.15.camel@megagerbil> On Sat, 2004-01-24 at 19:50, Gervase Markham wrote: > Is the semantic difference between this and WORKSFORME great enough to > justify having two resolutions? I think it's important that we keep the > default set as small as practicable; the more there are, the more people > will be scared of choosing the wrong one. Anyone qualified to resolve bugs is qualified to make these simple distinctions. The point is to make the set easier to use, not only for the resolver, but also for everyone else involved in the bug report, and anyone who wants to gather proper statistics later. It is far closer to FIXED than WORKSFORME, since NOWWORKS is a "successful" resolution, whereas WORKSFORME is an "unsuccessful" one. WORKSFORME is entirely the wrong resolution here, and part of the reason for introducing this is to avoid people misusing it. WORKSFORME is only for stuff that could never be reproduced, and I'm thinking of trying to get it prohibited for confirmed bugs. > I'd just call this "FEATURE". After all, "it's not a bug, it's a > feature" is a well-known phrase. So let's call it that. That should be fine. > > NOTWORTHIT It should be fixed in a perfect world, but this isn't a > > perfect world, so it won't be. (probably should be deleted by OSS) > In what way is this different to the WONTFIX that you hate so much? ;-) WONTFIX is bad because it is ambiguous and as such has overloaded meanings. Why won't you fix it? In particular, WONTFIX is currently used for NOTWORTHIT and FEATURE on various systems. Splitting these off makes the reason clearer. > In my view the default Bugzilla settings should encourage good > development practice; and I think that good development practice doesn't > resolve bugs like this. We learnt that with REMIND, LATER etc. I say we > ditch this one. It's there for closed projects where there are a closed set of contributors under the control of a central entity, where such decisions can be made. Clearly this is a large demographic for Bugzilla. I never suggested this should be used for OSS projects, quite the opposite. My initial intention with this was to demonstrate possibilities to administrators rather than the final product, similar to the way we do TestProduct etc. However in this case you're probably right in that administrators may well tend to stick with what they have, unlike TestProduct. So it might be worth leaving NOTWORTHIT as a suggestion for closed projects in the Bugzilla Guide. > I'd prefer NOINFO - "this bug cannot be dealt with due to missing and > unobtainable information." MISSING on its own isn't very descriptive. > "What's missing?" MISSINGINFO might be OK. Part of the concern is making it look nice (and descriptive if possible) using the first four letters that appear on the bug list. > Then someone else should be made responsible. Again, this is not a > _resolution_. I also think that, unlike some of the other choices, many > non-Americans will have trouble understanding this one. This is a joke. -- Matthew Tuck: Software Developer & All-Round Nice Guy My Short Autobiography: 1985 Grade Bin Monitor 1990 Class Clown Award 1992 Awarded Most Likely To Spontaneously Combust 1996 Crowned Galactic Emperor 1998 Released From Smith Psychiatric Hospital From mattyt-spam at tpg.com.au Sat Jan 24 11:12:27 2004 From: mattyt-spam at tpg.com.au (MattyT) Date: Sat, 24 Jan 2004 21:42:27 +1030 Subject: Directions In Architectural Redesign In-Reply-To: <40123616.4080507@mozilla.org> References: <1074859520.5902.29.camel@megagerbil> <20040123124930.GA18517@physik.fu-berlin.de> <1074923805.1816.25.camel@megagerbil> <40123616.4080507@mozilla.org> Message-ID: <1074942746.7771.28.camel@megagerbil> On Sat, 2004-01-24 at 19:38, Gervase Markham wrote: > One of the very good things about our current localisation architecture > is that installing new localisations is very simple. You drop a set of > templates into template//, add the value to the param list, > and you are off to the races. Whatever solution we come up with needs to > preserve this. We can't put translations in the database. I'm not asking for translations in the database. Values are configurable and we have no expectation that they will stay the same. The rule should be very simple, code went to the template, database stays in the database. Translations are *NOT* going to be able to deal with this issue. Either way new values aren't going to be translated by default. We can either make the administrator deal with the administrator interface, or the administrator interface AND template modification. > However, I can see your point that, in the usual case of a single > language, the admin does not want to edit templates when he adds or > removed customised whatevers (hereafter known as "thingys"). Nor in the multi-language case. Given we already have good (soon to be) complete translations that provide all the administrator may well ever want, the administrator will likely want to avoid the templates if they otherwise provide the needed functionality. > When you define a new thingy, you give it a name. This is a string, e.g. > WORKSFORME. The thingy can be translated in templates via an override: > > [% thingy_descriptions.thingy || thingy %] How is this different from what you're proposing in the first place? It's not symmetric and it's not clean or easy for the administrator. > The default Bugzilla thingys are well-known, and translations for them > (and perhaps a few common alternatives) will ship in translation packs. This is NOT just a resolutions issue. It is also an issue for products, components, keywords and so on. Translations are not going to be able to deal with this issue. -- Matthew Tuck: Software Developer & All-Round Nice Guy My Short Autobiography: 1985 Grade Bin Monitor 1990 Class Clown Award 1992 Awarded Most Likely To Spontaneously Combust 1996 Crowned Galactic Emperor 1998 Released From Smith Psychiatric Hospital From justdave at bugzilla.org Sat Jan 24 19:30:53 2004 From: justdave at bugzilla.org (David Miller) Date: Sat, 24 Jan 2004 14:30:53 -0500 Subject: The Future Of Resolutions In-Reply-To: <401238DD.5050507@mozilla.org> References: <1074923096.1830.16.camel@megagerbil> <401238DD.5050507@mozilla.org> Message-ID: On 1/24/2004 9:20 AM +0000, Gervase Markham wrote: >> CAREFACTORZERO When the person responsible really just does not care. > > Then someone else should be made responsible. Again, this is not a > _resolution_. I also think that, unlike some of the other choices, many > non-Americans will have trouble understanding this one. That's amusing, coming from a Brit and an Aussie. ;) But to broaden that a bit, yes, people whose native language isn't English will probably have trouble understanding that. :) -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From gerv at mozilla.org Sat Jan 24 20:21:48 2004 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 24 Jan 2004 20:21:48 +0000 Subject: Large Documentation Update Message-ID: <4012D3DC.6030207@mozilla.org> I've just checked in a massive rearrangement of the Installation section, the product of the lion's share of my Saturday :-) It should now be a lot easier to understand and shorter. However, I've undoubtedly thrown out the odd baby with the bathwater, so it would be great if people could look it over and see if there are any obvious omissions. Amusingly, this big bit of work has had almost no effect on the approximate documentation ToDo list, which remains: User: - Request Tracker - Wildcard matching - Autolinkification page - New reporting and charting - Full text search - JS-powered comment reply - Alternative formats of various templates, e.g. CSV, JS, RDF Admin: - Time tracking - Insiders - requirelogin - Groups Cust: - Term customisation Contrib: - The email interface If you wrote any of these features, please sign up to document them :-) Gerv From JWilmoth at starbucks.com Sun Jan 25 18:21:37 2004 From: JWilmoth at starbucks.com (Jon Wilmoth) Date: Sun, 25 Jan 2004 10:21:37 -0800 Subject: Directions In Architectural Redesign Message-ID: <72AB874F99785949A2898773AEDB5ED8DCBCFE@seams043.starbucks.net> Isn't this notion already present in the "terms" template? -----Original Message----- From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] On Behalf Of Gervase Markham Sent: Saturday, January 24, 2004 1:09 AM To: developers at bugzilla.org Subject: Re: Directions In Architectural Redesign MattyT wrote: > As best as I can tell, the only real solution is to put this information > into the database and let the administration system edit it. A separate > table for names against language is one solution. Alternatively, we > might try packing the name field. I'm sure we've had this discussion before, either on this list or in a bug. But I'm summarise my points again :-) One of the very good things about our current localisation architecture is that installing new localisations is very simple. You drop a set of templates into template//, add the value to the param list, and you are off to the races. Whatever solution we come up with needs to preserve this. We can't put translations in the database. However, I can see your point that, in the usual case of a single language, the admin does not want to edit templates when he adds or removed customised whatevers (hereafter known as "thingys"). How about this: When you define a new thingy, you give it a name. This is a string, e.g. WORKSFORME. The thingy can be translated in templates via an override: [% thingy_descriptions.thingy || thingy %] The default Bugzilla thingys are well-known, and translations for them (and perhaps a few common alternatives) will ship in translation packs. If you add a new thingy, and are only using one language, you just make the name of the thingy the name that you want displayed. However, if you add a new thingy, _and_ are using multiple languages, you need to translate that thingy and add it to the description list; otherwise, when using any language for which you haven't done a translation, you'll get the bare name displayed. Gerv - To view or change your list settings, click here: From gerv at mozilla.org Sun Jan 25 22:09:41 2004 From: gerv at mozilla.org (Gervase Markham) Date: Sun, 25 Jan 2004 22:09:41 +0000 Subject: Directions In Architectural Redesign In-Reply-To: <72AB874F99785949A2898773AEDB5ED8DCBCFE@seams043.starbucks.net> References: <72AB874F99785949A2898773AEDB5ED8DCBCFE@seams043.starbucks.net> Message-ID: <40143EA5.6080601@mozilla.org> Jon Wilmoth wrote: > Isn't this notion already present in the "terms" template? Somewhat; "terms" is about renaming bugs rather than translation. It's a similar idea, though. What is closer is the translation arrays we've got... somewhere. I can't find them at the moment. Gerv From louie at ximian.com Mon Jan 26 03:12:25 2004 From: louie at ximian.com (Luis Villa) Date: Sun, 25 Jan 2004 22:12:25 -0500 Subject: The Future Of Resolutions In-Reply-To: <401238DD.5050507@mozilla.org> References: <1074923096.1830.16.camel@megagerbil> <401238DD.5050507@mozilla.org> Message-ID: <1075086744.4932.29.camel@localhost.localdomain> On Sat, 2004-01-24 at 04:20, Gervase Markham wrote: > > INVALID This is not a proper report. > > FEATURENOTBUG This is not a bug, it's a feature. > > I'd just call this "FEATURE". After all, "it's not a bug, it's a > feature" is a well-known phrase. So let's call it that. FWIW, b.g.o uses 'NOTABUG' for this and it seems to convey the necessary information clearly both to developers and to newbie-types who may not be as clear on the idea. Luis From preed at sigkill.com Mon Jan 26 08:07:18 2004 From: preed at sigkill.com (J. Paul Reed) Date: Mon, 26 Jan 2004 00:07:18 -0800 Subject: Interesting development Message-ID: <20040126080718.GA2789@sigkill.com> Some of you may have heard of Joel Spolsky of Joel-on-Software fame. One of his company's main products, FobBUGZ, could losely be called a competitor of Bugzilla's, except it runs solely on Windows and I don't think it does as much as Bugzilla does (which I think Joel considers a feature; see http://www.joelonsoftware.com/news/20020912.html). Well, that has all recently changed: his company recently released FogBUGZ for Linux and OS X. Looks like it runs on Apache, MySQL 4, and... PHP. Later, Paul ------------------------------------------------------------------------ J. Paul Reed -- 0xDF8708F8 || preed at sigkill.com || web.sigkill.com/preed Math, my dear boy, is nothing more than the lesbian sister of biology. -- Peter Griffin, Family Guy I use PGP; you should use PGP too... if only to piss off John Ashcroft From timeless at myrealbox.com Mon Jan 26 09:10:35 2004 From: timeless at myrealbox.com (timeless) Date: Mon, 26 Jan 2004 01:10:35 -0800 Subject: The Future Of Resolutions In-Reply-To: <1074923096.1830.16.camel@megagerbil> References: <1074923096.1830.16.camel@megagerbil> Message-ID: <4014D98B.1070103@myrealbox.com> MattyT wrote: > I'm still looking at getting customised resolutions in early in the 2.19 > cycle, so I thought I'd solicit feedback on the new resolution set. > > Existing installations should have their resolution sets maintained > (even if they've changed the hardcoding), but new installations will > receive an updated set to reflect years of Bugzilla experience. > > Without further ado, the following is my current plan: > > FIXED A fix for this bug is checked into the tree and tested. > WORKSNOW The problem was reproduced, but seems to have disappeared by > changes not made on this bug. > INVALID This is not a proper report. > FEATURENOTBUG This is not a bug, it's a feature. > NOTWORTHIT It should be fixed in a perfect world, but this isn't a > perfect world, so it won't be. (probably should be deleted by OSS) > DUPLICATE The problem is a duplicate of an existing bug. > WORKSFORME All attempts at reproducing this bug were futile, reading the > code produces no clues as to why this behavior would occur. > MOVED The bug has been moved to another Bugzilla installation. > MISSING When a bug report can't be dealt with because an external > resource (eg a page at a URL) is missing. (NOINFO maybe, after sitting > in NEEDINFO status) > CAREFACTORZERO When the person responsible really just does not care. > MUPPET The reporter is a muppet. > > In particular, WONTFIX, REMIND and LATER are gone, and good riddance. I've wanted: CANTFIX - the problem indeed exists but can not be fixed by changes to the codebase DONTFIX - the report was proper, but the module owner has indicated that the request should not be fixed/implemented wrt MISSING, I'd rather that be a status instead of a resolution Status: Needs "Resolution": Info|Testcase|Patch|Translation|... From myk at mozilla.org Mon Jan 26 10:11:03 2004 From: myk at mozilla.org (Myk Melez) Date: Mon, 26 Jan 2004 02:11:03 -0800 Subject: The Future Of Resolutions In-Reply-To: <1074923096.1830.16.camel@megagerbil> References: <1074923096.1830.16.camel@megagerbil> Message-ID: <4014E7B7.8020305@mozilla.org> MattyT wrote: >I'm still looking at getting customised resolutions in early in the 2.19 >cycle, so I thought I'd solicit feedback on the new resolution set. > >Existing installations should have their resolution sets maintained >(even if they've changed the hardcoding), but new installations will >receive an updated set to reflect years of Bugzilla experience. > > These changes will be contentious, so to avoid delaying custom resolutions, which lots of existing installations want, I suggest you split your work on updating the defaults into a new bug and do that after custom resolutions goes in. It'll make both patches go in more easily (but particularly custom resolutions). -myk From jth at mikrobitti.fi Mon Jan 26 11:31:04 2004 From: jth at mikrobitti.fi (Jouni Heikniemi) Date: Mon, 26 Jan 2004 13:31:04 +0200 Subject: The Future Of Resolutions In-Reply-To: <1074923096.1830.16.camel@megagerbil> Message-ID: <5.1.0.14.2.20040126131442.069851a0@mikrobitti.fi> At 16:14 24.1.2004 +1030, you wrote: >Without further ado, the following is my current plan: Without an intention to overly criticize, I'd be interested in hearing some thoughts behind these changes. Why are we doing all this? New resolutions add complexity, and we've got plenty of that already. The new choices should IMO lead to a simpler (but more extendable, through custom resolutions) system. Any default selections shouldn't be aimed at a particular type of installation, at least not anything of bmo's caliber. Certainly one can justify something like "MISSING" in an environment where that terminal state for bugs is common, but just as an example, I've never (and I think I really mean it, never) needed that. The difference between WORKSNOW and FIXED is often slim, as neither resolution provides information on "What actually fixed this". For certain kind of statistics this separation might be useful, but it's hardly ever been that for me. In another message, Matty says: >> Is the semantic difference between this and WORKSFORME great enough to >> justify having two resolutions? >Anyone qualified to resolve bugs is qualified to make these simple >distinctions. We cannot make statements like that. There's no way to know what abilities and knowledge people resolving bugs will have. Moreso, the claimed benefits of a fine-grained resolution set mostly revolve around the expectation of Bugzilla users being able to follow them consistently. This is doable, but for most companies, it probably requires an internal - possibly product-specific - policy on what is WORKSNOW and what is FIXED (just as an example). Many benefits of a well-designed resolution system can be lost, if it's too hard to communicate. I'm not claiming the current resolution set is perfect or anything, but this discussion hasn't yet seen a real background discussion. There probably exists one in a bug somewhere, and I'll be glad to read it when you point me at it. Still, I feel any changes to a fundamental (and highly visible) part of Bugzilla concept should start from a loudly stated and openly discussed need: What is wrong with WONTFIX? Why do we need to separate WORKSNOW and FIXED? Is changing the resolution set _really_ the best alternative here? Jouni From tree at basistech.com Mon Jan 26 17:34:47 2004 From: tree at basistech.com (Tom Emerson) Date: Mon, 26 Jan 2004 12:34:47 -0500 Subject: Interesting development In-Reply-To: <20040126080718.GA2789@sigkill.com> References: <20040126080718.GA2789@sigkill.com> Message-ID: <16405.20407.901301.539123@magrathea.basistech.com> J. Paul Reed writes: > Well, that has all recently changed: his company recently released FogBUGZ > for Linux and OS X. [...] Interesting indeed. Looking at his list of '50 new features', it looks like many of them were inspired by features that BZ has had for a (long) while. However, I think this is going to be a major competitor, so we should pay careful attention to it. -tree -- Tom Emerson Basis Technology Corp. Software Architect http://www.basistech.com "Beware the lollipop of mediocrity: lick it once and you suck forever" From john.fisher at znyx.com Mon Jan 26 17:55:35 2004 From: john.fisher at znyx.com (John P. Fisher) Date: Mon, 26 Jan 2004 09:55:35 -0800 Subject: The Future Of Resolutions In-Reply-To: <5.1.0.14.2.20040126131442.069851a0@mikrobitti.fi> References: <1074923096.1830.16.camel@megagerbil> Message-ID: <5.2.0.9.0.20040126094726.038ef328@208.2.156.7> I agree with Jouni. Trying to control workflow with Bugzilla is like building a Space Shuttle - once all the features are installed, its too heavy to fly. Please don't make it more complicated for me to throw away most of these categories: FWIW dept: long ago ( 2.13 ) we customized resolutions to: FIXED REJECTED DEFERRED bugs may also be marked DUPLICATE The descriptive fields are sufficient for the rest of the information. ( we use both found-in and fixed-in versions, and have about 20 developers) -John >Without an intention to overly criticize, I'd be interested in hearing >some thoughts behind these changes. Why are we doing all this? New >resolutions add complexity, and we've got plenty of that already. The new >choices should IMO lead to a simpler (but more extendable, through custom >resolutions) system. Any default selections shouldn't be aimed at a >particular type of installation, at least not anything of bmo's caliber. > >Still, I feel any changes to a fundamental (and highly visible) part of >Bugzilla concept should start from a loudly stated and openly discussed >need: What is wrong with WONTFIX? Why do we need to separate WORKSNOW and >FIXED? Is changing the resolution set _really_ the best alternative here? > > >Jouni John P. Fisher at ZNYX Networks 805 683 1488 x 3245 john.fisher at znyx.com From preed at sigkill.com Mon Jan 26 17:59:47 2004 From: preed at sigkill.com (J. Paul Reed) Date: Mon, 26 Jan 2004 09:59:47 -0800 Subject: Interesting development In-Reply-To: <16405.20407.901301.539123@magrathea.basistech.com> References: <20040126080718.GA2789@sigkill.com> <16405.20407.901301.539123@magrathea.basistech.com> Message-ID: <20040126175947.GA5213@sigkill.com> On 26 Jan 2004 at 12:34:47, Tom Emerson arranged the bits on my disk to say: > However, I think this is going to be a major competitor, so we should pay > careful attention to it. I agree FogBUGZ has the potential to be, if it isn't already. But in this economy especially, one thing his company probably won't be able to compete on is price. Maybe he can write a Joel-on-Software about *that* ;-) Later, Paul ------------------------------------------------------------------------ J. Paul Reed -- 0xDF8708F8 || preed at sigkill.com || web.sigkill.com/preed Math, my dear boy, is nothing more than the lesbian sister of biology. -- Peter Griffin, Family Guy I use PGP; you should use PGP too... if only to piss off John Ashcroft From suson at TuckerEnergy.com Mon Jan 26 18:51:39 2004 From: suson at TuckerEnergy.com (Steven Suson) Date: Mon, 26 Jan 2004 12:51:39 -0600 Subject: 2.16.5/2.17.7 release prep In-Reply-To: <401189F7.9030406@mozilla.org> References: <401182A8.9010308@TuckerEnergy.com> <401189F7.9030406@mozilla.org> Message-ID: <401561BB.8010402@TuckerEnergy.com> That is truly unfortunate, as there is a definite ISO related requirement that this feature would allow my company to fulfill, without ANY code changes to Bugzilla. From a users point of view, this is a natural extension to the Templating subsystem. I truly believe that this is a very powerful AND needed feature for Bugzilla. And this comes from someone who has been using Bugzilla since 2.8... In the meantime, would one of the maintainers of the (one or more) patches shoot me an email to let me know it the patch will be supported for the next stable version of Bugzilla? Thanks, Steve Gervase Markham wrote: > Steven Suson wrote: > >> What is the status of Custom Fields (`a la the previously >> available Custom Fields patch)? Will this be making it into a Stable >> or Development version soon? For the record, it certainly gets my >> vote! ;-) > > > It still has the same status - as an unofficial patch. Concerns have > been raised about its architecture; it's quite possible than any > custom fields function Bugzilla acquires in the future will work quite > differently. > > No-one is working on custom fields as far as I know. > > Gerv > - > To view or change your list settings, click here: > > From suson at TuckerEnergy.com Mon Jan 26 19:23:04 2004 From: suson at TuckerEnergy.com (Steven Suson) Date: Mon, 26 Jan 2004 13:23:04 -0600 Subject: The Future Of Resolutions In-Reply-To: <1074923096.1830.16.camel@megagerbil> References: <1074923096.1830.16.camel@megagerbil> Message-ID: <40156918.2060900@TuckerEnergy.com> I disagree with the removal of WONTFIX (I saw nothing in your list that simply allows the maintainer to say "No.") and LATER (for bugs that we still want to fix, but not now). Steven Suson MattyT wrote: >I'm still looking at getting customised resolutions in early in the 2.19 >cycle, so I thought I'd solicit feedback on the new resolution set. > >Existing installations should have their resolution sets maintained >(even if they've changed the hardcoding), but new installations will >receive an updated set to reflect years of Bugzilla experience. > >Without further ado, the following is my current plan: > >FIXED A fix for this bug is checked into the tree and tested. >WORKSNOW The problem was reproduced, but seems to have disappeared by >changes not made on this bug. >INVALID This is not a proper report. >FEATURENOTBUG This is not a bug, it's a feature. >NOTWORTHIT It should be fixed in a perfect world, but this isn't a >perfect world, so it won't be. (probably should be deleted by OSS) >DUPLICATE The problem is a duplicate of an existing bug. >WORKSFORME All attempts at reproducing this bug were futile, reading the >code produces no clues as to why this behavior would occur. >MOVED The bug has been moved to another Bugzilla installation. >MISSING When a bug report can't be dealt with because an external >resource (eg a page at a URL) is missing. (NOINFO maybe, after sitting >in NEEDINFO status) >CAREFACTORZERO When the person responsible really just does not care. >MUPPET The reporter is a muppet. > >In particular, WONTFIX, REMIND and LATER are gone, and good riddance. > > > From gerv at mozilla.org Mon Jan 26 23:21:40 2004 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 26 Jan 2004 23:21:40 +0000 Subject: The Future Of Resolutions In-Reply-To: <40156918.2060900@TuckerEnergy.com> References: <1074923096.1830.16.camel@megagerbil> <40156918.2060900@TuckerEnergy.com> Message-ID: <4015A104.7090301@mozilla.org> Steven Suson wrote: > I disagree with the removal of WONTFIX (I saw nothing in your list that > simply allows the maintainer to say "No.") and LATER (for bugs that we > still want to fix, but not now). LATER is definitely going. If the situation is "I want to fix this bug later, but not now", then you should change the Target Milestone (to "Future" if necessary), not resolve the bug. This is a discovery based on long experience on b.m.o. If a bug isn't fixed, it should remain open so it can be found with queries. Gerv From justdave at bugzilla.org Tue Jan 27 03:29:29 2004 From: justdave at bugzilla.org (David Miller) Date: Mon, 26 Jan 2004 22:29:29 -0500 Subject: Fwd: Re: Bugzilla Flow of State Transition Message-ID: ----- Begin Forwarded Text ----- Date: Mon, 26 Jan 2004 19:25:09 -0800 (PST) From: "Kash A. Aziz" Subject: Re: Bugzilla Flow of State Transition To: David Miller Dave, thanks for a quik response. I am attaching the file. Do let me know if you have any questions. PS. I did this in visio and then converted in gif format. Let me know if you'd rather have this in other format. Thanks. Kash --- David Miller wrote: > On 1/26/2004 4:57 PM -0800, Kash A. Aziz wrote: > > > Hey Dave, > > I found your name/email on the bugzilla website. > > > > In an attempt to deploy and use bugzilla for my > > program, I tried to look for a flow chart > depiction of > > state transitions that is being used in bugzilla > > release 2.16.4. However, I was unable to find such > a > > reference doc on the net and thus I created a > > flowchart articulating the state transitions. I > would > > like to contribute that flow chart to the bugzilla > > team to perhaps post it to the bugzilla's > > documentation website such that others can > leverage > > from it. > > Again my motivation to create a flow chart was > simply > > to have a graphical depiction of the state > transition > > such that it can be easier for my team of 20 some > > engineers to read, understand and follow. > > If you wish for me to email you the flow chart, do > let > > me know and I would be more than happy to. > > That would be great! We'd appreciate it. > -- > Dave Miller Project Leader, Bugzilla Bug > Tracking System > http://www.justdave.net/ http://www.bugzilla.org/ __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ Content-Type: image/gif; name="Bugzilla v2_16_4 State Flow.gif" Content-Description: Bugzilla v2_16_4 State Flow.gif Content-Disposition: inline; filename="Bugzilla v2_16_4 State Flow.gif" ----- End Forwarded Text ----- -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: Bugzilla_v2_16_4_State_Flow.gif Type: image/gif Size: 30925 bytes Desc: not available URL: From timeless at myrealbox.com Tue Jan 27 06:44:33 2004 From: timeless at myrealbox.com (timeless) Date: Mon, 26 Jan 2004 22:44:33 -0800 Subject: Fwd: Re: Bugzilla Flow of State Transition In-Reply-To: References: Message-ID: <401608D1.3020905@myrealbox.com> David Miller forwarded a from Kash A. Aziz: > I am attaching the file. Do let me know if you have > any questions. > PS. I did this in visio and then converted in gif > format. Let me know if you'd rather have this in other > format. Thanks. Kash 1. It's possible for me to reassign a bug assigned to me to myself. Doing so will transition the bug from ASSIGNED to NEW. I don't consider me/myself/i as '(an)other' resources :). 2. It's possible (even likely?) for a bug to transition from reopened to NEW. I think that there's actually a transition from RESOLVED to UNCONFIRMED, but i'd have to check. 3. (not current), it's possible in the future we might be able to transition from NEW to UNCO as we move bugs across products w/+w/o an unconfirmed state. From gerv at mozilla.org Tue Jan 27 10:10:42 2004 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 27 Jan 2004 10:10:42 +0000 Subject: FogBugz on Unix Message-ID: <40163922.3040401@mozilla.org> This is how they did it: http://www.fogcreek.com/Jobs/SummerIntern.html "Last summer, an intern wrote a complete ASP to PHP compiler, which allowed us to port our flagship product to Unix. He learned Java, ASP, and PHP in one summer and wrote an industrial-strength compiler from beginning to end in two months. Sounds like your kind of job? Apply today! There are two openings for summer 2004." Gerv From dberlin at dberlin.org Tue Jan 27 13:44:53 2004 From: dberlin at dberlin.org (Daniel Berlin) Date: Tue, 27 Jan 2004 08:44:53 -0500 Subject: FogBugz on Unix In-Reply-To: <40163922.3040401@mozilla.org> References: <40163922.3040401@mozilla.org> Message-ID: On Jan 27, 2004, at 5:10 AM, Gervase Markham wrote: > This is how they did it: > > http://www.fogcreek.com/Jobs/SummerIntern.html > "Last summer, an intern wrote a complete ASP to PHP compiler, which > allowed us to port our flagship product to Unix. He learned Java, ASP, > and PHP in one summer and wrote an industrial-strength compiler from > beginning to end in two months. Sounds like your kind of job? Apply > today! There are two openings for summer 2004." > This already existed before they decided to do it. google for asp2php. > From gerv at mozilla.org Tue Jan 27 14:36:38 2004 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 27 Jan 2004 14:36:38 +0000 Subject: FogBugz on Unix In-Reply-To: References: <40163922.3040401@mozilla.org> Message-ID: <40167776.3010603@mozilla.org> >> http://www.fogcreek.com/Jobs/SummerIntern.html >> "Last summer, an intern wrote a complete ASP to PHP compiler, which >> allowed us to port our flagship product to Unix. He learned Java, ASP, >> and PHP in one summer and wrote an industrial-strength compiler from >> beginning to end in two months. Sounds like your kind of job? Apply >> today! There are two openings for summer 2004." > > This already existed before they decided to do it. > google for asp2php. Hmm. Methinks that intern pulled a fast one ;-) Gerv From tree at basistech.com Tue Jan 27 14:40:14 2004 From: tree at basistech.com (Tom Emerson) Date: Tue, 27 Jan 2004 09:40:14 -0500 Subject: FogBugz on Unix In-Reply-To: <40167776.3010603@mozilla.org> References: <40163922.3040401@mozilla.org> <40167776.3010603@mozilla.org> Message-ID: <16406.30798.697504.228757@magrathea.basistech.com> Gervase Markham writes: > >> http://www.fogcreek.com/Jobs/SummerIntern.html > >> "Last summer, an intern wrote a complete ASP to PHP compiler, which > >> allowed us to port our flagship product to Unix. He learned Java, ASP, > >> and PHP in one summer and wrote an industrial-strength compiler from > >> beginning to end in two months. Sounds like your kind of job? Apply > >> today! There are two openings for summer 2004." > > > > This already existed before they decided to do it. > > google for asp2php. > > Hmm. Methinks that intern pulled a fast one ;-) Yeah, no one, especially an intern, has ever reinvented the wheel. -- Tom Emerson Basis Technology Corp. Software Architect http://www.basistech.com "Beware the lollipop of mediocrity: lick it once and you suck forever" From justdave at bugzilla.org Tue Jan 27 21:26:23 2004 From: justdave at bugzilla.org (David Miller) Date: Tue, 27 Jan 2004 16:26:23 -0500 Subject: Fwd: Bugzilla Flow Message-ID: Heh, someone else just sent me one of these the other day, too. The only thing I see missing off this off-hand (which was from the other one, too) is that if a bug goes directly to RESOLVED from UNCONFIRMED, it'll go back to UNCONFIRMED instead of REOPENED if someone reopens it. ----- Begin Forwarded Text ----- From: "Kumar, Arun" To: "'justdave at bugzilla.org'" Cc: "'u_arun at hotmail.com'" Subject: Date: Tue, 27 Jan 2004 16:10:41 -0500 Hi Dave, In the process of documenting our local Bugzilla setup, I came up with a Bug resolution workflow diagram based on http://bugzilla.mozilla.org/bug_status.html Since this is very generic, I thought maybe you'll be interested in including it as part of the standard documentation. I am attaching a JPEG version of the diagram. Let me know if you would prefer any other file format or changes in the diagram itself. And Kudos !! for all the great work on Bugzilla Documentation Regards, Arun ----- End Forwarded Text ----- -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: Bugzilla_Flow.jpg Type: image/jpeg Size: 108996 bytes Desc: not available URL: From justdave at bugzilla.org Wed Jan 28 02:22:40 2004 From: justdave at bugzilla.org (David Miller) Date: Tue, 27 Jan 2004 21:22:40 -0500 Subject: Documentation Message-ID: Reminder: the default assignee for Bugzilla documentation bugs is documentation at bugzilla.org, which is a dummy account on bugzilla.mozilla.org. If you would like to help with docs, please go to your preferences and add that account to your watch list. I'm pretty sure I heard from no less than 3 people who volunteered to help (outside of myself), and there's a total of 3 people watching that account, which includes myself and the ircbot. :) In other news... I'd like to propose completely removing the HTML, Text, and PDF versions of the docs from CVS. Under my plan, the website will automatically build those directories upon pulling changes to the xml directory, and the tarball build script will be changed to build the docs after checking out of cvs prior to rolling the tarball. Reasons for doing this: 1) those directories are already off-limits for direct modifications in cvs anyway, they're required to be generated from the XML before checkin 2) every time they're regenerated, it "modifies" every single file, which results in a HUGE chunk of space in the cvs commit log on bonsai. Cons: 1) If someone checks in an XML change that doesn't validate, it'll likely take out the HTML version of the docs on the website if they don't fix it within 15 minutes. 2) People checking out of cvs who don't have docbook set up won't have the html and text versions of the docs to read. Pros: 1) XML changes would be immediately reflected on the website instead of having to wait for someone to regenerate the HTML and check it in. Any comments? Any other pros/cons to this? Does this sound like a good idea? -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From mkanat at kerio.com Wed Jan 28 05:12:12 2004 From: mkanat at kerio.com (Maxwell Kanat-Alexander) Date: Tue, 27 Jan 2004 21:12:12 -0800 Subject: Documentation In-Reply-To: References: Message-ID: <1075266731.5545.15.camel@max.localdomain> On Tue, 2004-01-27 at 18:22, David Miller wrote: > there's a total of 3 people watching that account, which > includes myself and the ircbot. :) Hahahahaha! I guess that makes me responsible for all that documentation!! Gee, I guess I'd better get on it. :-D -Max -- Maxwell Kanat-Alexander 2nd Level Tech Support Engineer, USA Kerio Technologies, Inc. 2041 Mission College Blvd. Suite 100 Santa Clara, CA 95054 Phone: (408) 496-4500 x23 Fax: (408) 496-6902 Web: http://www.kerio.com/support.html From mkanat at kerio.com Wed Jan 28 05:17:35 2004 From: mkanat at kerio.com (Maxwell Kanat-Alexander) Date: Tue, 27 Jan 2004 21:17:35 -0800 Subject: Documentation In-Reply-To: References: Message-ID: <1075267054.5545.21.camel@max.localdomain> On Tue, 2004-01-27 at 18:22, David Miller wrote: > In other news... > I'd like to propose completely removing the HTML, Text, and PDF versions > of the docs from CVS. Most of the other projects that I know of have been doing this recently, too. > 1) If someone checks in an XML change that doesn't validate, it'll likely > take out the HTML version of the docs on the website if they don't fix it > within 15 minutes. Which honestly, shouldn't be a problem if people are actually testing and reviewing. :-) Also, you could have a script that publishes the CVS-docs to the web and refuses to post a new version if the XML validation fails. > 2) People checking out of cvs who don't have docbook set up won't have the > html and text versions of the docs to read. That would suck, a bit. We should make checksetup note that docbook is optional, and have checksetup do the doc rebuilding, perhaps? I think it sounds like a good idea. It seems simpler, all things considered, than having four different "versions" in CVS of what's essentially the same thing. -Max -- Maxwell Kanat-Alexander 2nd Level Tech Support Engineer, USA Kerio Technologies, Inc. 2041 Mission College Blvd. Suite 100 Santa Clara, CA 95054 Phone: (408) 496-4500 x23 Fax: (408) 496-6902 Web: http://www.kerio.com/support.html From gerv at mozilla.org Wed Jan 28 07:52:53 2004 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 28 Jan 2004 07:52:53 +0000 Subject: Documentation In-Reply-To: References: Message-ID: <40176A55.8060908@mozilla.org> David Miller wrote: > Cons: > 1) If someone checks in an XML change that doesn't validate, it'll likely > take out the HTML version of the docs on the website if they don't fix it > within 15 minutes. I don't see this as a Con; people shouldn't be modifying the docs without rebuilding, just as they shouldn't modify code without building it. > 2) People checking out of cvs who don't have docbook set up won't have the > html and text versions of the docs to read. I'm more concerned about this con. Can we mitigate it? We certainly don't want to require people to set up a docs build environment; it's a real pain. Suggestion: we could get the website build script to also build a documentation tarball (HTML, text and PDF), and checksetup.pl could offer to download and unpack it if there is no documentation present. This would only ever happen on CVS checkouts, as we'd be shipping docs in all the release tarballs anyway. So we wouldn't have problems worrying about version skew. Gerv From gerv at mozilla.org Wed Jan 28 07:56:10 2004 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 28 Jan 2004 07:56:10 +0000 Subject: Fwd: Bugzilla Flow In-Reply-To: References: Message-ID: <40176B1A.9040508@mozilla.org> David Miller wrote: > Heh, someone else just sent me one of these the other day, too. The only > thing I see missing off this off-hand (which was from the other one, too) > is that if a bug goes directly to RESOLVED from UNCONFIRMED, it'll go back > to UNCONFIRMED instead of REOPENED if someone reopens it. One of them should get into the docs, preferably with the raw file and instructions on regeneration. Gerv From jth at mikrobitti.fi Wed Jan 28 07:56:45 2004 From: jth at mikrobitti.fi (Jouni Heikniemi) Date: Wed, 28 Jan 2004 09:56:45 +0200 Subject: Documentation In-Reply-To: <40176A55.8060908@mozilla.org> References: Message-ID: <5.1.0.14.2.20040128095238.05cfccf8@mikrobitti.fi> At 07:52 28.1.2004 +0000, you wrote: >Suggestion: we could get the website build script to also build a >documentation tarball (HTML, text and PDF), and checksetup.pl could offer >to download and unpack it if there is no documentation present. This would >only ever happen on CVS checkouts, as we'd be shipping docs in all the >release tarballs anyway. So we wouldn't have problems worrying about >version skew. I'd be totally happy if a cvs pull contained a short html (or text) file in the docs/html dir that contains the address to the current documentation. A downloadable tarball (or something more easily cross-platform, a .zip perhaps?) is good enough, making checksetup.pl do semi-automatic downloads is pampering the users too much (;-)). Besides, it adds another external dependency and may prove problematic with firewalls. Other than that, I agree. Jouni From Arun.Kumar at mercer.com Wed Jan 28 14:42:10 2004 From: Arun.Kumar at mercer.com (Kumar, Arun) Date: Wed, 28 Jan 2004 09:42:10 -0500 Subject: Bugzilla Flow Message-ID: Hi Dave, I have made the necessary modifications, see if it makes sense now. Thanks, Arun -----Original Message----- From: David Miller [mailto:justdave at bugzilla.org] Sent: Tuesday, January 27, 2004 4:26 PM To: Kumar, Arun Cc: developers at bugzilla.org; 'u_arun at hotmail.com' Subject: Fwd: Bugzilla Flow Heh, someone else just sent me one of these the other day, too. The only thing I see missing off this off-hand (which was from the other one, too) is that if a bug goes directly to RESOLVED from UNCONFIRMED, it'll go back to UNCONFIRMED instead of REOPENED if someone reopens it. ----- Begin Forwarded Text ----- From: "Kumar, Arun" To: "'justdave at bugzilla.org'" Cc: "'u_arun at hotmail.com'" Subject: Date: Tue, 27 Jan 2004 16:10:41 -0500 Hi Dave, In the process of documenting our local Bugzilla setup, I came up with a Bug resolution workflow diagram based on http://bugzilla.mozilla.org/bug_status.html Since this is very generic, I thought maybe you'll be interested in including it as part of the standard documentation. I am attaching a JPEG version of the diagram. Let me know if you would prefer any other file format or changes in the diagram itself. And Kudos !! for all the great work on Bugzilla Documentation Regards, Arun ----- End Forwarded Text ----- -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: Bugzilla_Flow.jpg Type: image/jpeg Size: 122559 bytes Desc: not available URL: From myk at mozilla.org Wed Jan 28 15:15:18 2004 From: myk at mozilla.org (Myk Melez) Date: Wed, 28 Jan 2004 07:15:18 -0800 Subject: Documentation In-Reply-To: <40176A55.8060908@mozilla.org> References: <40176A55.8060908@mozilla.org> Message-ID: <4017D206.8030907@mozilla.org> Gervase Markham wrote: > I'm more concerned about this con. Can we mitigate it? We certainly > don't want to require people to set up a docs build environment; it's > a real pain. I'm not sure how true that is anymore. My Fedora Core 1 installation comes with everything needed except for the LDP stylesheet and three shell variables that could probably be set automatically by the script. Oh, and lynx, which is easily installed. -myk From JWilmoth at starbucks.com Wed Jan 28 16:48:01 2004 From: JWilmoth at starbucks.com (Jon Wilmoth) Date: Wed, 28 Jan 2004 08:48:01 -0800 Subject: Documentation Message-ID: <72AB874F99785949A2898773AEDB5ED8DCBD06@seams043.starbucks.net> As I submitted the first patch for the "customizable terminology" contribution, I'm willing to help with the documentation effort. How should I submit this info? I think the move to the xml definition is great and will lower the barrier to entry for following up code contributions with documentation so others are aware of the functionality and benefit fully from it. I'd also be willing to help develop the xsl stylesheets for at least the HTML and Text versions. I'm not sure PDF can be generated with simple XSL. -----Original Message----- From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] On Behalf Of David Miller Sent: Tuesday, January 27, 2004 6:23 PM To: developers at bugzilla.org Subject: Documentation Reminder: the default assignee for Bugzilla documentation bugs is documentation at bugzilla.org, which is a dummy account on bugzilla.mozilla.org. If you would like to help with docs, please go to your preferences and add that account to your watch list. I'm pretty sure I heard from no less than 3 people who volunteered to help (outside of myself), and there's a total of 3 people watching that account, which includes myself and the ircbot. :) In other news... I'd like to propose completely removing the HTML, Text, and PDF versions of the docs from CVS. Under my plan, the website will automatically build those directories upon pulling changes to the xml directory, and the tarball build script will be changed to build the docs after checking out of cvs prior to rolling the tarball. Reasons for doing this: 1) those directories are already off-limits for direct modifications in cvs anyway, they're required to be generated from the XML before checkin 2) every time they're regenerated, it "modifies" every single file, which results in a HUGE chunk of space in the cvs commit log on bonsai. Cons: 1) If someone checks in an XML change that doesn't validate, it'll likely take out the HTML version of the docs on the website if they don't fix it within 15 minutes. 2) People checking out of cvs who don't have docbook set up won't have the html and text versions of the docs to read. Pros: 1) XML changes would be immediately reflected on the website instead of having to wait for someone to regenerate the HTML and check it in. Any comments? Any other pros/cons to this? Does this sound like a good idea? -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ - To view or change your list settings, click here: From justdave at bugzilla.org Wed Jan 28 16:58:25 2004 From: justdave at bugzilla.org (David Miller) Date: Wed, 28 Jan 2004 11:58:25 -0500 Subject: Documentation In-Reply-To: <72AB874F99785949A2898773AEDB5ED8DCBD06@seams043.starbucks.net> References: <72AB874F99785949A2898773AEDB5ED8DCBD06@seams043.starbucks.net> Message-ID: On 1/28/2004 8:48 AM -0800, Jon Wilmoth wrote: > As I submitted the first patch for the "customizable terminology" > contribution, I'm willing to help with the documentation effort. How > should I submit this info? As patches to the existing XML files preferably. :) There's lots of open documentation bugs on things that need to be fixed up. We're still supporting 2.16, too, so the docs on the 2.16 branch need any changes you submit also (if they're applicable to 2.16). > I think the move to the xml definition is great and will lower the > barrier to entry for following up code contributions with documentation > so others are aware of the functionality and benefit fully from it. I'd > also be willing to help develop the xsl stylesheets for at least the > HTML and Text versions. I'm not sure PDF can be generated with simple > XSL. We've done that already, a couple years ago. Look at the "README.docs" and "makedocs.pl" scripts in your docs directory. :) (not to mention the xml directory itself ;) What's in question is that we currently run the makedocs.pl script then cvs commit the compiled results (the html, text, and pdf). We're discussing the possibility of removing the (compiled) html, text, and pdf from cvs, and letting the website generate them on checkout when there are changes to the xml. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From gerv at mozilla.org Wed Jan 28 23:21:55 2004 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 28 Jan 2004 23:21:55 +0000 Subject: Documentation In-Reply-To: <4017D206.8030907@mozilla.org> References: <40176A55.8060908@mozilla.org> <4017D206.8030907@mozilla.org> Message-ID: <40184413.5020905@mozilla.org> Myk Melez wrote: > Gervase Markham wrote: > >> I'm more concerned about this con. Can we mitigate it? We certainly >> don't want to require people to set up a docs build environment; it's >> a real pain. > > I'm not sure how true that is anymore. My Fedora Core 1 installation > comes with everything needed except for the LDP stylesheet and three > shell variables that could probably be set automatically by the script. > Oh, and lynx, which is easily installed. But no build tools are required to 'build' the rest of Bugzilla. :-) I think even CVS checker-outers should be able to view documentation as something that is just there, rather than something they have to work to get. Gerv From gerv at mozilla.org Wed Jan 28 23:27:19 2004 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 28 Jan 2004 23:27:19 +0000 Subject: Documentation In-Reply-To: <5.1.0.14.2.20040128095238.05cfccf8@mikrobitti.fi> References: <5.1.0.14.2.20040128095238.05cfccf8@mikrobitti.fi> Message-ID: <40184557.3000707@mozilla.org> Jouni Heikniemi wrote: > I'd be totally happy if a cvs pull contained a short html (or text) file > in the docs/html dir that contains the address to the current > documentation. A downloadable tarball (or something more easily > cross-platform, a .zip perhaps?) is good enough, making checksetup.pl do > semi-automatic downloads is pampering the users too much (;-)). Besides, > it adds another external dependency and may prove problematic with > firewalls. I doubt many users have firewall troubles over port 80. There would be no dependency; we wouldn't offer to download it unless we could find either LWP::Simple or wget. Ideally, the documentation would be Just There when you pulled the CVS tree. If we don't have that (for our own convenience), I think we should put in a little effort to get as close to that as possible (for the user's convenience). Gerv From suson at TuckerEnergy.com Thu Jan 29 00:00:03 2004 From: suson at TuckerEnergy.com (Steven Suson) Date: Wed, 28 Jan 2004 18:00:03 -0600 Subject: Documentation In-Reply-To: References: <72AB874F99785949A2898773AEDB5ED8DCBD06@seams043.starbucks.net> Message-ID: <40184D03.6000500@TuckerEnergy.com> Interestingly enough, my company just began formalizing a Code Management Policy. One of the things that we have already established is that NO derived files (i.e. files that are somehow generated from one or more other files) will be in CVS. Steven Suson David Miller wrote: >On 1/28/2004 8:48 AM -0800, Jon Wilmoth wrote: > > > >>As I submitted the first patch for the "customizable terminology" >>contribution, I'm willing to help with the documentation effort. How >>should I submit this info? >> >> > >As patches to the existing XML files preferably. :) There's lots of open >documentation bugs on things that need to be fixed up. > >We're still supporting 2.16, too, so the docs on the 2.16 branch need any >changes you submit also (if they're applicable to 2.16). > > > >>I think the move to the xml definition is great and will lower the >>barrier to entry for following up code contributions with documentation >>so others are aware of the functionality and benefit fully from it. I'd >>also be willing to help develop the xsl stylesheets for at least the >>HTML and Text versions. I'm not sure PDF can be generated with simple >>XSL. >> >> > >We've done that already, a couple years ago. Look at the "README.docs" and >"makedocs.pl" scripts in your docs directory. :) (not to mention the xml >directory itself ;) > >What's in question is that we currently run the makedocs.pl script then cvs >commit the compiled results (the html, text, and pdf). We're discussing >the possibility of removing the (compiled) html, text, and pdf from cvs, >and letting the website generate them on checkout when there are changes to >the xml. > > From myk at mozilla.org Wed Jan 28 23:48:22 2004 From: myk at mozilla.org (Myk Melez) Date: Wed, 28 Jan 2004 15:48:22 -0800 Subject: Documentation In-Reply-To: <40184413.5020905@mozilla.org> References: <40176A55.8060908@mozilla.org> <4017D206.8030907@mozilla.org> <40184413.5020905@mozilla.org> Message-ID: <40184A46.4030106@mozilla.org> Gervase Markham wrote: > I think even CVS checker-outers should be able to view documentation > as something that is just there, rather than something they have to > work to get. True, they should, but they can anyway, since the docs are available online. Wouldn't most of these users prefer the online version anyway, with its guarantee of longer lived URLs for bookmarking, Google searching, and the like? I know I do. CVS checker-outers are a small subset of Bugzilla users, those who can't build the docs an even smaller subset, and those who prefer to read local docs an even smaller subset. It seems like an unnecessary waste to cater to that set when it's a matter of preference and in the face of significant pros to doing something else. I should mention another pro for me with not storing the generated versions: cleaner CVS updates that are easier to read for the important changes to my working copy because they don't contain a bunch of docs changes I'm not interested in. Come to think about it, leaving generated versions out is even better when I am interested in the docs changes, since it's the XML changes I care about anyway. -myk From etzwane at schwag.org Wed Jan 28 23:35:45 2004 From: etzwane at schwag.org (Sean McAfee) Date: Wed, 28 Jan 2004 18:35:45 -0500 Subject: Custom fields and more (was Re: 2.16.5/2.17.7 release prep) In-Reply-To: <401189F7.9030406@mozilla.org> Message-ID: <20040128233545.826E1C3B8@diggity.schwag.org> Gervase Markham wrote: >Steven Suson wrote: >> What is the status of Custom Fields (`a la the previously available >> Custom Fields patch)? Will this be making it into a Stable or >> Development version soon? For the record, it certainly gets my vote! ;-) > >It still has the same status - as an unofficial patch. Concerns have >been raised about its architecture; it's quite possible than any custom >fields function Bugzilla acquires in the future will work quite differently. > >No-one is working on custom fields as far as I know. I still am! I'm sorry I haven't been more active on the developers' list lately, but I've been working nonstop on getting people at my workplace off of Teamshare and onto Bugzilla. One department has been using Bugzilla exclusively for a few months now, and has been satisfied, by and large. Other departments are set to follow in the near future. The flood of bug fixes and feature requests has just recently slowed to the point that I have some spare time to work on getting my new stuff merged back into the main code base--pending input and approval from you folks, of course. I've actually implemented a large number of additional features beyond the basic custom field functionality I originally proposed, all of which I'd like to make available to the developer community. So, starting from the top... Firstly, there are the custom fields themselves. They still work essentially as originally described, and come in several varieties. * integer * date, with or without time * short string (255 characters or less; represented on web pages as an element) * long string (64K characters or less; represented on web pages as a