From gerv at mozilla.org Mon Mar 1 09:37:32 2004 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 01 Mar 2004 09:37:32 +0000 Subject: eGovOS registration Message-ID: <4043045C.9020201@mozilla.org> There's a booklet being published for the eGovOS conference (http://www.egovos.org). They want projects to input information to be in it. It'll get given to all attendees, including government IT officials. The deadline is today. I plan to fill in the form for Mozilla and Bugzilla appropriately (2 separate forms) and submit it. Someone shout if that's the wrong thing to do (like, for example, you've already done it.) Gerv Form: http://www.egovos.org/EGovOSRegistration/OSProjectReferences/CreateOSProjectReferenceForm From justdave at bugzilla.org Mon Mar 1 09:46:27 2004 From: justdave at bugzilla.org (David Miller) Date: Mon, 1 Mar 2004 04:46:27 -0500 Subject: eGovOS registration In-Reply-To: <4043045C.9020201@mozilla.org> References: <4043045C.9020201@mozilla.org> Message-ID: On 3/1/2004 9:37 AM +0000, Gervase Markham wrote: > There's a booklet being published for the eGovOS conference > (http://www.egovos.org). They want projects to input information to be > in it. It'll get given to all attendees, including government IT officials. > > The deadline is today. I plan to fill in the form for Mozilla and > Bugzilla appropriately (2 separate forms) and submit it. Someone shout > if that's the wrong thing to do (like, for example, you've already done it.) I was going to suggest that myself. Go for it. I started to fill it out, then realized some of the questions they want answered are a bit beyond my "advertising to PHB-types" skills :) so I was going to ask for volunteers. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From savdekar at hotmail.com Mon Mar 1 12:35:52 2004 From: savdekar at hotmail.com (Pankaj Savdekar) Date: Mon, 01 Mar 2004 18:05:52 +0530 Subject: Bugzilla setup problem - Redhat 8 Message-ID: Hi, Thanks for the reply. I got the problem. DBD::mysql was giving runtime problem due to libz, I installed libz.devel rpm and re-installed DBD and it started working. Thanks for the help. Pankaj >From: David Miller >Reply-To: developers at bugzilla.org >To: developers at bugzilla.org >Subject: Re: Bugzilla setup problem - Redhat 8 >Date: Fri, 27 Feb 2004 14:23:26 -0500 > >On 2/27/2004 6:06 PM +0530, Pankaj Savdekar wrote: > > > I tried these commands, but no luck. > > > > Can you please tell me how checksetup.pl find the whether the component >is > > installed or not? What file should I check to confirm that DBD component >is > > installed? > >/usr/bonsaitools/bin/perl -MDBD::mysql -e 'print "$DBD::mysql::VERSION\n";' > >If it's installed, that'll print the version number, if it's not you'll get >an error. That's very similar to the method checksetup.pl uses to detect >if it's present or not. >-- >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: > _________________________________________________________________ Raja Ravi Varma paintings. Buy art prints. http://go.msnserver.com/IN/42737.asp At MSN Shopping. From savdekar at hotmail.com Mon Mar 1 14:47:19 2004 From: savdekar at hotmail.com (Pankaj Savdekar) Date: Mon, 01 Mar 2004 20:17:19 +0530 Subject: Bugzilla setup problem - Redhat 8 Message-ID: Hi All, It's again me. I'm able to proceed till checksetup.pl returns no error, but now I'm stuck at opening index.cgi in browser. http://localhost/bugzilla/index.cgi gives the following error [Mon Mar 1 15:42:41 2004] index.cgi: [Mon Mar 1 15:42:41 2004] index.cgi: mkdir data/template/en: Permission denied at /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Template/Provider.pm line 377 [Mon Mar 1 15:42:41 2004] index.cgi: Compilation failed in require at CGI.pl line 53. Compilation failed in require at /data/bugzilla/index.cgi line 38. Earlier it was giving me "Premature end of script headers" error, but then I executed the following command chmod a+x *.cgi chmod a+r *.cgi chmod a+r *.pl chmod a+r *.pm I don't know why it's creating data/template/en directory. That directory is already present. Does anyone have idea as what's going wrong? Thanks, Pankaj _________________________________________________________________ INDIA TODAY @ Rs. 5 for 5 years ! http://www.indiatoday.com/itoday/intlsubscription/itsubs/it_offer.html Subcribe Now ... From vlad at goobix.com Mon Mar 1 17:02:33 2004 From: vlad at goobix.com (Vlad Dascalu) Date: Mon, 1 Mar 2004 19:02:33 +0200 Subject: Bugzilla setup problem - Redhat 8 In-Reply-To: References: Message-ID: <200403011902.33355.vlad@goobix.com> You need to give it manually write permission, not r or x. The best way is to set correctly in localconfig the username of the webserver (probably "apache"), and then rerun checksetup.pl as root. Vlad. On Monday 01 March 2004 16:47, you wrote: > Hi All, > > It's again me. I'm able to proceed till checksetup.pl returns no error, but > now I'm stuck at opening index.cgi in browser. > http://localhost/bugzilla/index.cgi gives the following error > > [Mon Mar 1 15:42:41 2004] index.cgi: [Mon Mar 1 15:42:41 2004] index.cgi: > mkdir data/template/en: Permission denied at > /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Template/Provider.pm > line 377 > [Mon Mar 1 15:42:41 2004] index.cgi: Compilation failed in require at > CGI.pl line 53. > Compilation failed in require at /data/bugzilla/index.cgi line 38. > > Earlier it was giving me "Premature end of script headers" error, but then > I executed the following command > chmod a+x *.cgi > chmod a+r *.cgi > chmod a+r *.pl > chmod a+r *.pm > > I don't know why it's creating data/template/en directory. That directory > is already present. Does anyone have idea as what's going wrong? > > Thanks, > Pankaj > > _________________________________________________________________ > INDIA TODAY @ Rs. 5 for 5 years ! > http://www.indiatoday.com/itoday/intlsubscription/itsubs/it_offer.html > Subcribe Now ... > > - > To view or change your list settings, click here: > From Mitchell at osafoundation.org Tue Mar 2 00:04:29 2004 From: Mitchell at osafoundation.org (Mitchell Baker) Date: Mon, 01 Mar 2004 16:04:29 -0800 Subject: eGovOS registration In-Reply-To: <4043045C.9020201@mozilla.org> References: <4043045C.9020201@mozilla.org> Message-ID: <4043CF8D.9060706@osafoundation.org> Gerv I did this last night. I just added a bit about Bugzilla to the Mozilla one. So you could do a separate one for Bugzilla, and I'll delete that one from the Mozilla one. If I can cooy the Mozilla text out and send it to you for editing, I'll do that too ml Gervase Markham wrote: > There's a booklet being published for the eGovOS conference > (http://www.egovos.org). They want projects to input information to be > in it. It'll get given to all attendees, including government IT > officials. > > The deadline is today. I plan to fill in the form for Mozilla and > Bugzilla appropriately (2 separate forms) and submit it. Someone shout > if that's the wrong thing to do (like, for example, you've already > done it.) > > Gerv > > Form: > http://www.egovos.org/EGovOSRegistration/OSProjectReferences/CreateOSProjectReferenceForm > > > From john.fisher at znyx.com Tue Mar 2 23:08:55 2004 From: john.fisher at znyx.com (John P. Fisher) Date: Tue, 02 Mar 2004 15:08:55 -0800 Subject: GetVersionTable bug #110503 In-Reply-To: References: <40351ADE.8060101@opencs.com.br> Message-ID: <6.0.3.0.0.20040302145847.03daa7a0@208.2.156.7> I am going to have to hack into this sub and its mate GenerateVersionTable. I see from the bug report that there is *some* desire to do something with it. Can you give me some direction on where it might go so I can stay as compatible as possible? Of course if anything I do seems worthy, I'll make it public. why? I need to add version-found-in vs. version fixed-in fields. I am making OS (opsys) & Platform (rep_platform) Product dependent. what? A) I can just write my own subs. If I do I'll ignore the cacheing mechanism. As a sop to security I could query-by-group, but security of this kind is a small issue with us. B) or I could hack into the existing subs and add three more hashes of data C) or there could be some hash that defines the data structure of Product-Components etc which is followed by GetVersionTable no doubt there's more clever solutions too. all suggestions welcome. thanks John John P. Fisher at ZNYX Networks 805 683 1488 x 3245 john.fisher at znyx.com From gerv at mozilla.org Thu Mar 4 08:58:31 2004 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 04 Mar 2004 08:58:31 +0000 Subject: Group combinations Message-ID: <4046EFB7.3080507@mozilla.org> Dear developers, Architecture question. It's about groups, so unfortunately it's quite a long mail. Initial assertion: a common use of non-product groups is to classify customers, and keep them separate from one another. So Customer A accounts are in Group A, and they only sees bugs they filed and bugs the company has let them see. The same for Customer B in Group B, and so on. One would want to force each customer to file bugs in their group, using the Mandatory For Members flag for that group on all products. Currently, for historical reasons, our groups system uses an AND model - that is, if a bug is in group A and group B, only users in both groups A AND B can see it. This seems fine at first glance, but breaks when you introduce the employees of the Bugzilla owner. Which groups are they in? Under the current model, they have to be in their own group (for company-private bugs, i.e. the majority) but also members of every customer group, so they can see the bugs they are showing to customers - remember, it's AND. Group inheritance? Maybe. But the problem then is that anyone in Group A (including employees) files bugs in Group A mandatorily. If you remember, we set this so Customer A people don't accidentally create public bugs. That means that bugs employees file go into Group A, and can never be seen by Customer B, even if that's who they are filing the bug for. But this works the other way, too - the bugs go into Group B also! The upshot is that bugs employees file can never be seen by any customer! Oh dear. If you want to sub-divide your employees into groups, it gets even worse. Basically, the AND model doesn't work in this environment. There are a few possible solutions: - Change wholesale to an OR model. Because of the complexity of the new groups system, this could be a migration nightmare. There are several ways we could approach that. - Offer users a choice of AND and OR, making all new installations OR. This has the disadvantage that it's one more variable to find out when diagnosing problems by email, and perhaps increases the potential of security holes. - Make insidergroup more special - people in insidergroup can always see all bugs. That would solve the "employees" problem, but not the "two customers seeing the same bug" problem. Thoughts? Gerv From justdave at bugzilla.org Thu Mar 4 09:07:12 2004 From: justdave at bugzilla.org (David Miller) Date: Thu, 4 Mar 2004 04:07:12 -0500 Subject: Group combinations In-Reply-To: <4046EFB7.3080507@mozilla.org> References: <4046EFB7.3080507@mozilla.org> Message-ID: On 3/4/2004 8:58 AM +0000, Gervase Markham wrote: > Group inheritance? Maybe. But the problem then is that anyone in Group A > (including employees) files bugs in Group A mandatorily. If you > remember, we set this so Customer A people don't accidentally create > public bugs. That means that bugs employees file go into Group A, and > can never be seen by Customer B, even if that's who they are filing the > bug for. But this works the other way, too - the bugs go into Group B > also! The upshot is that bugs employees file can never be seen by any > customer! Oh dear. It doesn't work this way. The group restrictions on the bugs are set by product, not by who filed them. The bugs would be restricted to the groups that were set on the product it was filed in, regardless of whether it was an employee that filed it or not. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From gerv at mozilla.org Thu Mar 4 09:35:21 2004 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 04 Mar 2004 09:35:21 +0000 Subject: Group combinations In-Reply-To: References: <4046EFB7.3080507@mozilla.org> Message-ID: <4046F859.6010002@mozilla.org> David Miller wrote: > On 3/4/2004 8:58 AM +0000, Gervase Markham wrote: >>Group inheritance? Maybe. But the problem then is that anyone in Group A >>(including employees) files bugs in Group A mandatorily. If you >>remember, we set this so Customer A people don't accidentally create >>public bugs. That means that bugs employees file go into Group A, and >>can never be seen by Customer B, even if that's who they are filing the >>bug for. But this works the other way, too - the bugs go into Group B >>also! The upshot is that bugs employees file can never be seen by any >>customer! Oh dear. > > It doesn't work this way. The group restrictions on the bugs are set by > product, not by who filed them. The bugs would be restricted to the groups > that were set on the product it was filed in, regardless of whether it was > an employee that filed it or not. I'm confused, then. Is is true that, after filing, the groups on a bug never change except by explicit group-changing action from someone? If so, why does it make sense that the groups for a bug are defined by the Product it's filed into? Surely it would be better to have (at least the option of having) them defined by the person who filed it? Or, to put it another way: is it possible to achieve my scenario using the current groups system? Gerv From MKey at atmi.com Thu Mar 4 13:28:07 2004 From: MKey at atmi.com (MKey at atmi.com) Date: Thu, 4 Mar 2004 13:28:07 +0000 Subject: Having trouble writing data to certain fields Message-ID: Hi all, I have hacked my local Bugzilla to add in Customer and CustomerContact fields. This way we can keep track of who reported what issue, and how many come from each company. The backend database code is fine - I can create Customers and Contacts via a new CGI script. The front end is 90% there. I select the Customer in the same way as the Product, then the Contact in the same way as the component. Problem is when I try and add this data into the database. It seems that my new variables are not being passed into the post_bug.cgi script - if I use the perl toolkit debug command, and manually specify the Customer and Contact values, then the SQL statement that is created is correct. So my question is, what is the process of transferring variable data between the enter_bug.cgi, post_bug.cgi and the associated Template files ? I have tried to simply copy and paste the existing product and component code renaming the fields to customer and contact.....but it doesnt seem to work Mat ________________________________________________________ Mathew Key Technical Marketing Engineer Emosyn Spinners Court, 53-55 West End Witney, Oxon. OX28 1NH ENGLAND Tel: +44 (0) 1993 700327 Fax: +44 (0) 1993 700299 Email: mkey at emosyn.com ________________________________________________________ Remeber - Every great achievement was once impossible ! ________________________________________________________ This email may contain confidential and / or privileged information. If you are not the intended recipient or have received this email in error, please notify the sender immediately and destroy this email. Any unauthorized copying, disclosure or distribution of the material in this email is strictly forbidden. Thank you. ________________________________________________________ From kiko at async.com.br Thu Mar 4 17:41:30 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Thu, 4 Mar 2004 14:41:30 -0300 Subject: Having trouble writing data to certain fields In-Reply-To: References: Message-ID: <20040304174130.GA1955@async.com.br> On Thu, Mar 04, 2004 at 01:28:07PM +0000, MKey at atmi.com wrote: > So my question is, what is the process of transferring variable data > between the enter_bug.cgi, post_bug.cgi and the associated Template files ? > I have tried to simply copy and paste the existing product and component > code renaming the fields to customer and contact.....but it doesnt seem to > work Data is only moved from template into CGI files through a form submission. You can access the related CGI object in the CGI via Bugzilla->cgi, though it normally is already set to a local $cgi attribute. It's then a matter of grabbing $cgi->param("foo") to get the related form fields ("foo" being whatever you set the form element's name attribute to). Data is moved from CGI files into the template via the $vars hash which is provided to $template->process(). I guess you've managed to do that given that you've been able to see customers listed in your generated HTML.. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From MKey at atmi.com Fri Mar 5 17:31:55 2004 From: MKey at atmi.com (MKey at atmi.com) Date: Fri, 5 Mar 2004 17:31:55 +0000 Subject: Another question...this time to do with Seach.pm Message-ID: Hi folks, Christian - thanks for the help on adding data into new fields in the database. I had forgotten to create a hidden variable on the HTML to pass my Customer data into the Post_bug.cgi script. All working now :) Now comes the final piece of the puzzle. Modifying the query code so I can search on it. I have got it so that the buglist.cgi script is called with " &customer=TestCustomer" in the URL.....but the Search.pm code seems to ignore it. I have added this "customer" field into the fielddefs table, so I would assume that it would parse this and query against it. So my question - are there any tricks that are needed to be able to search new fields ?? Mat ________________________________________________________ Mathew Key Technical Marketing Engineer Emosyn Spinners Court, 53-55 West End Witney, Oxon. OX28 1NH ENGLAND Tel: +44 (0) 1993 700327 Fax: +44 (0) 1993 700299 Email: mkey at emosyn.com ________________________________________________________ Remeber - Every great achievement was once impossible ! ________________________________________________________ This email may contain confidential and / or privileged information. If you are not the intended recipient or have received this email in error, please notify the sender immediately and destroy this email. Any unauthorized copying, disclosure or distribution of the material in this email is strictly forbidden. Thank you. ________________________________________________________ From kiko at async.com.br Fri Mar 5 20:07:57 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Fri, 5 Mar 2004 17:07:57 -0300 Subject: Another question...this time to do with Seach.pm In-Reply-To: References: Message-ID: <20040305200757.GH2044@async.com.br> On Fri, Mar 05, 2004 at 05:31:55PM +0000, MKey at atmi.com wrote: > Now comes the final piece of the puzzle. Modifying the query code so I can > search on it. > I have got it so that the buglist.cgi script is called with " > &customer=TestCustomer" in the URL.....but the Search.pm code seems to > ignore it. I have added this "customer" field into the fielddefs table, so > I would assume that it would parse this and query against it. I may be mistaken, but from my reading of the code, you simply need to dig into Search.pm and code in the query bits for you -- note however that I am guessing at this point. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From justdave at bugzilla.org Sat Mar 6 00:52:34 2004 From: justdave at bugzilla.org (David Miller) Date: Fri, 5 Mar 2004 19:52:34 -0500 Subject: The Road to 2.18 Message-ID: If you haven't already read the status update from the other day, go read it now. :) http://www.bugzilla.org/status_udpates/2004-03-03.html This continues where the "Road to 2.18" section on that page leaves off. It's been a LONG time since we've had a new stable full release. I think pretty much everyone agrees that it's high time we had one now. I'd like to propose that we do our feature freeze for 2.18 on March 15th. That's a little less than a week and a half from now. Is this too soon? Whatever date we pick is initiating our new date-based release cycle, so that puts us freezing for 2.20 on September 15th if we go with that date. Keep in mind that only means no new enhancements can go in. Low-risk or high-impact bugfixes would still be welcome after that point. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From justdave at bugzilla.org Sat Mar 6 04:10:11 2004 From: justdave at bugzilla.org (David Miller) Date: Fri, 5 Mar 2004 23:10:11 -0500 Subject: The Road to 2.18 In-Reply-To: References: Message-ID: On 3/5/2004 7:52 PM -0500, David Miller wrote: > If you haven't already read the status update from the other day, go read > it now. :) http://www.bugzilla.org/status_udpates/2004-03-03.html Oops. Try this url: http://www.bugzilla.org/status_updates/2004-03-03.html Thanks to Bruce Armstrong for pointing out my goof :) -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From kiko at async.com.br Sat Mar 6 16:52:25 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Sat, 6 Mar 2004 13:52:25 -0300 Subject: The Road to 2.18 In-Reply-To: References: Message-ID: <20040306165224.GB1097@async.com.br> On Fri, Mar 05, 2004 at 07:52:34PM -0500, David Miller wrote: > I'd like to propose that we do our feature freeze for 2.18 on March 15th. > That's a little less than a week and a half from now. Is this too soon? Is there anything "almost done" that will suffer because the author will need an extra week over that time? I personally only have bug 226754 which I plan on getting done before then. It's not really an "enhancement", but it's a cleanup I'd rather see done before freeze. The one area I'd really like to see move is bug 190212 (Templatize all administrator-facing pages in Bugzilla).. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From mdavis at laszlosystems.com Sat Mar 6 18:45:38 2004 From: mdavis at laszlosystems.com (Mark Davis) Date: Sat, 06 Mar 2004 10:45:38 -0800 Subject: The Road to 2.18 In-Reply-To: <20040306165224.GB1097@async.com.br> References: <20040306165224.GB1097@async.com.br> Message-ID: <404A1C52.8050001@laszlosystems.com> Christian Robottom Reis wrote: >On Fri, Mar 05, 2004 at 07:52:34PM -0500, David Miller wrote: > > >>I'd like to propose that we do our feature freeze for 2.18 on March 15th. >>That's a little less than a week and a half from now. Is this too soon? >> >> What are the odds of 91037 making it in to 2.18? I've been working with a patched 2.17.6 and have been please with the base functionality, but there are a couple of things that still need to be worked if the custom fields are to be first-order fields. The biggest problem we are having is getting the new fields to appear as list boxes on the query page... I hope to be able to work on this in the coming week, but I'm not certain if the patches in the bug are in a state to be merged with CVS in included in the next major release. Thoughts? -- Mark Davis Quality Assurance Manager, Laszlo Systems (415) 241-2736 -- http://www.laszlosystems.com From gerv at mozilla.org Sun Mar 7 23:19:18 2004 From: gerv at mozilla.org (Gervase Markham) Date: Sun, 07 Mar 2004 23:19:18 +0000 Subject: The Road to 2.18 In-Reply-To: <20040306165224.GB1097@async.com.br> References: <20040306165224.GB1097@async.com.br> Message-ID: <404BADF6.5090803@mozilla.org> Christian Robottom Reis wrote: > The one area I'd really like to see move is bug 190212 (Templatize all > administrator-facing pages in Bugzilla).. That's not going to happen for 2.18 :-) I'd like to see all _user_-facing output templatised for 2.18; but that depends on bug 84876... Gerv From gerv at mozilla.org Sun Mar 7 23:20:51 2004 From: gerv at mozilla.org (Gervase Markham) Date: Sun, 07 Mar 2004 23:20:51 +0000 Subject: The Road to 2.18 In-Reply-To: <404A1C52.8050001@laszlosystems.com> References: <20040306165224.GB1097@async.com.br> <404A1C52.8050001@laszlosystems.com> Message-ID: <404BAE53.1040208@mozilla.org> Mark Davis wrote: > What are the odds of 91037 making it in to 2.18? [That's Custom Fields] Near-zero, I'd say. If any custom fields patch gets anywhere near getting checked in, I'd want to take the time to take a long hard look at its architecture. And I'm sure I'm not the only one. Gerv From stu at asyn.com Sun Mar 7 23:41:06 2004 From: stu at asyn.com (Stuart Donaldson) Date: Sun, 07 Mar 2004 15:41:06 -0800 Subject: The Road to 2.18 In-Reply-To: <404A1C52.8050001@laszlosystems.com> References: <20040306165224.GB1097@async.com.br> <404A1C52.8050001@laszlosystems.com> Message-ID: <404BB312.50801@asyn.com> Mark Davis wrote: > Christian Robottom Reis wrote: > >> On Fri, Mar 05, 2004 at 07:52:34PM -0500, David Miller wrote: >> >> >>> I'd like to propose that we do our feature freeze for 2.18 on March >>> 15th. >>> That's a little less than a week and a half from now. Is this too soon? >>> > What are the odds of 91037 making it in to 2.18? I've been working > with a patched 2.17.6 and have been please with the base > functionality, but there are a couple of things that still need to be > worked if the custom fields are to be first-order fields. > > The biggest problem we are having is getting the new fields to appear > as list boxes on the query page... I hope to be able to work on this > in the coming week, but I'm not certain if the patches in the bug are > in a state to be merged with CVS in included in the next major release. > > Thoughts? > It would be a big win from the users perspective to get even a partial solution towards custom fields get into the system for the next release. This would lock-down a supported schema with a migration path in case the approach were to change. All these caveats about applying the custom fields patches because there is "no guarantee that this will be the way we do it" are holding some people back from trying it out. -Stuart- From gerv at mozilla.org Mon Mar 8 00:12:38 2004 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 08 Mar 2004 00:12:38 +0000 Subject: The Road to 2.18 In-Reply-To: <404BB312.50801@asyn.com> References: <20040306165224.GB1097@async.com.br> <404A1C52.8050001@laszlosystems.com> <404BB312.50801@asyn.com> Message-ID: <404BBA76.9020207@mozilla.org> Stuart Donaldson wrote: > It would be a big win from the users perspective to get even a partial > solution towards custom fields get into the system for the next release. > This would lock-down a supported schema with a migration path in case > the approach were to change. All these caveats about applying the custom > fields patches because there is "no guarantee that this will be the way > we do it" are holding some people back from trying it out. Indeed. And that's something we want to maintain. Locking down the schema is to be avoided - because we want to be able to say "actually, this is all wrong, we want to do it differently." Gerv From dberlin at dberlin.org Mon Mar 8 00:13:45 2004 From: dberlin at dberlin.org (Daniel Berlin) Date: Sun, 7 Mar 2004 19:13:45 -0500 Subject: The Road to 2.18 In-Reply-To: <404BB312.50801@asyn.com> References: <20040306165224.GB1097@async.com.br> <404A1C52.8050001@laszlosystems.com> <404BB312.50801@asyn.com> Message-ID: <772D321F-7095-11D8-B3AE-000A95DA505C@dberlin.org> > It would be a big win from the users perspective to get even a partial > solution towards custom fields get into the system for the next > release. This would lock-down a supported schema with a migration path > in case the approach were to change. All these caveats about applying > the custom fields patches because there is "no guarantee that this > will be the way we do it" are holding some people back from trying it > out. > > -Stuart- > I completely agree with Stuart here. Of course, the majority of my merging conflicts for upgrading our bugzilla, and maintaining it, is custom field maintenance (without a custom fields patch). I also have to use all-custom templates (which is another burden because i have to manually move the changes from the default templates with each release) for things that use op_sys and rep_platform (which is quite a few right now), because gcc/glibc/binutils/rhdb bugzilla don't use them (we use host/build/target triplets. op_sys and rep_platform are useless to us). --Dan From stu at asyn.com Mon Mar 8 01:54:22 2004 From: stu at asyn.com (Stuart Donaldson) Date: Sun, 07 Mar 2004 17:54:22 -0800 Subject: The Road to 2.18 In-Reply-To: <404BBA76.9020207@mozilla.org> References: <20040306165224.GB1097@async.com.br> <404A1C52.8050001@laszlosystems.com> <404BB312.50801@asyn.com> <404BBA76.9020207@mozilla.org> Message-ID: <404BD24E.2010309@asyn.com> Gervase Markham wrote: > Stuart Donaldson wrote: > >> It would be a big win from the users perspective to get even a >> partial solution towards custom fields get into the system for the >> next release. This would lock-down a supported schema with a >> migration path in case the approach were to change. All these caveats >> about applying the custom fields patches because there is "no >> guarantee that this will be the way we do it" are holding some people >> back from trying it out. > > > Indeed. And that's something we want to maintain. Locking down the > schema is to be avoided - because we want to be able to say "actually, > this is all wrong, we want to do it differently." > I must respectfully disagree. The custom fields issue has been around for several years with only a handful of people able to put any time into working it because of the maintenance risks, and the chance of it going in a conflicting direction. Continuing to wait for the perfect solution will result in the same issues and frustrations several years from now. What is needed, is a path to be chosen, and for Bugzilla to take at least a couple of steps down that path. It should be possible to choose a minimal feature set that will take will address 75% of the requirements for custom fields. Then make the committment to maintain an upward migration path for that approach. The schema is never "locked down" only the requirement that a migration from an old schema be provided. I believe many bugzilla users would really like to see some progress here. I also believe that if some support for custom fields can make it into the main release, that contributions and participation on filling out the functionality will accelerate as the barrier for participation becomes lower. -Stuart- From justdave at bugzilla.org Mon Mar 8 06:01:05 2004 From: justdave at bugzilla.org (David Miller) Date: Mon, 8 Mar 2004 01:01:05 -0500 Subject: The Road to 2.18 In-Reply-To: <404A1C52.8050001@laszlosystems.com> References: <20040306165224.GB1097@async.com.br> <404A1C52.8050001@laszlosystems.com> Message-ID: On 3/6/2004 10:45 AM -0800, Mark Davis wrote: > What are the odds of 91037 making it in to 2.18? Zero. Anything that changes the schema is going to need a pretty thorough review to get in this close to release. And a change this major is probably going to need a few months to mature on the development branch prior to being included in a release. This would, however, make it very plausible to make it into 2.20 on the new 6 month release cycles. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From MKey at atmi.com Mon Mar 8 17:02:17 2004 From: MKey at atmi.com (MKey at atmi.com) Date: Mon, 8 Mar 2004 17:02:17 +0000 Subject: Question about grey backgrounds in searches. Message-ID: Hi, I have sucessfully added in Customer and Customer Contact fields into a v2.17.6 installation. I can enter and seach by customer and contact. I have just noticed that on some buglist.cgi lists, there?are bugs with grey backgrounds that dont seem to be included in my search.....why ? Whats the significance of the grey background ?? Cheers Mat ________________________________________________________ Mathew Key Technical Marketing Engineer Emosyn Spinners Court, 53-55 West End Witney, Oxon. OX28 1NH ENGLAND Tel: +44 (0) 1993 700327 Fax: +44 (0) 1993 700299 Email: mkey at emosyn.com ________________________________________________________ Remeber - Every great achievement was once impossible ! ________________________________________________________ This email may contain confidential and / or privileged information. If you are not the intended recipient or have received this email in error, please notify the sender immediately and destroy this email. Any unauthorized copying, disclosure or distribution of the material in this email is strictly forbidden. Thank you. ________________________________________________________ From ttaby at web.de Mon Mar 8 17:24:22 2004 From: ttaby at web.de (Tamas Taby) Date: Mon, 8 Mar 2004 18:24:22 +0100 Subject: {Spam?} bugzilla translation Message-ID: <200403081724.i28HOMQ07419@mailgate5.cinetic.de> An HTML attachment was scrubbed... URL: From mdavis at laszlosystems.com Mon Mar 8 17:29:47 2004 From: mdavis at laszlosystems.com (Mark Davis) Date: Mon, 08 Mar 2004 09:29:47 -0800 Subject: The Road to 2.18 In-Reply-To: References: <20040306165224.GB1097@async.com.br> <404A1C52.8050001@laszlosystems.com> Message-ID: <404CAD8B.9080001@laszlosystems.com> David Miller wrote: >>What are the odds of 91037 making it in to 2.18? >> >> > >Zero. Anything that changes the schema is going to need a pretty thorough >review to get in this close to release. And a change this major is >probably going to need a few months to mature on the development branch >prior to being included in a release. This would, however, make it very >plausible to make it into 2.20 on the new 6 month release cycles. > > This is a mjor drag. The request has been open almost 3 years and the schema requirements havn't been reviewed? My feeling is that of all the feature requests, custom fields is probably the biggest blocker to adoption. Having the source makes it possible to create your own first-order fields, but the process is painful and obvioulsy cements an installation to one release. Every Bugzilla installation that I've maintained has had this need. Looking at the DB, this feature is ranked #4 by voters. The bugs that are getting fixed for 2.18: 68022 - 2 votes 12282 - 6 votes 16009 - 1 vote 86168 - 6 votes All of win32Compatibility: 20 votes (41 if you count the initial report as a vote) I'll stop ranting now, but it looks like 91037 should be reprioritized. -- Mark Davis Quality Assurance Manager, Laszlo Systems (415) 241-2736 -- http://www.laszlosystems.com From kiko at async.com.br Mon Mar 8 17:45:28 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Mon, 8 Mar 2004 14:45:28 -0300 Subject: The Road to 2.18 In-Reply-To: <404CAD8B.9080001@laszlosystems.com> References: <20040306165224.GB1097@async.com.br> <404A1C52.8050001@laszlosystems.com> <404CAD8B.9080001@laszlosystems.com> Message-ID: <20040308174528.GF1862@async.com.br> Speaking on my own behalf here: On Mon, Mar 08, 2004 at 09:29:47AM -0800, Mark Davis wrote: > I'll stop ranting now, but it looks like 91037 should be reprioritized. It's not a low-priority fix; it *is* a high-impact one, however, that requires significant effort on behalf of reviewers and maintainers to understand, review and integrate. And I mean SIGNIFICANT in case that's still not clear -- complaining about it doesn't change that essential fact. If you ask me, I would suggest the following as a good way to try and get it in: - Summarize the plan in bite-sized changes. - Discuss each of the changes via mailing list and in a bug when sufficient consensus is reached. - Patch, get review and fix each of these bugs till none are left. - Go crazy. One the key words here is *consensus*. You need to make sure at least one of the core reviewers understands, approves and agrees with the changes involved. It's not the reviewer's burden, mind you, though the reviewer may be effectively interested (I certainly am) in getting this in, and therefore work to make things easier for whoever's submitting a patch. It's *always* easier if patches can be split up into smaller bits and go in bit-by-bit. Ask Linus what he thinks about large patches that hit him [and are subsequently dropped] -- there's no way we can try and guarantee quality if we're not careful about what goes in. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From justdave at bugzilla.org Mon Mar 8 17:51:37 2004 From: justdave at bugzilla.org (David Miller) Date: Mon, 8 Mar 2004 12:51:37 -0500 Subject: The Road to 2.18 In-Reply-To: <404CAD8B.9080001@laszlosystems.com> References: <20040306165224.GB1097@async.com.br> <404A1C52.8050001@laszlosystems.com> <404CAD8B.9080001@laszlosystems.com> Message-ID: On 3/8/2004 9:29 AM -0800, Mark Davis wrote: > David Miller wrote: > >>>What are the odds of 91037 making it in to 2.18? >>> >>> >> >>Zero. Anything that changes the schema is going to need a pretty thorough >>review to get in this close to release. And a change this major is >>probably going to need a few months to mature on the development branch >>prior to being included in a release. This would, however, make it very >>plausible to make it into 2.20 on the new 6 month release cycles. > > This is a mjor drag. The request has been open almost 3 years and the > schema requirements havn't been reviewed? The problem is that it's a HUGE FREAKING PATCH, and we're all volunteers (at least we all have been until just recently). Something that size takes a lot of time to review, and contiguous time, at that, where you can concentrate on it until you're done so you don't miss anything. Something most of us haven't had time for in more than a few years. If you want it in that bad, put one of the core developers on your payroll for a month or two to shepherd it in. Otherwise we have real jobs to tend to that take most of our time. Just look at bug 87846 (the mail notification rearchitecture to drop the dependency on Sendmail). That's another huge freaking patch. And it's also been there *longer than custom fields* I might point out, and it's just now getting to the point where it may get checked in soon. > I'll stop ranting now, but it looks like 91037 should be reprioritized. Priority means nothing if there's no time to deal with it. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From mdavis at laszlosystems.com Mon Mar 8 18:08:32 2004 From: mdavis at laszlosystems.com (Mark Davis) Date: Mon, 08 Mar 2004 10:08:32 -0800 Subject: The Road to 2.18 In-Reply-To: References: <20040306165224.GB1097@async.com.br> <404A1C52.8050001@laszlosystems.com> <404CAD8B.9080001@laszlosystems.com> Message-ID: <404CB6A0.5090903@laszlosystems.com> David Miller wrote: >If you want it in that bad, put one of the core developers on your payroll >for a month or two to shepherd it in. Otherwise we have real jobs to tend >to that take most of our time. > > I would *love* to be able to do that. Who's in San Francisco, As soon as My dept gets properly funded I'll see what I can do. >>I'll stop ranting now, but it looks like 91037 should be reprioritized. >> >> > >Priority means nothing if there's no time to deal with it. > > Given, but priority drives time allocation... -- Mark Davis Quality Assurance Manager, Laszlo Systems (415) 241-2736 -- http://www.laszlosystems.com From stu at asyn.com Mon Mar 8 18:14:43 2004 From: stu at asyn.com (Stuart Donaldson) Date: Mon, 08 Mar 2004 10:14:43 -0800 Subject: The Road to 2.18 (custom fields) In-Reply-To: References: <20040306165224.GB1097@async.com.br> <404A1C52.8050001@laszlosystems.com> <404CAD8B.9080001@laszlosystems.com> Message-ID: <404CB813.5020105@asyn.com> Due to the size and impact of the Custom Fields work, it sounds like it would be good if this can be broken down into smaller pieces. Is it reasonable to break this down into smaller parts? Would it make sense to break it into: a) Schema change & Field definnition b) Placing fields on the bug page c) Adding selectable fields to the buglist d) Simple searching on custom fields (any custom field contains x) d) Advanced searching on custom fields (specify field=x) This is just a quick stab at a breakdown to illustrate the concept. Now of course you want to understand the searching issues in order to evaluate the Schema, but we don't have to have a fully debugged implementation of searching. If (a) above can be agreed to, then compatibility with future releases becomes much easier to maintain. I am no longer worried about implementing custom field patches that address the searching, or the buglist, or any other issues, because I know my database schema will be supported at least in a migration sense in the future. Would it help if the this were broken out in a manner similar to what I listed above? Likely a better breakdown of phases exists, but the concept remains. Regards, -Stuart- From gerv at mozilla.org Mon Mar 8 18:16:36 2004 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 08 Mar 2004 18:16:36 +0000 Subject: The Road to 2.18 In-Reply-To: <404BD24E.2010309@asyn.com> References: <20040306165224.GB1097@async.com.br> <404A1C52.8050001@laszlosystems.com> <404BB312.50801@asyn.com> <404BBA76.9020207@mozilla.org> <404BD24E.2010309@asyn.com> Message-ID: <404CB884.7070907@mozilla.org> Stuart Donaldson wrote: > Gervase Markham wrote: >> Indeed. And that's something we want to maintain. Locking down the >> schema is to be avoided - because we want to be able to say "actually, >> this is all wrong, we want to do it differently." Let me clarify this. For a change of this magnitude, it would be wrong to lock down the schema until the Bugzilla core team has: - decided whether we want custom fields at all - if we do, written a design for them - written the actual patch (either based on existing one, or different) - checked it in. At that point, and that point only, there is an onus on us to provide migration paths. The key point to grasp is that _writing_ a custom fields patch is not the hard part of this process. The hard part is agreeing that we want it, and how to do it. There are several very different ways one could approach the problem. So far, no-one on the core team has had enough time to spare, or prioritised this high enough, for it to happen. And although the decision on what code to accept is justdave's, the list of people that _I_ personally would trust to do this work is not very long at all. The serious consequences that could arise if we mess this up mean that this is not a situation where we can knock something together and refine it incrementally. Custom fields are obviously important to a number of Bugzilla users. Up to this point, though, self-evidentially other things have been more important to the core team. You may not like this, or agree with it. Sorry about that, but there you go. The great thing about Free software is that people can take it in another direction if they like. That's what the custom fields patch basically is. If the people maintaining that patch want to set up a website, or a wiki, or a mailing list, to make it easier for those who want it to get it, that's fine. But we won't and can't promise that that particular patch will get integrated, or that whatever patch does get integrated will work anything like that one, or that one of us will write migration code. Gerv From stu at asyn.com Mon Mar 8 18:37:34 2004 From: stu at asyn.com (Stuart Donaldson) Date: Mon, 08 Mar 2004 10:37:34 -0800 Subject: The Road to 2.18 In-Reply-To: <404CB884.7070907@mozilla.org> References: <20040306165224.GB1097@async.com.br> <404A1C52.8050001@laszlosystems.com> <404BB312.50801@asyn.com> <404BBA76.9020207@mozilla.org> <404BD24E.2010309@asyn.com> <404CB884.7070907@mozilla.org> Message-ID: <404CBD6E.40607@asyn.com> Gervase Markham wrote: > Stuart Donaldson wrote: > >> Gervase Markham wrote: >> >>> Indeed. And that's something we want to maintain. Locking down the >>> schema is to be avoided - because we want to be able to say >>> "actually, this is all wrong, we want to do it differently." >> > > Let me clarify this. > ... > The key point to grasp is that _writing_ a custom fields patch is not > the hard part of this process. The hard part is agreeing that we want > it, and how to do it. There are several very different ways one could > approach the problem. > So if you are still in doubt about the need for custom fields after all this time, are we really just wasting our time on this? Should we be looking elsewhere for this functionality? Has anyone created a fork with custom fields support? Don't get me wrong, I certainly appreciate all of the very thoughtful and intelligent efforts that go into maintaining and extending Bugzilla. But I am a little dismayed at the impression that the "core team" has not reached a consensus at this point that something is necessary. -Stuart- From kiko at async.com.br Mon Mar 8 20:18:27 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Mon, 8 Mar 2004 17:18:27 -0300 Subject: The Road to 2.18 In-Reply-To: <404CB884.7070907@mozilla.org> References: <20040306165224.GB1097@async.com.br> <404A1C52.8050001@laszlosystems.com> <404BB312.50801@asyn.com> <404BBA76.9020207@mozilla.org> <404BD24E.2010309@asyn.com> <404CB884.7070907@mozilla.org> Message-ID: <20040308201827.GB2281@async.com.br> Again, on my behalf, On Mon, Mar 08, 2004 at 06:16:36PM +0000, Gervase Markham wrote: > So far, no-one on the core team has had enough time to spare, or > prioritised this high enough, for it to happen. And although the > decision on what code to accept is justdave's, the list of people that > _I_ personally would trust to do this work is not very long at all. The > serious consequences that could arise if we mess this up mean that this > is not a situation where we can knock something together and refine it > incrementally. I'm sure there is a better alternative than stalling all work on this subject till someone comes up with the perfect approach. I honestly think that: a) CVS HEAD (or a branch if we want to do that) can take some breakage if it makes integration of this easier -- hey, we file and fix bugs on regressions all the time. The design has to be agreed upon beforehand, but not all the itty bitty details. b) it's possible to break the work into smaller bits -- as would have been possible for the DB-independence work and many other large changes we need to do. Instead of saying that it's dreadfully complicated, patch authors need to sit down and take the time to cut it up into bits, and making sure that at least one core member is interested enough to understand the bits. As for whether custom fields is a good idea or not, I don't want to argue about that any longer -- if a good enough design and implementation is reached, I would vote for including it. Unless somebody has a better workaround to propose. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From bugreport at peshkin.net Mon Mar 8 20:23:28 2004 From: bugreport at peshkin.net (Joel Peshkin) Date: Mon, 08 Mar 2004 12:23:28 -0800 Subject: The Road to custome fields [was 2.18] In-Reply-To: <404CBD6E.40607@asyn.com> References: <20040306165224.GB1097@async.com.br> <404A1C52.8050001@laszlosystems.com> <404BB312.50801@asyn.com> <404BBA76.9020207@mozilla.org> <404BD24E.2010309@asyn.com> <404CB884.7070907@mozilla.org> <404CBD6E.40607@asyn.com> Message-ID: <404CD640.7080201@peshkin.net> A few points from my end.... 1) If you have funding for custom fields, I'd suggest you consider the team members regardless of location. Start by looking for people who appear on BOTH http://www.bugzilla.org/consulting.html and http://www.bugzilla.org/who_we_are.html 2) Can't we start by agreeing we DO want custom fields?? We don't have to want a bad implementation of it, but we do want a good implementation. 3) Perhaps we can back off of some of the challanges of custom fields by not requring it to happen entirely through the web interface and assuming that anyone who wants to use them will be willing to make a few changes to some files, run checksetup, and even hack some templates. If we can keep users of customfields from having to understand the whole schema and Serach.pm, we have helped 90% of the users. -Joel From louie at ximian.com Mon Mar 8 21:22:44 2004 From: louie at ximian.com (Luis Villa) Date: Mon, 08 Mar 2004 16:22:44 -0500 Subject: The Road to custome fields [was 2.18] In-Reply-To: <404CD640.7080201@peshkin.net> References: <20040306165224.GB1097@async.com.br> <404A1C52.8050001@laszlosystems.com> <404BB312.50801@asyn.com> <404BBA76.9020207@mozilla.org> <404BD24E.2010309@asyn.com> <404CB884.7070907@mozilla.org> <404CBD6E.40607@asyn.com> <404CD640.7080201@peshkin.net> Message-ID: <1078780963.9752.77.camel@localhost.localdomain> On Mon, 2004-03-08 at 12:23 -0800, Joel Peshkin wrote: > 3) Perhaps we can back off of some of the challanges of custom fields by > not requring it to happen entirely through the web interface and > assuming that anyone who wants to use them will be willing to make a few > changes to some files, run checksetup, and even hack some templates. If > we can keep users of customfields from having to understand the whole > schema and Serach.pm, we have helped 90% of the users. I was actually totally shocked to see that the patch attempts to have the whole thing web configurable. That's ambitious, and in my mind totally optional- just having it doable from a text editor + a shell script is much more important right now to get it out and get it tested than getting a web UI totally right. Just two cents from a part-time admin- Luis From gerv at mozilla.org Tue Mar 9 00:07:40 2004 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 09 Mar 2004 00:07:40 +0000 Subject: The Road to 2.18 In-Reply-To: <404CBD6E.40607@asyn.com> References: <20040306165224.GB1097@async.com.br> <404A1C52.8050001@laszlosystems.com> <404BB312.50801@asyn.com> <404BBA76.9020207@mozilla.org> <404BD24E.2010309@asyn.com> <404CB884.7070907@mozilla.org> <404CBD6E.40607@asyn.com> Message-ID: <404D0ACC.2000506@mozilla.org> Stuart Donaldson wrote: > So if you are still in doubt about the need for custom fields after all > this time, are we really just wasting our time on this? I'm in two minds about it. If other core developers want them, I won't stand in the way. But I will stand in the way of a badly-architected implementation, as I'll be one of the people having to maintain it from here on. > Should we be > looking elsewhere for this functionality? Has anyone created a fork with > custom fields support? That's what the custom fields patch is, basically. > Don't get me wrong, I certainly appreciate all of the very thoughtful > and intelligent efforts that go into maintaining and extending Bugzilla. > But I am a little dismayed at the impression that the "core team" has > not reached a consensus at this point that something is necessary. Why is that dismaying? It's a controversial subject. Gerv From gerv at mozilla.org Tue Mar 9 00:09:31 2004 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 09 Mar 2004 00:09:31 +0000 Subject: The Road to custome fields [was 2.18] In-Reply-To: <404CD640.7080201@peshkin.net> References: <20040306165224.GB1097@async.com.br> <404A1C52.8050001@laszlosystems.com> <404BB312.50801@asyn.com> <404BBA76.9020207@mozilla.org> <404BD24E.2010309@asyn.com> <404CB884.7070907@mozilla.org> <404CBD6E.40607@asyn.com> <404CD640.7080201@peshkin.net> Message-ID: <404D0B3B.7050501@mozilla.org> Joel Peshkin wrote: > 3) Perhaps we can back off of some of the challanges of custom fields by > not requring it to happen entirely through the web interface and > assuming that anyone who wants to use them will be willing to make a few > changes to some files, run checksetup, and even hack some templates. If > we can keep users of customfields from having to understand the whole > schema and Serach.pm, we have helped 90% of the users. I'd actively say that we _don't_ want a web interface. If a point-and-click manager can add custom fields, we've actually done that company and all its Bugzilla users a big disservice, because their Bugzilla will get less and less usable. We have that problem at my company. Our home-grown issue tracker has literally 40 fields, including three version fields. Gerv From chicks at chicks.net Tue Mar 9 01:27:24 2004 From: chicks at chicks.net (Christopher Hicks) Date: Mon, 8 Mar 2004 20:27:24 -0500 (EST) Subject: The Road to 2.18 In-Reply-To: <404D0ACC.2000506@mozilla.org> Message-ID: On Tue, 9 Mar 2004, Gervase Markham wrote: > Stuart Donaldson wrote: > > Don't get me wrong, I certainly appreciate all of the very thoughtful > > and intelligent efforts that go into maintaining and extending Bugzilla. > > But I am a little dismayed at the impression that the "core team" has > > not reached a consensus at this point that something is necessary. > > Why is that dismaying? It's a controversial subject. Still!?!?!? One would think after as many times as we've been around this topic that some concensus might have developed. The inability of the core bugzilla developers to grapple with the desirability of custom fields at this point is truly surprising. It's eerily similar to my utter discouragement at trying to get an obvious one-line patch added. The way new contributors are repressed is unlike anything I've experienced or witnessed on any other open source project. Its difficult to imagine very many folks having the ego and persistance to jump through the ridiculous hoops and actually make a contribution. Bugzilla rocks and I appreciate everything folks have done through the years, but maybe people wouldn't be so pressed for time if newcomers didn't need to beat their head against the wall for so long before being accepted. -- No, no, you're not thinking, you're just being logical. -Niels Bohr, physicist (1885-1962) From JWilmoth at starbucks.com Tue Mar 9 01:26:14 2004 From: JWilmoth at starbucks.com (Jon Wilmoth) Date: Mon, 8 Mar 2004 17:26:14 -0800 Subject: The Road to custome fields [was 2.18] Message-ID: <72AB874F99785949A2898773AEDB5ED8DCBD79@seams043.starbucks.net> I appreciate the caution of overdoing custom fields and caution should be exercised when considering this action. Especially since part of the beauty of BZ is it's simplicity to enter bugs/issues. However, the user community here would greatly appreciate the ability to capture department specific information (i.e. by product/product group custom fields) that doesn't necessarily apply to other departments. The only way I see that happening is if it is easy for an administrator to add fields. If the admin has to hack templates and change a few files, the upgrade path becomes extremely difficult and the usage of custom fields becomes too costly in terms of total cost of ownership. -----Original Message----- From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] On Behalf Of Gervase Markham Sent: Monday, March 08, 2004 4:10 PM To: developers at bugzilla.org Subject: Re: The Road to custome fields [was 2.18] Joel Peshkin wrote: > 3) Perhaps we can back off of some of the challanges of custom fields by > not requring it to happen entirely through the web interface and > assuming that anyone who wants to use them will be willing to make a few > changes to some files, run checksetup, and even hack some templates. If > we can keep users of customfields from having to understand the whole > schema and Serach.pm, we have helped 90% of the users. I'd actively say that we _don't_ want a web interface. If a point-and-click manager can add custom fields, we've actually done that company and all its Bugzilla users a big disservice, because their Bugzilla will get less and less usable. We have that problem at my company. Our home-grown issue tracker has literally 40 fields, including three version fields. Gerv - To view or change your list settings, click here: From matthew at barnson.org Tue Mar 9 01:21:20 2004 From: matthew at barnson.org (Matthew P. Barnson) Date: Mon, 8 Mar 2004 18:21:20 -0700 Subject: The Road to 2.18 In-Reply-To: References: <404D0ACC.2000506@mozilla.org> Message-ID: <20040309012120.GH10105@barnson.org> On Mon, Mar 08, 2004 at 08:27:24PM -0500, Christopher Hicks wrote: > Bugzilla rocks and I appreciate > everything folks have done through the years, but maybe people wouldn't be > so pressed for time if newcomers didn't need to beat their head against > the wall for so long before being accepted. Just fork the code. I'm not joking. Many projects cross-fertilize from forks and sets of patches. Just make sure to keep your fork current as a patch for the Bugzilla CVS HEAD, and enjoy allowing liberal patches to it. Savannah.gnu.org and sourceforge.net are both excellent places to host such a project. Heck, I'm a sysadmin for a living, and would gladly set up the resources to host such a project, as well. Progress on a fork that makes it better than standard CVS Bugzilla would probably gain rapid, wide acceptance. As long as people work to make sure the projects remain interoperable, such a fork can be a good thing. My take on reticence towards massive changes in Bugzilla is that it stems from one simple historical phrase: "Don't break bugzilla.mozilla.org." I can understand both sides: one mainly interested in stability, one mainly interested in features. A well-run fork (or set of patches) was a good thing for egcs & gcc, the Alan Cox Linux kernel, and progress on WINE (erm, that last one is just my opinion, you know :). You never know what might happen. That's the beauty of free software. Anyway, that's my thoughts on the subject. If people are sufficiently dissatisfied with progress in a project, there's little sense in fighting about it when open source is so easy to fork and improve. -- Matthew P. Barnson - - - - Thought for the moment: The truth is what is; what should be is a dirty lie. -- Lenny Bruce From justdave at bugzilla.org Tue Mar 9 02:29:39 2004 From: justdave at bugzilla.org (David Miller) Date: Mon, 8 Mar 2004 21:29:39 -0500 Subject: Contibuting to Bugzilla (was: The Road to 2.18) In-Reply-To: References: Message-ID: On 3/8/2004 8:27 PM -0500, Christopher Hicks wrote: > On Tue, 9 Mar 2004, Gervase Markham wrote: >> Stuart Donaldson wrote: >> > Don't get me wrong, I certainly appreciate all of the very thoughtful >> > and intelligent efforts that go into maintaining and extending Bugzilla. >> > But I am a little dismayed at the impression that the "core team" has >> > not reached a consensus at this point that something is necessary. >> >> Why is that dismaying? It's a controversial subject. > > Still!?!?!? One would think after as many times as we've been around this > topic that some concensus might have developed. The inability of the core > bugzilla developers to grapple with the desirability of custom fields at > this point is truly surprising. I don't think anyone's grappling with the desirability of it (except maybe Gerv). Gerv is often a bit out of touch, because most of these things get discussed in IRC, and he's seldom there. He often has very good opinions on things, but be careful of putting too much stock into anything he says on behalf of the team. That said, I think it's clear among the rest of the core team that we want this. The remaining controversy centers around the proper way to implement it. And much of that hasn't had any solid decisions made simply because the people involved in making those decisions haven't had time to review the available options yet. Hopefully that's changing in the near future (see below). > It's eerily similar to my utter > discouragement at trying to get an obvious one-line patch added. The way > new contributors are repressed is unlike anything I've experienced or > witnessed on any other open source project. Knowing the time period around which you started contributing, I have no problem believing this is the experience you had, as much as it pains me to admit it. We lost almost all active participation by anyone even remotely related to the core team at that time because people had job changes and new employers weren't as sympathetic about spending time on Bugzilla. This of course was a catch 22 situation because said people didn't even have time to mentor new participants who might have been able to pick up the slack once they'd been shown how things worked. As a result, many people who probably would have been happy to pick up that slack came and went because no one was around to "show them the ropes." Things started to ease up a lot around the time AOL cut the Mozilla Foundation loose. Myself and Myk were both working for AOL. Myk got stolen from AOL by the Mozilla Foundation, with support of the Mozilla Webtools (including Bugzilla) in his job description (it was in his job description at AOL, too, but AOL usually found other things for him to do with his time). Being able to work on the Open Source Bugzilla on company time got written out of my job description around March of 2003. I was still working at AOL until the end of February when I resigned in order to take a position with a new open-source based startup, with Bugzilla being almost my entire job description and a promise that anything I do can be contributed (I can't say much more right now, but more details will be forthcoming as the startup makes a public appearance in the next couple months :) Several other of the core team that had previously been taken away have also started having more time to help out again in the last few months, and we were also fortunate enough to have some new contributors who showed up about the time people were starting to have enough time to mentor folks again, and began heavily participating. In short, I sincerely hope that over the last month or two, and from this point forward, that nobody has been getting ignored the way you did back then. I do apologize that it happened at all. Please understand that all of us were very frustrated last year. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From gerv at mozilla.org Tue Mar 9 08:34:28 2004 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 09 Mar 2004 08:34:28 +0000 Subject: The Road to 2.18 In-Reply-To: <20040309012120.GH10105@barnson.org> References: <404D0ACC.2000506@mozilla.org> <20040309012120.GH10105@barnson.org> Message-ID: <404D8194.5070903@mozilla.org> Matthew P. Barnson wrote: > Just fork the code. I actually think that this is a bad idea - not because I've some vested interest, but for the good of the code. If there's a fork, it takes the pressure off us to make our processes better, to improve and be more responsive. It divides effort and duplicates work. Forking should be a last resort measure. The grass is not always greener on the other side of the fence. Gerv From gerv at mozilla.org Tue Mar 9 08:35:39 2004 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 09 Mar 2004 08:35:39 +0000 Subject: The Road to custome fields [was 2.18] In-Reply-To: <72AB874F99785949A2898773AEDB5ED8DCBD79@seams043.starbucks.net> References: <72AB874F99785949A2898773AEDB5ED8DCBD79@seams043.starbucks.net> Message-ID: <404D81DB.20600@mozilla.org> Jon Wilmoth wrote: > However, the user community here would greatly appreciate the ability to > capture department specific information (i.e. by product/product group > custom fields) that doesn't necessarily apply to other departments. The > only way I see that happening is if it is easy for an administrator to > add fields. I don't think that's necessarily true - why can the admin not submit a request for a new field? That way, someone who understands the downsides of 40 fields per bug can evaluate the request. Gerv From gerv at mozilla.org Tue Mar 9 08:38:07 2004 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 09 Mar 2004 08:38:07 +0000 Subject: The Road to 2.18 In-Reply-To: References: Message-ID: <404D826F.8050206@mozilla.org> Christopher Hicks wrote: > Still!?!?!? One would think after as many times as we've been around this > topic that some concensus might have developed. The inability of the core > bugzilla developers to grapple with the desirability of custom fields at > this point is truly surprising. Have you read Joel's article? http://www.joelonsoftware.com/news/20020912.html That's a big part of the reason why some people are reticent. > It's eerily similar to my utter > discouragement at trying to get an obvious one-line patch added. Bug number? > The way > new contributors are repressed is unlike anything I've experienced or > witnessed on any other open source project. Ever worked on Mozilla? ;-) > Its difficult to imagine very > many folks having the ego and persistance to jump through the ridiculous > hoops and actually make a contribution. Bugzilla rocks and I appreciate > everything folks have done through the years, but maybe people wouldn't be > so pressed for time if newcomers didn't need to beat their head against > the wall for so long before being accepted. I don't think it's an acceptance thing - no-one's being excluded because they are new. It's a time thing and a priorities thing - we have very little time, and a set of priorities which may not be the same as yours. As my Bugzilla Etiquette document says, "Open Source does not mean 'the developers must do my bidding'". Gerv From gerv at mozilla.org Tue Mar 9 08:41:46 2004 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 09 Mar 2004 08:41:46 +0000 Subject: Contibuting to Bugzilla In-Reply-To: References: Message-ID: <404D834A.2070106@mozilla.org> David Miller wrote: > I don't think anyone's grappling with the desirability of it (except maybe > Gerv). Gerv is often a bit out of touch, because most of these things get > discussed in IRC, and he's seldom there. I think it's somewhat unreasonable to ask someone with a day job and in a different timezone to hang around there when you lot in the US are - but that's the way it is. However, I'd appreciate it if the mailing list could be informed when something is decided - like, perhaps, a decision to go for 2.18 and do an rc1 - rather than finding out when people start adding statuses for it to bugs. Gerv From justdave at bugzilla.org Tue Mar 9 08:52:10 2004 From: justdave at bugzilla.org (David Miller) Date: Tue, 9 Mar 2004 03:52:10 -0500 Subject: Contibuting to Bugzilla In-Reply-To: <404D834A.2070106@mozilla.org> References: <404D834A.2070106@mozilla.org> Message-ID: On 3/9/2004 8:41 AM +0000, Gervase Markham wrote: > David Miller wrote: >> I don't think anyone's grappling with the desirability of it (except maybe >> Gerv). Gerv is often a bit out of touch, because most of these things get >> discussed in IRC, and he's seldom there. > > I think it's somewhat unreasonable to ask someone with a day job and in > a different timezone to hang around there when you lot in the US are - > but that's the way it is. You've actually been there quite a bit the last week or so. :) > However, I'd appreciate it if the mailing list could be informed when > something is decided - like, perhaps, a decision to go for 2.18 and do > an rc1 - rather than finding out when people start adding statuses for > it to bugs. Yes, I agree. That's something I need to work on. I'm lucky enough to be one of those folks who could get on IRC from work, and it's quite easy to throw out an idea or two at an off moment and let people discuss in the hour or two before you get time to look at that window again. It's a little more effort to type up an email. :) Informing the list was actually the reason the Road to 2.18 thread was started. :) -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From abenea at home.ro Tue Mar 9 11:03:39 2004 From: abenea at home.ro (Andrei Benea) Date: Tue, 09 Mar 2004 13:03:39 +0200 Subject: Official ppm repository for Windows Message-ID: Justdave suggested in: http://bugzilla.mozilla.org/show_bug.cgi?id=236664#c9 to discuss on this list the ppm repository to be included in Bugzilla's Windows installation instructions (checksetup.pl). The proposed URL is now http://www.apache.org/dist/perl/win32-bin/ppms/ Mirrors for this repository can be found at: http://www.apache.org/dyn/closer.cgi/perl/win32-bin/ppms/ I've chosen this one because it includes all ActivePerl packages needed by Bugzilla except Chart::Base (which is optional). Andrei. From chicks at chicks.net Tue Mar 9 13:27:18 2004 From: chicks at chicks.net (Christopher Hicks) Date: Tue, 9 Mar 2004 08:27:18 -0500 (EST) Subject: The Road to 2.18 In-Reply-To: <404D826F.8050206@mozilla.org> Message-ID: On Tue, 9 Mar 2004, Gervase Markham wrote: > Christopher Hicks wrote: > > Still!?!?!? One would think after as many times as we've been around this > > topic that some concensus might have developed. The inability of the core > > bugzilla developers to grapple with the desirability of custom fields at > > this point is truly surprising. > > Have you read Joel's article? > http://www.joelonsoftware.com/news/20020912.html > That's a big part of the reason why some people are reticent. A feature that may be abused and cause people to harm themselves, oh my. Maybe we should remove the unlink() call from the kernel, it might be dangerous. People can abuse software in numerous ways to their own detriment. That's no reason not to write software in the first place. > > It's eerily similar to my utter > > discouragement at trying to get an obvious one-line patch added. > > Bug number? 225221 > > The way > > new contributors are repressed is unlike anything I've experienced or > > witnessed on any other open source project. > > Ever worked on Mozilla? ;-) Nope! > I don't think it's an acceptance thing - no-one's being excluded because > they are new. It's a time thing and a priorities thing - we have very > little time, and a set of priorities which may not be the same as yours. I can sympathise with that. > As my Bugzilla Etiquette document says, "Open Source does not mean 'the > developers must do my bidding'". That's not what I'm looking for and I don't think that's what the folks whining about custom fields ongoing neglect are looking for. -- No, no, you're not thinking, you're just being logical. -Niels Bohr, physicist (1885-1962) From chicks at chicks.net Tue Mar 9 13:29:28 2004 From: chicks at chicks.net (Christopher Hicks) Date: Tue, 9 Mar 2004 08:29:28 -0500 (EST) Subject: Contibuting to Bugzilla (was: The Road to 2.18) In-Reply-To: Message-ID: On Mon, 8 Mar 2004, David Miller wrote: > Knowing the time period around which you started contributing, I have no > problem believing this is the experience you had, as much as it pains me > to admit it. I'm glad it wasn't just me. > In short, I sincerely hope that over the last month or two, and from > this point forward, that nobody has been getting ignored the way you did > back then. I do apologize that it happened at all. Please understand > that all of us were very frustrated last year. Accepted. -- No, no, you're not thinking, you're just being logical. -Niels Bohr, physicist (1885-1962) From gerv at mozilla.org Tue Mar 9 14:18:52 2004 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 09 Mar 2004 14:18:52 +0000 Subject: The Road to 2.18 In-Reply-To: References: Message-ID: <404DD24C.80000@mozilla.org> Christopher Hicks wrote: >>>It's eerily similar to my utter >>>discouragement at trying to get an obvious one-line patch added. >> >>Bug number? > > 225221 ("longdescs table needs a primary key") I think calling that an "obvious one-line patch" is rather far from the truth. Jouni, bbaetz and I all had comments - which means that the right thing to do wasn't actually obvious. When told that there was need for more than the one-liner, you said: "Pushing all of this onto somebody trying to get their first simple patch through seems a very effective way to keep the database structure dorked." Who would you have do the necessary additional work if not you? On the other hand, I should have paid the bug more attention and given more help. Mea culpa - I just didn't have time. Apologies for that. Gerv From louie at ximian.com Tue Mar 9 14:32:37 2004 From: louie at ximian.com (Luis Villa) Date: Tue, 09 Mar 2004 09:32:37 -0500 Subject: The Need for Custom Fields [was Re: The Road to 2.18] In-Reply-To: <404D826F.8050206@mozilla.org> References: <404D826F.8050206@mozilla.org> Message-ID: <1078842757.10142.45.camel@localhost.localdomain> On Tue, 2004-03-09 at 08:38 +0000, Gervase Markham wrote: > Christopher Hicks wrote: > > Still!?!?!? One would think after as many times as we've been around this > > topic that some concensus might have developed. The inability of the core > > bugzilla developers to grapple with the desirability of custom fields at > > this point is truly surprising. > > Have you read Joel's article? > http://www.joelonsoftware.com/news/20020912.html > That's a big part of the reason why some people are reticent. Joel's argument, as usual, is 'I'm the center of the universe, and it wasn't necessary for me, so it isn't necessary for you.' I'm as against software options as anyone (see http://www106.pair.com/rhp/free-software-ui.html for some stuff I strongly believe in), and I suffer daily from the poor choice of additional bug fields in bugzilla.ximian.com. So I agree that 90% of additional bug fields put in by admins are a waste of everyone's time, and should be avoided. However, bug tracking systems are systems targeted at experienced expert users with often idiosyncratic needs. Expecting one size fits-all to actually work across the wide variety of distribution and development models out there isn't sane. Furthermore, it is something where poor field selection can make a piece of software nearly useless, unlike more general purpose software where the lack of an option can be irritating but usually not a showstopper. So those last 10% of genuinely useful and important custom fields are hugely important- they can make the difference between using bugzilla and not for many people. It impacts me in real life- not only is it a pain to get the fields I do need in b.g.o and b.x.c (talk to me about the 10K nasty keyword hacks we all have to use) but it is costing us users. Novell's development tools people were on the cusp of offering to switch the entire company over to bugzilla- but can't, and this is the killer. [Yes, they abuse custom fields horribly- but there are some that are very reasonable for how they do development internally, and it would not make sense to get rid of them.] Anyway, I can rant on and on about this, but I probably shouldn't. :) Stopping now- Luis From mdavis at laszlosystems.com Tue Mar 9 20:05:37 2004 From: mdavis at laszlosystems.com (Mark Davis) Date: Tue, 09 Mar 2004 12:05:37 -0800 Subject: The Road to 2.18 In-Reply-To: <404D826F.8050206@mozilla.org> References: <404D826F.8050206@mozilla.org> Message-ID: <404E2391.4040004@laszlosystems.com> Gervase Markham wrote: > Have you read Joel's article? > http://www.joelonsoftware.com/news/20020912.html > That's a big part of the reason why some people are reticent. I read it... mostly agreed. The custom fields in all of my installations are always required on the analysis side and not on the entry side. The main reasons for keeping things simple are valid for bug entry, but totally fall apart for prioritizing and allocating development resources. Another frequent complaint that causes the need for more fields deals with broad-based multi-platform compatibility. Custom fields aren't for everyone, but the arguements are not strong enough to suggest that they are for nobody. -- Mark Davis Quality Assurance Manager, Laszlo Systems (415) 241-2736 -- http://www.laszlosystems.com From justdave at bugzilla.org Tue Mar 9 20:09:55 2004 From: justdave at bugzilla.org (David Miller) Date: Tue, 9 Mar 2004 15:09:55 -0500 Subject: Fwd: website-beta feedback Message-ID: Mike Morgan is doing it, but I'll forward to developers so we can all discuss... Mike's willing to do whatever our consensus is on it. ----- Begin Forwarded Text ----- Date: Tue, 09 Mar 2004 19:22:04 +0000 From: Gervase Markham To: justdave at bugzilla.org Subject: website-beta feedback Here's some feedback on website-beta.bugzilla.org. [Dave: I've forgotten who you said is doing it. Can you forward this? Ta.] This is a look and feel overhaul, not a content overhaul, right? Because the content needs some serious work too - in most cases, via the judicious application of a virtual pair of scissors. For example, the front page and the download page are both terribly verbose. Having established that, some feedback: - The general layout and stylesheet are mostly fine. We could do with a few less sidebar links, but that would be a content overhaul. - What's the difference between the sidebar and the top bar? On mozilla.org, the top bar is permanent and the sidebar changes. We don't have that, so why have two? - Have we officially decided to adopt the sad-looking bug as our logo? - The search box should say "search bugzilla.org", and should do that. Gerv ----- End Forwarded Text ----- -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From justdave at bugzilla.org Tue Mar 9 20:54:03 2004 From: justdave at bugzilla.org (David Miller) Date: Tue, 9 Mar 2004 15:54:03 -0500 Subject: website-beta feedback In-Reply-To: <404E195C.3020804@mozilla.org> References: <404E195C.3020804@mozilla.org> Message-ID: On 3/9/2004 7:22 PM +0000, Gervase Markham wrote: > This is a look and feel overhaul, not a content overhaul, right? Because > the content needs some serious work too - in most cases, via the > judicious application of a virtual pair of scissors. For example, the > front page and the download page are both terribly verbose. It's actually intended to be both. The look and feel is what's mostly done now, he was going to start working on the content this coming week when he gets back from his trip. > - The general layout and stylesheet are mostly fine. We could do with a > few less sidebar links, but that would be a content overhaul. Which is the main intention. We decided to do the look and feel overhaul at the same time in order to fit in with Mozilla.org's look, since we're now a decent sized chunk of their advertising. > - What's the difference between the sidebar and the top bar? On > mozilla.org, the top bar is permanent and the sidebar changes. We > don't have that, so why have two? As part of the content overhaul, I was envisioning the sidebar containing links to things within each section (for developers, for administrators, for end-users, etc) and the top bar containing the links to each section. > - Have we officially decided to adopt the sad-looking bug as our logo? There's still room for dissension. Mozilla.org uses that logo on their website (they chose it without consulting us during their last site redesign, but I thought it looked good, and it fits well with the other mozilla.org stuff) -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From mars at mars-tmc.hq.themunicenter.com Wed Mar 10 04:21:17 2004 From: mars at mars-tmc.hq.themunicenter.com (Matthew A. R. Sherian) Date: Tue, 09 Mar 2004 23:21:17 -0500 Subject: When is this code block accessed? [aka search comments, by comment entry date] Message-ID: I am attemting to extend the query interface to allow searching on comments made after a certain date. i.e. a row is added to longdescs on 2004-01-10 on a bug changed on 2003-12-17. I'd like to catch bugs that have activity (in my environment cvs checkins). In my quest to ascertain a method by which this may be achieved I have come accross the section [% BLOCK a_comment %] [% IF count > 0 %]
------- Additional Comment #[% count %] From [% comment.name FILTER html %] [%+ comment.time %] ------- [% END %] in bug/comments.html.tmpl. I also have lines 525-530 of buglist.cgi: my @funcdefs = "^long_?desc,changedafter" => sub { my $table = "longdescs_$chartid"; push(@supptables, "longdescs $table"); push(@wherepart, "$table.bug_id = bugs.bug_id"); $term = "$table.bug_when > " . SqlQuote(SqlifyDate($v)); }, however it appears that funcdefs is just an abandoned data structure. I also inserted a new row into fielddefs and had it's name column set to longdescs.bug_when and then tried a drop_down OR search. This seems to work but only for a small subset of bugs that have comments on or after a date. If anyone could point me in the right direction to get this kind of search working through the user interface it would be most appreciated. From justdave at bugzilla.org Wed Mar 10 08:04:34 2004 From: justdave at bugzilla.org (David Miller) Date: Wed, 10 Mar 2004 03:04:34 -0500 Subject: 2.16 Reviewers? Message-ID: As we're approaching the branch point for 2.18, I'm interested in finding people who are currently living on the 2.16 branch with no immediate plans to upgrade who wouldn't mind taking over reviewer duties for the 2.16 branch, since we'll be supporting it still for a while after 2.18 is out, and most of us who have been dealing with it so far have been living on the tip and are having a hard time dealing with 2.16 already (as evidenced by the screw-up with 2.16.4 when we toasted xml.cgi). What should go on the 2.16 branch? Low-risk bugfixes and any future security fixes. What we need are people who are using a production system in 2.16.x that are willing to review patches aimed at the 2.16 branch (don't have to review them on your production system, but the fact that you're still running it in production means you'll be familiar with it). Any takers? I have no objections to having more than one person on this task (actually, more eyes is better ;) But our existing folks who have been doing this have been getting worse and worse at it as the differences between 2.16 and 2.17 continue to grow exponentially. :) The workload will probably not be that high... point releases to the 2.16 branch generally come about every 3 to 4 months, and typically have somewhere between 5 and 15 bugs fixed in them. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From guzman at varial.de Wed Mar 10 15:01:07 2004 From: guzman at varial.de (=?ISO-8859-1?Q?Guzm=E1n?=) Date: 10 Mar 2004 12:01:07 -0300 Subject: 2.16 Reviewers? In-Reply-To: References: Message-ID: <1078930870.2845.16.camel@daika> You have one now. My free time is not a bigpack, but I'll try to do my best. I'm working with 2.16.x since 2002. This is my first try to work with bugzilla developers, so please be so kind and explain me well my duty. Cheers Guzm?n From bugreport at peshkin.net Wed Mar 10 18:43:33 2004 From: bugreport at peshkin.net (Joel Peshkin) Date: Wed, 10 Mar 2004 10:43:33 -0800 Subject: 2.16 Reviewers? In-Reply-To: References: Message-ID: <404F61D5.7090006@peshkin.net> David Miller wrote: > >What we need are people who are using a production system in 2.16.x that >are willing to review patches aimed at the 2.16 branch (don't have to >review them on your production system, but the fact that you're still >running it in production means you'll be familiar with it). > >Any takers? > >I have no objections to having more than one person on this task (actually, >more eyes is better ;) But our existing folks who have been doing this >have been getting worse and worse at it as the differences between 2.16 and >2.17 continue to grow exponentially. :) > > > It might pay to solicit some 2.16 testers as a distinct group of people from the 2.16 reviewers. There may be some folks who are not comfortable enough with the internals to do the code inspection but still strong at testing it. -Joel From justdave at bugzilla.org Wed Mar 10 18:58:43 2004 From: justdave at bugzilla.org (David Miller) Date: Wed, 10 Mar 2004 13:58:43 -0500 Subject: 2.16 Reviewers? In-Reply-To: References: Message-ID: On 3/10/2004 3:04 AM -0500, David Miller wrote: > But our existing folks who have been doing this > have been getting worse and worse at it as the differences between 2.16 and > 2.17 continue to grow exponentially. :) And just to clarify this (since I heard comments), the above statement primarily refers to me, myself, and I. :) I've had a few cohorts along the way, but I've been the primary person reviewing patches on the 2.16 branch, and I no longer have confidence in my own abilities to keep them sane because I've been dealing with 2.17 for too long and the two code bases are just too different now. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From chicks at chicks.net Wed Mar 10 20:16:24 2004 From: chicks at chicks.net (Christopher Hicks) Date: Wed, 10 Mar 2004 15:16:24 -0500 (EST) Subject: bug 225221 "longdescs table needs a primary key" In-Reply-To: <404DD24C.80000@mozilla.org> Message-ID: On Tue, 9 Mar 2004, Gervase Markham wrote: > I think calling that an "obvious one-line patch" is rather far from the > truth. Jouni, bbaetz and I all had comments - which means that the right > thing to do wasn't actually obvious. Obviousness is obviously in the eyes of the beholder. > When told that there was need for more than the one-liner, you said: > "Pushing all of this onto somebody trying to get their first simple > patch through seems a very effective way to keep the database structure > dorked." Who would you have do the necessary additional work if not you? The point was that the additional work was needed for extending this to fix other bugs. The fix for this bug I believe is the one I've suggested. If people want to extend it to help fix other bugs, that's fine. What I put forward is a necessary prerequisite for any of those extensions. You need some way to uniquely refer to rows to update them which implies a primary key which leads to my straight forward patch. Given that all of this is brought up in a conversation about code quality, who ever reviewed things to allow a table to be created without a primary key in the first place? This violates such a fundamental rule of database design and maintenance it's difficult to believe it occurred in the first place and it's even more difficult to believe that it has persisted for so long with noone objecting. > On the other hand, I should have paid the bug more attention and given > more help. Mea culpa - I just didn't have time. Apologies for that. Life happens. -- No, no, you're not thinking, you're just being logical. -Niels Bohr, physicist (1885-1962) From justdave at bugzilla.org Wed Mar 10 19:23:38 2004 From: justdave at bugzilla.org (David Miller) Date: Wed, 10 Mar 2004 14:23:38 -0500 Subject: bug 225221 "longdescs table needs a primary key" In-Reply-To: References: Message-ID: On 3/10/2004 3:16 PM -0500, Christopher Hicks wrote: > Given that all of this is brought up in a conversation about code quality, > who ever reviewed things to allow a table to be created without a primary > key in the first place? This violates such a fundamental rule of database > design and maintenance it's difficult to believe it occurred in the first > place and it's even more difficult to believe that it has persisted for so > long with noone objecting. Best way to answer that is "we inherited it". That's been in the schema since before any of us ever saw Bugzilla. The reasons it hasn't been fixed yet got pretty well discussed on bug 225221. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From bz at barnson.org Wed Mar 10 19:31:34 2004 From: bz at barnson.org (Barnboy) Date: Wed, 10 Mar 2004 12:31:34 -0700 Subject: What ever happened to Bugzilla 3? Message-ID: <20040310193134.GC95914@barnson.org> What ever happened to Bugzilla 3? The last CVS log information is from November of 2001 regarding the design, and nothing after that. Did enthusiasm simply die off, or was there a larger reason for not wanting to move to a large redesign? I totally missed it somewhere along the line, and just had an off-list conversation with a couple of people completely unaware that, at one time, we'd planned a complete redesign with a normalized database, database independence, etc.etc. Not complaining, by the way, just curious where it ever went. Well, obviously, it went nowhere. And the obvious answer is probably "nobody wanted to do it". I'm interested if there were additional reasons... -- Matthew P. Barnson - - - - Thought for the moment: Don't worry over what other people are thinking about you. They're too busy worrying over what you are thinking about them. From dberlin at dberlin.org Wed Mar 10 19:40:04 2004 From: dberlin at dberlin.org (Daniel Berlin) Date: Wed, 10 Mar 2004 14:40:04 -0500 Subject: What ever happened to Bugzilla 3? In-Reply-To: <20040310193134.GC95914@barnson.org> References: <20040310193134.GC95914@barnson.org> Message-ID: On Mar 10, 2004, at 2:31 PM, Barnboy wrote: > What ever happened to Bugzilla 3? The last CVS log information is > from November of 2001 regarding the design, and nothing after that. > Did enthusiasm simply die off, or was there a larger reason for not > wanting to move to a large redesign? > > I totally missed it somewhere along the line, and just had an off-list > conversation with a couple of people completely unaware that, at one > time, we'd planned a complete redesign with a normalized database, > database independence, etc.etc. Not complaining, by the way, just > curious where it ever went. > > Well, obviously, it went nowhere. And the obvious answer is probably > "nobody wanted to do it". I'm interested if there were additional > reasons... Python wasn't on as many machines then as it is now, so they suspended development --Dan From dberlin at dberlin.org Wed Mar 10 19:49:55 2004 From: dberlin at dberlin.org (Daniel Berlin) Date: Wed, 10 Mar 2004 14:49:55 -0500 Subject: What ever happened to Bugzilla 3? In-Reply-To: References: <20040310193134.GC95914@barnson.org> Message-ID: <1AE430A1-72CC-11D8-B3AE-000A95DA505C@dberlin.org> On Mar 10, 2004, at 2:40 PM, Daniel Berlin wrote: > > On Mar 10, 2004, at 2:31 PM, Barnboy wrote: > >> What ever happened to Bugzilla 3? The last CVS log information is >> from November of 2001 regarding the design, and nothing after that. >> Did enthusiasm simply die off, or was there a larger reason for not >> wanting to move to a large redesign? >> >> I totally missed it somewhere along the line, and just had an >> off-list conversation with a couple of people completely unaware >> that, at one time, we'd planned a complete redesign with a normalized >> database, database independence, etc.etc. Not complaining, by the >> way, just curious where it ever went. >> >> Well, obviously, it went nowhere. And the obvious answer is probably >> "nobody wanted to do it". I'm interested if there were additional >> reasons... > > Python wasn't on as many machines then as it is now, so they suspended > development > For those who can't tell I'm kidding, the real answer is that it just kind of faded away. It still lives on in spirit somewhat, in the form of a few filed bugs that have been around forever. --Dan From ian at hixie.ch Wed Mar 10 20:57:51 2004 From: ian at hixie.ch (Ian Hickson) Date: Wed, 10 Mar 2004 20:57:51 +0000 (UTC) Subject: Fwd: What ever happened to Bugzilla 3? In-Reply-To: References: Message-ID: On Wed, 10 Mar 2004, Barnboy wrote: > > What ever happened to Bugzilla 3? Two things. 1. I did a lot of work on the proposed core (PLIF) but inexperience in designing that kind of system led me to design a "perfect" system, with the side-effect that it was ridiculously over-engineered and thus insanely slow and bloated. I actually still use that engine to power, amongst other things, my blog. It has definite performance issues that have actually been a problem even in my small-use scenarios. I'm working on making it better, but I doubt it will ever be suitable for large-scale enterprise software like Bugzilla. I actually quite like PLIF, it's a fun toy to work on. But that's all it is, really, a toy. 2. I got hired by Opera Software and now have less than zero time to devote to that kind of project, with no likelihood of any time appearing within the next two or three years. I recently reassigned all the B3 bugs I had assigned to me back to the default assignee. I still think there are a lot of things that were in the original proposals that Bugzilla should do. Some of them are being done on the 2.x codebase. When I started doing this, a number of people said "we should just do this incrementally". I'm slightly older now, and slightly wiser, and would now tend to agree. -- Ian Hickson )\._.,--....,'``. fL U+1047E /, _.. \ _\ ;`._ ,. http://index.hixie.ch/ `._.-(,_..'--(,_..'`-.;.' From gerv at mozilla.org Wed Mar 10 22:27:30 2004 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 10 Mar 2004 22:27:30 +0000 Subject: Fwd: What ever happened to Bugzilla 3? In-Reply-To: References: Message-ID: <404F9652.20707@mozilla.org> Ian Hickson wrote: > I still think there are a lot of things that were in the original > proposals that Bugzilla should do. Some of them are being done on the 2.x > codebase. When I started doing this, a number of people said "we should > just do this incrementally". I'm slightly older now, and slightly wiser, > and would now tend to agree. I also was in the rewrite camp; Myk was the older and wiser head. And I also would now agree with him :-) Gerv From matthew at barnson.org Wed Mar 10 22:37:19 2004 From: matthew at barnson.org (Matthew P. Barnson) Date: Wed, 10 Mar 2004 15:37:19 -0700 Subject: bug 225221 "longdescs table needs a primary key" In-Reply-To: References: <404DD24C.80000@mozilla.org> Message-ID: <20040310223719.GE47746@barnson.org> Three small words for why there's no primary key in longdescs: "Blame Terry Weissman" :) Bugzilla was his first learning experience in SQL... what was it, six years ago now? Dude, I've been doing this a long time; I remember playing with Bugzilla when bugzilla.mozilla.org had less than 10,000 bugs... Here was Terry's answer to me in 2000 asking a question about portability (from the old FAQ): "I'm not a real SQL or database person. I just wanted to make a useful tool, and build it on top of free software. So, I picked MySQL, and learned SQL by staring at the MySQL manual and some code lying around here, and wrote Bugzilla." So there's your answer for the database design. Yes, it should be fixed. But there's a definite historical reason for "common sense" database administration stuff being neglected in the creation of the tool for ya :) -- Matthew P. Barnson - - - - Thought for the moment: It will be generally found that those who sneer habitually at human nature and affect to despise it, are among its worst and least pleasant examples. -- Charles Dickens From matthew at barnson.org Wed Mar 10 22:40:59 2004 From: matthew at barnson.org (Matthew P. Barnson) Date: Wed, 10 Mar 2004 15:40:59 -0700 Subject: bug 225221 "longdescs table needs a primary key" In-Reply-To: References: Message-ID: <20040310224059.GF47746@barnson.org> On Wed, Mar 10, 2004 at 02:23:38PM -0500, David Miller wrote: > Best way to answer that is "we inherited it". That's been in the schema > since before any of us ever saw Bugzilla. The reasons it hasn't been fixed > yet got pretty well discussed on bug 225221. It almost makes me long for the old days when Tara's rule on checking in was: "Don't fuck up the tree. Don't go on a drunken binge and fuck up other people's projects. Don't fuck up b.m.o. Otherwise, have fun." I think that viewpoint drove Dawn crazy with late night fixes to b.m.o. more than once... I wonder why I'm feeling so nostalgic today? -- Matthew P. Barnson - - - - Thought for the moment: "I cannot and will not cut my conscience to fit this year's fashions." -- Lillian Hellman From justdave at bugzilla.org Wed Mar 10 22:50:25 2004 From: justdave at bugzilla.org (David Miller) Date: Wed, 10 Mar 2004 17:50:25 -0500 Subject: bug 225221 "longdescs table needs a primary key" In-Reply-To: <20040310224059.GF47746@barnson.org> References: <20040310224059.GF47746@barnson.org> Message-ID: On 3/10/2004 3:40 PM -0700, Matthew P. Barnson wrote: > I think that viewpoint drove Dawn crazy with late night fixes to b.m.o. >more than once... Ah yes, I remember those long nights in IRC helping Dawn track down those bugs after a b.m.o upgrade :) The last few b.m.o upgrades have paled by comparison because we're doing decent with reviews :) -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From justdave at bugzilla.org Thu Mar 11 01:10:53 2004 From: justdave at bugzilla.org (David Miller) Date: Wed, 10 Mar 2004 20:10:53 -0500 Subject: Win32: what PPM repository to suggest in checksetup.pl? In-Reply-To: References: Message-ID: On 3/9/2004 1:03 PM +0200, Andrei Benea wrote: > Justdave suggested in: > > http://bugzilla.mozilla.org/show_bug.cgi?id=236664#c9 > > to discuss on this list the ppm repository to be included in Bugzilla's > Windows installation instructions (checksetup.pl). The proposed URL is now > > http://www.apache.org/dist/perl/win32-bin/ppms/ > > Mirrors for this repository can be found at: > > http://www.apache.org/dyn/closer.cgi/perl/win32-bin/ppms/ > > I've chosen this one because it includes all ActivePerl packages needed by > Bugzilla except Chart::Base (which is optional). > > Andrei. We're trying to make checksetup.pl more friendly to Win32. Part of this is having the "missing perl modules" output actually give the necessary commands to use PPM to install the Perl modules if running on Win32. The problem is: not all of the modules we require are available in ActiveState's official PPM repository. Thus the patch on the above-mentioned bug also changes the output to suggest using Apache's PPM repository. The call here is to get opinions on this from Windows folks of whether this is a good repository to suggest, or if there's another we should be using? We've recommended OpenInteract's repository for the Template and AppConfig modules in the docs, but that was only because Template-Toolkit's site suggests that one for obtaining Template Toolkit. And apparently OpenInteract's site doesn't have some of the other modules. Thoughts anyone? -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From etzwane at schwag.org Thu Mar 11 02:27:26 2004 From: etzwane at schwag.org (Sean McAfee) Date: Wed, 10 Mar 2004 21:27:26 -0500 Subject: The Road to 2.18 Message-ID: <20040311022726.E077EC45E@diggity.schwag.org> I should've jumped in well before now, but I've been ill for the last few days. I'll respond to several messages in this thread at once. Gervase Markham wrote: >Mark Davis wrote: >> What are the odds of 91037 making it in to 2.18? >[That's Custom Fields] Near-zero, I'd say. If any custom fields patch >gets anywhere near getting checked in, I'd want to take the time to take >a long hard look at its architecture. And I'm sure I'm not the only one. May I ask, then, what it would take to get an evaluation of my custom fields patch of February 13 started? I'm willing to do whatever it takes to move this issue along; make myself available to discuss the architecture; whatever. I think my implementation is very solid. It's been in use here at my workplace (Transmeta) in a production environment since October. One department is using it now; another is set to follow suit this Friday; others will adopt it within a few weeks. As a replacement for the bloated, proprietary TeamTrack system we had been shackled to, Bugzilla plus my custom field enhancements has been a great success. I would *dearly* love to help roll the patch into the core, not only because I want to give back to the community (with Transmeta's blessing, of course, on whose dime I created the bulk of the code), but also because it would free me from sole responsibility for maintaining the patch. Stuart Donaldson wrote: >It would be a big win from the users perspective to get even a partial >solution towards custom fields get into the system for the next release. >This would lock-down a supported schema with a migration path in case >the approach were to change. All these caveats about applying the custom >fields patches because there is "no guarantee that this will be the way >we do it" are holding some people back from trying it out. My patch represents such a partial solution. I've built numerous higher-level features on the basic functionality of the patch--transaction logging and workflow support, to name the two biggest ones--without changing the basic schema. Gervase Markham wrote: >Indeed. And that's something we want to maintain. Locking down the >schema is to be avoided - because we want to be able to say "actually, >this is all wrong, we want to do it differently." Well, one obvious solution is to require that any custom fields schema be orthogonal to the basic schema. My own schema fulfills this condition, save for some foreign key references (to PRODUCTS, PROFILES, etc) that are ignored by MySQL anyway. And later: >For a change of this magnitude, it would be wrong to lock down the >schema until the Bugzilla core team has: > >- decided whether we want custom fields at all Is it too much to ask for a definitive answer to this question, soonish? >- if we do, written a design for them Must this be done by the core team? I'd be happy to write a document describing the design of my patch. (Yeah, it's a little bit backwards, I know.) >- written the actual patch (either based on existing one, or different) Obviously I'm pulling for my own implementation here. >The great thing about Free software is that people can take it in >another direction if they like. That's what the custom fields patch >basically is. If the people maintaining that patch want to set up a >website, or a wiki, or a mailing list, to make it easier for those who >want it to get it, that's fine. I'd be happy to do this, if only the status of custom fields would be decided one way or the other. >But we won't and can't promise that that >particular patch will get integrated, or that whatever patch does get >integrated will work anything like that one, or that one of us will >write migration code. In the case of my patch, no migration code is necessary, thanks to the previously-mentioned orthogonality. --Sean From gerv at mozilla.org Thu Mar 11 04:07:55 2004 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 11 Mar 2004 04:07:55 +0000 Subject: The Road to 2.18 In-Reply-To: <20040311022726.E077EC45E@diggity.schwag.org> References: <20040311022726.E077EC45E@diggity.schwag.org> Message-ID: <404FE61B.1080703@mozilla.org> Sean McAfee wrote: > Well, one obvious solution is to require that any custom fields schema be > orthogonal to the basic schema. My own schema fulfills this condition, save > for some foreign key references (to PRODUCTS, PROFILES, etc) that are > ignored by MySQL anyway. If you remember, this feature of your patch was actually one of the biggest issues people had with it at review - it duplicated a lot of Bugzilla function, both in terms of code and tables. For example, applying the patch gives one two tables full of bug activity data... But re-reviewing your patch is probably not the point of this thread. Gerv From gerv at mozilla.org Thu Mar 11 04:13:08 2004 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 11 Mar 2004 04:13:08 +0000 Subject: Quick holiday note Message-ID: <404FE754.5000205@mozilla.org> Just in case anyone wonders, I'm away until Sunday evening on a company ski trip. (There are some small compensations to not being able to hack on Mozilla/Bugzilla full time...) Gerv From etzwane at schwag.org Thu Mar 11 05:32:10 2004 From: etzwane at schwag.org (Sean McAfee) Date: Thu, 11 Mar 2004 00:32:10 -0500 Subject: The Road to 2.18 In-Reply-To: <404FE61B.1080703@mozilla.org> Message-ID: <20040311053210.4830AC45E@diggity.schwag.org> Gervase Markham wrote: >Sean McAfee wrote: >> Well, one obvious solution is to require that any custom fields schema be >> orthogonal to the basic schema. My own schema fulfills this condition, save >> for some foreign key references (to PRODUCTS, PROFILES, etc) that are >> ignored by MySQL anyway. >If you remember, this feature of your patch was actually one of the >biggest issues people had with it at review - it duplicated a lot of >Bugzilla function, both in terms of code and tables. For example, >applying the patch gives one two tables full of bug activity data... No, six. I added five, one for each major custom field data type. The original activity table would have lost information in many cases if it were pressed to handle custom fields in the same way it handles built-in fields, a situation which, I found it hard to believe, seemed to be considered acceptable. >But re-reviewing your patch is probably not the point of this thread. Yes, especially since the patch I most recently submitted is a stripped-down one that doesn't log custom field data changes at all. --Sean From kiko at async.com.br Thu Mar 11 13:52:29 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Thu, 11 Mar 2004 10:52:29 -0300 Subject: website-beta feedback In-Reply-To: References: <404E195C.3020804@mozilla.org> Message-ID: <20040311135229.GE1052@async.com.br> On Tue, Mar 09, 2004 at 03:54:03PM -0500, David Miller wrote: > On 3/9/2004 7:22 PM +0000, Gervase Markham wrote: > > > This is a look and feel overhaul, not a content overhaul, right? Because > > the content needs some serious work too - in most cases, via the > > judicious application of a virtual pair of scissors. For example, the > > front page and the download page are both terribly verbose. > > It's actually intended to be both. The look and feel is what's mostly done > now, he was going to start working on the content this coming week when he > gets back from his trip. Why not commit the layout changes and fix the content incrementally? Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From kiko at async.com.br Thu Mar 11 14:34:26 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Thu, 11 Mar 2004 11:34:26 -0300 Subject: When is this code block accessed? [aka search comments, by comment entry date] In-Reply-To: References: Message-ID: <20040311143426.GI1052@async.com.br> On Tue, Mar 09, 2004 at 11:21:17PM -0500, Matthew A. R. Sherian wrote: > have activity (in my environment cvs checkins). In my quest to ascertain a > method by which this may be achieved I have come accross the section > > [% BLOCK a_comment %] > [% IF count > 0 %] >
> ------- Additional Comment > #[% count %] From href="mailto:[% comment.email FILTER html %]">[% comment.name FILTER > html %] [%+ comment.time %] ------- > > [% END %] > > in bug/comments.html.tmpl. Yes, this is the comment header, which is echoed before each comment in a bug report (show_bug). It's quite unrelated to the code below: > I also have lines 525-530 of buglist.cgi: > my @funcdefs = > > "^long_?desc,changedafter" => sub { > my $table = "longdescs_$chartid"; > push(@supptables, "longdescs $table"); push(@wherepart, > "$table.bug_id = bugs.bug_id"); $term = "$table.bug_when > " > . SqlQuote(SqlifyDate($v)); > }, > > > however it appears that funcdefs is just an abandoned data structure. This now lives in Search.pm, though I don't see why funcdefs is an "abandoned data structure". > I also inserted a new row into fielddefs and had it's name column set to > longdescs.bug_when and then tried a drop_down OR search. This seems to > work but only for a small subset of bugs that have comments on or after a > date. Look at the SQL being generated and do a query manually to see what should be happening that isn't? Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From suson at TuckerEnergy.com Thu Mar 11 17:22:23 2004 From: suson at TuckerEnergy.com (Steven Suson) Date: Thu, 11 Mar 2004 11:22:23 -0600 Subject: The Road to 2.18 In-Reply-To: <20040311022726.E077EC45E@diggity.schwag.org> References: <20040311022726.E077EC45E@diggity.schwag.org> Message-ID: <4050A04F.2010608@TuckerEnergy.com> I too perhaps should've posted my two cents worth earlier. There are just two things that I wanted to say. One, that when discussing the design issues, waiting, etc., that "best is the enemy of good enough." And the other, that my company has been waiting approximately a year for an extension of functionality to bugzilla, which is FULLY provided by custom fields. I pity our poor secretary who is forced to supplement our use of bugzilla, using paper and PDF forms. Therefore, I heartily support Sean in his efforts. Steven Suson Sean McAfee wrote: >I should've jumped in well before now, but I've been ill for the last few >days. I'll respond to several messages in this thread at once. > >Gervase Markham wrote: > > >>Mark Davis wrote: >> >> >>>What are the odds of 91037 making it in to 2.18? >>> >>> > > > >>[That's Custom Fields] Near-zero, I'd say. If any custom fields patch >>gets anywhere near getting checked in, I'd want to take the time to take >>a long hard look at its architecture. And I'm sure I'm not the only one. >> >> > >May I ask, then, what it would take to get an evaluation of my custom fields >patch of February 13 started? I'm willing to do whatever it takes to move >this issue along; make myself available to discuss the architecture; >whatever. > >I think my implementation is very solid. It's been in use here at my >workplace (Transmeta) in a production environment since October. One >department is using it now; another is set to follow suit this Friday; >others will adopt it within a few weeks. As a replacement for the >bloated, proprietary TeamTrack system we had been shackled to, Bugzilla plus >my custom field enhancements has been a great success. I would *dearly* >love to help roll the patch into the core, not only because I want to give >back to the community (with Transmeta's blessing, of course, on whose dime I >created the bulk of the code), but also because it would free me from sole >responsibility for maintaining the patch. > > >Stuart Donaldson wrote: > > >>It would be a big win from the users perspective to get even a partial >>solution towards custom fields get into the system for the next release. >>This would lock-down a supported schema with a migration path in case >>the approach were to change. All these caveats about applying the custom >>fields patches because there is "no guarantee that this will be the way >>we do it" are holding some people back from trying it out. >> >> > >My patch represents such a partial solution. I've built numerous >higher-level features on the basic functionality of the patch--transaction >logging and workflow support, to name the two biggest ones--without changing >the basic schema. > > >Gervase Markham wrote: > > >>Indeed. And that's something we want to maintain. Locking down the >>schema is to be avoided - because we want to be able to say "actually, >>this is all wrong, we want to do it differently." >> >> > >Well, one obvious solution is to require that any custom fields schema be >orthogonal to the basic schema. My own schema fulfills this condition, save >for some foreign key references (to PRODUCTS, PROFILES, etc) that are >ignored by MySQL anyway. > >And later: > > > >>For a change of this magnitude, it would be wrong to lock down the >>schema until the Bugzilla core team has: >> >>- decided whether we want custom fields at all >> >> > >Is it too much to ask for a definitive answer to this question, soonish? > > > >>- if we do, written a design for them >> >> > >Must this be done by the core team? I'd be happy to write a document >describing the design of my patch. (Yeah, it's a little bit backwards, I >know.) > > > >>- written the actual patch (either based on existing one, or different) >> >> > >Obviously I'm pulling for my own implementation here. > > > >>The great thing about Free software is that people can take it in >>another direction if they like. That's what the custom fields patch >>basically is. If the people maintaining that patch want to set up a >>website, or a wiki, or a mailing list, to make it easier for those who >>want it to get it, that's fine. >> >> > >I'd be happy to do this, if only the status of custom fields would be >decided one way or the other. > > > >>But we won't and can't promise that that >>particular patch will get integrated, or that whatever patch does get >>integrated will work anything like that one, or that one of us will >>write migration code. >> >> > >In the case of my patch, no migration code is necessary, thanks to the >previously-mentioned orthogonality. > > >--Sean >- >To view or change your list settings, click here: > > > From bugreport at peshkin.net Thu Mar 11 17:50:15 2004 From: bugreport at peshkin.net (Joel Peshkin) Date: Thu, 11 Mar 2004 09:50:15 -0800 Subject: The Road to 2.18 - Customfields In-Reply-To: <4050A04F.2010608@TuckerEnergy.com> References: <20040311022726.E077EC45E@diggity.schwag.org> <4050A04F.2010608@TuckerEnergy.com> Message-ID: <4050A6D7.807@peshkin.net> Steven Suson wrote: > I too perhaps should've posted my two cents worth earlier. There are > just two things that I wanted to say. One, that when discussing the > design issues, waiting, etc., that "best is the enemy of good enough." > And the other, that my company has been waiting approximately a year > for an extension of functionality to bugzilla, which is FULLY provided > by custom fields. I pity our poor secretary who is forced to > supplement our use of bugzilla, using paper and PDF forms. Therefore, > I heartily support Sean in his efforts. > > Steven Suson Unfortunately, none of the patches seen to date is "good enough" at all. The team cannot just merge in a patch that is not written in a manner that will permit smooth upgrades from version to version, etc.. I agree that we should not require the first customfields patch to do everything imaginable. There are a base set of design decisions that need to be agreed to and then a patch, consistent with the standards of the overall project, can be written an landed. The problem is that nobody has done that. I suggest that the following requirements be accepted..... 1) Schema changes must be made by checksetup in the standard way 2) Creation of new fields can be done either using the web (preferred) or localconfig/checksetup 3) All activity log functions must still work with customfields. If this means that the activity log mechansim needs to be replaced, the old log information must be ported by the upgrade. 4) GUI forms must include custom fields and work, but need not be pretty 5) Possibly in a subsequent release, custom templates should be able to "hook" custom fields and handle them, overriding the builtin GUI generation that may be ugly or insufficiently localized. 6) Customfields that are missing from a bug form should never cause an error or deletion of a customfield when a bug edit is processed. 7) Email notification of customfield changes should work and be selectable. 8) If customfields are product-specific, no information should be lost on product change, even if the bug is changed to a product that does not use that field and back again. 9) No really bad SQL should be used. Multiple choices must be handled by one-to-many relations in the database, not by concatenating multiple items in strings. Notice that I didn't even say if I care if the patch supports multiple datatypes, etc... so long as the schema doesn't preclude adding additional types later. Now, if someone writes a real proposal, we can get consensus on it and go forward. Someone could also skip that step, spend months writing code, and then get frustrated when the code cannot land. -Joel [not on anything, especially software] From jay at veggiespam.com Thu Mar 11 19:35:45 2004 From: jay at veggiespam.com (jay ball) Date: Thu, 11 Mar 2004 14:35:45 -0500 Subject: The Road to 2.18 In-Reply-To: <404BAE53.1040208@mozilla.org> References: <20040306165224.GB1097@async.com.br> <404A1C52.8050001@laszlosystems.com> <404BAE53.1040208@mozilla.org> Message-ID: <4ACA4C2D-7393-11D8-8B7A-003065D5C6A2@veggiespam.com> My 0.02? Freeze it now and call it 2.18 ASAP. With the new bugzilla release cycle of early and often, we're going to have 2.20 in four to six months anyway. Many people [including myself] want the custom fields patch, but there is no way to vet it in the small time period before March 15 (or whenever the suggested freeze date was). So, forget it for 2.18 and begin the major push to get it into 2.20. It has been 1.5 years since 2.16 and bugzilla has evolved since then. let's give the bugzilla public the wonderful new features that are added now, in a non-beta (2.17) form. -j From mkanat at kerio.com Thu Mar 11 21:34:24 2004 From: mkanat at kerio.com (Maxwell Kanat-Alexander) Date: Thu, 11 Mar 2004 13:34:24 -0800 Subject: The Road to 2.18 - Customfields In-Reply-To: <4050A6D7.807@peshkin.net> References: <20040311022726.E077EC45E@diggity.schwag.org> <4050A04F.2010608@TuckerEnergy.com> <4050A6D7.807@peshkin.net> Message-ID: <1079040863.4145.5.camel@localhost.localdomain> On Thu, 2004-03-11 at 09:50, Joel Peshkin wrote: > Now, if someone writes a real proposal, we can get consensus on it and > go forward. Someone could also skip that step, spend months writing > code, and then get frustrated when the code cannot land. I have the beginnings of something like this posted at (bug 91037 comment 239). It's a broad overview, more of a game plan than anything else. -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 etzwane at schwag.org Fri Mar 12 02:40:28 2004 From: etzwane at schwag.org (Sean McAfee) Date: Thu, 11 Mar 2004 21:40:28 -0500 Subject: Partial custom fields design document Message-ID: <20040312024028.893EBC45E@diggity.schwag.org> Hi folks-- It's been suggested that the best way to kick-start the process of getting custom fields functionality into the core is to start with a design document that all can agree on. Makes sense to me. Accordingly, I've started drawing up a document that describes the design of my latest custom fields patch. Rather than wait the several days I anticipate it will take to crank the entire thing out, I plan to post it here, incrementally, as I complete it. I'll work any changes agreed upon by the group into subsequent versions. The initial cut is attached; have at it! Notes: I've added some comments about the document itself; they appear in square brackets. I really need to add an introductory "basic terminology" section. I use set terminology to describe selection fields which really needs some set-up. --Sean -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cfdesign.txt URL: From bruce.armstrong at teamsybase.com Fri Mar 12 03:08:54 2004 From: bruce.armstrong at teamsybase.com (Bruce Armstrong [TeamSybase]) Date: Thu, 11 Mar 2004 19:08:54 -0800 (PST) Subject: Win32: what PPM repository to suggest in checksetup.pl? In-Reply-To: Message-ID: <20040312030854.26605.qmail@web12506.mail.yahoo.com> My bad. It's the build of ActiveState that is the issue. I just tried with the later build and the instructions in the documentation are correct for that one. David Miller wrote:On 3/9/2004 1:03 PM +0200, Andrei Benea wrote: > Justdave suggested in: > > http://bugzilla.mozilla.org/show_bug.cgi?id=236664#c9 > > to discuss on this list the ppm repository to be included in Bugzilla's > Windows installation instructions (checksetup.pl). The proposed URL is now > > http://www.apache.org/dist/perl/win32-bin/ppms/ > > Mirrors for this repository can be found at: > > http://www.apache.org/dyn/closer.cgi/perl/win32-bin/ppms/ > > I've chosen this one because it includes all ActivePerl packages needed by > Bugzilla except Chart::Base (which is optional). > > Andrei. We're trying to make checksetup.pl more friendly to Win32. Part of this is having the "missing perl modules" output actually give the necessary commands to use PPM to install the Perl modules if running on Win32. The problem is: not all of the modules we require are available in ActiveState's official PPM repository. Thus the patch on the above-mentioned bug also changes the output to suggest using Apache's PPM repository. The call here is to get opinions on this from Windows folks of whether this is a good repository to suggest, or if there's another we should be using? We've recommended OpenInteract's repository for the Template and AppConfig modules in the docs, but that was only because Template-Toolkit's site suggests that one for obtaining Template Toolkit. And apparently OpenInteract's site doesn't have some of the other modules. Thoughts anyone? -- 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: 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 bruce.armstrong at teamsybase.com Fri Mar 12 03:00:37 2004 From: bruce.armstrong at teamsybase.com (Bruce Armstrong [TeamSybase]) Date: Thu, 11 Mar 2004 19:00:37 -0800 (PST) Subject: Win32: what PPM repository to suggest in checksetup.pl? In-Reply-To: Message-ID: <20040312030037.24242.qmail@web12506.mail.yahoo.com> I've never found it too much of a problem to load the majority from ActiveState and get the rest from OpenInteract. I would note, however, the the instructions in the documentation for getting the files from OpenInteract are wrong. Where it indicates: ppm repository add oi http://openinteract.sourceforge.net/ppmpackages I believe it should actually be: ppm set repository oi http://openinteract.sourceforge.net/ppmpackages When I try to install the ones from Apache, I get: Error installing package 'AppConfig': Read a PPD for 'AppConfig', but it is not intended for this build of Perl (MSWin32-x86-multi-thread) Is it because of the build of ActiveState I'm on? David Miller wrote: We're trying to make checksetup.pl more friendly to Win32. Part of this is having the "missing perl modules" output actually give the necessary commands to use PPM to install the Perl modules if running on Win32. The problem is: not all of the modules we require are available in ActiveState's official PPM repository. Thus the patch on the above-mentioned bug also changes the output to suggest using Apache's PPM repository. The call here is to get opinions on this from Windows folks of whether this is a good repository to suggest, or if there's another we should be using? We've recommended OpenInteract's repository for the Template and AppConfig modules in the docs, but that was only because Template-Toolkit's site suggests that one for obtaining Template Toolkit. And apparently OpenInteract's site doesn't have some of the other modules. Thoughts anyone? -- 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: 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 bugreport at peshkin.net Fri Mar 12 03:26:52 2004 From: bugreport at peshkin.net (Joel Peshkin) Date: Thu, 11 Mar 2004 19:26:52 -0800 Subject: Partial custom fields design document In-Reply-To: <20040312024028.893EBC45E@diggity.schwag.org> References: <20040312024028.893EBC45E@diggity.schwag.org> Message-ID: <40512DFC.1040403@peshkin.net> This is a very good start. In the interest of getting the discussion rolling while Gerv isn't here ;-), I'll respond on the list. I think enough of the team is keen on seeing a good customfields implementation that this deserves this level of attention. Please correct me if I am wrong. It seems that multiple fields may wind up using the same selection id. In that case, would it make sense to treat the cf_selection records as items that have a human-understandable name (like a typedef) so that an administrator who is creating 3 or 4 fields of the same type has a name with which to refer to that type?? I am a bit confused about as_string. Is that supposed to be something that is fixed for each field type or something that is configured somewhere? In either case, this should be hookable (eventually) so someone doing a small amount of coding can add a function that gets called for conversion and validation of specific custom fields. Similarly, other items that lend themselves to a degree of customization that confounds web configuarbility can be made hookable (after the initial patch lands). I suspect that the system will need a notion of the length of a custom field and, possibly, a flag indicating if the actual contents of the custom field should be logged in the activity log and if it should be included in bugmail. One additional schema change is probably needed. I suggest that bugs_activity have a new field that distinguishes between schema fields (references to fielddefs) and custom fields. There is probably enough information in the schema to make boolean searches work. A subsequent enhancment can make the fields more casually searchable. -Joel From stu at asyn.com Fri Mar 12 05:20:48 2004 From: stu at asyn.com (Stuart Donaldson) Date: Thu, 11 Mar 2004 21:20:48 -0800 Subject: The Road to 2.18 - Customfields In-Reply-To: <4050A6D7.807@peshkin.net> References: <20040311022726.E077EC45E@diggity.schwag.org> <4050A04F.2010608@TuckerEnergy.com> <4050A6D7.807@peshkin.net> Message-ID: <405148B0.1010901@asyn.com> This is a great start at getting a set of requirements identified. I think we should prioritize the requirements. What is mandatory, and what would be nice to have. Mandatory means that a solution MUST meat that requirement. The nice to haves, are things that could be done by a solution, but are not required right now. These might also be debatable as to their need, or how to do it. Some of the things Joel mentions I think fit the later category... Joel Peshkin wrote: > Steven Suson wrote: > >> I too perhaps should've posted my two cents worth earlier. There are >> just two things that I wanted to say. One, that when discussing the >> design issues, waiting, etc., that "best is the enemy of good >> enough." And the other, that my company has been waiting >> approximately a year for an extension of functionality to bugzilla, >> which is FULLY provided by custom fields. I pity our poor secretary >> who is forced to supplement our use of bugzilla, using paper and PDF >> forms. Therefore, I heartily support Sean in his efforts. >> >> Steven Suson > > > > Unfortunately, none of the patches seen to date is "good enough" at > all. The team cannot just merge in a patch that is not written in a > manner that will permit smooth upgrades from version to version, etc.. > > I agree that we should not require the first customfields patch to do > everything imaginable. There are a base set of design decisions that > need to be agreed to and then a patch, consistent with the standards > of the overall project, can be written an landed. The problem is that > nobody has done that. > > I suggest that the following requirements be accepted..... > > 1) Schema changes must be made by checksetup in the standard way > 2) Creation of new fields can be done either using the web (preferred) > or localconfig/checksetup Someone recently posted a concern about using a web interface to create custom fields. I share the concern that a web interface makes it too easy to add custom fields, and may encourage bad use of bugzilla. I think it would make much more sense to be implemented via localconfig/checksetup such that it forces a little more forethought into the process. Furthermore, I suspect a localconfig/checksetup solution would reduce the complexity of the implementation. A requirement for a web interface for the setup should be postponed. Although if we want the option of a web interface, then we should state that the entire custom fields definition must be represented in the database, rather than in code loaded in localconfig. > 3) All activity log functions must still work with customfields. If > this means that the activity log mechansim needs to be replaced, the > old log information must be ported by the upgrade. > 4) GUI forms must include custom fields and work, but need not be pretty > 5) Possibly in a subsequent release, custom templates should be able > to "hook" custom fields and handle them, overriding the builtin GUI > generation that may be ugly or insufficiently localized. > 6) Customfields that are missing from a bug form should never cause an > error or deletion of a customfield when a bug edit is processed. > 7) Email notification of customfield changes should work and be > selectable. > 8) If customfields are product-specific, no information should be lost > on product change, even if the bug is changed to a product that does > not use that field and back again. > 9) No really bad SQL should be used. Multiple choices must be handled > by one-to-many relations in the database, not by concatenating > multiple items in strings. > > Notice that I didn't even say if I care if the patch supports multiple > datatypes, etc... so long as the schema doesn't preclude adding > additional types later. > > Now, if someone writes a real proposal, we can get consensus on it and > go forward. Someone could also skip that step, spend months writing > code, and then get frustrated when the code cannot land. > > -Joel [not on anything, especially software] > > > - > To view or change your list settings, click here: > > > From justdave at bugzilla.org Fri Mar 12 05:53:38 2004 From: justdave at bugzilla.org (David Miller) Date: Fri, 12 Mar 2004 00:53:38 -0500 Subject: The Road to 2.18 - Customfields In-Reply-To: <405148B0.1010901@asyn.com> References: <20040311022726.E077EC45E@diggity.schwag.org> <4050A04F.2010608@TuckerEnergy.com> <4050A6D7.807@peshkin.net> <405148B0.1010901@asyn.com> Message-ID: On 3/11/2004 9:20 PM -0800, Stuart Donaldson wrote: > Joel Peshkin wrote: > >> 2) Creation of new fields can be done either using the web (preferred) >> or localconfig/checksetup > > Someone recently posted a concern about using a web interface to create > custom fields. I share the concern that a web interface makes it too > easy to add custom fields, and may encourage bad use of bugzilla. I > think it would make much more sense to be implemented via > localconfig/checksetup such that it forces a little more forethought > into the process. Furthermore, I suspect a localconfig/checksetup > solution would reduce the complexity of the implementation. I also think a web interface is a bad idea. My thinking is on the Database Independence track (which seems to be in high gear now, as well, and will probably land on the trunk VERY shortly after we branch for 2.18). Many companies choose to have DBAs to handle their databases. Most companies who do this also have a requirement that nobody but the DBA can make schema changes in the production databases. The Bugzilla application (and hence, probably the bugzilla admin) in such an environment will probably not have sufficient access to the database to make schema changes. Which means the DBA will be the one to run checksetup.pl (or the database setup script once it gets separated out -- it will get separated at some point due to the above), and specifying their own userID while doing it. The current design calls for a dynamic way of defining custom fields without making schema changes. This is a lofty design goal, and really good for keeping things simple for the admin. But the performance on queries is going to suck badly once you try to get querying working on custom fields, because of all the extra table joins you need in order to match the fields. I remain convinced that the best way to get performance out of it is going to be to add a column for each field to a single table (for fields that aren't multi-selects, anyway -- joins for those are going to be unavoidable) so that the entire table only has to be joined once, no matter how many custom fields you have. That table would basically be an add-on to the bugs table, and would be a straight one-to-one join with a row for each bug. When you add a single-select or freeform field, it gets added as a column in that table. Which brings me back to schema changes... A performant way to do custom fields would require schema changes to set them up, so they would need to be defined in a datafile that can be accessed by the database setup script. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From etzwane at schwag.org Fri Mar 12 06:58:25 2004 From: etzwane at schwag.org (Sean McAfee) Date: Fri, 12 Mar 2004 01:58:25 -0500 Subject: Partial custom fields design document In-Reply-To: <40512DFC.1040403@peshkin.net> Message-ID: <20040312065825.C28D0C45E@diggity.schwag.org> Joel Peshkin wrote: >It seems that multiple fields may wind up using the same selection id. Yeah, that's the idea. > In that case, would it make sense to treat the cf_selection records as >items that have a human-understandable name (like a typedef) so that an >administrator who is creating 3 or 4 fields of the same type has a name >with which to refer to that type?? Maybe. I think my original schema had such a selection name column, but I never got around to writing any code that used it, so I took it out again. An alternative to providing a name is to just let the administarator say "when creating this new selection field, use the same selection set as that other field". >I am a bit confused about as_string. Is that supposed to be something >that is fixed for each field type or something that is configured >somewhere? It's fixed for each field type. In my current implementation it's a no-op for integer and string fields; for date fields, it converts the date fields' [ $year, $month, $day ] representation (more convenient for code to deal with, I think) to a string representation. The custom fields template then looks liks this: [% IF field.is_selection %] [% # ... %] [% ELSE %] [% value = field.as_string(field.value) %] [% # do stuff with value %] [% END %] Another alternative is to bless the arrays holding the date data into a class that overloads stringification. That would eliminate the need for as_string. I'm a bit reluctant to employ magic for so small a gain, though. --Sean From chicks at chicks.net Fri Mar 12 17:36:35 2004 From: chicks at chicks.net (Christopher Hicks) Date: Fri, 12 Mar 2004 12:36:35 -0500 (EST) Subject: The Road to 2.18 - Customfields In-Reply-To: Message-ID: On Fri, 12 Mar 2004, David Miller wrote: > But the performance on queries is going to suck badly once you try to > get querying working on custom fields, because of all the extra table > joins you need in order to match the fields. The only reason those extra table joins would be happening is if you were querying on a custom field and in that case there would only be one extra join per field queried. That seems a pretty small price to pay. Presumably most of the time people are going to be querying on the non-custom fields anyway which won't be any worse than it is now. -- No, no, you're not thinking, you're just being logical. -Niels Bohr, physicist (1885-1962) From bugreport at peshkin.net Fri Mar 12 16:47:39 2004 From: bugreport at peshkin.net (Joel Peshkin) Date: Fri, 12 Mar 2004 08:47:39 -0800 Subject: The Road to 2.18 - Customfields In-Reply-To: References: Message-ID: <4051E9AB.2080701@peshkin.net> Christopher Hicks wrote: >On Fri, 12 Mar 2004, David Miller wrote: > > > >>But the performance on queries is going to suck badly once you try to >>get querying working on custom fields, because of all the extra table >>joins you need in order to match the fields. >> >> > >The only reason those extra table joins would be happening is if you were >querying on a custom field and in that case there would only be one extra >join per field queried. That seems a pretty small price to pay. >Presumably most of the time people are going to be querying on the >non-custom fields anyway which won't be any worse than it is now. > > > Er... One left join per field either selected or used as a criteria. I'd like to understand the actual performance impact of this. In many ways, Sean's approach is cleaner than addind a bunch of columns to the tables, but we need some numbers on the performance impact before we can decide. -Joel From mkanat at kerio.com Fri Mar 12 17:55:10 2004 From: mkanat at kerio.com (Maxwell Kanat-Alexander) Date: Fri, 12 Mar 2004 09:55:10 -0800 Subject: The Road to 2.18 - Customfields In-Reply-To: <4051E9AB.2080701@peshkin.net> References: <4051E9AB.2080701@peshkin.net> Message-ID: <1079114109.4264.2.camel@localhost.localdomain> On Fri, 2004-03-12 at 08:47, Joel Peshkin wrote: > Er... > > One left join per field either selected or used as a criteria. > > I'd like to understand the actual performance impact of this. There was a discussion about this in the bug itself, I believe: And following comments. -M From mkanat at kerio.com Fri Mar 12 17:58:12 2004 From: mkanat at kerio.com (Maxwell Kanat-Alexander) Date: Fri, 12 Mar 2004 09:58:12 -0800 Subject: The Road to 2.18 - Customfields In-Reply-To: <405148B0.1010901@asyn.com> References: <20040311022726.E077EC45E@diggity.schwag.org> <4050A04F.2010608@TuckerEnergy.com> <4050A6D7.807@peshkin.net> <405148B0.1010901@asyn.com> Message-ID: <1079114292.4264.4.camel@localhost.localdomain> On Thu, 2004-03-11 at 21:20, Stuart Donaldson wrote: > This is a great start at getting a set of requirements identified. > > I think we should prioritize the requirements. I attempted to do something like this on my last comment on the custom fields bug: -M From chicks at chicks.net Fri Mar 12 19:01:25 2004 From: chicks at chicks.net (Christopher Hicks) Date: Fri, 12 Mar 2004 14:01:25 -0500 (EST) Subject: The Road to 2.18 - Customfields In-Reply-To: <4051E9AB.2080701@peshkin.net> Message-ID: On Fri, 12 Mar 2004, Joel Peshkin wrote: > In many ways, Sean's approach is cleaner than addind a bunch of columns > to the tables, For instance, we would need to avoid custom columns conflicting with future official columns which implies munging the custom columns with ugly names and ugly is bad. :) -- No, no, you're not thinking, you're just being logical. -Niels Bohr, physicist (1885-1962) From bcwhite at precidia.com Fri Mar 12 18:21:11 2004 From: bcwhite at precidia.com (Brian White) Date: Fri, 12 Mar 2004 13:21:11 -0500 Subject: Copying Everything to Global Email Address Message-ID: <4051FF97.44996036@precidia.com> In going through the bugzilla (v2.16.4) preferences, I was hoping to find the ability to set an email address that would receive a copy of every bug- relate email that went out. I see none. Is there any way to do this? I'd like to use such to forward all our bug info to a newsgroup for easier access. I could use the "qa" address, but I'd rather reserve this for other uses. Any ideas? Thanks! Brian ( bcwhite at precidia.com ) ------------------------------------------------------------------------------- What we can easily see is only a small percentage of what is possible. Imagination is having the vision to see what is just below the surface; to picture that which is essential, but invisible to the eye. From mdavis at laszlosystems.com Fri Mar 12 18:30:18 2004 From: mdavis at laszlosystems.com (Mark Davis) Date: Fri, 12 Mar 2004 10:30:18 -0800 Subject: Copying Everything to Global Email Address In-Reply-To: <4051FF97.44996036@precidia.com> References: <4051FF97.44996036@precidia.com> Message-ID: <405201BA.1020002@laszlosystems.com> Brian White wrote: >In going through the bugzilla (v2.16.4) preferences, I was hoping to find >the ability to set an email address that would receive a copy of every bug- >relate email that went out. I see none. > That sounds like a feature request... add default cc filed for components... The QA contact does this, but having a default cc would be nice. -- Mark Davis Quality Assurance Manager, Laszlo Systems (415) 241-2736 -- http://www.laszlosystems.com From kniht at us.ibm.com Fri Mar 12 18:32:20 2004 From: kniht at us.ibm.com (Jon Tollefson) Date: Fri, 12 Mar 2004 12:32:20 -0600 Subject: The Road to 2.18 - Customfields In-Reply-To: References: Message-ID: <1079116340.28574.297.camel@skynet.rchland.ibm.com> On Fri, 2004-03-12 at 13:01, Christopher Hicks wrote: > On Fri, 12 Mar 2004, Joel Peshkin wrote: > > > In many ways, Sean's approach is cleaner than addind a bunch of columns > > to the tables, > > For instance, we would need to avoid custom columns conflicting with > future official columns which implies munging the custom columns with ugly > names and ugly is bad. :) Might we want some of the official columns(eg. status whiteboard, keywords, target milestone, qa contact, etc) to be implemented as custom fields? Then sites could easily remove those fields if they didn't need them. Jon From zach at zachlipton.com Fri Mar 12 18:38:50 2004 From: zach at zachlipton.com (Zach Lipton) Date: Fri, 12 Mar 2004 10:38:50 -0800 Subject: Copying Everything to Global Email Address In-Reply-To: <4051FF97.44996036@precidia.com> References: <4051FF97.44996036@precidia.com> Message-ID: <817BDCE2-7454-11D8-81D0-000A95985212@zachlipton.com> One way you can probably do this is to edit the newchangedmail setting in editparams. You can change the line: To: %to% And make it: To: %to%, foo at bar.com This should send all new or changed bugmails to that address in addition to the addresses it would normally send the message to. Another way to do this would be to create a bugzilla account and have it "watch" all the component owners or qa contacts, but it's probably cleaner to do it in the params. Zach On Mar 12, 2004, at 10:21 AM, Brian White wrote: > In going through the bugzilla (v2.16.4) preferences, I was hoping to > find > the ability to set an email address that would receive a copy of every > bug- > relate email that went out. I see none. > > Is there any way to do this? I'd like to use such to forward all our > bug > info to a newsgroup for easier access. > > I could use the "qa" address, but I'd rather reserve this for other > uses. > > Any ideas? Thanks! > > Brian > ( bcwhite at precidia.com ) > > ----------------------------------------------------------------------- > -------- > What we can easily see is only a small percentage of what is > possible. > Imagination is having the vision to see what is just below the > surface; > to picture that which is essential, but invisible to the eye. > - > To view or change your list settings, click here: > > From preed at sigkill.com Fri Mar 12 18:43:26 2004 From: preed at sigkill.com (J. Paul Reed) Date: Fri, 12 Mar 2004 10:43:26 -0800 Subject: Copying Everything to Global Email Address In-Reply-To: <405201BA.1020002@laszlosystems.com> References: <4051FF97.44996036@precidia.com> <405201BA.1020002@laszlosystems.com> Message-ID: <20040312184326.GC9312@sigkill.com> On 12 Mar 2004 at 10:30:18, Mark Davis arranged the bits on my disk to say: > That sounds like a feature request... add default cc filed for > components... The QA contact does this, but having a default cc would be > nice. Bug 38922. 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 bcwhite at precidia.com Fri Mar 12 19:14:04 2004 From: bcwhite at precidia.com (Brian White) Date: Fri, 12 Mar 2004 14:14:04 -0500 Subject: Copying Everything to Global Email Address References: <4051FF97.44996036@precidia.com> <405201BA.1020002@laszlosystems.com> <20040312184326.GC9312@sigkill.com> Message-ID: <40520BFC.9DE0C728@precidia.com> > > That sounds like a feature request... add default cc filed for > > components... The QA contact does this, but having a default cc would be > > nice. > > Bug 38922. Thanks! Looking at that, though, it seems a bit different. That's for users to watch selected components. I guess the closest to what I have in mind would be an additional column under the "email" tab on the "prefs" page with a heading of "other". So, if you're not the reporter and you're not the assignee and you're not the QA Contact and you're not on the CC list and you're not on the Voter list, then follow what was selected under "Other". Thoughts? Brian ( bcwhite at precidia.com ) ------------------------------------------------------------------------------- Far away there in the sunshine are my highest aspirations. I may not reach them, but I can look up and see their beauty, believe in them, and try to follow where they lead. From stu at asyn.com Fri Mar 12 19:34:03 2004 From: stu at asyn.com (Stuart Donaldson) Date: Fri, 12 Mar 2004 11:34:03 -0800 Subject: The Road to 2.18 - Customfields In-Reply-To: <1079116340.28574.297.camel@skynet.rchland.ibm.com> References: <1079116340.28574.297.camel@skynet.rchland.ibm.com> Message-ID: <405210AB.2030008@asyn.com> Jon Tollefson wrote: >On Fri, 2004-03-12 at 13:01, Christopher Hicks wrote: > > >>On Fri, 12 Mar 2004, Joel Peshkin wrote: >> >> >> >>>In many ways, Sean's approach is cleaner than addind a bunch of columns >>>to the tables, >>> >>> >>For instance, we would need to avoid custom columns conflicting with >>future official columns which implies munging the custom columns with ugly >>names and ugly is bad. :) >> >> > >Might we want some of the official columns(eg. status whiteboard, >keywords, target milestone, qa contact, etc) to be implemented as custom >fields? Then sites could easily remove those fields if they didn't need >them. > > > There has been concern about the number of tables and left-joins involved with custom fields. There is also some interest in per-project custom fields. Personally, I just need a couple of global fields, and do not need the per-project fields. Does it make sense to have two categories of fields. Global, and Per-Project? The global fields could be added columns in bugs table. That way existing columns could be easily incorporated as custom global fields. From dberlin at dberlin.org Fri Mar 12 19:53:16 2004 From: dberlin at dberlin.org (Daniel Berlin) Date: Fri, 12 Mar 2004 14:53:16 -0500 Subject: The Road to 2.18 - Customfields In-Reply-To: <405210AB.2030008@asyn.com> References: <1079116340.28574.297.camel@skynet.rchland.ibm.com> <405210AB.2030008@asyn.com> Message-ID: On Mar 12, 2004, at 2:34 PM, Stuart Donaldson wrote: > Jon Tollefson wrote: > >> On Fri, 2004-03-12 at 13:01, Christopher Hicks wrote: >> >>> On Fri, 12 Mar 2004, Joel Peshkin wrote: >>> >>> >>>> In many ways, Sean's approach is cleaner than addind a bunch of >>>> columns >>>> to the tables, >>>> >>> For instance, we would need to avoid custom columns conflicting with >>> future official columns which implies munging the custom columns >>> with ugly names and ugly is bad. :) >>> >> >> Might we want some of the official columns(eg. status whiteboard, >> keywords, target milestone, qa contact, etc) to be implemented as >> custom >> fields? Then sites could easily remove those fields if they didn't >> need >> them. >> >> > There has been concern about the number of tables and left-joins > involved with custom fields. Well, Sean obviously has a working implementation of this. Sean, how many bugs does your install have? What is performance like on your database for queries against multiple custom fields? > From alicia.pena at s2io.com Fri Mar 12 20:17:55 2004 From: alicia.pena at s2io.com (Alicia Pena) Date: Fri, 12 Mar 2004 12:17:55 -0800 Subject: upgrading from 2.14.1 to 2.16.5 Message-ID: <200403122006.i2CK6LUg010377@guinness.s2io.com> Does anyone know of any major concerns or 'gotchas' to look out for when upgrading from version 2.14.1 to the current stable version 2.16.5? Any extra patches or applications needed for all of the enhancements or is it safe to simply do the upgrade? If there are any BIG changes or enhancements you'd like to point out to us, I'd really appreciate that info as well. We're poking around the bug logs but there are obviously many changes made between those versions to read through. Thank you for any help you can provide, Alicia -------------- next part -------------- An HTML attachment was scrubbed... URL: From justdave at bugzilla.org Fri Mar 12 20:05:46 2004 From: justdave at bugzilla.org (David Miller) Date: Fri, 12 Mar 2004 15:05:46 -0500 Subject: The Road to 2.18 - Customfields In-Reply-To: References: <1079116340.28574.297.camel@skynet.rchland.ibm.com> <405210AB.2030008@asyn.com> Message-ID: On 3/12/2004 2:53 PM -0500, Daniel Berlin wrote: > Well, Sean obviously has a working implementation of this. > Sean, how many bugs does your install have? > What is performance like on your database for queries against multiple > custom fields? Last I heard, he doesn't have query implemented yet. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From justdave at bugzilla.org Fri Mar 12 20:08:21 2004 From: justdave at bugzilla.org (David Miller) Date: Fri, 12 Mar 2004 15:08:21 -0500 Subject: The Road to 2.18 - Customfields In-Reply-To: <1079116340.28574.297.camel@skynet.rchland.ibm.com> References: <1079116340.28574.297.camel@skynet.rchland.ibm.com> Message-ID: On 3/12/2004 12:32 PM -0600, Jon Tollefson wrote: > On Fri, 2004-03-12 at 13:01, Christopher Hicks wrote: >> On Fri, 12 Mar 2004, Joel Peshkin wrote: >> >> > In many ways, Sean's approach is cleaner than addind a bunch of columns >> > to the tables, >> >> For instance, we would need to avoid custom columns conflicting with >> future official columns which implies munging the custom columns with ugly >> names and ugly is bad. :) > > Might we want some of the official columns(eg. status whiteboard, > keywords, target milestone, qa contact, etc) to be implemented as custom > fields? Then sites could easily remove those fields if they didn't need > them. Yes, that's been the plan, which is why I'm worried about performance impact on table joins. We've been intending that several of the existing columns which were capable of being defined within the custom fields framework would be converted to custom fields so that they could be removed by people that don't want them. This means that people that don't remove them would have a potential performance impact if custom fields don't perform as well as the base fields do. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From mdavis at laszlosystems.com Fri Mar 12 20:12:50 2004 From: mdavis at laszlosystems.com (Mark Davis) Date: Fri, 12 Mar 2004 12:12:50 -0800 Subject: The Road to 2.18 - Customfields In-Reply-To: References: <1079116340.28574.297.camel@skynet.rchland.ibm.com> <405210AB.2030008@asyn.com> Message-ID: <405219C2.5060305@laszlosystems.com> David Miller wrote: >On 3/12/2004 2:53 PM -0500, Daniel Berlin wrote: > > > >>Well, Sean obviously has a working implementation of this. >>Sean, how many bugs does your install have? >>What is performance like on your database for queries against multiple >>custom fields? >> >> > >Last I heard, he doesn't have query implemented yet. > > Boolean queries are here and they work alright. I'm running customfields against 2.17.6 and have not noticed any performance hit with our installation (3500 bugs). The interface fro queries against custom fields in its current incarnation is painful... -- Mark Davis Quality Assurance Manager, Laszlo Systems (415) 241-2736 -- http://www.laszlosystems.com From justdave at bugzilla.org Fri Mar 12 20:14:33 2004 From: justdave at bugzilla.org (David Miller) Date: Fri, 12 Mar 2004 15:14:33 -0500 Subject: upgrading from 2.14.1 to 2.16.5 In-Reply-To: <200403122006.i2CK6LUg010377@guinness.s2io.com> References: <200403122006.i2CK6LUg010377@guinness.s2io.com> Message-ID: On 3/12/2004 12:17 PM -0800, Alicia Pena wrote: >If there are any BIG changes or enhancements you'd like to point out to >us, I'd really appreciate that info as well. We're poking around the bug >logs but there are obviously many changes made between those versions to >read through. I'll reply to this on mozilla-webtools at mozilla.org, which is where support questions go. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From alicia.pena at s2io.com Fri Mar 12 20:39:50 2004 From: alicia.pena at s2io.com (Alicia Pena) Date: Fri, 12 Mar 2004 12:39:50 -0800 Subject: upgrading from 2.14.1 to 2.16.5 In-Reply-To: Message-ID: <200403122028.i2CKSGUg014232@guinness.s2io.com> Thank you. Where exactly on that site should I go to find it? -----Original Message----- From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] On Behalf Of David Miller Sent: Friday, March 12, 2004 12:15 PM To: developers at bugzilla.org Subject: Re: upgrading from 2.14.1 to 2.16.5 On 3/12/2004 12:17 PM -0800, Alicia Pena wrote: >If there are any BIG changes or enhancements you'd like to point out to >us, I'd really appreciate that info as well. We're poking around the bug >logs but there are obviously many changes made between those versions to >read through. I'll reply to this on mozilla-webtools at mozilla.org, which is where support questions go. -- 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 Fri Mar 12 20:35:27 2004 From: justdave at bugzilla.org (David Miller) Date: Fri, 12 Mar 2004 15:35:27 -0500 Subject: upgrading from 2.14.1 to 2.16.5 In-Reply-To: <200403122028.i2CKSGUg014232@guinness.s2io.com> References: <200403122028.i2CKSGUg014232@guinness.s2io.com> Message-ID: Links to the archives and subscription information are on http://www.bugzilla.org/discussion.html On 3/12/2004 12:39 PM -0800, Alicia Pena wrote: > Thank you. Where exactly on that site should I go to find it? > > -----Original Message----- > From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] > On Behalf Of David Miller > Sent: Friday, March 12, 2004 12:15 PM > To: developers at bugzilla.org > Subject: Re: upgrading from 2.14.1 to 2.16.5 > > On 3/12/2004 12:17 PM -0800, Alicia Pena wrote: > >>If there are any BIG changes or enhancements you'd like to point out to >>us, I'd really appreciate that info as well. We're poking around the bug >>logs but there are obviously many changes made between those versions to >>read through. > > I'll reply to this on mozilla-webtools at mozilla.org, which is where support > questions go. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From etzwane at schwag.org Fri Mar 12 21:14:00 2004 From: etzwane at schwag.org (Sean McAfee) Date: Fri, 12 Mar 2004 16:14:00 -0500 Subject: The Road to 2.18 - Customfields In-Reply-To: Message-ID: <20040312211400.E090CC45E@diggity.schwag.org> David Miller wrote: >On 3/12/2004 2:53 PM -0500, Daniel Berlin wrote: >> Well, Sean obviously has a working implementation of this. >> Sean, how many bugs does your install have? >> What is performance like on your database for queries against multiple >> custom fields? >Last I heard, he doesn't have query implemented yet. Not implemented? It's practically the crown jewel of my patch. Here's a message I posted back in October that describes it: http://bugzilla.org/cgi-bin/mj_wwwusr?user=&passw=&list=developers&brief=on&func=archive-get-part&extra=200310/17 Our installation has, let's see...1760 bugs. Here's a little program I just wrote to gauge query performance: ---------------------------------------- #!/usr/bin/perl use Bugzilla::CustomFields::Query; use strict; do 'globals.pl'; @ARGV > 0 && @ARGV % 3 == 0 or die "usage: $0 field op value [ field op value ... ]\n"; my @where; for (my $i = 0; $i < @ARGV; $i += 3) { push @where, [ @ARGV[ $i, $i+1, $i+2 ] ]; } my $count = 0; my $iterator = bug_iterator(where => \@where, custom_fields => 0); while (my $bug = $iterator->()) { ++$count; } print "$count bugs found.\n"; ---------------------------------------- I ran this program several times with progressively more query terms. "short_desc" is the short description from the BUGS table. bash-2.05a$ time ./count-bugs.pl short_desc allwords Astro 344 bugs found. real 0m1.037s user 0m0.713s sys 0m0.068s tlc_incident_num is an integer field; querying against it introduces a join against the CF_INTEGER table. bash-2.05a$ time ./count-bugs.pl short_desc allwords Astro tlc_incident_num '>=' 2700 117 bugs found. real 0m0.834s user 0m0.717s sys 0m0.053s tlc_platform_serial_num is a short string field; querying against it introduces a join against the CF_SHORTSTRING table. bash-2.05a$ time ./count-bugs.pl short_desc allwords Astro tlc_incident_num '>=' 2700 tlc_platform_serial_num allwords 'n/a' 21 bugs found. real 0m0.801s user 0m0.689s sys 0m0.059s tlc_reproducibility_details is a long string field; querying against it introduces a join against the CF_LONGSTRING table. bash-2.05a$ time ./count-bugs.pl short_desc allwords Astro tlc_incident_num '>=' 2700 tlc_platform_serial_num allwords 'n/a' tlc_reproducibility_details allwords happens 10 bugs found. real 0m0.813s user 0m0.701s sys 0m0.053s It would appear that the differences in times in all three of the later cases are just noise. In any case, no significant performance hit is evident. --Sean From chicks at chicks.net Fri Mar 12 22:18:47 2004 From: chicks at chicks.net (Christopher Hicks) Date: Fri, 12 Mar 2004 17:18:47 -0500 (EST) Subject: The Road to 2.18 - Customfields In-Reply-To: <20040312211400.E090CC45E@diggity.schwag.org> Message-ID: On Fri, 12 Mar 2004, Sean McAfee wrote: > It would appear that the differences in times in all three of the later > cases are just noise. In any case, no significant performance hit is > evident. Bravo. Real data stumps more fear and loathing. -- No, no, you're not thinking, you're just being logical. -Niels Bohr, physicist (1885-1962) From justdave at bugzilla.org Fri Mar 12 21:20:18 2004 From: justdave at bugzilla.org (David Miller) Date: Fri, 12 Mar 2004 16:20:18 -0500 Subject: The Road to 2.18 - Customfields In-Reply-To: <20040312211400.E090CC45E@diggity.schwag.org> References: <20040312211400.E090CC45E@diggity.schwag.org> Message-ID: On 3/12/2004 4:14 PM -0500, Sean McAfee wrote: >>Last I heard, he doesn't have query implemented yet. > > Not implemented? It's practically the crown jewel of my patch. Ah. cool. :) I misread something on the bug then, my bad. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From bbaetz at acm.org Fri Mar 12 22:27:26 2004 From: bbaetz at acm.org (Bradley Baetz) Date: Sat, 13 Mar 2004 09:27:26 +1100 Subject: The Road to 2.18 - Customfields In-Reply-To: <1079116340.28574.297.camel@skynet.rchland.ibm.com> References: <1079116340.28574.297.camel@skynet.rchland.ibm.com> Message-ID: <20040312222726.GA1810@mango.home> On Fri, Mar 12, 2004 at 12:32:20PM -0600, Jon Tollefson wrote: > Might we want some of the official columns(eg. status whiteboard, > keywords, target milestone, qa contact, etc) to be implemented as custom > fields? Then sites could easily remove those fields if they didn't need > them. Yes! Any custom fields solution must be able to do that. Not necessarily for the first round of patches which goes in, but the implementation must not prclude that happening in the future. (QA contact is a bit tricker because it needs email hooks, but status whiteboard and target milestone/version should be trivialy doable.) Bradley From dcullen7 at csibugs.com Sat Mar 13 12:03:28 2004 From: dcullen7 at csibugs.com (David Cullen) Date: Sat, 13 Mar 2004 07:03:28 -0500 Subject: Non-root installs Message-ID: <00a901c408f3$3296b830$204ca8c0@SOJOURNER> Dear Bugzilla Folks, I just did a non-root install of Bugzilla. I had to overcome the hurdle of downloading Perl packages from CPAN and installing them in a sub-tree of my home directory. I also used the conversion command found on lines 988-990 of Bugzilla-Guide.txt to handle not being able to symlink /usr/bin/perl to /usr/bonsaitools/bin/perl. However, I had to add a "use" command to _every_ .cgi and .pl file to include the proper library directory: use lib '/home/bugfixer/perl/lib/site_perl/5.6.1'; Is there some global include file that such lines can be put into? If not, should one be added to save the headache of running vi *.cgi *.pl and pasting the same line 49 times? This would also help in the event that a non-root install of bugzilla needed to be moved from one server to another. Since I don't have root access, I can't modify the PERLLIB environment variable for the apache user. Can bugzilla be patched so that every .cgi and .pl file includes an empty module and people can add installation specific commands to that module? I would be willing to create, test, and submit such a patch. Also, is there any interest in adding a special sub-section for non-root users to the INSTALLATION section of the documentation? David (from the Laptop) From bugreport at peshkin.net Sat Mar 13 15:19:49 2004 From: bugreport at peshkin.net (Joel Peshkin) Date: Sat, 13 Mar 2004 07:19:49 -0800 Subject: Non-root installs In-Reply-To: <00a901c408f3$3296b830$204ca8c0@SOJOURNER> References: <00a901c408f3$3296b830$204ca8c0@SOJOURNER> Message-ID: <40532695.6010508@peshkin.net> David Cullen wrote: > >Also, is there any interest in adding a special sub-section for >non-root users to the INSTALLATION section of the documentation? > > > There is a bug open for this and contributions to it are certainly welcome... http://bugzilla.mozilla.org/show_bug.cgi?id=207039 Your question is addressed in ... http://bugzilla.mozilla.org/attachment.cgi?id=127738&action=view Though it is probably still a case of doing it the hard way. The method of creating a perl installation as a user is also discussed in the bug. From matthew at barnson.org Sat Mar 13 19:59:08 2004 From: matthew at barnson.org (Matthew P. Barnson) Date: Sat, 13 Mar 2004 12:59:08 -0700 Subject: Non-root installs In-Reply-To: <40532695.6010508@peshkin.net> References: <00a901c408f3$3296b830$204ca8c0@SOJOURNER> <40532695.6010508@peshkin.net> Message-ID: <20040313195908.GA22179@barnson.org> Non-root installs are easy; I've done them for two clients recently, and it didn't involve more than a quick find-and-replace (I use sed, not the perl one-liner) to fix the shebang line, and it was done. As long as they are all using the same custom version of perl, with the right modules installed, you don't need an additoinal 'use' line. -- Matthew P. Barnson - - - - Thought for the moment: Adore, v.: To venerate expectantly. -- Ambrose Bierce, "The Devil's Dictionary" From bugreport at peshkin.net Sun Mar 14 01:06:28 2004 From: bugreport at peshkin.net (Joel Peshkin) Date: Sat, 13 Mar 2004 17:06:28 -0800 Subject: Non-root installs In-Reply-To: <20040313195908.GA22179@barnson.org> References: <00a901c408f3$3296b830$204ca8c0@SOJOURNER> <40532695.6010508@peshkin.net> <20040313195908.GA22179@barnson.org> Message-ID: <4053B014.9000309@peshkin.net> Matthew P. Barnson wrote: >Non-root installs are easy; I've done them for two clients recently, and it didn't involve more than a quick find-and-replace (I use sed, not the perl one-liner) to fix the shebang line, and it was done. As long as they are all using the same custom version of perl, with the right modules installed, you don't need an additoinal 'use' line. > > > That is true if you have a custom install of perl (my favorite way). Others make their own local installs. Both are described in a documentation patch waiting for your review :-) From bugreport at peshkin.net Sun Mar 14 16:26:10 2004 From: bugreport at peshkin.net (Joel Peshkin) Date: Sun, 14 Mar 2004 08:26:10 -0800 Subject: The Road to 2.18 - Customfields In-Reply-To: <20040312222726.GA1810@mango.home> References: <1079116340.28574.297.camel@skynet.rchland.ibm.com> <20040312222726.GA1810@mango.home> Message-ID: <405487A2.9090703@peshkin.net> Bradley Baetz wrote: >Yes! Any custom fields solution must be able to do that. Not >necessarily for the first round of patches which goes in, but the >implementation must not prclude that happening in the future. (QA >contact is a bit tricker because it needs email hooks, but status >whiteboard and target milestone/version should be trivialy doable.) > > > So, if I focus on the bugs table itself, fields might fit into several categories... 1) "Core" fields that are integral to the way bugzilla itself operates. (Examples: bug_id, assigned_to, etc...) These would probably never become customfields, but some of the functions invented to handle customfields may be useful in handling these. 2) "Traditional" fields are fields that would have been customfields, but BMO and others needed them when customfields did not exist, so everyone has them and many sites use them. (Examples: status_whiteboard, URL, etc...) These could eventually become customfields if the functions invented to handle customfields, combined with hooks and template support, permit them to work just as well as they do now. 3) "Customfields" are the fields about which we have been debating. 4) "Site" fields are fields that have been hacked into sites by folks who needed them badly enough to patch them into checksetup, Search.pm, their templates, etc... If we decide to keep the customfields in the bugs table and have other tables that describe the presentation and proper handling of customfields, it should be possible to "adopt" a site field with the same mechanism as customfields and make it unnecessary for a site to maintain their old hacked code going forward while still keeping the data. With this in mind, I suggest the following view... a) Field definition of customfields be handled by editing "cf_config" and running checksetup. When a field is defined in cf_config, it should be added only if it previously did not exist. cf_config should prepend "cf_" to the field names of all new fields it creates, but it should permit a field without the "cf_" prefix to be specified for pre-existing fields. The information in cf_config should permit a field to be defined (like AddField and AddFDef did) as well as permitting additional indices to be defined. b) Once fields are defined and created by running checksetup, the web-based tools for handling customfields (hopefully very similar to those already done in the customfields patch) can be used to define how those fields are presented and used. c) Template authors should always be able to define a "hook" indicating to the automatic customfields presentation code that the template wants the automatic customfields code to omit a field and leave it to the template code to handle it. Standard templates could use this to continue to handle status_whiteboard and URL fields. Custom templates could use this to handle custom fields in any manner they choose. It probably makes sense to permit this hook to be processed on a per-template basis so that a site could use the automatic presentation of a field on a bug entry form while overriding that with a custom presentation on the "format for printing" page. Comments?? From gerv at mozilla.org Sun Mar 14 23:06:28 2004 From: gerv at mozilla.org (Gervase Markham) Date: Sun, 14 Mar 2004 23:06:28 +0000 Subject: Copying Everything to Global Email Address In-Reply-To: <817BDCE2-7454-11D8-81D0-000A95985212@zachlipton.com> References: <4051FF97.44996036@precidia.com> <817BDCE2-7454-11D8-81D0-000A95985212@zachlipton.com> Message-ID: <4054E574.8000703@mozilla.org> Zach Lipton wrote: > One way you can probably do this is to edit the newchangedmail setting > in editparams. You can change the line: As we say every time this is suggested, the problem with it is that you get one copy of every mail sent out - so if a change engenders five mails, you get five copies to foo at bar.com. A better way in 2.16 is to hack processmail to push the address onto the @cc (I think) array at the appropriate moment. Gerv From gerv at mozilla.org Sun Mar 14 23:17:05 2004 From: gerv at mozilla.org (Gervase Markham) Date: Sun, 14 Mar 2004 23:17:05 +0000 Subject: The Road to 2.18 - Customfields In-Reply-To: References: Message-ID: <4054E7F1.5000309@mozilla.org> Christopher Hicks wrote: > Bravo. Real data stumps more fear and loathing. But can you accurately scale up data gathered from an installation of only 1760 bugs? Gerv From mkanat at kerio.com Sun Mar 14 23:23:06 2004 From: mkanat at kerio.com (Maxwell Kanat-Alexander) Date: Sun, 14 Mar 2004 15:23:06 -0800 Subject: The Road to 2.18 - Customfields In-Reply-To: <4054E7F1.5000309@mozilla.org> References: <4054E7F1.5000309@mozilla.org> Message-ID: <1079306586.15743.3.camel@max.localdomain> On Sun, 2004-03-14 at 15:17, Gervase Markham wrote: > Christopher Hicks wrote: > > Bravo. Real data stumps more fear and loathing. > > But can you accurately scale up data gathered from an installation of > only 1760 bugs? Do we have a script to generate a testing installation with hundreds of thousands of bugs? If we don't, it sure would be useful in general. -M From etzwane at schwag.org Mon Mar 15 07:21:05 2004 From: etzwane at schwag.org (Sean McAfee) Date: Mon, 15 Mar 2004 02:21:05 -0500 Subject: The Road to 2.18 - Customfields In-Reply-To: <4054E7F1.5000309@mozilla.org> Message-ID: <20040315072105.5757FC45E@diggity.schwag.org> Gervase Markham wrote: >Christopher Hicks wrote: >> Bravo. Real data stumps more fear and loathing. >But can you accurately scale up data gathered from an installation of >only 1760 bugs? Fair enough. I copied the production database I used to gather my previously-described data over to a test machine, then ran a program which replicated each existing bug one hundred times. I did not replicate notes or attachments, since they're irrelevant for this purpose. The production database had grown to about 2100 bugs; between that and a few dry runs of the replication program, I eventually got this as a starting point: bash-2.05a$ mysql -e 'select count(*) from bugs' +----------+ | count(*) | +----------+ | 214524 | +----------+ Here are the new results. Against short_desc only: bash-2.05a$ time ./count-bugs.pl short_desc allwords Astro 35350 bugs found. real 0m35.397s user 0m4.890s sys 0m0.380s Against one custom fields table, CF_INTEGER: bash-2.05a$ time ./count-bugs.pl short_desc allwords Astro tlc_incident_num '>=' 2700 11817 bugs found. real 0m10.935s user 0m2.800s sys 0m0.240s Against a second custom fields table, CF_SHORTSTRING: bash-2.05a$ time ./count-bugs.pl short_desc allwords Astro tlc_incident_num '>=' 2700 tlc_platform_serial_num allwords 'n/a' 2121 bugs found. real 0m6.262s user 0m1.850s sys 0m0.170s Against a third custom fields table, CF_LONGSTRING: bash-2.05a$ time ./count-bugs.pl short_desc allwords Astro tlc_incident_num '>=' 2700 tlc_platform_serial_num allwords 'n/a' tlc_reproducibility_details allwords happens 1010 bugs found. real 0m4.902s user 0m1.760s sys 0m0.140s Far from revealing a performance penalty, it appears that the more (scalar) custom fields one queries against, the better the results. --Sean From bbaetz at acm.org Mon Mar 15 08:23:31 2004 From: bbaetz at acm.org (Bradley Baetz) Date: Mon, 15 Mar 2004 19:23:31 +1100 Subject: The Road to 2.18 - Customfields In-Reply-To: <1079306586.15743.3.camel@max.localdomain> References: <4054E7F1.5000309@mozilla.org> <1079306586.15743.3.camel@max.localdomain> Message-ID: <20040315082331.GA1280@mango.home> On Sun, Mar 14, 2004 at 03:23:06PM -0800, Maxwell Kanat-Alexander wrote: > On Sun, 2004-03-14 at 15:17, Gervase Markham wrote: > > Christopher Hicks wrote: > > > Bravo. Real data stumps more fear and loathing. > > > > But can you accurately scale up data gathered from an installation of > > only 1760 bugs? > > Do we have a script to generate a testing installation with hundreds of > thousands of bugs? If we don't, it sure would be useful in general. Yes - its attached to some bug somewhere, and I've posted it to this list before. It doesn't generate valid data for bz to work, but if you know the SQL you're going to end up with, it does work. The problem is that (esp with MySQL) the perf impact is when you ave lots of queries running at once, and some updates, and so on. thats ahrder to simulated. Bradley From bbaetz at acm.org Mon Mar 15 08:28:12 2004 From: bbaetz at acm.org (Bradley Baetz) Date: Mon, 15 Mar 2004 19:28:12 +1100 Subject: The Road to 2.18 - Customfields In-Reply-To: <20040315072105.5757FC45E@diggity.schwag.org> References: <4054E7F1.5000309@mozilla.org> <20040315072105.5757FC45E@diggity.schwag.org> Message-ID: <20040315082812.GB1280@mango.home> On Mon, Mar 15, 2004 at 02:21:05AM -0500, Sean McAfee wrote: > Far from revealing a performance penalty, it appears that the more (scalar) > custom fields one queries against, the better the results. Thats not really likely, unless mysql is scanning fewer rows due to additional constraints. Run each query a few times, and throw the first run away. Mem caching may account for that. Bradley From etzwane at schwag.org Mon Mar 15 19:41:39 2004 From: etzwane at schwag.org (Sean McAfee) Date: Mon, 15 Mar 2004 14:41:39 -0500 Subject: The Road to 2.18 - Customfields In-Reply-To: <20040315082812.GB1280@mango.home> Message-ID: <20040315194139.8A8ECC45E@diggity.schwag.org> Bradley Baetz wrote: >On Mon, Mar 15, 2004 at 02:21:05AM -0500, Sean McAfee wrote: >> Far from revealing a performance penalty, it appears that the more (scalar) >> custom fields one queries against, the better the results. >Thats not really likely, unless mysql is scanning fewer rows due to >additional constraints. It is scanning fewer rows, thanks to the indices on the field_id column in each of the custom field tables. For example, here's the SQL that gets generated (more or less) for the summary/integer field case: SELECT b.bug_id FROM bugs AS b, cf_integer AS cfi WHERE (INSTR(LOWER(b.short_desc), 'astro') AND cfi.value >= 2700) AND cfi.field_id = 1 AND b.bug_id = cfi.bug_id Thanks to the index, the MySQL server knows only to check those rows in CF_INTEGER where the field_id is 1. Because of the inner join, it apparently can figure out that it only has to test the rows in BUGS that match, by bug_id, the rows in CF_INTEGER. >Run each query a few times, and throw the first run away. Mem caching >may account for that. OK, OK. How's this: -------------------- #!/usr/bin/perl use Bugzilla::CustomFields::Query qw(bug_iterator); use Benchmark; use strict; do 'globals.pl'; my @summary = ([ 'short_desc', 'casesubstring', 'Astro' ]); my @onecustom = (@summary, [ 'tlc_incident_num', '>=', 2700 ]); my @twocustom = (@onecustom, [ 'tlc_platform_serial_num', 'casesubstring', 'n/a' ]); my @threecustom = (@twocustom, [ 'tlc_reproducibility_details', 'casesubstring', 'happens' ]); timethese(25, { summary => sub { count_bugs(@summary) }, onecust => sub { count_bugs(@onecustom) }, twocust => sub { count_bugs(@twocustom) }, threecust => sub { count_bugs(@threecustom) }, }); sub count_bugs { my @where = @_; my $count = 0; my $iterator = bug_iterator(where => \@where, custom_fields => 0); while (my $bug = $iterator->()) { ++$count; } print "$count bugs found.\n"; } -------------------- I replaced 'allwords' with 'casesubstring', which is more efficient. This is the output (with duplicate output trimmed): Benchmark: timing 25 iterations of onecust, summary, threecust, twocust... 11817 bugs found. [...] onecust: 137 wallclock secs (59.54 usr + 4.03 sys = 63.57 CPU) @ 0.39/s (n=25) 35552 bugs found. [...] summary: 397 wallclock secs (115.32 usr + 6.94 sys = 122.26 CPU) @ 0.20/s (n=25) 1010 bugs found. [...] threecust: 106 wallclock secs (35.16 usr + 2.63 sys = 37.79 CPU) @ 0.66/s (n=25) 2121 bugs found. [...] twocust: 95 wallclock secs (37.37 usr + 2.52 sys = 39.89 CPU) @ 0.63/s (n=25) So yes, the trend that I thought I noted--more custom fields means less time--is seen not to always hold. Two is still more efficient than one, however. Now can we dispense with the notion, once and for all, that storing custom field data in multiple tables is bad for performance? --Sean From bugreport at peshkin.net Mon Mar 15 19:49:55 2004 From: bugreport at peshkin.net (Joel Peshkin) Date: Mon, 15 Mar 2004 11:49:55 -0800 Subject: The Road to 2.18 - Customfields In-Reply-To: <20040315194139.8A8ECC45E@diggity.schwag.org> References: <20040315194139.8A8ECC45E@diggity.schwag.org> Message-ID: <405608E3.8020101@peshkin.net> Sean McAfee wrote: > >Now can we dispense with the notion, once and for all, that storing custom >field data in multiple tables is bad for performance? > > >--Sean > > There is nobody better than bbaetz to attempt to convince on the performance question. Additionally, it is not clear to me which approach is better from a standpoint of seperating the DBA functions from the web administrator functions and providing a migration path that permits existing 1-per-bug fields (like URL and Whiteboard) to collapse into customfields. What would that look like? -Joel From etzwane at schwag.org Mon Mar 15 20:24:55 2004 From: etzwane at schwag.org (Sean McAfee) Date: Mon, 15 Mar 2004 15:24:55 -0500 Subject: The Road to 2.18 - Customfields In-Reply-To: <405608E3.8020101@peshkin.net> Message-ID: <20040315202456.11EE5C45E@diggity.schwag.org> Joel Peshkin wrote: >Additionally, it is not clear to me which approach is better from a >standpoint of seperating the DBA functions from the web administrator >functions and providing a migration path that permits existing 1-per-bug >fields (like URL and Whiteboard) to collapse into customfields. What >would that look like? Something like this, supposing 42 is the ID of the custom field created for the bug_file_loc field to collapse into: INSERT INTO cf_longstring (bug_id, field_id, value) SELECT bug_id, 42, bug_file_loc FROM bugs; Real easy. --Sean From justdave at bugzilla.org Tue Mar 16 05:01:46 2004 From: justdave at bugzilla.org (David Miller) Date: Tue, 16 Mar 2004 00:01:46 -0500 Subject: Flags and the 2.18 push Message-ID: For a while now we've been using short blurbs in the status whiteboard field to indicate a bugs applicability to non-trunk branches when a bug applies to multiple branches. "[wanted for 2.16.6]", "[fixed in 2.16.5]" etc. Mozilla's been using Flags for this... should we start doing that for Bugzilla as well? The net result would probably be easier searches as well. Mozilla appears to use two flags for each upcoming version... approval blocking The blocking flag is requested by people who nominate the bug to be included in that release. Project drivers then grant that flag if they agree "yes, this should be included in the new release". This would be equivalent to me currently setting "[wanted for 2.16.6]" on the status whiteboard. The approval flag is then equivalent to our existing approval flag, but only applies to that branch. My thinking is a single approval flag for each branch that we're actively supporting (which would currently be "approval2.16", and we'd be adding an "approval2.18" after we branch for 2.18), and then a blocking flag for each individual version we plan to release ("blocking2.16.6", "blocking2.16.7" etc). Any thoughts? Good idea? Bad idea? If we're going to do this it should probably be done in the next day or so as we're freezing for 2.18 really shortly now (as soon as I get a little more triage done). -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From MKey at atmi.com Tue Mar 16 11:04:48 2004 From: MKey at atmi.com (MKey at atmi.com) Date: Tue, 16 Mar 2004 11:04:48 +0000 Subject: How do I change the text that goes out in Emails Message-ID: Hi all, In the emails that get sent out to people, how do I change the name of the fields ? For example, I want to change the Platform field to say Region and the OS/Version field to say Account Manager. I have managed this throughout my Bugzilla installation, but havnt worked out where to change the email text's..... Product: XX Version: unspecified Platform: EMEA OS/Version: XX Status: NEW Severity: minor Priority: P2 Component: Code requests AssignedTo: mkey at emosyn.com ReportedBy: CC: XX Estimated Hours: 4.0 Mat ________________________________________________________ Mathew Key Technical Marketing Engineer Emosyn Spinners Court, 53-55 West End Witney, Oxon. OX28 1NH ENGLAND Tel: +44 (0) 1993 700327 Fax: +44 (0) 1993 700299 Email: mkey at emosyn.com ________________________________________________________ Remeber - Every great achievement was once impossible ! ________________________________________________________ This email may contain confidential and / or privileged information. If you are not the intended recipient or have received this email in error, please notify the sender immediately and destroy this email. Any unauthorized copying, disclosure or distribution of the material in this email is strictly forbidden. Thank you. ________________________________________________________ From kiko at async.com.br Tue Mar 16 13:07:08 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Tue, 16 Mar 2004 10:07:08 -0300 Subject: How do I change the text that goes out in Emails In-Reply-To: References: Message-ID: <20040316130708.GF540@async.com.br> On Tue, Mar 16, 2004 at 11:04:48AM +0000, MKey at atmi.com wrote: > In the emails that get sent out to people, how do I change the name of the > fields ? If I'm not mistaken, this comes from the fielddefs table. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From kiko at async.com.br Tue Mar 16 15:02:20 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Tue, 16 Mar 2004 12:02:20 -0300 Subject: Flags and the 2.18 push In-Reply-To: References: Message-ID: <20040316150220.GA2066@async.com.br> On Tue, Mar 16, 2004 at 12:01:46AM -0500, David Miller wrote: > My thinking is a single approval flag for each branch that we're actively > supporting (which would currently be "approval2.16", and we'd be adding an > "approval2.18" after we branch for 2.18), and then a blocking flag for each > individual version we plan to release ("blocking2.16.6", "blocking2.16.7" > etc). > > Any thoughts? Good idea? Bad idea? I don't see why not -- it's certainly better than using the whiteboard. The only thing that could be a problem is the proliferation of flags, so it might make sense to only use one flag for each branch and not individual versions. I guess you can always delete the flag lateron, though. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From gerv at mozilla.org Tue Mar 16 18:18:53 2004 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 16 Mar 2004 18:18:53 +0000 Subject: How do I change the text that goes out in Emails In-Reply-To: <20040316130708.GF540@async.com.br> References: <20040316130708.GF540@async.com.br> Message-ID: <4057450D.3070603@mozilla.org> Christian Robottom Reis wrote: > On Tue, Mar 16, 2004 at 11:04:48AM +0000, MKey at atmi.com wrote: > >>In the emails that get sent out to people, how do I change the name of the >>fields ? > > If I'm not mistaken, this comes from the fielddefs table. Indeed - but I suspect that a few places rely on it not changing... Gerv From gerv at mozilla.org Tue Mar 16 18:26:33 2004 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 16 Mar 2004 18:26:33 +0000 Subject: Flags and the 2.18 push In-Reply-To: References: Message-ID: <405746D9.5080100@mozilla.org> David Miller wrote: > Mozilla's been using Flags for this... should we start doing that for > Bugzilla as well? The net result would probably be easier searches as well. Sounds very sensible to me. We need an approval flag per-branch, and a blocking flag per-release, as you say. We can remove the blocking flags a couple of releases after the release in question. Gerv From bruce.armstrong at teamsybase.com Tue Mar 16 20:55:55 2004 From: bruce.armstrong at teamsybase.com (Bruce Armstrong [TeamSybase]) Date: Tue, 16 Mar 2004 12:55:55 -0800 (PST) Subject: Win32: what PPM repository to suggest in checksetup.pl? In-Reply-To: Message-ID: <20040316205555.54141.qmail@web12505.mail.yahoo.com> Well, a few issues: 1. That particular repository requires the 5.8 version of ActiveState. Might need to make a note of that. Somewhat related, I haven't found to date a version of Chart (Chart-Base) that is supported for 5.8. That's why I've generally used 5.6 instead. However, using 5.6 usually means you have to go to the ActiveState and OpenInteract sites and download zip versions, they don't appear to have modules for 5.6 available via PPM (or not a lot of them). 2. The ActiveState repository (which is included by default in ActiveState's PPM) also contains some of the same packages for non-Windows platforms but not Windows. It appears that a PPM search stops at the first matching module, so the non-Windows one that ActiveState hosts get seen first and the ones that Apache is hosting don't get seen. I was only able to get this to work by removing the ActiveState repository entirely: ppm repository delete ActiveState Package Repository 3. These PPM directories occassionally name the modules differently (the name you search on that is). For example, a hyphen is used instead of a double colon (File-Spec, not File::Spec). The Date::Format module isn't hosted seperately, instead it's part of the TimeDate module. Apache stores GD::Graph as GDGraph and GD::Text::Align as part of the GDTextUtil module. Finally some of these are also installed as part of the ActiveState perl distribution and so don't need to be installed at all and may not be available in the PPM directory. It's all very confusing for somebody who is not entirely Perl conversant. David Miller wrote:On 3/9/2004 1:03 PM +0200, Andrei Benea wrote: > Justdave suggested in: > > http://bugzilla.mozilla.org/show_bug.cgi?id=236664#c9 > > to discuss on this list the ppm repository to be included in Bugzilla's > Windows installation instructions (checksetup.pl). The proposed URL is now > > http://www.apache.org/dist/perl/win32-bin/ppms/ > > Mirrors for this repository can be found at: > > http://www.apache.org/dyn/closer.cgi/perl/win32-bin/ppms/ > > I've chosen this one because it includes all ActivePerl packages needed by > Bugzilla except Chart::Base (which is optional). > > Andrei. We're trying to make checksetup.pl more friendly to Win32. Part of this is having the "missing perl modules" output actually give the necessary commands to use PPM to install the Perl modules if running on Win32. The problem is: not all of the modules we require are available in ActiveState's official PPM repository. Thus the patch on the above-mentioned bug also changes the output to suggest using Apache's PPM repository. The call here is to get opinions on this from Windows folks of whether this is a good repository to suggest, or if there's another we should be using? We've recommended OpenInteract's repository for the Template and AppConfig modules in the docs, but that was only because Template-Toolkit's site suggests that one for obtaining Template Toolkit. And apparently OpenInteract's site doesn't have some of the other modules. Thoughts anyone? -- 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: 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 mkanat at kerio.com Tue Mar 16 21:39:34 2004 From: mkanat at kerio.com (Maxwell Kanat-Alexander) Date: Tue, 16 Mar 2004 13:39:34 -0800 Subject: Win32: what PPM repository to suggest in checksetup.pl? In-Reply-To: <20040316205555.54141.qmail@web12505.mail.yahoo.com> References: <20040316205555.54141.qmail@web12505.mail.yahoo.com> Message-ID: <1079473174.4173.118.camel@localhost.localdomain> On Tue, 2004-03-16 at 12:55, Bruce Armstrong [TeamSybase] wrote: > [snip] It's all very confusing for somebody who is not entirely Perl > conversant. Wow, you ain't kiddin' there, partner. Would it be possible for bugzilla.org to host its own PPM repository? If we have somebody who can make the packages, then it wouldn't be that hard to keep on top of it, since we know what packages need to be in there and it's probably not all that many... -M From kiko at async.com.br Tue Mar 16 22:05:35 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Tue, 16 Mar 2004 19:05:35 -0300 Subject: Win32: what PPM repository to suggest in checksetup.pl? In-Reply-To: <1079473174.4173.118.camel@localhost.localdomain> References: <20040316205555.54141.qmail@web12505.mail.yahoo.com> <1079473174.4173.118.camel@localhost.localdomain> Message-ID: <20040316220535.GA3380@async.com.br> On Tue, Mar 16, 2004 at 01:39:34PM -0800, Maxwell Kanat-Alexander wrote: > On Tue, 2004-03-16 at 12:55, Bruce Armstrong [TeamSybase] wrote: > > [snip] It's all very confusing for somebody who is not entirely Perl > > conversant. > > Wow, you ain't kiddin' there, partner. > > Would it be possible for bugzilla.org to host its own PPM repository? > If we have somebody who can make the packages, then it wouldn't be that > hard to keep on top of it, since we know what packages need to be in Max, is that a thinly veiled form of volunteering I'm perceiving there? Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From mkanat at kerio.com Tue Mar 16 22:25:56 2004 From: mkanat at kerio.com (Maxwell Kanat-Alexander) Date: Tue, 16 Mar 2004 14:25:56 -0800 Subject: Win32: what PPM repository to suggest in checksetup.pl? In-Reply-To: <20040316220535.GA3380@async.com.br> References: <20040316205555.54141.qmail@web12505.mail.yahoo.com> <1079473174.4173.118.camel@localhost.localdomain> <20040316220535.GA3380@async.com.br> Message-ID: <1079475956.11265.17.camel@localhost.localdomain> On Tue, 2004-03-16 at 14:05, Christian Robottom Reis wrote: > > Would it be possible for bugzilla.org to host its own PPM repository? > > If we have somebody who can make the packages, then it wouldn't be that > > hard to keep on top of it, since we know what packages need to be in > > Max, is that a thinly veiled form of volunteering I'm perceiving > there? Hahahahahaha. Maybe... (/me perceives a future of thousands of Win32 users screaming, "This PPM package doesn't work...!" and me saying "Well, um, I use Fedora. Why don't you? It's really not too hard, just read my FAQ..." :-D) Um... Please, somebody, take it from me! Get it off me! Aaaaaah! They're eating my brain... :-D -M From bruce.armstrong at teamsybase.com Tue Mar 16 23:32:03 2004 From: bruce.armstrong at teamsybase.com (Bruce Armstrong [TeamSybase]) Date: Tue, 16 Mar 2004 15:32:03 -0800 (PST) Subject: Win32: what PPM repository to suggest in checksetup.pl? In-Reply-To: <1079473174.4173.118.camel@localhost.localdomain> Message-ID: <20040316233203.53163.qmail@web12504.mail.yahoo.com> I'm not convinced that's the best approach. The Apache repository works fine with 5.8 (with the exception of Chart, which I can't find). I think it's more a matter of documentation: noting that you need to remove the ActiveState default repository and the names of the modules you really need to search on. That would be simplier at least. It's definately more of an issue for 5.6 though. I'd see it as something that might just be addressed by expanding more in the OS-Specific Installation Notes. Those changes might also help cover some of the other issues I encountered trying to do an 2.17.7 install on window. I don't know if it's just an issue with the developers versions, but the following statements in checksetup.pl generated errors when I ran it on Windows and had to be commented out: my $cvs_executable = `which cvs`; my $interdiff_executable = `which interdiff`; my $diff_binaries = `which diff`; Where I kept getting: 'which' is not recognized as an internal or external command, operable program or batch file. Such changes might also discuss the issue associated with getting it to work with IIS, which the majority of Windows are proabably going to use, even though Apache is available for Windows. Maxwell Kanat-Alexander wrote: On Tue, 2004-03-16 at 12:55, Bruce Armstrong [TeamSybase] wrote: > [snip] It's all very confusing for somebody who is not entirely Perl > conversant. Wow, you ain't kiddin' there, partner. Would it be possible for bugzilla.org to host its own PPM repository? If we have somebody who can make the packages, then it wouldn't be that hard to keep on top of it, since we know what packages need to be in there and it's probably not all that many... -M - 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 justdave at bugzilla.org Wed Mar 17 00:57:07 2004 From: justdave at bugzilla.org (David Miller) Date: Tue, 16 Mar 2004 19:57:07 -0500 Subject: How do I change the text that goes out in Emails In-Reply-To: <4057450D.3070603@mozilla.org> References: <20040316130708.GF540@async.com.br> <4057450D.3070603@mozilla.org> Message-ID: On 3/16/2004 6:18 PM +0000, Gervase Markham wrote: > Christian Robottom Reis wrote: > >> On Tue, Mar 16, 2004 at 11:04:48AM +0000, MKey at atmi.com wrote: >> >>>In the emails that get sent out to people, how do I change the name of the >>>fields ? >> >> If I'm not mistaken, this comes from the fielddefs table. > > Indeed - but I suspect that a few places rely on it not changing... I doubt it. Nothing in the code should care about the human readable names in that table. They're used for exactly that. Everything in the code uses the IDs and the database names. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From justdave at bugzilla.org Wed Mar 17 00:55:50 2004 From: justdave at bugzilla.org (David Miller) Date: Tue, 16 Mar 2004 19:55:50 -0500 Subject: Win32: what PPM repository to suggest in checksetup.pl? In-Reply-To: <20040316233203.53163.qmail@web12504.mail.yahoo.com> References: <20040316233203.53163.qmail@web12504.mail.yahoo.com> Message-ID: On 3/16/2004 3:32 PM -0800, Bruce Armstrong \[TeamSybase\] wrote: >I'd see it as something that might just be addressed by expanding more in >the OS-Specific Installation Notes. Those changes might also help cover >some of the other issues I encountered trying to do an 2.17.7 install on >window. I don't know if it's just an issue with the developers versions, >but the following statements in checksetup.pl generated errors when I ran >it on Windows and had to be commented out: > > my $cvs_executable = `which cvs`; > my $interdiff_executable = `which interdiff`; > my $diff_binaries = `which diff`; > >Where I kept getting: > >'which' is not recognized as an internal or external command, operable >program or batch file. I believe this is all fixed on the tip (after 2.17.7 was released). Those are all conditional on $^O !~ /Win32/i now, as well as telling you to use ppm instead of CPAN to get the modules (with mappings to the PPM package names). That's what the bug was about that started this thread, which has since been checked in since we decided we'd fix it later if someone didn't like the PPM repo that was listed. :) Right now it's also forking on the perl version and suggesting openinteract if you have Perl 5.6.x or less and apache if you have 5.8.0 or newer -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From bruce.armstrong at teamsybase.com Wed Mar 17 19:58:05 2004 From: bruce.armstrong at teamsybase.com (Bruce Armstrong [TeamSybase]) Date: Wed, 17 Mar 2004 11:58:05 -0800 (PST) Subject: Win32: what PPM repository to suggest in checksetup.pl? In-Reply-To: Message-ID: <20040317195805.29469.qmail@web12508.mail.yahoo.com> Got it. I've just grabbed the tip and am checking it out. Along the lines of documentation for the Windows weenies like me though, we could probably also use: a. Instructions on using WinCVS to do a tip pull. Took me about 20 mintues to figure out how to tell WinCVS I wanted the tip. b. More discussion in the configuration page on configuring Bugzilla under IIS (which I'm assuming most Windows users will end up using). c. Perhaps some discussion in the extra configuration page about using utilities like nnCron to implement cron capability on Windows, since it's not native to that platform. David Miller wrote: On 3/16/2004 3:32 PM -0800, Bruce Armstrong \[TeamSybase\] wrote: >I'd see it as something that might just be addressed by expanding more in >the OS-Specific Installation Notes. Those changes might also help cover >some of the other issues I encountered trying to do an 2.17.7 install on >window. I don't know if it's just an issue with the developers versions, >but the following statements in checksetup.pl generated errors when I ran >it on Windows and had to be commented out: > > my $cvs_executable = `which cvs`; > my $interdiff_executable = `which interdiff`; > my $diff_binaries = `which diff`; > >Where I kept getting: > >'which' is not recognized as an internal or external command, operable >program or batch file. I believe this is all fixed on the tip (after 2.17.7 was released). Those are all conditional on $^O !~ /Win32/i now, as well as telling you to use ppm instead of CPAN to get the modules (with mappings to the PPM package names). That's what the bug was about that started this thread, which has since been checked in since we decided we'd fix it later if someone didn't like the PPM repo that was listed. :) Right now it's also forking on the perl version and suggesting openinteract if you have Perl 5.6.x or less and apache if you have 5.8.0 or newer -- 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: 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 justdave at bugzilla.org Thu Mar 18 02:42:17 2004 From: justdave at bugzilla.org (David Miller) Date: Wed, 17 Mar 2004 21:42:17 -0500 Subject: Win32: what PPM repository to suggest in checksetup.pl? In-Reply-To: <20040317195805.29469.qmail@web12508.mail.yahoo.com> References: <20040317195805.29469.qmail@web12508.mail.yahoo.com> Message-ID: On 3/17/2004 11:58 AM -0800, Bruce Armstrong \[TeamSybase\] wrote: >Got it. I've just grabbed the tip and am checking it out. > >Along the lines of documentation for the Windows weenies like me though, >we could probably also use: > >a. Instructions on using WinCVS to do a tip pull. Took me about 20 >mintues to figure out how to tell WinCVS I wanted the tip. > >b. More discussion in the configuration page on configuring Bugzilla >under IIS (which I'm assuming most Windows users will end up using). > >c. Perhaps some discussion in the extra configuration page about using >utilities like nnCron to implement cron capability on Windows, since it's >not native to that platform. Best written by someone who's actually done it before. :) (I can tell you now that most of the existing documentation maintainers have probably never seen IIS or WinCVS before). If you'd like to write up your experiences, I'm sure one of the docs guys can format it to fit in the docs and put it in. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From justdave at bugzilla.org Thu Mar 18 07:45:45 2004 From: justdave at bugzilla.org (David Miller) Date: Thu, 18 Mar 2004 02:45:45 -0500 Subject: Funky dependency mails Message-ID: There's a problem that's been around since shortly after we branched for 2.16 (the problem doesn't exist in 2.16, but only on the tip), where mail about a dependency state change will get doubled intermittently (it doesn't happen all the time, either). We *cannot* ship Bugzilla 2.18 with this still happening. Unfortunately, nobody has a clue what's causing it, and the code surrounding it is not obvious. This is http://bugzilla.mozilla.org/show_bug.cgi?id=179351 If there's anyone out there that can donate some time into trying to track this down, it would be really, really appreciated! It's been widely speculated that the big massive mail rewrite on bug 84876 will probably fix this by virtue of rewriting that chunk of code, but it's obvious at this point that 84876 isn't going to make it for 2.18, so we've no choice but to find and fix this bugger in the existing code :) -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From gerv at mozilla.org Thu Mar 18 21:13:10 2004 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 18 Mar 2004 21:13:10 +0000 Subject: Use of "Future" Message-ID: <405A10E6.5000006@mozilla.org> Guys, Currently, we appear to be pushing a load of bugs from "2.18" to "2.20". I can see the same thing happening again in six months time. In the interests of having a 2.20 list which is always fairly accurate, why don't we start using "Future", and pull _in_ bugs as appropriate, rather than always pushing them out? Gerv From kiko at async.com.br Thu Mar 18 21:51:06 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Thu, 18 Mar 2004 18:51:06 -0300 Subject: Use of "Future" In-Reply-To: <405A10E6.5000006@mozilla.org> References: <405A10E6.5000006@mozilla.org> Message-ID: <20040318215106.GD1647@async.com.br> On Thu, Mar 18, 2004 at 09:13:10PM +0000, Gervase Markham wrote: > Currently, we appear to be pushing a load of bugs from "2.18" to "2.20". > I can see the same thing happening again in six months time. > > In the interests of having a 2.20 list which is always fairly accurate, > why don't we start using "Future", and pull _in_ bugs as appropriate, > rather than always pushing them out? I have my reservations aboute the use of Future. I think the current "pushout" of bugs might not be the best way of triaging things, but that should be solved by stronger planning ("this is the feature set or general target we want for 2.20") and using the plan to justify what we'll be working on for a certain release. Whether this is practical for an OSS project with a small team is yet to be determined . I appreciate pushing bugs off because it's a chance you have of actually looking at stuff that might have been forgotten -- I added a one-liner patch today that wouldn't have been added if I hadn't noticed it during the retargetting. My impression is that stuff in "Future" tends to be forgotten since we aren't targetting having it fixed at all, ever. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From justdave at bugzilla.org Thu Mar 18 21:53:51 2004 From: justdave at bugzilla.org (David Miller) Date: Thu, 18 Mar 2004 16:53:51 -0500 Subject: Use of "Future" In-Reply-To: <405A10E6.5000006@mozilla.org> References: <405A10E6.5000006@mozilla.org> Message-ID: On 3/18/2004 9:13 PM +0000, Gervase Markham wrote: > Currently, we appear to be pushing a load of bugs from "2.18" to "2.20". > I can see the same thing happening again in six months time. > > In the interests of having a 2.20 list which is always fairly accurate, > why don't we start using "Future", and pull _in_ bugs as appropriate, > rather than always pushing them out? That sounds good to me. Anything assigned to nobody at bugzilla.org would be a good place to start. :) -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From justdave at bugzilla.org Thu Mar 18 22:07:20 2004 From: justdave at bugzilla.org (David Miller) Date: Thu, 18 Mar 2004 17:07:20 -0500 Subject: Use of "Future" In-Reply-To: <20040318215106.GD1647@async.com.br> References: <405A10E6.5000006@mozilla.org> <20040318215106.GD1647@async.com.br> Message-ID: On 3/18/2004 6:51 PM -0300, Christian Robottom Reis wrote: > I appreciate pushing bugs off because it's a chance you have of actually > looking at stuff that might have been forgotten -- I added a one-liner > patch today that wouldn't have been added if I hadn't noticed it during > the retargetting. My impression is that stuff in "Future" tends to be > forgotten since we aren't targetting having it fixed at all, ever. This is a good point. There's been a number of bugs that have wound up being marked as duplicates of already-fixed bugs as a result of going through and actually looking at bugs while triaging them, too. :) If we move things to future, then we need to remember to go through and triage future bugs every so often. Lots of third-party folks looking at Bugzilla see the target milestone and say "oh, that'll be in 2.18" then when 2.18 comes out they're disappointed :) That in itself is probably the biggest reason to target as little as possible. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From bugreport at peshkin.net Thu Mar 18 22:22:02 2004 From: bugreport at peshkin.net (Joel Peshkin) Date: Thu, 18 Mar 2004 14:22:02 -0800 Subject: Use of "Future" In-Reply-To: References: <405A10E6.5000006@mozilla.org> <20040318215106.GD1647@async.com.br> Message-ID: <405A210A.70302@peshkin.net> David Miller wrote: >On 3/18/2004 6:51 PM -0300, Christian Robottom Reis wrote: > >Lots of third-party folks looking at Bugzilla see the target milestone and >say "oh, that'll be in 2.18" then when 2.18 comes out they're disappointed >:) That in itself is probably the biggest reason to target as little as >possible. > > How about we only target when someone says "oh, I intend to write that for 2.18?" Then, we'll only have to retarget when intentions meet reality. From kiko at async.com.br Thu Mar 18 22:27:35 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Thu, 18 Mar 2004 19:27:35 -0300 Subject: Use of "Future" In-Reply-To: References: <405A10E6.5000006@mozilla.org> <20040318215106.GD1647@async.com.br> Message-ID: <20040318222735.GF1647@async.com.br> On Thu, Mar 18, 2004 at 05:07:20PM -0500, David Miller wrote: > If we move things to future, then we need to remember to go through and > triage future bugs every so often. Question is whether that will be done. The push for a release makes everybody happy to go through targetted bugs and move them off (didn't make it, sorry). This is less likely to interest people during the normal development cycle, and I don't see it being done during release which is normally occam's razor for planned changes. > Lots of third-party folks looking at Bugzilla see the target milestone and > say "oh, that'll be in 2.18" then when 2.18 comes out they're disappointed > :) That in itself is probably the biggest reason to target as little as > possible. Well, as I said, I think the solution to that part of the problem is providing a strong "target" concept for future releases (2.20 could be mod_perl and cleanups and user-facing templatization, for instance; 2.22 could be multiple database support and custom fields; 2.22 could be multiple database support and custom fields; 2.24 could be UI css-ification and redesign; etc). That way we both know what sort of problems to pick up, and what should be expected to go in. Setting reasonable (i.e. not a lot) goals for each release would avoid the eternal "upcoming features" saga. I think setting some policy and triaging bug milestones according to this policy is a good idea; I would offer to help plan these targets if people think it's a good idea. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From gerv at mozilla.org Thu Mar 18 23:18:36 2004 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 18 Mar 2004 23:18:36 +0000 Subject: Use of "Future" In-Reply-To: <20040318222735.GF1647@async.com.br> References: <405A10E6.5000006@mozilla.org> <20040318215106.GD1647@async.com.br> <20040318222735.GF1647@async.com.br> Message-ID: <405A2E4C.8000603@mozilla.org> Christian Robottom Reis wrote: > Well, as I said, I think the solution to that part of the problem is > providing a strong "target" concept for future releases (2.20 could be > mod_perl and cleanups and user-facing templatization, ... Surely this is exactly what we've moved away from with date-based releases? IMO, we need some way for people (including us) to get an idea of what is currently planned to be fixed in the next milestone. The "Milestone" field seems a good choice for this. Ideally, the number of bugs planned for 2.20 (for example), should start at X and decline gradually to zero about six months later. Gerv From justdave at bugzilla.org Fri Mar 19 12:30:34 2004 From: justdave at bugzilla.org (David Miller) Date: Fri, 19 Mar 2004 07:30:34 -0500 Subject: Funky dependency mails In-Reply-To: References: Message-ID: On 3/18/2004 2:45 AM -0500, David Miller wrote: > There's a problem that's been around since shortly after we branched for > 2.16 (the problem doesn't exist in 2.16, but only on the tip), where mail > about a dependency state change will get doubled intermittently (it doesn't > happen all the time, either). We *cannot* ship Bugzilla 2.18 with this > still happening. Unfortunately, nobody has a clue what's causing it, and > the code surrounding it is not obvious. > > This is http://bugzilla.mozilla.org/show_bug.cgi?id=179351 > > If there's anyone out there that can donate some time into trying to track > this down, it would be really, really appreciated! Many thanks to Teemu Mannermaa who took this on, and indeed found and fixed it :) Amazing what a difference the scope of a variable can make ;) -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From etzwane at schwag.org Sat Mar 20 00:22:21 2004 From: etzwane at schwag.org (Sean McAfee) Date: Fri, 19 Mar 2004 19:22:21 -0500 Subject: Huge attachments Message-ID: <20040320002221.B196FC45F@diggity.schwag.org> Has anyone else ever grappled with the issue of adding huge attachments to a Bugzilla installation based on a pre-v4 version of the MySQL server, which has a packet size limited to 16MB? The only workaround I've been able to come up with doesn't work, due to an apparent server bug: mysql> insert into attachments (thedata) values (repeat("*", 14000000)); Query OK, 1 row affected (1.24 sec) mysql> select last_insert_id(); +------------------+ | last_insert_id() | +------------------+ | 4183 | +------------------+ 1 row in set (0.00 sec) mysql> select length(thedata) from attachments where attach_id = 4183; +-----------------+ | length(thedata) | +-----------------+ | 14000000 | +-----------------+ 1 row in set (0.11 sec) mysql> update attachments set thedata = concat(thedata, repeat("*", 14000000)) where attach_id = 4183; Query OK, 1 row affected (1.30 sec) Rows matched: 1 Changed: 1 Warnings: 1 mysql> select length(thedata) from attachments where attach_id = 4183; +-----------------+ | length(thedata) | +-----------------+ | 0 | +-----------------+ 1 row in set (0.00 sec) Not only is the thedata column not updated correctly, the original data is lost. Looks like a pretty serious bug to me. --Sean From bugreport at peshkin.net Sat Mar 20 01:15:50 2004 From: bugreport at peshkin.net (Joel Peshkin) Date: Fri, 19 Mar 2004 17:15:50 -0800 Subject: Huge attachments In-Reply-To: <20040320002221.B196FC45F@diggity.schwag.org> References: <20040320002221.B196FC45F@diggity.schwag.org> Message-ID: <405B9B46.1020100@peshkin.net> Sean McAfee wrote: >Has anyone else ever grappled with the issue of adding huge attachments to a >Bugzilla installation based on a pre-v4 version of the MySQL server, which >has a packet size limited to 16MB? > >The only workaround I've been able to come up with doesn't work, due to an >apparent server bug: > > > I found that most such attachments are rather temporary in nature and added an option for local attachment storage. When storing, the user chooses local (temporary) storage where the attachments can be deletedin the future. The thedata field of attachments las length zero. When fetching an attachment, if thedata is zero length, the big file is read from disk and sent to the browser. It seems to be a bit too controversial and approach to actually land. From mattyt-spam at tpg.com.au Sat Mar 20 11:35:51 2004 From: mattyt-spam at tpg.com.au (MattyT) Date: Sat, 20 Mar 2004 22:05:51 +1030 Subject: Use of "Future" In-Reply-To: <20040318215106.GD1647@async.com.br> References: <405A10E6.5000006@mozilla.org> <20040318215106.GD1647@async.com.br> Message-ID: <1079782549.836.26.camel@megagerbil> On Fri, 2004-03-19 at 08:21, Christian Robottom Reis wrote: > I have my reservations aboute the use of Future. I think the current > "pushout" of bugs might not be the best way of triaging things, but that > should be solved by stronger planning ("this is the feature set or > general target we want for 2.20") and using the plan to justify what > we'll be working on for a certain release. Whether this is practical for > an OSS project with a small team is yet to be determined . I agree with this totally. The stuff targetted at 2.20 is stuff that needs to get done soon enough, the stuff targetted at Future is stuff that never need get done. We shouldn't lose this distinction. There definitely needs to be some form of stronger planning. My original milestone triaging was wildly optimistic, and I'd been meaning to change milestones to be more balanced over 3 or so targets. With shorter release spans, that should now perhaps be 5 or 6. -- 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 Mar 20 11:39:26 2004 From: mattyt-spam at tpg.com.au (MattyT) Date: Sat, 20 Mar 2004 22:09:26 +1030 Subject: Use of "Future" In-Reply-To: <405A2E4C.8000603@mozilla.org> References: <405A10E6.5000006@mozilla.org> <20040318215106.GD1647@async.com.br> <20040318222735.GF1647@async.com.br> <405A2E4C.8000603@mozilla.org> Message-ID: <1079782764.836.31.camel@megagerbil> On Fri, 2004-03-19 at 09:48, Gervase Markham wrote: > > Well, as I said, I think the solution to that part of the problem is > > providing a strong "target" concept for future releases (2.20 could be > > mod_perl and cleanups and user-facing templatization, > Surely this is exactly what we've moved away from with date-based releases? Feature and date based releases are about (not) making commitments. Target milestones are a best guess and guide, they were never commitments. If they were, we wouldn't be using them at all, since we're not making commitments now. Even the name "target milestone" suggests no commitments, as targets are things that get missed (unless you're Robin Hood). So they're totally independent. > IMO, we need some way for people (including us) to get an idea of what > is currently planned to be fixed in the next milestone. The "Milestone" > field seems a good choice for this. Ideally, the number of bugs planned > for 2.20 (for example), should start at X and decline gradually to zero > about six months later. We already have this - two ways in fact. Both having an active assignee, and the ASSIGNED status. -- 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 vlad at goobix.com Sun Mar 21 15:40:15 2004 From: vlad at goobix.com (Vlad Dascalu) Date: Sun, 21 Mar 2004 10:40:15 -0500 Subject: XML Documentation patches needed Message-ID: <200403211040.15843.vlad@goobix.com> As we're getting closer to the 2.18 release, we are increasingly needing documentation updates to reflect the code changes that happened during our development cycle. The documentation is stored in CVS in the docs/xml directory using the DocBook format; writing patches to update it is a pretty straightforward process. There are currently 54 bugs for documentation updates (that need XML patches), all targeted to 2.18. Some of them have the documentation posted as a comment and only need a diff for the XML patch that can be applied to the CVS tip. Others need someone to play with the newly introduced feature/enhancement, then propose a text that describes it. If you have any free time, help would be appreciated with those tasks, even if it's a simple sentence or a simple diff command. It will also be a great way to get involved in the BZ-devel world. You can query for those bugs in Bugzilla by searching all bugs from the Documentation component of the Bugzilla product. If you want to help and you have questions don't hesitate to ask. You can find justdave and others on #mozwebtools (irc.mozilla.org) for live assistance on how to get involved. Thanks! (let's make the 2.18 release rock :) ) Vlad. From gerv at mozilla.org Sun Mar 21 13:19:27 2004 From: gerv at mozilla.org (Gervase Markham) Date: Sun, 21 Mar 2004 13:19:27 +0000 Subject: Badger Book thoughts Message-ID: <405D965F.4080800@mozilla.org> I've been looking through the Badger Book (the new O'Reilly volume on the Template Toolkit.) I came up with the following thoughts/ideas: - Contrary to my understanding, the form: [% FOREACH foo IN bar %] is supported. We should use it (i.e. IN instead of =) for clarity. - There is a useful DEBUG option allowing you to spot use of undefined variables. You invoke it when the template is constructed (in our case, in Bugzilla::Template->create): my $template = Template->new({ DEBUG => DEBUG_UNDEF, }); - There is a Date plugin which formats dates. I seem to remember we haven't been using this because of rumours of Win32 issues. But we should re-investigate. - [% somescalar.chunk(n) %] splits a scalar into a list of chunks of n characters. - Unlike Perl, TT has a SWITCH directive, which works on both numbers and strings. [% SWITCH foo %] [% CASE "Fred" %] ... [% CASE "Barney" %] ... Note that there is no case fallthrough. We should consider using this in e.g. the error templates. - There is a URL plugin which we should probably use when assembling long URLs (which we often do in charting, for example.) Instead of: Run Search do: [% buglist = url("buglist.cgi") %] [% buglist(cmdtype='dorem') %] [% namedcmd = "$series.category / $series.subcategory / $series.name" FILTER url_quote %] [% buglist(namedcmd=$namedcmd) %] etc. [% buglist %] on its own (no params) outputs the URL. - Last but not least, one of my own. PRE_CHOMP is great for making output more readable; the one trick you need to remember is not to start a line with a directive if you want a space between it and the previous bit of text. Gerv From gerv at mozilla.org Sun Mar 21 13:44:03 2004 From: gerv at mozilla.org (Gervase Markham) Date: Sun, 21 Mar 2004 13:44:03 +0000 Subject: Use of "Future" In-Reply-To: <1079782764.836.31.camel@megagerbil> References: <405A10E6.5000006@mozilla.org> <20040318215106.GD1647@async.com.br> <20040318222735.GF1647@async.com.br> <405A2E4C.8000603@mozilla.org> <1079782764.836.31.camel@megagerbil> Message-ID: <405D9C23.4000800@mozilla.org> MattyT wrote: > Feature and date based releases are about (not) making commitments. > Target milestones are a best guess and guide, they were never > commitments. Sure. But they aren't our _best_ guess if we start by targetting a lot of bugs at them that we have no idea whether they are going to be fixed in 2.20 or not. >>IMO, we need some way for people (including us) to get an idea of what >>is currently planned to be fixed in the next milestone. The "Milestone" >>field seems a good choice for this. Ideally, the number of bugs planned >>for 2.20 (for example), should start at X and decline gradually to zero >>about six months later. > > We already have this - two ways in fact. Both having an active > assignee, and the ASSIGNED status. I'd say that indicates what bugs are currently being worked on, not what bugs anyone is planning to work on between now and six months time. Gerv From gerv at mozilla.org Sun Mar 21 17:23:35 2004 From: gerv at mozilla.org (Gervase Markham) Date: Sun, 21 Mar 2004 17:23:35 +0000 Subject: Partial custom fields design document In-Reply-To: <20040312024028.893EBC45E@diggity.schwag.org> References: <20040312024028.893EBC45E@diggity.schwag.org> Message-ID: <405DCF97.4060402@mozilla.org> Sean McAfee wrote: > Rather than wait the several days I anticipate it will take to crank the > entire thing out, I plan to post it here, incrementally, as I complete it. > I'll work any changes agreed upon by the group into subsequent versions. > The initial cut is attached; have at it! Sean, I was planning to have a look at this, and then read the above. Is there a newer cut than the one you posted on the 12th, or is that still the one to review? Gerv From etzwane at schwag.org Mon Mar 22 04:19:05 2004 From: etzwane at schwag.org (Sean McAfee) Date: Sun, 21 Mar 2004 23:19:05 -0500 Subject: Partial custom fields design document In-Reply-To: <405DCF97.4060402@mozilla.org> Message-ID: <20040322041905.B2E43C460@diggity.schwag.org> Gervase Markham wrote: >Sean, > >I was planning to have a look at this, and then read the above. Is there >a newer cut than the one you posted on the 12th, or is that still the >one to review? I'm attaching the most-current version I have. It ends pretty abruptly, but there's more content than the original one I posted. --Sean -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cfdesign.txt URL: From justdave at bugzilla.org Mon Mar 22 04:31:51 2004 From: justdave at bugzilla.org (David Miller) Date: Sun, 21 Mar 2004 23:31:51 -0500 Subject: XML Documentation patches needed In-Reply-To: <200403211040.15843.vlad@goobix.com> References: <200403211040.15843.vlad@goobix.com> Message-ID: On 3/21/2004 10:40 AM -0500, Vlad Dascalu wrote: > There are currently 54 bugs for documentation updates (that need XML >patches), > all targeted to 2.18. Some of them have the documentation posted as a comment > and only need a diff for the XML patch that can be applied to the CVS tip. > Others need someone to play with the newly introduced feature/enhancement, > then propose a text that describes it. And don't forget there's a bunch of bugs outside of the documentation component which have documentation? or documentation2.16? flags on them (indicating bugs that have probably been fixed and checked in, but affected something that needs updating in the docs). You can search for those with the Advanced Query at the bottom by choosing "Flag" "is equal to" "documentation?" Make sure you clear the statuses at the top, and some of those are already marked FIXED (but the documentation isn't done until the flag gets plussed). I count 4 with documentation? and 2 with documentation2.16? right now. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From gerv at mozilla.org Mon Mar 22 17:08:38 2004 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 22 Mar 2004 17:08:38 +0000 Subject: Bugzilla as a discussion forum Message-ID: <405F1D96.6010906@mozilla.org> mpt has some very wise (in my view; but then he agrees with me, so I would say that) comments about how making it easier to have discussions in public Bugzillas is a bad idea. "As a result, over the past few years several of Mozilla?s best programmers have begun to ignore most or all of the e-mail they receive from Bugzilla, for the good reason that they?d rather be fixing bugs than wading through Bugzilla discussions. The correct response from Bugzilla?s maintainers would have been to make Bugzilla harder to use as a discussion forum, but instead they made it easier..." http://mpt.net.nz/archive/2004/03/22/ Gerv From mkanat at kerio.com Mon Mar 22 21:25:18 2004 From: mkanat at kerio.com (Maxwell Kanat-Alexander) Date: Mon, 22 Mar 2004 13:25:18 -0800 Subject: Bugzilla as a discussion forum In-Reply-To: <405F1D96.6010906@mozilla.org> References: <405F1D96.6010906@mozilla.org> Message-ID: <1079990718.4156.1.camel@localhost.localdomain> On Mon, 2004-03-22 at 09:08, Gervase Markham wrote: > http://mpt.net.nz/archive/2004/03/22/ I like mpt's suggestion of a parallel forum. You could have a "discuss this bug" link that would go to a vBulletin, or something. editbug.cgi could make it clear that the comments field was for "comments of a technical nature, not for discussion." -M From chicks at chicks.net Mon Mar 22 22:36:30 2004 From: chicks at chicks.net (Christopher Hicks) Date: Mon, 22 Mar 2004 17:36:30 -0500 (EST) Subject: Bugzilla as a discussion forum In-Reply-To: <405F1D96.6010906@mozilla.org> Message-ID: On Mon, 22 Mar 2004, Gervase Markham wrote: > mpt has some very wise (in my view; but then he agrees with me, so I > would say that) comments about how making it easier to have discussions > in public Bugzillas is a bad idea. Look at all the cc's on key bugs in bmo. Those people are people who explicitly want to follow the discussion! -- No, no, you're not thinking, you're just being logical. -Niels Bohr, physicist (1885-1962) From ihok at hotmail.com Mon Mar 22 22:17:14 2004 From: ihok at hotmail.com (Jack Tanner) Date: Mon, 22 Mar 2004 17:17:14 -0500 Subject: Bugzilla as a discussion forum In-Reply-To: <405F1D96.6010906@mozilla.org> References: <405F1D96.6010906@mozilla.org> Message-ID: Gervase Markham wrote: > mpt has some very wise (in my view; but then he agrees with me, so I > would say that) comments about how making it easier to have discussions > in public Bugzillas is a bad idea. > > "As a result, over the past few years several of Mozilla?s best > programmers have begun to ignore most or all of the e-mail they receive > from Bugzilla, for the good reason that they?d rather be fixing bugs > than wading through Bugzilla discussions. The correct response from > Bugzilla?s maintainers would have been to make Bugzilla harder to use as > a discussion forum, but instead they made it easier..." I tend to agree with mpt, but not on this. The problem isn't that the Bugzilla UI affords discussions; the problem is the signal/noise ratio. Worse, mpt makes the assumption that the s/n ratio got worse when the discussion UI became easier to use. In fact, it could've done the opposite -- good comments got are (and were) exactly as easy to post as bad comments. (It would be interesting to check this empirically.) Two approaches could be used to address the s/n problem: 1) make it more difficult to post noise, but easy to post signal, and 2) make the signal more recognizable. The latter could be accomplished by, say, visually distinguishing posts from important stakeholders (e.g., known developers @mozilla.org and elsewhere, the original reporter, etc.). The former could be accomplished by 1) requiring a valid e-mail address of all Bugzilla users, 2) requiring that only really special people can turn off bugmail (e.g., see list above), and 3) requiring that only people CC'ed on the bug can post to the discussion. The hypothesis here is that high-discussion, high-noise bugs (e.g., the MNG fiasco) would then automatically generate so much mail to all discussants, that the social cost of posting me-too's and other noise would rise quickly. -JT From bugreport at peshkin.net Mon Mar 22 22:50:03 2004 From: bugreport at peshkin.net (Joel Peshkin) Date: Mon, 22 Mar 2004 14:50:03 -0800 Subject: Bugzilla as a discussion forum In-Reply-To: References: <405F1D96.6010906@mozilla.org> Message-ID: <405F6D9B.20908@peshkin.net> Jack Tanner wrote: > > Two approaches could be used to address the s/n problem: > 1) make it more difficult to post noise, but easy to post signal, and > 2) make the signal more recognizable. > > The latter could be accomplished by, say, visually distinguishing > posts from important stakeholders (e.g., known developers @mozilla.org > and elsewhere, the original reporter, etc.). > > The former could be accomplished by 1) requiring a valid e-mail > address of all Bugzilla users, 2) requiring that only really special > people can turn off bugmail (e.g., see list above), and 3) requiring > that only people CC'ed on the bug can post to the discussion. The > hypothesis here is that high-discussion, high-noise bugs (e.g., the > MNG fiasco) would then automatically generate so much mail to all > discussants, that the social cost of posting me-too's and other noise > would rise quickly. AHA! Emailprefs meets group permissions...... I want to see only comments added by people in the canedit group. From gerv at mozilla.org Mon Mar 22 23:13:29 2004 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 22 Mar 2004 23:13:29 +0000 Subject: Bugzilla as a discussion forum In-Reply-To: References: <405F1D96.6010906@mozilla.org> Message-ID: <405F7319.4010003@mozilla.org> Jack Tanner wrote: > I tend to agree with mpt, but not on this. The problem isn't that the > Bugzilla UI affords discussions; the problem is the signal/noise ratio. > Worse, mpt makes the assumption that the s/n ratio got worse when the > discussion UI became easier to use. In fact, it could've done the > opposite -- good comments got are (and were) exactly as easy to post as > bad comments. (It would be interesting to check this empirically.) I think his point is that people with signal are more likely to move past bad UI than people with offhand noise. > Two approaches could be used to address the s/n problem: > 1) make it more difficult to post noise, but easy to post signal, and > 2) make the signal more recognizable. > > The latter could be accomplished by, say, visually distinguishing posts > from important stakeholders (e.g., known developers @mozilla.org and > elsewhere, the original reporter, etc.). Now that's an interesting idea. We could visually distinguish comments from the current assignee, QA contact and reporter. > The former could be accomplished by 1) requiring a valid e-mail address > of all Bugzilla users, We do that... > 2) requiring that only really special people can > turn off bugmail (e.g., see list above), How does this make it more difficult to post noise? > and 3) requiring that only > people CC'ed on the bug can post to the discussion. I don't like that idea. Non-CC comments are too useful in legitimate work. > The hypothesis here > is that high-discussion, high-noise bugs (e.g., the MNG fiasco) would > then automatically generate so much mail to all discussants, that the > social cost of posting me-too's and other noise would rise quickly. Problem is, that doesn't discourage people. The social cost is already high, but people feel "my opinion is important, and it needs to be heard." Gerv From bz at barnson.org Mon Mar 22 23:18:26 2004 From: bz at barnson.org (Barnboy) Date: Mon, 22 Mar 2004 16:18:26 -0700 Subject: Bugzilla as a discussion forum In-Reply-To: <405F7319.4010003@mozilla.org> References: <405F1D96.6010906@mozilla.org> <405F7319.4010003@mozilla.org> Message-ID: <20040322231826.GK45419@barnson.org> Me, I'm of the opinion that discussion on a bug is a *good* thing. Slashdot and Kuro5hin's moderation systems have done wonders for their signal-to-noise ration from the end-user perspective -- set your threshold to a number you're comfortable with, and get your job done. Just a thought :) -- Matthew P. Barnson - - - - Thought for the moment: n = ((n >> 1) & 0x55555555) | ((n << 1) & 0xaaaaaaaa); n = ((n >> 2) & 0x33333333) | ((n << 2) & 0xcccccccc); n = ((n >> 4) & 0x0f0f0f0f) | ((n << 4) & 0xf0f0f0f0); n = ((n >> 8) & 0x00ff00ff) | ((n << 8) & 0xff00ff00); n = ((n >> 16) & 0x0000ffff) | ((n << 16) & 0xffff0000); -- C code which reverses the bits in a word. From gerv at mozilla.org Mon Mar 22 23:42:41 2004 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 22 Mar 2004 23:42:41 +0000 Subject: Partial custom fields design document In-Reply-To: <20040322041905.B2E43C460@diggity.schwag.org> References: <20040322041905.B2E43C460@diggity.schwag.org> Message-ID: <405F79F1.1010600@mozilla.org> Before I kick off, I should say that I rather like this design. My one overall concern is that some parts of it don't fit well with our object-oriented design (such as it is.) I've reviewed the first bit in more detail than the later bits. Such is my attention span. ;-) Sean McAfee wrote: > display_name is the human-readable name of the field which appears on > the Web interface. How does this interact with localisation? > The cf_membership table describes which fields belong to which > products, and in what order those fields are to be displayed on the > web interface. Currently, fields are not really displayed in the web interface in an "order", but in a two-dimensional layout. How would the "sortkey" parameter map to a position in that layout? How would it interact with permanent fields? > The cf_selections table enumerates every selection field defined at > this Bugzilla installation, and provides an "unset label" for each. > An "unset label" is a short string which is displayed on the Web > interface when the value is a selection field is the empty set. Multi-select fields can have an empty membership, but do not need a special value to denote that. Arguably single-select fields could have an empty set - but would it not be better to just have a "default" flag in cf_selection_labels? That way, you could: - Have multiple defaults for a multi-select - Have a meaningful default - e.g. P3 as a default priority. - Emulate the current suggestion by merely adding the "unset label" as another option and making it the default. > inactive is true if the label is inactive, and false otherwise. A > label may be made inactive when it should no longer be possible to > store new data with that label. The label must remain in the > database, however, so that old data can refer to it. How would this work in practice? Would it be present in lists only when selected, and absent otherwise, allowing people to remove the value but not add it? I suggest that might be confusing. Deprecation of values is IMO better handled by a mass-query to remove the value from bugs, and then removal from the list. > sortkey is an integer used for ordering the labels within a selection > set. Is this necessary? I would have thought most people would be happy with alphabetical order. Having a sortkey necessitates more UI and complexity... > The cf_lonstring table holds data for long string custom fields. Nit: typo. > The cf_data table holds data for date and date/time custom fields. Nit: typo. Better to call it cf_datetime, as it also contains times? > get_custom_fields > ----------------- > > This function returns information on zero or more custom fields. Its > arguments should be in the form of zero or one name-value pairs, as > enumerated in the following prototype: > > @custom_fields = get_custom_fields( > [ product => $product, ] > [ product_id => $product_id, ] > [ bug_id => $bug_id, ] > [ fields => \@fields, ] > [ field_ids => \@field_ids, ] > ); I'm not convinced we'll need all these options in practice... As a matter of preference, I'm also generally a fan of having a different function for each. Also, the bug ID one will be a method on the bug object. > the fields appear in in that product. If no such product exists, an > exception is thrown. We don't tend to throw exceptions in Bugzilla... unless you mean ThrowCodeError()? > extended > A boolean value, true if the field is of type long string, > date/time, or multiselection, and false otherwise. > > is_integer > A boolean value, true if the field is of type integer, and false > otherwise. What's wrong with a "type" field? > as_string > A reference to a subroutine which can convert the field's value to > a simple string representation. It will be undefined for > selection fields. toString() is the more usual name, I think. > [ The is_integer, is_date, is_string, is_selection, and extended > elements are redundant with the type element, but they are more > convenient to use from templates. ] We should probably make that determination at implementation time; at first sight, I don't think it's worth the additional interface complexity. > For selection fields, the following additional elements are present: > > unset > The field's "unset label", taken from the unset_label column of > the CF_SELECTIONS table. > > domain > A reference to an array containing the labels which make up the > field's domain, sorted into the appropriate order. domain is probably technically the correct word, but we should consider a more user-friendly name if we can think of one. > lblid > A hash reference. The keys are the labels that make up the > field's domain, and the values are the corresponding numerical > label IDs. Surely "labelid"? :-) > label > A hash reference. The keys are numerical IDs of the labels which > make up the field's domain, and the corresponding values are > references to hashes which describe that label. Why do we need both hashes? Can they not be combined? > store_custom_fields > ------------------- > > This function adds new custom field data to the database. It should > be called only when a new bug is being created. Again, I think this code should be internal to the Bug object. > update_custom_fields > -------------------- And again. > QUERYING > ======== > > An interface for obtaining lists of bugs which meet user-specified > criteria is provided by the module Bugzilla::CustomFields::Query. Why is this code not an enhancement to the current query module? I can't quite see how the two are integrated. This design doesn't yet cover tracking bug_activity for custom fields... Gerv From bugreport at peshkin.net Mon Mar 22 23:52:46 2004 From: bugreport at peshkin.net (Joel Peshkin) Date: Mon, 22 Mar 2004 15:52:46 -0800 Subject: Partial custom fields design document In-Reply-To: <405F79F1.1010600@mozilla.org> References: <20040322041905.B2E43C460@diggity.schwag.org> <405F79F1.1010600@mozilla.org> Message-ID: <405F7C4E.9010408@peshkin.net> Gervase Markham wrote: > Sean McAfee wrote: > >> display_name is the human-readable name of the field which appears on >> the Web interface. > > > How does this interact with localisation? > I've been advocating the use of a "hook" mechanism to permit templates that know better to preempt the default handling of the UI for customfields on a per-field basis. > > > This design doesn't yet cover tracking bug_activity for custom fields... > > > Gerv Why wouldn't this be just a case of adding a field to the bug activity table indicating if the fieldid is a custom field or a standard field? From mkanat at kerio.com Tue Mar 23 00:11:53 2004 From: mkanat at kerio.com (Maxwell Kanat-Alexander) Date: Mon, 22 Mar 2004 16:11:53 -0800 Subject: Bugzilla Flow In-Reply-To: References: Message-ID: <1080000713.5429.1.camel@localhost.localdomain> On Wed, 2004-01-28 at 06:42, Kumar, Arun wrote: > Hi Dave, > > I have made the necessary modifications, see if it makes sense now. Hey Arun -- I'd like to get this state chart into the Bugzilla documentation. Do you have the source that you used to create the chart with? If so, could you attach it to bug 137631 ? -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 mdavis at laszlosystems.com Tue Mar 23 02:19:28 2004 From: mdavis at laszlosystems.com (Mark Davis) Date: Mon, 22 Mar 2004 18:19:28 -0800 Subject: Partial custom fields design document In-Reply-To: <405F79F1.1010600@mozilla.org> References: <20040322041905.B2E43C460@diggity.schwag.org> <405F79F1.1010600@mozilla.org> Message-ID: <405F9EB0.2010408@laszlosystems.com> Gervase Markham wrote: >> sortkey is an integer used for ordering the labels within a selection >> set. > > > Is this necessary? I would have thought most people would be happy > with alphabetical order. Having a sortkey necessitates more UI and > complexity... I find that to be very useful for some fields. In our installation we're tracking symptom, scope, client OS and server JVM*. Scope is a range of people affected by the defect reported and it includes "usr-all, usr-most, usr-some, usr-few, dev-all, dev-most, dev-some, dev-few, adm-all, adm-most, adm-some, adm-few, laszlo" Keeping them in that order is very nice for the bug writers to get used to. FWIW YMMV * There's actually quite a few more custom fields that we've added for revison, version and release tracking... -- Mark Davis Quality Assurance Manager, Laszlo Systems (415) 241-2736 -- http://www.laszlosystems.com From etzwane at schwag.org Tue Mar 23 03:07:07 2004 From: etzwane at schwag.org (Sean McAfee) Date: Mon, 22 Mar 2004 22:07:07 -0500 Subject: Partial custom fields design document In-Reply-To: <405F79F1.1010600@mozilla.org> Message-ID: <20040323030708.320F6C45F@diggity.schwag.org> Gervase Markham wrote: >Sean McAfee wrote: >> display_name is the human-readable name of the field which appears on >> the Web interface. >How does this interact with localisation? It doesn't, yet. As we've discussed before, I favor storing localized text in the database, while I know you'd rather see it in templates. I'm willing to be convinced that templates are better, but I'd need to see a good example of how that would work. >> The cf_membership table describes which fields belong to which >> products, and in what order those fields are to be displayed on the >> web interface. >Currently, fields are not really displayed in the web interface in an >"order", but in a two-dimensional layout. How would the "sortkey" >parameter map to a position in that layout? How would it interact with >permanent fields? In the current implementation, custom fields appear in a table, one field per row, above the attachments. I'd never really thought about it before, but it might be nifty to be able to store more sophisticated layout information in the DB and display the custom fields according to it. >> The cf_selections table enumerates every selection field defined at >> this Bugzilla installation, and provides an "unset label" for each. >> An "unset label" is a short string which is displayed on the Web >> interface when the value is a selection field is the empty set. >Multi-select fields can have an empty membership, but do not need a >special value to denote that. Hmmm, maybe not. One of the changes I introduced since my original implementation was to represent scalar fields whose values are NULL as a gray-toned pair of hyphens. The same could be done for multiselects, I suppose. >Arguably single-select fields could have >an empty set - but would it not be better to just have a "default" flag >in cf_selection_labels? That way, you could: > >- Have multiple defaults for a multi-select >- Have a meaningful default - e.g. P3 as a default priority. >- Emulate the current suggestion by merely adding the "unset label" as >another option and making it the default. A default value is a distinct concept from an unset value. Let me mull this over a bit... >> inactive is true if the label is inactive, and false otherwise. A >> label may be made inactive when it should no longer be possible to >> store new data with that label. The label must remain in the >> database, however, so that old data can refer to it. >How would this work in practice? Well, the primary use for it here is with selection fields whose domains are sets of employees. When an employee leaves the company, it should no longer be possible to set the field to his name. However, it's still important to be able to retain the employee's name on old bugs. >Would it be present in lists only when >selected, and absent otherwise, allowing people to remove the value but >not add it? I suggest that might be confusing. Perhaps, but unavoidably so IMHO. >Deprecation of values is IMO better handled by a mass-query to remove >the value from bugs, and then removal from the list. Eradicating old data like this isn't really acceptable. >> sortkey is an integer used for ordering the labels within a selection >> set. >Is this necessary? I would have thought most people would be happy with >alphabetical order. Having a sortkey necessitates more UI and complexity... Yes, but not much more. As a simple example of when alphabetic order isn't the best choice, consider a selection field describing something similar to priority, with three values "Low", "Medium", and "High". That order is more natural than "High", "Low", "Medium". >> The cf_data table holds data for date and date/time custom fields. >Better to call it cf_datetime, as it also contains times? Well, perhaps. >> get_custom_fields >> ----------------- >> >> This function returns information on zero or more custom fields. Its >> arguments should be in the form of zero or one name-value pairs, as >> enumerated in the following prototype: >> >> @custom_fields = get_custom_fields( >> [ product => $product, ] >> [ product_id => $product_id, ] >> [ bug_id => $bug_id, ] >> [ fields => \@fields, ] >> [ field_ids => \@field_ids, ] >> ); >I'm not convinced we'll need all these options in practice... Actually, usefulness in practice is why I introduced most of them. >As a >matter of preference, I'm also generally a fan of having a different >function for each. I'd rather limit the number of functions exported by the API. Consider a situation like this: if (fetch_by_product()) { @args = (product => $product); } else { @args = (product_id => $product_id); } @fields = get_custom_fields(@args); Versus: if (fetch_by_product()) { ($func, $arg) = (\&get_custom_fields_by_product, $product); } else { ($func, $arg) = (\&get_custom_fields_by_product_id, $product_id); } @fields = $func->($arg); I think the unified API provides a cleaner approach. >> the fields appear in in that product. If no such product exists, an >> exception is thrown. >We don't tend to throw exceptions in Bugzilla... unless you mean >ThrowCodeError()? Well, no. Actually, this touches on an important issue. It's vital for my purposes to be able to access Bugzilla data from programs--cron jobs and the like--which lack an enclosing browser context. Right now I'm just kind of grinning and bearing the fact that errors in such programs can generate error messages that look like HTTP responses, thanks to the $SIG{__DIE__} handler that gets installed somewhere. Perhaps some kind of global switch is called for which determines whether a Bugzilla program has a browser context or not. I certainly don't mind making the default answer to this question "Yes" and requiring other programs to take an extra step to make it "No". >> extended >> A boolean value, true if the field is of type long string, >> date/time, or multiselection, and false otherwise. >> >> is_integer >> A boolean value, true if the field is of type integer, and false >> otherwise. > >What's wrong with a "type" field? Nothing. There is one. >> as_string >> A reference to a subroutine which can convert the field's value to >> a simple string representation. It will be undefined for >> selection fields. >toString() is the more usual name, I think. I'm not really fond of the StudlyCaps convention, at least not in Perl. >> [ The is_integer, is_date, is_string, is_selection, and extended >> elements are redundant with the type element, but they are more >> convenient to use from templates. ] >We should probably make that determination at implementation time; at >first sight, I don't think it's worth the additional interface complexity. Actually, reducing complexity was my motivation for introducing these elements. Compare: [% IF field.is_selection %] ... [% ELSIF field.extended %] ... [% END %] Versus: [% IF field.type == "e" or field.type == "m" %] ... [% ELSIF field.type == "t" or field.type == "l" or field.type == "m" %] ... [% END %] >> lblid >> A hash reference. The keys are the labels that make up the >> field's domain, and the values are the corresponding numerical >> label IDs. >Surely "labelid"? :-) Well, I suppose it doesn't matter much. To me, "lblid" seems like a straightforward, if terse, name. >> label >> A hash reference. The keys are numerical IDs of the labels which >> make up the field's domain, and the corresponding values are >> references to hashes which describe that label. >Why do we need both hashes? Can they not be combined? In theory, yes, but again, reducing complexity was my motivation for the redundancy. "lblid" is used for converting labels supplied by a user into numerical selection IDs, eg: my $lblid = $field->{lblid}; my @userdata = Bugzilla->cgi->param('selection_field'); my @invalid = grep !exists $lblid->{$_}, @userdata; if (@invalid) { throw_invalid_selection_label_error(@invalid); } my @selection_id = @$lblid{ @userdata }; ...whereas "label" is used for the opposite purpose, ie. converting numerical selection IDs from the database into textual labels for presentation to the user, eg: my $label = $field->{label}; my @selection_id = read_selection_table($bug_id, $field_id); my @text = map { $_->{text} } sort { $a->{order} <=> $b->{order} } @$label{ @selection_id }; >> store_custom_fields >> ------------------- >> >> This function adds new custom field data to the database. It should >> be called only when a new bug is being created. >Again, I think this code should be internal to the Bug object. No objection here. >> update_custom_fields >> -------------------- >And again. Nor here. >> QUERYING >> ======== >> >> An interface for obtaining lists of bugs which meet user-specified >> criteria is provided by the module Bugzilla::CustomFields::Query. >Why is this code not an enhancement to the current query module? I can't >quite see how the two are integrated. They're not. This module is intended as a complete replacement, for two reasons. First, the original module is predicated on the assumption that a query result set can be obtained by a single SQL select statement, an assumption that no longer holds when selection fields enter the picture. Rather than attempting to shoehorn custom field querying onto a fundamentally incompatible basis, I decided that a rewrite was in order. Secondly, well... I mean no offense to the original author or authors, but the existing query code appears exceptionally crufty and impenetrable to me. I had to pore over it for a long time before I finally began to figure it out. No doubt this is due largely to the long evolution of the codebase, but whatever the cause, I think a clean rewrite can only help everyone. Actually, I guess there's a third reason. As I've stated, it's very important that I be able to search Bugzilla from a non-browser context. The current scheme does not support this. Vast amounts of preparation are performed in buglist.cgi before hanging the query off to Bugzilla::Search. Having the entirety of the query code in one module is much more convenient for me, as well being a cleaner design in general. > >This design doesn't yet cover tracking bug_activity for custom fields... > I was going to leave that for a later iteration of the design, but I can introduce it in the current one if you'd prefer. --Sean From gerv at mozilla.org Tue Mar 23 07:40:56 2004 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 23 Mar 2004 07:40:56 +0000 Subject: Partial custom fields design document In-Reply-To: <20040323030708.320F6C45F@diggity.schwag.org> References: <20040323030708.320F6C45F@diggity.schwag.org> Message-ID: <405FEA08.3090601@mozilla.org> Sean McAfee wrote: >>>display_name is the human-readable name of the field which appears on >>>the Web interface. > >>How does this interact with localisation? > > It doesn't, yet. As we've discussed before, I favor storing localized text > in the database, while I know you'd rather see it in templates. It's not that I'd rather see it in templates, it is that is _is_ in templates right now. On http://www.bugzilla.org/download.html we have ten localisation packs. To use any one (on a compatible version) you download it, unzip it and set a single parameter. If you want to get rid of it, you delete it and put the parameter back. My view is that this simplicity should not be changed. Other than that, I have no implementation views. > I'm willing > to be convinced that templates are better, but I'd need to see a good > example of how that would work. Both this and the positioning issue touch on a basic philosophical question: do we make the addition of custom fields require template and/or config file changes? There are several advantages of doing so: - Bugzilla administrators can specify exactly where they want the field to be laid out in various places. - They can specify exactly what it should be called in the UI, for all the languages they have defined. - It makes it non-trivial to add a custom field. This is a customer protection mechanism; if it's trivial, the usability of their bug system will undoubtedly go down under management pressure. - Much-reduced implementation complexity. I'm sure someone who believes admins should be able to do it all from a web GUI can make the case for the other side. > In the current implementation, custom fields appear in a table, one field > per row, above the attachments. I'd never really thought about it before, > but it might be nifty to be able to store more sophisticated layout > information in the DB and display the custom fields according to it. See above; IMO layout information is best stored in templates. > Hmmm, maybe not. One of the changes I introduced since my original > implementation was to represent scalar fields whose values are NULL as > a gray-toned pair of hyphens. The same could be done for multiselects, I > suppose. I don't quite follow you here. A multiselect with an empty set looks like a multi-select with nothing selected. Where do the hyphens come in? >>- Have multiple defaults for a multi-select >>- Have a meaningful default - e.g. P3 as a default priority. >>- Emulate the current suggestion by merely adding the "unset label" as >>another option and making it the default. > > A default value is a distinct concept from an unset value. Let me mull this > over a bit... Indeed - you are correct. But if the admin wants an "unset" value, they can just have a single default value called "unset", "---" or whatever. > Consider a situation like this: > > if (fetch_by_product()) { > @args = (product => $product); > } else { > @args = (product_id => $product_id); > } Why would you be doing both? If you have a product name, convert it to an ID using the function provided for this purpose and then call the API. > Versus: > > if (fetch_by_product()) { > ($func, $arg) = (\&get_custom_fields_by_product, $product); > } else { > ($func, $arg) = (\&get_custom_fields_by_product_id, $product_id); > } > > @fields = $func->($arg); That's a long-winded way of putting it. :-) In a particular piece of code, one should either be dealing with ones products as names or IDs, not both. $id = getProductId($product); ... @fields = get_custom_fields_by_product_id($id); >>We don't tend to throw exceptions in Bugzilla... unless you mean >>ThrowCodeError()? > > Well, no. Actually, this touches on an important issue. Stop right there :-) The issue of whether Bugzilla starts throwing exceptions or not is utterly separate from the design of custom fields. Let's not confuse the two, otherwise arguments about one will hinder the other. If you want to have that debate, let's have it, but not in the context of custom fields. >>toString() is the more usual name, I think. > > I'm not really fond of the StudlyCaps convention, at least not in Perl. Hmm. Looking through the existing modules, there seems to be an about even split between the two. This is not an ideal situation. We need to get Dave to pick one. > Actually, reducing complexity was my motivation for introducing these > elements. Compare: > > [% IF field.is_selection %] > ... > [% ELSIF field.extended %] > ... > [% END %] > > Versus: > > [% IF field.type == "e" or field.type == "m" %] > ... > [% ELSIF field.type == "t" or field.type == "l" or field.type == "m" %] > ... > [% END %] Again, a straw man :-) [% SWITCH field.type %] [% CASE "e" %] [% CASE "m" %] ... or even [% IF field.type.match(/[me]/) %] ... [% ENDIF %] Actually, thinking about it, you'd be better off using numbers in the database, and constants in the Bugzilla code, like the Auth stuff does now and like the new email stuff will. [% SWITCH field.type %] [% CASE MULTI_SELECT %] [% CASE SINGLE_SELECT %] ... >>>lblid >>> A hash reference. The keys are the labels that make up the >>> field's domain, and the values are the corresponding numerical >>> label IDs. > > >>Surely "labelid"? :-) > > > Well, I suppose it doesn't matter much. To me, "lblid" seems like a > straightforward, if terse, name. Why compress if you don't have to? Disk space is cheap ;-) "lblid" and "label" are inconsistent with each other. >>Why is this code not an enhancement to the current query module? I can't >>quite see how the two are integrated. > > They're not. This module is intended as a complete replacement, for > two reasons. First, the original module is predicated on the assumption > that a query result set can be obtained by a single SQL select statement, > an assumption that no longer holds when selection fields enter the > picture. So what does this mean for our set of supported databases? > Rather than attempting to shoehorn custom field querying onto > a fundamentally incompatible basis, I decided that a rewrite was in order. Rewriting the search module (which is some of our oldest and therefore least buggy code) is a massive job. Yes, as you say, it's crufty and impenetrable, but it also _works_. If there is a rewrite, we would need to adopt a strategy something like the following. It should begin as a reimplementation with exactly the same interface, so we can compare the two over a range of queries and a period of time in production usage. Then, we can change the interface to the new one, and then we can add custom field querying. > Actually, I guess there's a third reason. As I've stated, it's very > important that I be able to search Bugzilla from a non-browser context. The > current scheme does not support this. Vast amounts of preparation are > performed in buglist.cgi before hanging the query off to Bugzilla::Search. Anything needed to actually do a search is done in Bugzilla::Search. We know this, because places other than buglist.cgi do searches :-) You can't just incorporate all that buglist.cgi stuff into Bugzilla::Search or a replacement for it, because many callers don't need it. >> >>This design doesn't yet cover tracking bug_activity for custom fields... >> > > I was going to leave that for a later iteration of the design, but I can > introduce it in the current one if you'd prefer. Why not have all the arguments, that is, discussions, at once? :-) Gerv From Arun.Kumar at mercer.com Tue Mar 23 14:10:52 2004 From: Arun.Kumar at mercer.com (Kumar, Arun) Date: Tue, 23 Mar 2004 09:10:52 -0500 Subject: Bugzilla Flow Message-ID: Hey Max, Done. Let me know if I can be of any help. Kudos !! for the great work guys !! --Arun -----Original Message----- From: Maxwell Kanat-Alexander [mailto:mkanat at kerio.com] Sent: Monday, March 22, 2004 7:12 PM To: developers at bugzilla.org Cc: Arun.Kumar at mercer.com Subject: Re: Bugzilla Flow On Wed, 2004-01-28 at 06:42, Kumar, Arun wrote: > Hi Dave, > > I have made the necessary modifications, see if it makes sense now. Hey Arun -- I'd like to get this state chart into the Bugzilla documentation. Do you have the source that you used to create the chart with? If so, could you attach it to bug 137631 ? -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 bruce.armstrong at teamsybase.com Tue Mar 23 20:12:32 2004 From: bruce.armstrong at teamsybase.com (Bruce Armstrong [TeamSybase]) Date: Tue, 23 Mar 2004 12:12:32 -0800 (PST) Subject: XML Documentation patches needed In-Reply-To: <200403211040.15843.vlad@goobix.com> Message-ID: <20040323201232.53993.qmail@web12504.mail.yahoo.com> What do we do if we notice some mising documentation that there doesn't yet seem to be a bug to address. In particular, I can't find anything in the current docs that discusses the purpose of the timetrackinggroup param. Should we open a bug first, or simply submit a change? Vlad Dascalu wrote:As we're getting closer to the 2.18 release, we are increasingly needing documentation updates to reflect the code changes that happened during our development cycle. The documentation is stored in CVS in the docs/xml directory using the DocBook format; writing patches to update it is a pretty straightforward process. There are currently 54 bugs for documentation updates (that need XML patches), all targeted to 2.18. Some of them have the documentation posted as a comment and only need a diff for the XML patch that can be applied to the CVS tip. Others need someone to play with the newly introduced feature/enhancement, then propose a text that describes it. If you have any free time, help would be appreciated with those tasks, even if it's a simple sentence or a simple diff command. It will also be a great way to get involved in the BZ-devel world. You can query for those bugs in Bugzilla by searching all bugs from the Documentation component of the Bugzilla product. If you want to help and you have questions don't hesitate to ask. You can find justdave and others on #mozwebtools (irc.mozilla.org) for live assistance on how to get involved. Thanks! (let's make the 2.18 release rock :) ) Vlad. - 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 justdave at bugzilla.org Tue Mar 23 20:45:56 2004 From: justdave at bugzilla.org (David Miller) Date: Tue, 23 Mar 2004 15:45:56 -0500 Subject: XML Documentation patches needed In-Reply-To: <20040323201232.53993.qmail@web12504.mail.yahoo.com> References: <20040323201232.53993.qmail@web12504.mail.yahoo.com> Message-ID: On 3/23/2004 12:12 PM -0800, Bruce Armstrong \[TeamSybase\] wrote: >What do we do if we notice some mising documentation that there doesn't >yet seem to be a bug to address. In particular, I can't find anything in >the current docs that discusses the purpose of the timetrackinggroup >param. Should we open a bug first, or simply submit a change? Yes, anything you see missing is a definite want. Open a bug and attach your patch to it. :) -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From AndyHowell at austin.rr.com Wed Mar 24 23:01:23 2004 From: AndyHowell at austin.rr.com (Andy Howell) Date: Wed, 24 Mar 2004 17:01:23 -0600 Subject: checksetup.pl problem Message-ID: <40621343.9000909@austin.rr.com> I just installed, but haven't deployed 2.16.5. Hearing that 2.18 was on its way, I decided to give the cvs tip a try. When I ran checksetup.pl I see the following error: Adding new field refreshed_when to table profiles ... Use of uninitialized value in concatenation (.) or string at ./checksetup.pl line 3502. DBD::mysql::st execute failed: You have an error in your SQL syntax near '' at line 2 at ./checksetup.pl line 3504. DBD::mysql::st fetchrow_array failed: fetch() without execute() at ./checksetup.pl line 3505. Use of uninitialized value in concatenation (.) or string at ./checksetup.pl line 3552. DBD::mysql::st execute failed: You have an error in your SQL syntax near '' at line 2 at ./checksetup.pl line 3554. DBD::mysql::st fetchrow_array failed: fetch() without execute() at ./checksetup.pl line 3555. I think the error come about becaue the table fielddefs does not have and entry where name = 'groupset'. I have not used the groups functionality. Hope this helps, Andy From gerv at mozilla.org Wed Mar 24 00:22:59 2004 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 24 Mar 2004 00:22:59 +0000 Subject: Bugzilla as a discussion forum In-Reply-To: <20040322231826.GK45419@barnson.org> References: <405F1D96.6010906@mozilla.org> <405F7319.4010003@mozilla.org> <20040322231826.GK45419@barnson.org> Message-ID: <4060D4E3.3040302@mozilla.org> Barnboy wrote: > Me, I'm of the opinion that discussion on a bug is a *good* thing. Up to a point. However, there are a number of Mozilla hackers who would certainly agree that you can have too much of this particular good thing. Which was the point of the discussion. > Slashdot and Kuro5hin's moderation systems have done wonders for > their signal-to-noise ration from the end-user perspective -- set > your threshold to a number you're comfortable with, and get your job > done. Implementing moderation would be another further mistake in the same line. People would argue about moderation, demand meta-moderation, complain that their important comment was getting ignored because a key person had a threshold set higher, etc. etc. This is a can of worms we really do _not_ want to open. Gerv From preed at sigkill.com Wed Mar 24 00:33:21 2004 From: preed at sigkill.com (J. Paul Reed) Date: Tue, 23 Mar 2004 16:33:21 -0800 Subject: Bugzilla as a discussion forum In-Reply-To: <4060D4E3.3040302@mozilla.org> References: <405F1D96.6010906@mozilla.org> <405F7319.4010003@mozilla.org> <20040322231826.GK45419@barnson.org> <4060D4E3.3040302@mozilla.org> Message-ID: <20040324003321.GA31673@sigkill.com> On 24 Mar 2004 at 00:22:59, Gervase Markham arranged the bits on my disk to say: > Barnboy wrote: > >Me, I'm of the opinion that discussion on a bug is a *good* thing. > > Up to a point. However, there are a number of Mozilla hackers who would > certainly agree that you can have too much of this particular good > thing. Which was the point of the discussion. It'd be interesting to have a feature where the bug owner/component owner could "turn off" discussion such that it would restrict it only to owner/module owner/QA contact/a certain group; this may have already been proposed, as I've just been skimming this thread. Moderation is definitely a bad idea. 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 ihok at hotmail.com Wed Mar 24 00:41:36 2004 From: ihok at hotmail.com (Jack Tanner) Date: Tue, 23 Mar 2004 19:41:36 -0500 Subject: Bugzilla as a discussion forum In-Reply-To: <405F7319.4010003@mozilla.org> References: <405F1D96.6010906@mozilla.org> <405F7319.4010003@mozilla.org> Message-ID: My apologies for making someone have to approve this for posting manually. I'm using Gmane to read and post, and I don't subscribe to the mailing list. Gervase Markham wrote: > I think his point is that people with signal are more likely to move > past bad UI than people with offhand noise. Right; it's a plausible hypothesis, but not a substantiated one. The opposite is also plausible. > Now that's an interesting idea. We could visually distinguish comments > from the current assignee, QA contact and reporter. Sure, that's probably the minimum set worth distinguishing. You might also add whoever is asked for reviews. But chances are that other people, not explicitly related to the bug, might chime in with something worthwhile. For example, all the drivers, all the Mozilla Foundation staff, anyone whose patch has ever been committed, etc. Pick your criteria. The complementary approach is also interesting. Let's pretend that comments can be "collapsed" so only the author and date show up, similar to the list of e-mails in your e-mail client. If you click a "show-me-more" button to the comment, the comment expands. Say that we're looking at a bug that has so many comments (more than N), that reading through all of them is not practical; in this case, a special mechanism kicks in where some comments are collapsed by default. What criteria can be used to collapse comments by default? Length, authorship, key words, the fact noone who has looked at this page has bothered to uncollapse the comment, etc. (For those of you keeping score at home, this is starting to look like spam/ham detection...) >> 2) requiring that only really special people can turn off bugmail >> (e.g., see list above), > > How does this make it more difficult to post noise? It does in combination with 3, below. >> and 3) requiring that only people CC'ed on the bug can post to the >> discussion. > > I don't like that idea. Non-CC comments are too useful in legitimate work. You could relax the requirement for a select few (drivers, reviewers, etc.). >> The hypothesis here is that high-discussion, high-noise bugs (e.g., >> the MNG fiasco) would then automatically generate so much mail to all >> discussants, that the social cost of posting me-too's and other noise >> would rise quickly. > > Problem is, that doesn't discourage people. The social cost is already > high, but people feel "my opinion is important, and it needs to be heard." True, but I think the social cost rises if you implement (3) above. You post a comment, and it's CC'ed to all these people, and you feel self-righteous for making an intellectual contribution with your inane me-too. But then you get CC'ed on all these other me-toos, and you may learn the error of your ways and think twice before posting again. (It's a nice theory, at least, don't you think?) By the way, another perspective on what we're discussing here is that we're adding incentives for people to increase their tangible participation in Mozilla development by writing patches, triaging, QAing, etc., because that leads to getting Bugzilla privileges (like being able to post to bugs without having to be CC'ed). -JT From bugreport at peshkin.net Wed Mar 24 14:13:09 2004 From: bugreport at peshkin.net (Joel Peshkin) Date: Wed, 24 Mar 2004 06:13:09 -0800 Subject: checksetup.pl problem In-Reply-To: <40621343.9000909@austin.rr.com> References: <40621343.9000909@austin.rr.com> Message-ID: <40619775.8010804@peshkin.net> Andy Howell wrote: > I just installed, but haven't deployed 2.16.5. Hearing that 2.18 was > on its way, I decided to give the cvs tip a try. When I ran > checksetup.pl I see the following error: > > Adding new field refreshed_when to table profiles ... > Use of uninitialized value in concatenation (.) or string at > ./checksetup.pl line 3502. > DBD::mysql::st execute failed: You have an error in your SQL syntax > near '' at line 2 at ./checksetup.pl line 3504. > DBD::mysql::st fetchrow_array failed: fetch() without execute() at > ./checksetup.pl line 3505. I see the same problem. This is not a cockpit error. It is a regression. From bugreport at peshkin.net Wed Mar 24 14:24:39 2004 From: bugreport at peshkin.net (Joel Peshkin) Date: Wed, 24 Mar 2004 06:24:39 -0800 Subject: checksetup.pl problem In-Reply-To: <40621343.9000909@austin.rr.com> References: <40621343.9000909@austin.rr.com> Message-ID: <40619A27.5050609@peshkin.net> Andy Howell wrote: > I just installed, but haven't deployed 2.16.5. Hearing that 2.18 was > on its way, I decided to give the cvs tip a try. When I ran > checksetup.pl I see the following error: > > > I think the error come about becaue the table fielddefs does not have > and entry where name = 'groupset'. > > I have not used the groups functionality. Andy, Your assessment is exactly correct. If someone has NEVER changed a group setting, 2.16 would not have defined groupset as a field and it would do this. Nice catch. -Joel From AndyHowell at austin.rr.com Wed Mar 24 19:17:43 2004 From: AndyHowell at austin.rr.com (Andy Howell) Date: Wed, 24 Mar 2004 13:17:43 -0600 Subject: checksetup.pl problem In-Reply-To: <40619A27.5050609@peshkin.net> References: <40621343.9000909@austin.rr.com> <40619A27.5050609@peshkin.net> Message-ID: <4061DED7.8080108@austin.rr.com> Joel Peshkin wrote: > Your assessment is exactly correct. If someone has NEVER changed a > group setting, 2.16 would not have defined groupset as a field and it > would do this. Nice catch. Joel, Thanks. I'm giving groups a try in the current version. No problems so far. Andy From AndyHowell at austin.rr.com Thu Mar 25 13:35:53 2004 From: AndyHowell at austin.rr.com (Andy Howell) Date: Thu, 25 Mar 2004 07:35:53 -0600 Subject: Tinderbox 3 development Message-ID: <4062E039.5010205@austin.rr.com> I've been learning how tinderbox3 works over the last couple days. I want to use it for an internal project. Instead of just hacking it to fit my imediate need, I would like to make it more generic and easier to install. Some of the things I'm thinking of: Tinderclient Add authentication Consolidate mozilla specific URLs etc to start of file for easy customization Client & Server Make the location of the checkout & build makefile, mozilla/client.mk,part of the tree definition. Testing Make a stripped down client.mk file for testing/example Make a hello-world test for import into the CVS Documentation Write up install and useage... I working on the test setup now, as a way to learn how this all hangs together. I've got some very messy note on installing etc, wheich I'll clean up and post in a few days. I'm not sure if there is interest in this or not. Regards, ANdy From justdave at bugzilla.org Thu Mar 25 16:01:07 2004 From: justdave at bugzilla.org (David Miller) Date: Thu, 25 Mar 2004 11:01:07 -0500 Subject: Tinderbox 3 development In-Reply-To: <4062E039.5010205@austin.rr.com> References: <4062E039.5010205@austin.rr.com> Message-ID: On 3/25/2004 7:35 AM -0600, Andy Howell wrote: > I've been learning how tinderbox3 works over the last couple days. I > want to use it for an internal project. Instead of just hacking it to > fit my imediate need, I would like to make it more generic and easier to > install. This is kind of off-topic here.... this mailing list is specifically for Bugzilla. You might want to discuss this on mozilla-webtools at mozilla.org, which is where the Tinderbox discussion is. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From AndyHowell at austin.rr.com Thu Mar 25 16:20:15 2004 From: AndyHowell at austin.rr.com (Andy Howell) Date: Thu, 25 Mar 2004 10:20:15 -0600 Subject: Tinderbox 3 development In-Reply-To: References: <4062E039.5010205@austin.rr.com> Message-ID: <406306BF.4020202@austin.rr.com> David Miller wrote: > On 3/25/2004 7:35 AM -0600, Andy Howell wrote: > This is kind of off-topic here.... this mailing list is specifically for > Bugzilla. You might want to discuss this on mozilla-webtools at mozilla.org, > which is where the Tinderbox discussion is. Sorry, will move it there. Thanks Andy From kiko at async.com.br Thu Mar 25 18:15:11 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Thu, 25 Mar 2004 15:15:11 -0300 Subject: Bugzilla as a discussion forum In-Reply-To: <20040324003321.GA31673@sigkill.com> References: <405F1D96.6010906@mozilla.org> <405F7319.4010003@mozilla.org> <20040322231826.GK45419@barnson.org> <4060D4E3.3040302@mozilla.org> <20040324003321.GA31673@sigkill.com> Message-ID: <20040325181511.GA2420@async.com.br> On Tue, Mar 23, 2004 at 04:33:21PM -0800, J. Paul Reed wrote: > > Barnboy wrote: > > >Me, I'm of the opinion that discussion on a bug is a *good* thing. > > > > Up to a point. However, there are a number of Mozilla hackers who would > > certainly agree that you can have too much of this particular good > > thing. Which was the point of the discussion. > > It'd be interesting to have a feature where the bug owner/component owner > could "turn off" discussion such that it would restrict it only to > owner/module owner/QA contact/a certain group; this may have already been > proposed, as I've just been skimming this thread. Timeless once filed a bug that requested exactly that: blocking a bug on a question or resolution. I think that would manage BMO's problem (at least with the bugs that seem to annoy everybody, i.e. MNG etc) quite nicely, since everybody knows that additional "yeah! count my opinion in!" comments are useless. Timeless, am I right about this, and do you have a bug # handy? I'd like to point out, however, that the problem mpt's pointing out really only happens to a minority of bugs -- I'd say currently less than 50 open bugs in BMO. I think in the vast majority of cases, we're better off by providing better tools for communicating via Bugzilla. I'll elaborate here. The reason I implemented reply quoting is obvious: I wanted to make it easy for people to do context-enhanced replies. This is really nice, IMO, when replying to review comments, because you might want to disagree or differ in a specific bit here or there, and having the context is a lot more convenient and less error-prone than copying stuff around manually or citing by reference. It's also nice when people want to do clarifications or question parts of summaries and mini-specs posted to the bug. I agree there's a potential for abuse. I don't think the potential is large for most of the Bugzilla installations out there, which is why I actually pushed to include this in Bugzilla proper (I would have been happy with it as a local change -- it's really trivial). Perhaps for BMO the problem is significant enough to warrant removing it from templates or implementing some sort of "max-context" feature, but I loath the latter (as a bad idea) and I haven't seen grounds for the former yet. Finally, I think that having discussion kept on the bug is a *good* thing for *most* cases. God knows I wish some face-to-face discussions had been recorded in Bugzilla for future reference. I'm somewhat ambiguous to "comment moderation", since I think the meta-work may not justify adding the feature, but there are three things that off the top of my head I do think could improve the situation: - Specifying "Comment types", which would allow us to categorize comments -- there's a bug and patch for this open. This opens a lot of nice possibilities for queries and historical analysis later. - Allowing comments to be marked as "irrelevant" -- poor man's moderation, I guess. Both features would be restricted by privilege (perhaps editbugs, perhaps something different) - Timeless' proposed "block bug" feature. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From kiko at async.com.br Thu Mar 25 18:16:57 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Thu, 25 Mar 2004 15:16:57 -0300 Subject: Bugzilla as a discussion forum In-Reply-To: References: <405F1D96.6010906@mozilla.org> <405F7319.4010003@mozilla.org> Message-ID: <20040325181657.GB2420@async.com.br> [Gerv wrote] > >I don't like that idea. Non-CC comments are too useful in legitimate work. I don't see a good argument for this. If you're willing to pester people on a bug, shouldn't you be willing to be pestered back? There could be special-cases, such as QA and triage people, but that's not the general rule. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From kiko at async.com.br Thu Mar 25 18:37:49 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Thu, 25 Mar 2004 15:37:49 -0300 Subject: Use of "Future" In-Reply-To: <1079782549.836.26.camel@megagerbil> References: <405A10E6.5000006@mozilla.org> <20040318215106.GD1647@async.com.br> <1079782549.836.26.camel@megagerbil> Message-ID: <20040325183749.GC2653@async.com.br> On Sat, Mar 20, 2004 at 10:05:51PM +1030, MattyT wrote: > There definitely needs to be some form of stronger planning. My > original milestone triaging was wildly optimistic, and I'd been meaning > to change milestones to be more balanced over 3 or so targets. With > shorter release spans, that should now perhaps be 5 or 6. I think that's a given. The problem is finding out how this planning should be done and enforced in practice, given we don't have a huge amount of people hacking. Any ideas from Dave? Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From john.fisher at znyx.com Thu Mar 25 19:02:17 2004 From: john.fisher at znyx.com (John P. Fisher) Date: Thu, 25 Mar 2004 11:02:17 -0800 Subject: Bugzilla as a discussion forum In-Reply-To: <20040325181657.GB2420@async.com.br> References: <405F1D96.6010906@mozilla.org> <405F7319.4010003@mozilla.org> <20040325181657.GB2420@async.com.br> Message-ID: <6.0.3.0.0.20040325104717.02775208@208.2.156.7> Thanks for all the work you folks do. Could I offer a contrary opinion on this thread? I think a cascade of opinions and discussion is inefficient in a bug report. It clogs up the database, makes bugs hard to read, and leads to never-ending dissatisfaction with the comment mechanism. Mailing lists, and BBSes, do a much better job of organizing a debate. The bug report can have a link to a thread on a BBS. Its a matter of concern to me, only because I have an interest in avoiding feature-bloat in Bugzilla. thanks again John At 10:16 AM 3/25/2004, you wrote: >[Gerv wrote] > > >I don't like that idea. Non-CC comments are too useful in legitimate work. > >I don't see a good argument for this. If you're willing to pester people >on a bug, shouldn't you be willing to be pestered back? > >There could be special-cases, such as QA and triage people, but that's >not the general rule. > John P. Fisher at ZNYX Networks 805 683 1488 x 3245 john.fisher at znyx.com From Cheiny at synaptics.com Thu Mar 25 19:19:18 2004 From: Cheiny at synaptics.com (Christopher Heiny) Date: Thu, 25 Mar 2004 11:19:18 -0800 Subject: Bugzilla as a discussion forum Message-ID: > Thanks for all the work you folks do. > Could I offer a contrary opinion on this thread? > I think a cascade of opinions and discussion is inefficient in a bug > report. It clogs up the database, makes bugs hard to read, > and leads to > never-ending dissatisfaction with the comment mechanism. > Mailing lists, and BBSes, do a much better job of organizing > a debate. The > bug report can have a link to a thread on a BBS. > Its a matter of concern to me, only because I have an > interest in avoiding > feature-bloat in Bugzilla. > thanks again > John I'll offer a contrary contrary opinion. One size does NOT fit all. Our organization uses Bugzilla internally to track problems with our products. Maintaining running discussions in Bugzilla has proven extremely valuable for a number of reasons: - all interested parties are reliably cc'ed on discussions - it's much harder to inappropriately forward the discussion - an archive of past discussion on an issue is immediately available to newcomers to the issue - issue history and related files (via attachments) are centrally located and easily accessed If the database gets bigger than our hard drive, we can buy another, bigger drive for a couple of hundred bucks. That's just a few hours of engineering time - we used to lose far more than that on people hunting for customer reports, relevant data sheets, and so on. Basic philosophy for things like this should be: + just because a feature is useful to one group of user, doesn't mean it should be foisted on all users. + just because one group of users does not find a feature useful, doesn't mean it should be crippled for all users. Chris From gerv at mozilla.org Thu Mar 25 21:36:43 2004 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 25 Mar 2004 21:36:43 +0000 Subject: Bugzilla as a discussion forum In-Reply-To: <20040325181657.GB2420@async.com.br> References: <405F1D96.6010906@mozilla.org> <405F7319.4010003@mozilla.org> <20040325181657.GB2420@async.com.br> Message-ID: <406350EB.1070709@mozilla.org> Christian Robottom Reis wrote: > I don't see a good argument for this. If you're willing to pester people > on a bug, shouldn't you be willing to be pestered back? Here are a few examples from my life: - I come across a Bugzilla bug while doing triage. I have a useful technical point to contribute, or two cents to throw in, but I don't want to be bothered with how it finally plays out. - Someone emails me with a bug number to ask a licensing question. I add a comment answering that question. > There could be special-cases, such as QA and triage people, but that's > not the general rule. The problem is that there's no easy way of codifying these exceptions without yet more permissions and admin. Administering the current two-level permissions system is enough effort. And the more levels you have, the more you get "this person doesn't deserve permission X" mails which take effort to sort out. Gerv From gerv at mozilla.org Thu Mar 25 21:36:56 2004 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 25 Mar 2004 21:36:56 +0000 Subject: Bugzilla as a discussion forum In-Reply-To: <20040325181511.GA2420@async.com.br> References: <405F1D96.6010906@mozilla.org> <405F7319.4010003@mozilla.org> <20040322231826.GK45419@barnson.org> <4060D4E3.3040302@mozilla.org> <20040324003321.GA31673@sigkill.com> <20040325181511.GA2420@async.com.br> Message-ID: <406350F8.40009@mozilla.org> Christian Robottom Reis wrote: > but there are three things that off the top > of my head I do think could improve the situation: > > - Specifying "Comment types", which would allow us to categorize > comments -- there's a bug and patch for this open. This opens a > lot of nice possibilities for queries and historical analysis > later. Does this include negative/perjorative comment types ("irrelevant", "troll" etc.)? If so, this is bound to generate a massive amount of argument and bad feeling, as people mark and unmark particular comments. And in a closed Bugzilla, such types would be useless anyway. I can see the virtue of "this comment was added with a patch", and "this comment was added as a mass change", and that sort of thing. > - Allowing comments to be marked as "irrelevant" -- poor man's > moderation, I guess. With all the inherent disadvantages of that. > Both features would be restricted by privilege (perhaps editbugs, > perhaps something different) > > - Timeless' proposed "block bug" feature. When it comes down to it, I think we may be trying to solve what is really a minor problem here. As you said, there are very few bugs that produce such large amounts of interest and discussion. And, with the exception of the assignee (who can always just walk away) and the reporter, no-one is forced to pay any attention to it. Gerv From kiko at async.com.br Thu Mar 25 21:50:47 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Thu, 25 Mar 2004 18:50:47 -0300 Subject: Bugzilla as a discussion forum In-Reply-To: <406350EB.1070709@mozilla.org> References: <405F1D96.6010906@mozilla.org> <405F7319.4010003@mozilla.org> <20040325181657.GB2420@async.com.br> <406350EB.1070709@mozilla.org> Message-ID: <20040325215047.GC3343@async.com.br> On Thu, Mar 25, 2004 at 09:36:43PM +0000, Gervase Markham wrote: > Christian Robottom Reis wrote: > >I don't see a good argument for this. If you're willing to pester people > >on a bug, shouldn't you be willing to be pestered back? > > Here are a few examples from my life: > > - I come across a Bugzilla bug while doing triage. I have a useful > technical point to contribute, or two cents to throw in, but I don't > want to be bothered with how it finally plays out. I don't think you *need* to comment if you're unwilling to be bothered "how it plays out". One-off comments (the developer *needs* to hear this one!) are supposed to be exceptions. > - Someone emails me with a bug number to ask a licensing question. I add > a comment answering that question. This is a reasonable issue. Asking the person to CC: himself before commenting might be a lot, but it would ensure that replies go to the person (how many times have we replied to comments and then remembered -- duh, you're not CC:ed on this bug. We then go and add the person to the CC: list, regardless of whether they wanted to be added or not). > >There could be special-cases, such as QA and triage people, but that's > >not the general rule. > > The problem is that there's no easy way of codifying these exceptions > without yet more permissions and admin. Administering the current > two-level permissions system is enough effort. And the more levels you > have, the more you get "this person doesn't deserve permission X" mails > which take effort to sort out. I think you're being too bmo-centric here. I find no problem in allocating responsibility within a team and having Bugzilla permissions that go hand-in-hand with that responsibility. Handling complaints is a part of any bug-tracker-manager's life; it only hurts bmo so much because it's done as a side-job there (and the number of users is overwhelming, which can't help). I don't think the burden of granting editbugs and commentallbugs privs is blocker for this [sort of] approach. Having said that, I don't think having to add yourself to the CC: list is a significant deterrent in posting irrelevant comments -- I think other mechanisms (some of which I raised earlier) are more appropriate. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From kiko at async.com.br Thu Mar 25 21:58:37 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Thu, 25 Mar 2004 18:58:37 -0300 Subject: Bugzilla as a discussion forum In-Reply-To: <406350F8.40009@mozilla.org> References: <405F1D96.6010906@mozilla.org> <405F7319.4010003@mozilla.org> <20040322231826.GK45419@barnson.org> <4060D4E3.3040302@mozilla.org> <20040324003321.GA31673@sigkill.com> <20040325181511.GA2420@async.com.br> <406350F8.40009@mozilla.org> Message-ID: <20040325215837.GE3343@async.com.br> On Thu, Mar 25, 2004 at 09:36:56PM +0000, Gervase Markham wrote: > Christian Robottom Reis wrote: > >but there are three things that off the top > >of my head I do think could improve the situation: > > > > - Specifying "Comment types", which would allow us to categorize > > comments -- there's a bug and patch for this open. This opens a > > lot of nice possibilities for queries and historical analysis > > later. > > Does this include negative/perjorative comment types ("irrelevant", > "troll" etc.)? If so, this is bound to generate a massive amount of > argument and bad feeling, as people mark and unmark particular comments. > And in a closed Bugzilla, such types would be useless anyway. Not necessarily, and most probably not. But it would be nice to have something like "Reporter comment", "QA comment", "Assignee comment" because you can expect those parties won't be just adding random noise to the discussion. Your examples below are spot-on too. > I can see the virtue of "this comment was added with a patch", and "this > comment was added as a mass change", and that sort of thing. [...] > > - Allowing comments to be marked as "irrelevant" -- poor man's > > moderation, I guess. > > With all the inherent disadvantages of that. Well, not all the disadvantages -- just mark it as irrelevant and get it hidden by default; yeah, you could get whining for that, but perhaps not as much as with a full-blown moderation system. > > Both features would be restricted by privilege (perhaps editbugs, > > perhaps something different) > > > > - Timeless' proposed "block bug" feature. > > When it comes down to it, I think we may be trying to solve what is > really a minor problem here. As you said, there are very few bugs that Yeah, agreed. It's bad on some bugs in BMO because, well, BMO has too many [too vocal] users (and perhaps not enough punishment handed out IMO). Timeless feature would mitigate this problem, but if it was so important someone would have went out and coded it by now, right? :-) Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From gerv at mozilla.org Thu Mar 25 22:02:23 2004 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 25 Mar 2004 22:02:23 +0000 Subject: Bugzilla as a discussion forum In-Reply-To: References: Message-ID: <406356EF.1090006@mozilla.org> Christopher Heiny wrote: > Maintaining running discussions in Bugzilla has proven extremely valuable No-one would disagree with you here. :-) What we are trying to do is work out where the balance is between giving people the facilities they need to discuss bugs, and turning Bugzilla into a web-based bulletin board, which both encourages pointless discussion and distracts us from making Bugzilla beer at its core competency. I actually think that, right now, we are in a pretty good place. > If the database gets bigger than our hard drive, we can buy another I don't think anyone's concerned with database size; the comments table for b.m.o. is only a few tens of MB. (The attachments table dominates here.) > Basic philosophy for things like this should be: > + just because a feature is useful to one group of user, doesn't mean it should be foisted on all users. > + just because one group of users does not find a feature useful, doesn't mean it should be crippled for all users. Both these things are often true, but offer no help in deciding what features to include. As I'm sure you know, not all features people can write patches for are appropriate to include in any piece of software - there are a wide variety of things which might make it unsuitable. For example, I personally believe that we have a duty to exclude features which encourage bad practice in bug tracking, or which start to morph Bugzilla into something else e.g. a project planning app. But this is probably not a unanimous opinion ;-) Gerv From gerv at mozilla.org Thu Mar 25 22:07:52 2004 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 25 Mar 2004 22:07:52 +0000 Subject: Bugzilla as a discussion forum In-Reply-To: <20040325215837.GE3343@async.com.br> References: <405F1D96.6010906@mozilla.org> <405F7319.4010003@mozilla.org> <20040322231826.GK45419@barnson.org> <4060D4E3.3040302@mozilla.org> <20040324003321.GA31673@sigkill.com> <20040325181511.GA2420@async.com.br> <406350F8.40009@mozilla.org> <20040325215837.GE3343@async.com.br> Message-ID: <40635838.40804@mozilla.org> Christian Robottom Reis wrote: > Not necessarily, and most probably not. But it would be nice to have > something like "Reporter comment", "QA comment", "Assignee comment" > because you can expect those parties won't be just adding random noise > to the discussion. Would this be "current reporter comment" or "reporter-at-the-time comment"? The former can be done easily with CSS classes and styles. > Yeah, agreed. It's bad on some bugs in BMO because, well, BMO has too > many [too vocal] users (and perhaps not enough punishment handed out > IMO). Perhaps this is the issue; although I've always said, and continue to say, that people should email me with examples of what they think is Bugzilla abuse. Gerv From gerv at mozilla.org Thu Mar 25 22:11:14 2004 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 25 Mar 2004 22:11:14 +0000 Subject: Bugzilla as a discussion forum In-Reply-To: <20040325215047.GC3343@async.com.br> References: <405F1D96.6010906@mozilla.org> <405F7319.4010003@mozilla.org> <20040325181657.GB2420@async.com.br> <406350EB.1070709@mozilla.org> <20040325215047.GC3343@async.com.br> Message-ID: <40635902.9030605@mozilla.org> Christian Robottom Reis wrote: >>The problem is that there's no easy way of codifying these exceptions >>without yet more permissions and admin. Administering the current >>two-level permissions system is enough effort. And the more levels you >>have, the more you get "this person doesn't deserve permission X" mails >>which take effort to sort out. > > I think you're being too bmo-centric here. I find no problem in > allocating responsibility within a team and having Bugzilla permissions > that go hand-in-hand with that responsibility. I'm being open-source-centric. I would expect any closed Bugzilla (such as async's) to have a much smaller set of users, almost all of whom have editbugs, and zero of whom abuse that privilege, or complain about the privileges of others. So the admin burden is much less. Anyway, the original feature ("force someone to CC themselves if they want to comment") was suggested as a counter to a problem only found in OS projects anyway. Gerv From kiko at async.com.br Thu Mar 25 23:36:16 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Thu, 25 Mar 2004 20:36:16 -0300 Subject: Bugzilla as a discussion forum In-Reply-To: <40635838.40804@mozilla.org> References: <405F1D96.6010906@mozilla.org> <405F7319.4010003@mozilla.org> <20040322231826.GK45419@barnson.org> <4060D4E3.3040302@mozilla.org> <20040324003321.GA31673@sigkill.com> <20040325181511.GA2420@async.com.br> <406350F8.40009@mozilla.org> <20040325215837.GE3343@async.com.br> <40635838.40804@mozilla.org> Message-ID: <20040325233616.GA4205@async.com.br> On Thu, Mar 25, 2004 at 10:07:52PM +0000, Gervase Markham wrote: > Christian Robottom Reis wrote: > >Not necessarily, and most probably not. But it would be nice to have > >something like "Reporter comment", "QA comment", "Assignee comment" > >because you can expect those parties won't be just adding random noise > >to the discussion. > > Would this be "current reporter comment" or "reporter-at-the-time > comment"? The former can be done easily with CSS classes and styles. Does the bug reporter ever change? At any rate, it might be nice for these "types" to be specified in the database so we could query and filter easily for them. > >Yeah, agreed. It's bad on some bugs in BMO because, well, BMO has too > >many [too vocal] users (and perhaps not enough punishment handed out > >IMO). > > Perhaps this is the issue; although I've always said, and continue to > say, that people should email me with examples of what they think is > Bugzilla abuse. I'll remember that in the future :-) Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From gerv at mozilla.org Fri Mar 26 00:27:18 2004 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 26 Mar 2004 00:27:18 +0000 Subject: Bugzilla as a discussion forum In-Reply-To: <20040325233616.GA4205@async.com.br> References: <405F1D96.6010906@mozilla.org> <405F7319.4010003@mozilla.org> <20040322231826.GK45419@barnson.org> <4060D4E3.3040302@mozilla.org> <20040324003321.GA31673@sigkill.com> <20040325181511.GA2420@async.com.br> <406350F8.40009@mozilla.org> <20040325215837.GE3343@async.com.br> <40635838.40804@mozilla.org> <20040325233616.GA4205@async.com.br> Message-ID: <406378E6.9040005@mozilla.org> Christian Robottom Reis wrote: > On Thu, Mar 25, 2004 at 10:07:52PM +0000, Gervase Markham wrote: >>Would this be "current reporter comment" or "reporter-at-the-time >>comment"? The former can be done easily with CSS classes and styles. > > Does the bug reporter ever change? Ok, s/reporter/assignee/. :-) Gerv From justdave at bugzilla.org Fri Mar 26 03:18:31 2004 From: justdave at bugzilla.org (David Miller) Date: Thu, 25 Mar 2004 22:18:31 -0500 Subject: Use of "Future" In-Reply-To: <20040325183749.GC2653@async.com.br> References: <405A10E6.5000006@mozilla.org> <20040318215106.GD1647@async.com.br> <1079782549.836.26.camel@megagerbil> <20040325183749.GC2653@async.com.br> Message-ID: On 3/25/2004 3:37 PM -0300, Christian Robottom Reis wrote: > On Sat, Mar 20, 2004 at 10:05:51PM +1030, MattyT wrote: >> There definitely needs to be some form of stronger planning. My >> original milestone triaging was wildly optimistic, and I'd been meaning >> to change milestones to be more balanced over 3 or so targets. With >> shorter release spans, that should now perhaps be 5 or 6. > > I think that's a given. The problem is finding out how this planning > should be done and enforced in practice, given we don't have a huge > amount of people hacking. Any ideas from Dave? My usual take so far is that you can't plan too far ahead with an all volunteer team because there's no guarantee people will work on things in any particular order. People like to scratch their own itch. So plan a couple releases ahead, but be prepared to rearrange things if someone suddenly starts working on something that wasn't targetted at the current release. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From mattyt-spam at tpg.com.au Fri Mar 26 10:20:57 2004 From: mattyt-spam at tpg.com.au (MattyT) Date: Fri, 26 Mar 2004 20:50:57 +1030 Subject: Use of "Future" In-Reply-To: <405D9C23.4000800@mozilla.org> References: <405A10E6.5000006@mozilla.org> <20040318215106.GD1647@async.com.br> <20040318222735.GF1647@async.com.br> <405A2E4C.8000603@mozilla.org> <1079782764.836.31.camel@megagerbil> <405D9C23.4000800@mozilla.org> Message-ID: <1080272818.822.2.camel@megagerbil> On Mon, 2004-03-22 at 00:14, Gervase Markham wrote: > > Feature and date based releases are about (not) making commitments. > > Target milestones are a best guess and guide, they were never > > commitments. > Sure. But they aren't our _best_ guess if we start by targetting a lot > of bugs at them that we have no idea whether they are going to be fixed > in 2.20 or not. I never claimed to have done a good job at this - but there's no call for throwing the baby out with the bath water. This is only going to be fixed by someone balancing the targets. > > We already have this - two ways in fact. Both having an active > > assignee, and the ASSIGNED status. > > I'd say that indicates what bugs are currently being worked on, not what > bugs anyone is planning to work on between now and six months time. Well, they could be used for different things each. To me in the past, ASSIGNED means commited, not working on it. -- 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 Fri Mar 26 10:21:43 2004 From: mattyt-spam at tpg.com.au (MattyT) Date: Fri, 26 Mar 2004 20:51:43 +1030 Subject: Partial custom fields design document In-Reply-To: <20040312024028.893EBC45E@diggity.schwag.org> References: <20040312024028.893EBC45E@diggity.schwag.org> Message-ID: <1080285659.822.137.camel@megagerbil> On Fri, 2004-03-12 at 13:10, Sean McAfee wrote: > It's been suggested that the best way to kick-start the process of getting > custom fields functionality into the core is to start with a design document > that all can agree on. Makes sense to me. Accordingly, I've started > drawing up a document that describes the design of my latest custom fields > patch. I didn't read this in depth, so apologies if I missed something, but I skimmed it, and saw what I believe to be issues I have. Meta ---- While schema and programmatic interfaces are important, the details of these are also uninteresting and not major. We need a document that answers the major questions of how the system hangs together, such as: - how are fields added and removed? what happens to the data on removal? - how are fields configured? - how will custom fields interact with the templates - will custom fields automatically appear without hacking? - which existing fields will be able to become custom fields eventually? if some can't, why not? - how does your system interact with I18N? multi-language bugzillas and the existing fields are going to need some I18N support, which must entail some change in the way I18N works - what are the types of fields, and what customisation can be done to them? eg if i wanted text fields to regexp restrictions, how would i add this functionality? what about more general restrictions? inter-field restrictions? - general schema details - is the table metadata stored in the db? is there one or multiple multi-value fields per table? are single-valued fields implemented by a bugs table field? how will the existing fields be able to fit into this? - are you going to be able to display multi-valued enumeration fields on the bug list? if so, how? Also, there needs to be a rationale for the decisions, not just details. Otherwise everyone's going to be arguing about things you might have already figured out. Once we have all this, then we can move onto details. After there's some kind of consensus between this rabble, the details will likely be easy in comparison. And this is the biggest change that has ever happened to Bugzilla, so doubly so. So put an overall summary, then for each section, a summary, then the details. Mere mortals don't have the stomach to deal with all this implementation detail at once, this will help us. Details ------- The idea of having all these generic tables (packing multiple fields into one table) I find somewhat ugly. Not only does it make a dev's/admin's job of analysing a single field far more complicated, it makes Bugzilla's job more complicated too - not only the SQL, but it must either index on the field or a value, I think doing both is difficult, thought probably possible. The question here is whether you ever want to analyse more than one field at once, and I'm pretty sure the answer is no for most field types (the only obvious exception is relationship fields (for dep trees) which I don't think you even defined, although they're not really fields in some sense, since they're between bugs). Given that you don't need this, I think each field should have its own bugs field or separate table as per now. I can understand the current system doesn't require any schema changes, but I don't see that as a big enough issue to warrant doing things this way. Furthermore, I'd avoid putting "custom fields" on everything, since the intention of any custom fields system should be to eventually subsume almost all fields, making "custom fields" a rather useless description. I originally had objections to adding and removing fields from the web interface, but the more I think about it the less of a problem it seems. It's certainly a rare enough operation that it could be done locally without major issues, however. What I think we definitely do need, is to have modules controlling each field (sub)type. This will allow customisation through inheritance, and hence will benefit administrators greatly, since they can plug in field types. Over time the field modules would gain more functionality and hence more separate-file customisation capability. We're never going to catch everything admins will want through a web configuration system, but I think with bug field modules, we can get 99.9% through inheritance. This being said, the intention is of course to make this all reasonably easy. Ideally you'd be able to avoid any Perl work here for simple customisation, but there should be generous scope for Perl customisation. My Proposal ----------- There's no need to do this all immediately as one patch. But I'd want to see us on this path. A bug field module is placed in Bugzilla/BugFields/Field.pm. This contains all the code necessary for handling the field type, various events to override, defines its configuration parameters, and so on. It either directly inherits from a module for its field type (eg enumeration, text, date, etc), or directly inherit from another abstract module which inherits from this, providing some shared functionality. The field modules are only templates, and you can instantiate them multiple times - each time you would have a different config. The field list (name and type) would be in the database because it's a good idea to put the metadata with the data (eg if you copied the database). I don't have any objection to having a web interface here because it allows us to gracefully handle field deletion with prompts, and asking whether to remove the old field/table, which something like localconfig is famous for not doing. Each field module would define its configuration parameters and you could then set it up on a field config page. For a general text field, it might allow configuring an acceptable regex, but for a more specific one, it might be more appropriate hardcode the regex in Perl rather than configure it. The field configuration can be stored as name/value strings on one table. I would modify the templates to automatically display all the fields. It would know information such as the fields priority (first section, second section, etc), type, and so on, and could use this information to order the fields in a similar way they are now. This is going to shift a variety of strings out of the template. Two possibilities come to mind about I18N. The first is each field must have a template fragment defining these strings, which can get used by whatever templates display this field. The second places the strings elsewhere. Most of the strings would be in the field modules. For general field modules, some of the strings would be in the field configuration. The first means that all I18N remains in one place, the templates. The second however means that a module could come complete with I18N as one file without needing a separate template, which is good for pluggability. The strings in the field configuration would need a separate I18N capability for a multi-language installation, but that's an administrator's task, not a translator's task. This way an admin can set all this up from one place. I18N would be a matter of patching the module, instead of creating a copy of the template which could get out of sync. I would expect to see various types of fields eventually - enumeration (eg OS), text (eg URL), date/time, allocation (eg votes), account (eg reporter) and relationship (eg dependencies). I would expect to leave multi-valued custom fields off of the bug list for now, as we're likely to have subselects that can do this before we get to hardcore porting of the old fields over. -- 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 timeless at myrealbox.com Fri Mar 26 16:04:21 2004 From: timeless at myrealbox.com (timeless) Date: Fri, 26 Mar 2004 08:04:21 -0800 Subject: Bugzilla as a discussion forum In-Reply-To: <20040325181657.GB2420@async.com.br> References: <405F1D96.6010906@mozilla.org> <405F7319.4010003@mozilla.org> <20040325181657.GB2420@async.com.br> Message-ID: <40645485.6050609@myrealbox.com> Christian Robottom Reis wrote: > There could be special-cases, such as QA and triage people, but that's > not the general rule. i'd like to complain about special casing those two groups. people who want to act as qa should take their roll in the QA field. and 'triagers' should stick around long enough to find out if they blew it. the volunteer triagers we have @bmo make too many mistakes to be participating in hit and run triaging. they also change too few bugs to justify not eating the bugspam for the duration of the bugs they touch. From suson at TuckerEnergy.com Fri Mar 26 17:31:08 2004 From: suson at TuckerEnergy.com (Steven Suson) Date: Fri, 26 Mar 2004 11:31:08 -0600 Subject: Partial custom fields design document In-Reply-To: <1080285659.822.137.camel@megagerbil> References: <20040312024028.893EBC45E@diggity.schwag.org> <1080285659.822.137.camel@megagerbil> Message-ID: <406468DC.5000005@TuckerEnergy.com> I've tried to stay our of this, despite my company's strong need for this functionality. But, I can't keep quiet anymore... After 25 yrs. of programming, it's continually been my experience that it is always best to get something into the hands of the users as soon as possible. This gives them the opportunity to comment, complain, etc. People like Sean have tried to do this, but the discussion seems to be complicating things more and more... further delaying ANY sort of implementation. If I'm out of line here, feel free to flame me, but it's my 2 cents worth. Steven Suson MattyT wrote: >On Fri, 2004-03-12 at 13:10, Sean McAfee wrote: > > > >>It's been suggested that the best way to kick-start the process of getting >>custom fields functionality into the core is to start with a design document >>that all can agree on. Makes sense to me. Accordingly, I've started >>drawing up a document that describes the design of my latest custom fields >>patch. >> >> > >I didn't read this in depth, so apologies if I missed something, but I >skimmed it, and saw what I believe to be issues I have. > >Meta >---- > >While schema and programmatic interfaces are important, the details of >these are also uninteresting and not major. > >We need a document that answers the major questions of how the system >hangs together, such as: > >- how are fields added and removed? what happens to the data on >removal? >- how are fields configured? >- how will custom fields interact with the templates - will custom >fields automatically appear without hacking? >- which existing fields will be able to become custom fields >eventually? if some can't, why not? >- how does your system interact with I18N? multi-language bugzillas and >the existing fields are going to need some I18N support, which must >entail some change in the way I18N works >- what are the types of fields, and what customisation can be done to >them? eg if i wanted text fields to regexp restrictions, how would i >add this functionality? what about more general restrictions? >inter-field restrictions? >- general schema details - is the table metadata stored in the db? is >there one or multiple multi-value fields per table? are single-valued >fields implemented by a bugs table field? how will the existing fields >be able to fit into this? >- are you going to be able to display multi-valued enumeration fields on >the bug list? if so, how? > >Also, there needs to be a rationale for the decisions, not just >details. Otherwise everyone's going to be arguing about things you >might have already figured out. > >Once we have all this, then we can move onto details. After there's >some kind of consensus between this rabble, the details will likely be >easy in comparison. And this is the biggest change that has ever >happened to Bugzilla, so doubly so. > >So put an overall summary, then for each section, a summary, then the >details. Mere mortals don't have the stomach to deal with all this >implementation detail at once, this will help us. > >Details >------- > >The idea of having all these generic tables (packing multiple fields >into one table) I find somewhat ugly. Not only does it make a >dev's/admin's job of analysing a single field far more complicated, it >makes Bugzilla's job more complicated too - not only the SQL, but it >must either index on the field or a value, I think doing both is >difficult, thought probably possible. > >The question here is whether you ever want to analyse more than one >field at once, and I'm pretty sure the answer is no for most field types >(the only obvious exception is relationship fields (for dep trees) which >I don't think you even defined, although they're not really fields in >some sense, since they're between bugs). > >Given that you don't need this, I think each field should have its own >bugs field or separate table as per now. I can understand the current >system doesn't require any schema changes, but I don't see that as a big >enough issue to warrant doing things this way. > >Furthermore, I'd avoid putting "custom fields" on everything, since the >intention of any custom fields system should be to eventually subsume >almost all fields, making "custom fields" a rather useless description. > >I originally had objections to adding and removing fields from the web >interface, but the more I think about it the less of a problem it >seems. It's certainly a rare enough operation that it could be done >locally without major issues, however. > >What I think we definitely do need, is to have modules controlling each >field (sub)type. This will allow customisation through inheritance, and >hence will benefit administrators greatly, since they can plug in field >types. Over time the field modules would gain more functionality and >hence more separate-file customisation capability. > >We're never going to catch everything admins will want through a web >configuration system, but I think with bug field modules, we can get >99.9% through inheritance. > >This being said, the intention is of course to make this all reasonably >easy. Ideally you'd be able to avoid any Perl work here for simple >customisation, but there should be generous scope for Perl >customisation. > >My Proposal >----------- > >There's no need to do this all immediately as one patch. But I'd want >to see us on this path. > >A bug field module is placed in Bugzilla/BugFields/Field.pm. This >contains all the code necessary for handling the field type, various >events to override, defines its configuration parameters, and so on. > >It either directly inherits from a module for its field type (eg >enumeration, text, date, etc), or directly inherit from another abstract >module which inherits from this, providing some shared functionality. > >The field modules are only templates, and you can instantiate them >multiple times - each time you would have a different config. > >The field list (name and type) would be in the database because it's a >good idea to put the metadata with the data (eg if you copied the >database). I don't have any objection to having a web interface here >because it allows us to gracefully handle field deletion with prompts, >and asking whether to remove the old field/table, which something like >localconfig is famous for not doing. > >Each field module would define its configuration parameters and you >could then set it up on a field config page. For a general text field, >it might allow configuring an acceptable regex, but for a more specific >one, it might be more appropriate hardcode the regex in Perl rather than >configure it. The field configuration can be stored as name/value >strings on one table. > >I would modify the templates to automatically display all the fields. >It would know information such as the fields priority (first section, >second section, etc), type, and so on, and could use this information to >order the fields in a similar way they are now. > >This is going to shift a variety of strings out of the template. Two >possibilities come to mind about I18N. > >The first is each field must have a template fragment defining these >strings, which can get used by whatever templates display this field. > >The second places the strings elsewhere. Most of the strings would be >in the field modules. For general field modules, some of the strings >would be in the field configuration. > >The first means that all I18N remains in one place, the templates. > >The second however means that a module could come complete with I18N as >one file without needing a separate template, which is good for >pluggability. > >The strings in the field configuration would need a separate I18N >capability for a multi-language installation, but that's an >administrator's task, not a translator's task. This way an admin can >set all this up from one place. > >I18N would be a matter of patching the module, instead of creating a >copy of the template which could get out of sync. > >I would expect to see various types of fields eventually - enumeration >(eg OS), text (eg URL), date/time, allocation (eg votes), account (eg >reporter) and relationship (eg dependencies). > >I would expect to leave multi-valued custom fields off of the bug list >for now, as we're likely to have subselects that can do this before we >get to hardcore porting of the old fields over. > > From gerv at mozilla.org Fri Mar 26 18:10:19 2004 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 26 Mar 2004 18:10:19 +0000 Subject: Partial custom fields design document In-Reply-To: <406468DC.5000005@TuckerEnergy.com> References: <20040312024028.893EBC45E@diggity.schwag.org> <1080285659.822.137.camel@megagerbil> <406468DC.5000005@TuckerEnergy.com> Message-ID: <4064720B.60902@mozilla.org> Steven Suson wrote: > I've tried to stay our of this, despite my company's strong need for > this functionality. But, I can't keep quiet anymore... After 25 yrs. of > programming, it's continually been my experience that it is always best > to get something into the hands of the users as soon as possible. This > gives them the opportunity to comment, complain, etc. I'm sure they will complain particularly loudly if the feedback is that it's architected wrong, we therefore need to throw away various bits and rewrite them, and there are no plans for a migration path... > People like Sean > have tried to do this, but the discussion seems to be complicating > things more and more... That's because it _is_ complicated :-) > further delaying ANY sort of implementation. There is already one, and perhaps two implementations of custom fields :-) Several people are using them in production, too. See the relevant Bugzilla bug. Gerv From dberlin at dberlin.org Fri Mar 26 18:21:36 2004 From: dberlin at dberlin.org (Daniel Berlin) Date: Fri, 26 Mar 2004 13:21:36 -0500 Subject: Partial custom fields design document In-Reply-To: <4064720B.60902@mozilla.org> References: <20040312024028.893EBC45E@diggity.schwag.org> <1080285659.822.137.camel@megagerbil> <406468DC.5000005@TuckerEnergy.com> <4064720B.60902@mozilla.org> Message-ID: <6AEEE94A-7F52-11D8-9E31-000A95DA505C@dberlin.org> >> People like Sean have tried to do this, but the discussion seems to >> be complicating things more and more... > > That's because it _is_ complicated :-) > Only because it's continually being made more and more complicated by nit-picking it to death. It doesn't have to be extremely complicated. >> further delaying ANY sort of implementation. > > There is already one, and perhaps two implementations of custom fields > :-) Several people are using them in production, too. See the relevant > Bugzilla bug. And this doesn't tell you that waiting and nit picking the design to death isn't a good idea? To me, it says the need is so great that people have given up waiting for bugzilla developers to "get it right" and implemented it twice on their own. All this FUD about "not having a migration path" is a bit funny, too. It is, after all, simply data in a database. It would be pretty hard to develop a working custom field implementation that couldn't be transformed into another format. From kiko at async.com.br Fri Mar 26 18:30:57 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Fri, 26 Mar 2004 15:30:57 -0300 Subject: Partial custom fields design document In-Reply-To: <6AEEE94A-7F52-11D8-9E31-000A95DA505C@dberlin.org> References: <20040312024028.893EBC45E@diggity.schwag.org> <1080285659.822.137.camel@megagerbil> <406468DC.5000005@TuckerEnergy.com> <4064720B.60902@mozilla.org> <6AEEE94A-7F52-11D8-9E31-000A95DA505C@dberlin.org> Message-ID: <20040326183057.GH1380@async.com.br> On Fri, Mar 26, 2004 at 01:21:36PM -0500, Daniel Berlin wrote: > >There is already one, and perhaps two implementations of custom fields > >:-) Several people are using them in production, too. See the relevant > >Bugzilla bug. > > And this doesn't tell you that waiting and nit picking the design to > death isn't a good idea? > To me, it says the need is so great that people have given up waiting > for bugzilla developers to "get it right" and implemented it twice on > their own. Many important features were developed in OSS outside the main project trunks and then later merged in. There's no rule that says "project X must accept feature Y after Y has been coded", though with Bugzilla it's certainly the case that we are willing to accept and help merge in custom fields if people are willing to cope with the fact that we take our time at doing it. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From justdave at bugzilla.org Fri Mar 26 18:42:09 2004 From: justdave at bugzilla.org (David Miller) Date: Fri, 26 Mar 2004 13:42:09 -0500 Subject: Partial custom fields design document In-Reply-To: <6AEEE94A-7F52-11D8-9E31-000A95DA505C@dberlin.org> References: <20040312024028.893EBC45E@diggity.schwag.org> <1080285659.822.137.camel@megagerbil> <406468DC.5000005@TuckerEnergy.com> <4064720B.60902@mozilla.org> <6AEEE94A-7F52-11D8-9E31-000A95DA505C@dberlin.org> Message-ID: On 3/26/2004 1:21 PM -0500, Daniel Berlin wrote: > All this FUD about "not having a migration path" is a bit funny, too. > It is, after all, simply data in a database. > It would be pretty hard to develop a working custom field > implementation that couldn't be transformed into another format. I would have to agree here. I think a couple people have misinterpreted the original statement. There is no guarantee that there will be a migration path. That doesn't mean there won't be one, just that it's not guaranteed there will be. I'd be very surprised once we get something designed and checked in if someone who's using one of the existing implementations doesn't write and contribute some sort of migration tool if what ends up getting checked in doesn't match the original implementations that are out there now. But we're not going to guarantee that because it's not very likely the core Bugzilla team would participate in creating it. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From harriv-no-spam at prosys.fi Fri Mar 26 19:21:48 2004 From: harriv-no-spam at prosys.fi (Harri Vartiainen) Date: Fri, 26 Mar 2004 21:21:48 +0200 Subject: Partial custom fields design document In-Reply-To: <6AEEE94A-7F52-11D8-9E31-000A95DA505C@dberlin.org> References: <20040312024028.893EBC45E@diggity.schwag.org> <1080285659.822.137.camel@megagerbil> <406468DC.5000005@TuckerEnergy.com> <4064720B.60902@mozilla.org> <6AEEE94A-7F52-11D8-9E31-000A95DA505C@dberlin.org> Message-ID: <406482CC.5030401@prosys.fi> Daniel Berlin wrote: >> That's because it _is_ complicated :-) >> > > Only because it's continually being made more and more complicated by > nit-picking it to death. > It doesn't have to be extremely complicated. There's "semi-official" term for nit-picking features to death, analysis paralysis. More information, solutions, discussion etc can be found from http://c2.com/cgi/wiki?AnalysisParalysis From bugreport at peshkin.net Fri Mar 26 22:14:46 2004 From: bugreport at peshkin.net (Joel Peshkin) Date: Fri, 26 Mar 2004 14:14:46 -0800 Subject: Partial custom fields design document In-Reply-To: <6AEEE94A-7F52-11D8-9E31-000A95DA505C@dberlin.org> References: <20040312024028.893EBC45E@diggity.schwag.org> <1080285659.822.137.camel@megagerbil> <406468DC.5000005@TuckerEnergy.com> <4064720B.60902@mozilla.org> <6AEEE94A-7F52-11D8-9E31-000A95DA505C@dberlin.org> Message-ID: <4064AB56.9060708@peshkin.net> Daniel Berlin wrote: >>> People like Sean have tried to do this, but the discussion seems to >>> be complicating things more and more... >> >> >> That's because it _is_ complicated :-) >> > > Only because it's continually being made more and more complicated by > nit-picking it to death. > It doesn't have to be extremely complicated. > The proposal is not being held up by nit-picking, even though most of the discussion seems to be centered around addressing the nits and ignores the central issues... The central issues are.... 1) Should fields with a 1:1 relationship to bugs be a) placed in distinct fields of either bugs or another table that has a 1:1 relationship to bugs or b) placed in a table that needs to be joined to bugs once for each field 1.5) Whatever is done must not trash performance on huge systems. 2) Should customfields be something that get created in the DB through the web interface or should that function be seperate 3) Not a question, a statement... Bugs activity must work. Search must work. Bugmail must work. Localization must work (That said, I have been advocating addressing localization of custom fields by letting the database support ONE language and letting a site override that with templates if they want to and need to support more than one language.) So, please stop wangling on the nits and work to converge on the central issues. If you feel picked on, look at how many iterations of the design documents I went through on the group system rewrites. :-) -Joel From dberlin at dberlin.org Fri Mar 26 22:28:15 2004 From: dberlin at dberlin.org (Daniel Berlin) Date: Fri, 26 Mar 2004 17:28:15 -0500 Subject: Partial custom fields design document In-Reply-To: <4064AB56.9060708@peshkin.net> References: <20040312024028.893EBC45E@diggity.schwag.org> <1080285659.822.137.camel@megagerbil> <406468DC.5000005@TuckerEnergy.com> <4064720B.60902@mozilla.org> <6AEEE94A-7F52-11D8-9E31-000A95DA505C@dberlin.org> <4064AB56.9060708@peshkin.net> Message-ID: On Mar 26, 2004, at 5:14 PM, Joel Peshkin wrote: > Daniel Berlin wrote: > >>>> People like Sean have tried to do this, but the discussion seems to >>>> be complicating things more and more... >>> >>> >>> That's because it _is_ complicated :-) >>> >> >> Only because it's continually being made more and more complicated by >> nit-picking it to death. >> It doesn't have to be extremely complicated. >> > The proposal is not being held up by nit-picking, even though most of > the discussion seems to be centered around addressing the nits and > ignores the central issues... > This sounds a bit strange. It reads like "The proposal isn't being held up by nit picking, even though all people are doing to the proposal right now is picking nits". > The central issues are.... > 1) Should fields with a 1:1 relationship to bugs be > a) placed in distinct fields of either bugs or another table that > has a 1:1 relationship to bugs > or > b) placed in a table that needs to be joined to bugs once for each > field > Again, either way could be changed to the other later on if it is found to be a large problem. I don't see why this is a "central issue" that must be decided right now. > 1.5) Whatever is done must not trash performance on huge systems. Of course, but we have no evidence it does, and there are ways to solve this problem later on if it becomes an issue, which nobody has actually shown it will be. > 2) Should customfields be something that get created in the DB through > the web interface or should that function be seperate > Start with one, move to both. (IE choose one and get it over with, no potential user has yet said that they would/would not use custom fields simply because of the lack of a web interface) > > So, please stop wangling on the nits and work to converge on the > central issues. > If you feel picked on, look at how many iterations of the design > documents I went through on the group system rewrites. :-) > Why would i feel picked on, i am but a neutral observer in all of this. :) I would be a user of custom fields, except that i don't want to deal with maintaining even more changes to the bugzilla codebase than gcc already has. I'm a compiler person/lawyer, i just happen to be responsible for maintaining our bug system. --Dan From mdavis at laszlosystems.com Sat Mar 27 01:15:47 2004 From: mdavis at laszlosystems.com (Mark Davis) Date: Fri, 26 Mar 2004 17:15:47 -0800 Subject: Partial custom fields design document In-Reply-To: <20040312024028.893EBC45E@diggity.schwag.org> References: <20040312024028.893EBC45E@diggity.schwag.org> Message-ID: <4064D5C3.9050704@laszlosystems.com> While we're talking about this, I'd like to see a way to mark certain fields as required at certain points. Just as there is a required comment to mark a bug fixed now, I'd like to require that a user add a changeset number... ew... that just got ugly didn't it? -- Mark Davis Quality Assurance Manager, Laszlo Systems (415) 241-2736 -- http://www.laszlosystems.com From bugreport at peshkin.net Sat Mar 27 01:46:16 2004 From: bugreport at peshkin.net (Joel Peshkin) Date: Fri, 26 Mar 2004 17:46:16 -0800 Subject: Partial custom fields design document In-Reply-To: <4064D5C3.9050704@laszlosystems.com> References: <20040312024028.893EBC45E@diggity.schwag.org> <4064D5C3.9050704@laszlosystems.com> Message-ID: <4064DCE8.9070907@peshkin.net> Mark Davis wrote: > While we're talking about this, I'd like to see a way to mark certain > fields as required at certain points. > > Just as there is a required comment to mark a bug fixed now, I'd like > to require that a user add a changeset number... > > ew... that just got ugly didn't it? > Rather than burdening customfields with this, perhaps an approach similar to the CheckCanChangeField() function in process_bug would help. Essentially, you could put such checks in a known and reasonably stable location in the code. Would that suffice? From mdavis at laszlosystems.com Sat Mar 27 02:46:23 2004 From: mdavis at laszlosystems.com (Mark Davis) Date: Fri, 26 Mar 2004 18:46:23 -0800 Subject: Partial custom fields design document In-Reply-To: <4064DCE8.9070907@peshkin.net> References: <20040312024028.893EBC45E@diggity.schwag.org> <4064D5C3.9050704@laszlosystems.com> <4064DCE8.9070907@peshkin.net> Message-ID: <4064EAFF.6030204@laszlosystems.com> Joel Peshkin wrote: > Rather than burdening customfields with this, perhaps an approach > similar to the CheckCanChangeField() function in process_bug would > help. Essentially, you could put such checks in a known and > reasonably stable location in the code. Would that suffice? I'm going to be looking at implementing this here next week. I'll see what makes sense... -- Mark Davis Quality Assurance Manager, Laszlo Systems (415) 241-2736 -- http://www.laszlosystems.com From gerv at mozilla.org Sat Mar 27 11:04:12 2004 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 27 Mar 2004 11:04:12 +0000 Subject: Partial custom fields design document In-Reply-To: <406482CC.5030401@prosys.fi> References: <20040312024028.893EBC45E@diggity.schwag.org> <1080285659.822.137.camel@megagerbil> <406468DC.5000005@TuckerEnergy.com> <4064720B.60902@mozilla.org> <6AEEE94A-7F52-11D8-9E31-000A95DA505C@dberlin.org> <406482CC.5030401@prosys.fi> Message-ID: <40655FAC.2020204@mozilla.org> Harri Vartiainen wrote: > There's "semi-official" term for nit-picking features to death, analysis > paralysis. I'd say that's a bit unfair. A couple of weeks ago, someone said "Look, we really need to sort out custom fields." A consensus was established that this was a good idea, and a week ago a design document was posted. It's already had some review, and the large issues are being identified by those most able to identify them (e.g. I mentioned l10n, others have raised schema queries, and so on.) I don't think we're doing too badly. Gerv From gerv at mozilla.org Sat Mar 27 11:05:23 2004 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 27 Mar 2004 11:05:23 +0000 Subject: Partial custom fields design document In-Reply-To: References: <20040312024028.893EBC45E@diggity.schwag.org> <1080285659.822.137.camel@megagerbil> <406468DC.5000005@TuckerEnergy.com> <4064720B.60902@mozilla.org> <6AEEE94A-7F52-11D8-9E31-000A95DA505C@dberlin.org> <4064AB56.9060708@peshkin.net> Message-ID: <40655FF3.4060808@mozilla.org> Daniel Berlin wrote: > Again, either way could be changed to the other later on if it is found > to be a large problem. I don't see why this is a "central issue" that > must be decided right now. Because an ounce of prevention is worth a pound of cure. A design document is far easier to change than 50 working Bugzillas. If we can't see any difference between the approaches, or if we can't know which is best until we try it, then sure, let's implement one and see. But I don't think that's the case - at least not yet. Gerv From gerv at mozilla.org Sat Mar 27 11:16:59 2004 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 27 Mar 2004 11:16:59 +0000 Subject: Partial custom fields design document In-Reply-To: <1080285659.822.137.camel@megagerbil> References: <20040312024028.893EBC45E@diggity.schwag.org> <1080285659.822.137.camel@megagerbil> Message-ID: <406562AB.4070809@mozilla.org> MattyT wrote: > While schema and programmatic interfaces are important, the details of > these are also uninteresting and not major. Heartily disagree. ;-) For those of us who have to maintain it, they are interesting and of importance. But I agree the questions you raise below are more important. > We need a document that answers the major questions of how the system > hangs together, such as: Heartily agree with the whole list (snipped). > Given that you don't need this, I think each field should have its own > bugs field or separate table as per now. I can understand the current > system doesn't require any schema changes, but I don't see that as a big > enough issue to warrant doing things this way. If we are making custom fields product-specific instead of global (which I believe is the plan), then we shouldn't add them to the bugs table. Giving each field a separate table means that every Bugzilla which uses custom fields will have a different schema. This could really come back to bite us. Gerv From bugreport at peshkin.net Sat Mar 27 13:48:43 2004 From: bugreport at peshkin.net (Joel Peshkin) Date: Sat, 27 Mar 2004 05:48:43 -0800 Subject: Partial custom fields design document In-Reply-To: <406562AB.4070809@mozilla.org> References: <20040312024028.893EBC45E@diggity.schwag.org> <1080285659.822.137.camel@megagerbil> <406562AB.4070809@mozilla.org> Message-ID: <4065863B.8090608@peshkin.net> Gervase Markham wrote: > > If we are making custom fields product-specific instead of global > (which I believe is the plan), then we shouldn't add them to the bugs > table. > The problem with that particular item is that it is a terrible plan. Having custom fields come and go from the UI on a per-product basis is great. Having them come and go from the DB on a per-product basis is a recipe for dataloss. Once a bug has a custom field, it should be stuck with that field forever, even if it is moved to a product where that field is not supported and then back again. From gerv at mozilla.org Sat Mar 27 17:48:11 2004 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 27 Mar 2004 17:48:11 +0000 Subject: Partial custom fields design document In-Reply-To: <4065863B.8090608@peshkin.net> References: <20040312024028.893EBC45E@diggity.schwag.org> <1080285659.822.137.camel@megagerbil> <406562AB.4070809@mozilla.org> <4065863B.8090608@peshkin.net> Message-ID: <4065BE5B.5060502@mozilla.org> Joel Peshkin wrote: > The problem with that particular item is that it is a terrible plan. > Having custom fields come and go from the UI on a per-product basis is > great. Having them come and go from the DB on a per-product basis is a > recipe for dataloss. Once a bug has a custom field, it should be stuck > with that field forever, even if it is moved to a product where that > field is not supported and then back again. Sure - that's a very good point. The product-based custom fields thing should be a UI-only setting. But that's orthogonal to the question of whether they should be in the bugs table or not. Adding them to the bugs table will produce a lot of null values for the inapplicable fields; the bugs table would not be normalised correctly. I believe that's frowned upon in database design (although perhaps someone more knowledgeable will correct me there.) Gerv From boris at apinc.org Mon Mar 29 08:29:37 2004 From: boris at apinc.org (boris at apinc.org) Date: Mon, 29 Mar 2004 10:29:37 +0200 (CEST) Subject: multiple instance of bugzilla Message-ID: <4723.81.80.12.54.1080548977.squirrel@mail.apinc.org> hi all ; first of all thanks to all for the good job. bugzilla is one of these big open source software which can (and do) introduce a new mind in professional IT. althought "open source" spirit is not fully understood -- but we're on the right way, if we keep up the fight. hum; technically.. i'v been looking for this through the web, discussion groups, but i still have no hints. i'd like to implement several (4-5) lifecycles acting together. Typically, dependancies should be tracked through records of all of these workflows. I thought about multiple instances of bugzilla running on one or more database, interacting together. but i fear a major change.. if it's possible. I'm going to have a deeper look in 2.17.7, but i may need to use 2.16.5 for production purposes. So here are my questions: * has someone already done such a work ? * what do developers think about running multiples instances of bugzilla together ? TIA, -- Boris Baldassari From justdave at bugzilla.org Mon Mar 29 08:45:51 2004 From: justdave at bugzilla.org (David Miller) Date: Mon, 29 Mar 2004 03:45:51 -0500 Subject: multiple instance of bugzilla In-Reply-To: <4723.81.80.12.54.1080548977.squirrel@mail.apinc.org> References: <4723.81.80.12.54.1080548977.squirrel@mail.apinc.org> Message-ID: On 3/29/2004 10:29 AM +0200, wrote: > i'd like to implement several (4-5) lifecycles acting together. Typically, > dependancies should be tracked through records of all of these workflows. > I thought about multiple instances of bugzilla running on one or more > database, interacting together. > but i fear a major change.. if it's possible. I'm going to have a deeper > look in 2.17.7, but i may need to use 2.16.5 for production purposes. We've already frozen for 2.18. Based on current progress at getting past the freeze, it'll likely be about a month or a little more before it's actually released, but it's coming soon. > So here are my questions: > * has someone already done such a work ? > * what do developers think about running multiples instances of bugzilla > together ? You'll need to explain a little more of what you have in mind before I can give a really good answer, but it's usually more headache than it's worth. If your main concern is separating users from each other, then the group security can usually accomplish that within the same Bugzilla. As for inter-Bugzilla dependencies, I'm working on that currently for my employer. Initial implementation (I'd give it at least a month yet, and probably won't be in upstream Bugzilla until 2.19.1 or so) will allow you to have a bug "watch" a bug on another bug system and, via a cron job, will post status changes to the upstream bug as comments in the local bug. It's basically a one-way dependency - the upstream system wouldn't get any notification of changes to your bug. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From boris at apinc.org Mon Mar 29 12:42:09 2004 From: boris at apinc.org (Boris Baldassari) Date: Mon, 29 Mar 2004 14:42:09 +0200 (CEST) Subject: multiple instance of bugzilla In-Reply-To: References: <4723.81.80.12.54.1080548977.squirrel@mail.apinc.org> Message-ID: <22701.81.80.12.54.1080564129.squirrel@mail.apinc.org> hi; > We've already frozen for 2.18. Based on current progress at getting > past the freeze, it'll likely be about a month or a little more before > it's actually released, but it's coming soon. it may be too long. hum. i could work on cvs and upgrade when 2.18 will come out. ok, thanks. > You'll need to explain a little more of what you have in mind before I > can give a really good answer, but it's usually more headache than it's it's not an user problem. we have several types of record (eg. cr and pr), each with a specific lifecycle. the point is that they all have to interact: a cr record may generate (dependency) a pr record, and we need to track them up and down. since only one lifecycle can be used with an instance of bugzilla (or may i misunderstood something?), i thought about running several instances of bugzilla, each with a specific (customized) lifecycle, and allow them to send updates for dependencies. in such a system, dependency graph would typically span accross several database and/or bugzilla instances. > As for inter-Bugzilla dependencies, I'm working on that currently for my > employer. Initial implementation (I'd give it at least a month yet, and > probably won't be in upstream Bugzilla until 2.19.1 or so) will allow > you to have a bug "watch" a bug on another bug system and, via a cron > job, will post status changes to the upstream bug as comments in the > local bug. It's basically a one-way dependency - the upstream system > wouldn't get any notification of changes to your bug. that would partially fullfill my requirements (i need bidirectionnal dependencies, just like in one bugzilla). i could eventually (if my managers allow it, to be confirmed) work on this feature; in this case may i ask you some questions on your experience of this implementation ? tia, -- Boris Baldassari From jakob.nielsen at nhst.no Mon Mar 29 13:19:44 2004 From: jakob.nielsen at nhst.no (Jakob Vad Nielsen) Date: Mon, 29 Mar 2004 15:19:44 +0200 Subject: About XML-RPC API Message-ID: <40682270.4070102@nhst.no> Hi there, Searching the Internet I've found some infomation about a XML-RPC API for Bugzilla that is supposed to exists. But I haven't been able to find the actual API. Is there such a thing? Can't see anything in CVS that indicates such an API. Best regards, Jakob Vad Nielsen Senior System Developer NHST From gerv at mozilla.org Mon Mar 29 14:14:15 2004 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 29 Mar 2004 15:14:15 +0100 Subject: About XML-RPC API In-Reply-To: <40682270.4070102@nhst.no> References: <40682270.4070102@nhst.no> Message-ID: <40682F37.1040602@mozilla.org> Jakob Vad Nielsen wrote: > Searching the Internet I've found some infomation about a XML-RPC API > for Bugzilla that is supposed to exists. But I haven't been able to find > the actual API. Is there such a thing? > > Can't see anything in CVS that indicates such an API. You can access Bugzilla data as XML by issuing HTTP requests - is that what an XML-RPC API is? :-) Gerv From louie at ximian.com Mon Mar 29 14:30:10 2004 From: louie at ximian.com (Luis Villa) Date: Mon, 29 Mar 2004 09:30:10 -0500 Subject: About XML-RPC API In-Reply-To: <40682F37.1040602@mozilla.org> References: <40682270.4070102@nhst.no> <40682F37.1040602@mozilla.org> Message-ID: <1080570610.20928.12.camel@localhost.localdomain> On Mon, 2004-03-29 at 15:14 +0100, Gervase Markham wrote: > Jakob Vad Nielsen wrote: > > > Searching the Internet I've found some infomation about a XML-RPC API > > for Bugzilla that is supposed to exists. But I haven't been able to find > > the actual API. Is there such a thing? > > > > Can't see anything in CVS that indicates such an API. > > You can access Bugzilla data as XML by issuing HTTP requests - is that > what an XML-RPC API is? :-) I would guess Jakob is referring to the XML-RPC API implemented by Red Hat. It is in their tarballs (http://bugzilla.redhat.com/download/bugzilla-redhat-20031120.tar.gz) but extracting patches from there can be a bit of a PITA, and I have been surprised not to find patches for it in b.m.o. Luis From bugreport at peshkin.net Mon Mar 29 14:54:11 2004 From: bugreport at peshkin.net (Joel Peshkin) Date: Mon, 29 Mar 2004 06:54:11 -0800 Subject: multiple instance of bugzilla In-Reply-To: <22701.81.80.12.54.1080564129.squirrel@mail.apinc.org> References: <4723.81.80.12.54.1080548977.squirrel@mail.apinc.org> <22701.81.80.12.54.1080564129.squirrel@mail.apinc.org> Message-ID: <40683893.7050405@peshkin.net> Boris Baldassari wrote: >hi; > > > >>We've already frozen for 2.18. Based on current progress at getting >>past the freeze, it'll likely be about a month or a little more before >>it's actually released, but it's coming soon. >> >> >it may be too long. hum. i could work on cvs and upgrade when 2.18 will >come out. ok, thanks. > > > >>You'll need to explain a little more of what you have in mind before I >>can give a really good answer, but it's usually more headache than it's >> >> >it's not an user problem. we have several types of record (eg. cr and pr), >each with a specific lifecycle. the point is that they all have to >interact: a cr record may generate (dependency) a pr record, and we need >to track them up and down. >since only one lifecycle can be used with an instance of bugzilla (or may >i misunderstood something?), i thought about running several instances of >bugzilla, each with a specific (customized) lifecycle, and allow them to >send updates for dependencies. in such a system, dependency graph would >typically span accross several database and/or bugzilla instances. > > > Nothing you have said would be helped by running multiple bugzilla instances. Running multiple instances is something I suggest you treat as a last resort. Instead of running multiple bugzillas, you can use a distinct product for each type of record and even customize the templates to change terminology on a per-product basis. If there is something that you think can be done in multiple instances but not in a single instance, please mention it here. I do not think such a thing exists. From bruce.armstrong at teamsybase.com Mon Mar 29 18:02:23 2004 From: bruce.armstrong at teamsybase.com (Bruce Armstrong [TeamSybase]) Date: Mon, 29 Mar 2004 10:02:23 -0800 (PST) Subject: Win32: what PPM repository to suggest in checksetup.pl? Message-ID: <20040329180223.71664.qmail@web12506.mail.yahoo.com> Ok, now I'm reconsidering this. I've done a compile of Chart for ActiveState 5.8.3 (build 809), which is the only module I couldn't find in either the Apache or ActiveState repositories. However, I've discovered that ActiveState doens't have a policy for accepting user submitted PPMs, and it doesn't appear that Apache does either. I don't mind submitting the PPDs, but somebody needs to set up some space on the bugzilla site to host them. Maxwell Kanat-Alexander wrote: On Tue, 2004-03-16 at 12:55, Bruce Armstrong [TeamSybase] wrote: > [snip] It's all very confusing for somebody who is not entirely Perl > conversant. >Wow, you ain't kiddin' there, partner. >Would it be possible for bugzilla.org to host its own PPM repository? >If we have somebody who can make the packages, then it wouldn't be that >hard to keep on top of it, since we know what packages need to be in >there and it's probably not all that many... > >-M 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 JWilmoth at starbucks.com Mon Mar 29 21:03:34 2004 From: JWilmoth at starbucks.com (Jon Wilmoth) Date: Mon, 29 Mar 2004 13:03:34 -0800 Subject: Partial custom fields design document Message-ID: <72AB874F99785949A2898773AEDB5ED8DCBDC0@seams043.starbucks.net> Sean's original proposal called for custom fields to be both global and/or product specific. For whatever it's worth, this is the functionality I would like to see implemented. An example of how we would use both: Global custom field: Starbucks Systems Methodology phase Per product: For logistics related products, an "affected" distribution center would be a welcome classification. However, HR or financial related product users would not want to see/be confused by the decision to pick an "affected DC". -----Original Message----- From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] On Behalf Of Joel Peshkin Sent: Saturday, March 27, 2004 5:49 AM To: developers at bugzilla.org Subject: Re: Partial custom fields design document Gervase Markham wrote: > > If we are making custom fields product-specific instead of global > (which I believe is the plan), then we shouldn't add them to the bugs > table. > The problem with that particular item is that it is a terrible plan. Having custom fields come and go from the UI on a per-product basis is great. Having them come and go from the DB on a per-product basis is a recipe for dataloss. Once a bug has a custom field, it should be stuck with that field forever, even if it is moved to a product where that field is not supported and then back again. - To view or change your list settings, click here: From Cheiny at synaptics.com Mon Mar 29 23:39:16 2004 From: Cheiny at synaptics.com (Christopher Heiny) Date: Mon, 29 Mar 2004 15:39:16 -0800 Subject: Bugzilla as a discussion forum Message-ID: Gervase wrote > Christopher Heiny wrote: > > Maintaining running discussions in Bugzilla has proven > extremely valuable > > No-one would disagree with you here. :-) What we are trying to do is > work out where the balance is between giving people the > facilities they > need to discuss bugs, and turning Bugzilla into a web-based bulletin > board, which both encourages pointless discussion and > distracts us from > making Bugzilla beer at its core competency. > > I actually think that, right now, we are in a pretty good place. I agree. [snip] > > Basic philosophy for things like this should be: > > + just because a feature is useful to one group of > user, doesn't > mean it should be foisted on all users. > > + just because one group of users does not find a > feature useful, > doesn't mean it should be crippled for all users. > > Both these things are often true, but offer no help in deciding what > features to include. As I'm sure you know, not all features > people can > write patches for are appropriate to include in any piece of > software - > there are a wide variety of things which might make it unsuitable. > > For example, I personally believe that we have a duty to exclude > features which encourage bad practice in bug tracking, or > which start to > morph Bugzilla into something else e.g. a project planning > app. But this > is probably not a unanimous opinion ;-) I agree with that, too. I think you missed the point of my message, which is that changes should not be made (whether adding features, removing features, or crippling features) based on one or another group's use of Bugzilla. One of the major strengths of Bugzilla is that it is flexible enough to be used in many different ways, without having a lot of features tuned to specific models of use. This applies to both out of the box configuration and extensibility. From suson at TuckerEnergy.com Tue Mar 30 00:29:47 2004 From: suson at TuckerEnergy.com (Steven Suson) Date: Mon, 29 Mar 2004 18:29:47 -0600 Subject: Partial custom fields design document In-Reply-To: <72AB874F99785949A2898773AEDB5ED8DCBDC0@seams043.starbucks.net> References: <72AB874F99785949A2898773AEDB5ED8DCBDC0@seams043.starbucks.net> Message-ID: <4068BF7B.3090900@TuckerEnergy.com> I very much agree. Need both global and product specific. Steven Suson Jon Wilmoth wrote: >Sean's original proposal called for custom fields to be both global >and/or product specific. For whatever it's worth, this is the >functionality I would like to see implemented. An example of how we >would use both: > >Global custom field: >Starbucks Systems Methodology phase > >Per product: >For logistics related products, an "affected" distribution center would >be a welcome classification. However, HR or financial related product >users would not want to see/be confused by the decision to pick an >"affected DC". > >-----Original Message----- >From: developers-owner at bugzilla.org >[mailto:developers-owner at bugzilla.org] On Behalf Of Joel Peshkin >Sent: Saturday, March 27, 2004 5:49 AM >To: developers at bugzilla.org >Subject: Re: Partial custom fields design document > >Gervase Markham wrote: > > > >>If we are making custom fields product-specific instead of global >>(which I believe is the plan), then we shouldn't add them to the bugs >>table. >> >> >> >The problem with that particular item is that it is a terrible plan. >Having custom fields come and go from the UI on a per-product basis is >great. Having them come and go from the DB on a per-product basis is a >recipe for dataloss. Once a bug has a custom field, it should be stuck >with that field forever, even if it is moved to a product where that >field is not supported and then back again. > > > >- >To view or change your list settings, click here: > > >- >To view or change your list settings, click here: > > > From boris at apinc.org Tue Mar 30 14:56:03 2004 From: boris at apinc.org (Boris Baldassari) Date: Tue, 30 Mar 2004 16:56:03 +0200 (CEST) Subject: multiple instance of bugzilla In-Reply-To: <40683893.7050405@peshkin.net> References: <4723.81.80.12.54.1080548977.squirrel@mail.apinc.org> <22701.81.80.12.54.1080564129.squirrel@mail.apinc.org> <40683893.7050405@peshkin.net> Message-ID: <12668.81.80.12.54.1080658563.squirrel@mail.apinc.org> hi; > Nothing you have said would be helped by running multiple bugzilla > instances. Running multiple instances is something I suggest you treat > as a last resort. Instead of running multiple bugzillas, you can use a > distinct product for each type of record and even customize the > templates to change terminology on a per-product basis. this is not a matter of terminology. what i call lifecycle is the succession of statuses (such as new, approved, fixed, validated, etc.) and transition between them. > If there is something that you think can be done in multiple instances > but not in a single instance, please mention it here. I do not think > such a thing exists. having multiple lifecycle. for example, for one type of record, you have: new -> open -> fixed and for another type of record you have: new -> assigned -> open -> fixed -> approved \-> rejected -> closed or whatever (and usually far more complex) other statuses and transitions. i believe this can't be achieved in bugzilla without multiple instances running (one same or different server(s)), each having it's own lifecycle (and type of record). -- Boris Baldassari From bugreport at peshkin.net Tue Mar 30 16:14:51 2004 From: bugreport at peshkin.net (Joel Peshkin) Date: Tue, 30 Mar 2004 08:14:51 -0800 Subject: multiple instance of bugzilla In-Reply-To: <12668.81.80.12.54.1080658563.squirrel@mail.apinc.org> References: <4723.81.80.12.54.1080548977.squirrel@mail.apinc.org> <22701.81.80.12.54.1080564129.squirrel@mail.apinc.org> <40683893.7050405@peshkin.net> <12668.81.80.12.54.1080658563.squirrel@mail.apinc.org> Message-ID: <40699CFB.3020604@peshkin.net> Boris Baldassari wrote: >>If there is something that you think can be done in multiple instances >>but not in a single instance, please mention it here. I do not think >>such a thing exists. >> >> >having multiple lifecycle. for example, for one type of record, you have: >new -> open -> fixed > >and for another type of record you have: >new -> assigned -> open -> fixed -> approved > \-> rejected -> closed > >or whatever (and usually far more complex) other statuses and transitions. >i believe this can't be achieved in bugzilla without multiple instances >running (one same or different server(s)), each having it's own lifecycle >(and type of record). > > You would still do better by defining the internal structure of Bugzilla to a superset of the states, then using the product to distinguish between valid and/or legal state transitions and those you do not want to present or permit. From jakob.nielsen at nhst.no Wed Mar 31 11:48:54 2004 From: jakob.nielsen at nhst.no (Jakob Vad Nielsen) Date: Wed, 31 Mar 2004 13:48:54 +0200 Subject: About XML-RPC API In-Reply-To: <40682F37.1040602@mozilla.org> References: <40682270.4070102@nhst.no> <40682F37.1040602@mozilla.org> Message-ID: <406AB026.2020902@nhst.no> Hello Gervase, Since you have a smiley behind your message, I'm not sure if you really asked this question or not. But the answer to your question is no. /Jakob Gervase Markham wrote: > Jakob Vad Nielsen wrote: > >> Searching the Internet I've found some infomation about a XML-RPC API >> for Bugzilla that is supposed to exists. But I haven't been able to >> find the actual API. Is there such a thing? >> >> Can't see anything in CVS that indicates such an API. > > > You can access Bugzilla data as XML by issuing HTTP requests - is that > what an XML-RPC API is? :-) > > Gerv > > - > To view or change your list settings, click here: > From jakob.nielsen at nhst.no Wed Mar 31 11:51:40 2004 From: jakob.nielsen at nhst.no (Jakob Vad Nielsen) Date: Wed, 31 Mar 2004 13:51:40 +0200 Subject: About XML-RPC API In-Reply-To: <1080570610.20928.12.camel@localhost.localdomain> References: <40682270.4070102@nhst.no> <40682F37.1040602@mozilla.org> <1080570610.20928.12.camel@localhost.localdomain> Message-ID: <406AB0CC.3030403@nhst.no> Hello Luis, Thank you for your reply. I have two more questions: 1. What is b.m.o? 2. Is there any plans for implementing a XML-RPC api into the Bugzilla distribution? /Jakob Luis Villa wrote: >On Mon, 2004-03-29 at 15:14 +0100, Gervase Markham wrote: > > >>Jakob Vad Nielsen wrote: >> >> >> >>>Searching the Internet I've found some infomation about a XML-RPC API >>>for Bugzilla that is supposed to exists. But I haven't been able to find >>>the actual API. Is there such a thing? >>> >>>Can't see anything in CVS that indicates such an API. >>> >>> >>You can access Bugzilla data as XML by issuing HTTP requests - is that >>what an XML-RPC API is? :-) >> >> > >I would guess Jakob is referring to the XML-RPC API implemented by Red >Hat. It is in their tarballs >(http://bugzilla.redhat.com/download/bugzilla-redhat-20031120.tar.gz) >but extracting patches from there can be a bit of a PITA, and I have >been surprised not to find patches for it in b.m.o. > >Luis > >- >To view or change your list settings, click here: > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From louie at ximian.com Wed Mar 31 13:16:14 2004 From: louie at ximian.com (Luis Villa) Date: Wed, 31 Mar 2004 08:16:14 -0500 Subject: About XML-RPC API In-Reply-To: <406AB0CC.3030403@nhst.no> References: <40682270.4070102@nhst.no> <40682F37.1040602@mozilla.org> <1080570610.20928.12.camel@localhost.localdomain> <406AB0CC.3030403@nhst.no> Message-ID: <1080738974.15004.21.camel@localhost.localdomain> On Wed, 2004-03-31 at 13:51 +0200, Jakob Vad Nielsen wrote: > Hello Luis, > > Thank you for your reply. I have two more questions: > > 1. What is b.m.o? bugzilla.mozilla.org. > 2. Is there any plans for implementing a XML-RPC api into the Bugzilla > distribution? None that I have seen or been able to find, though I would think it is a logical and important step (personally.) Luis > /Jakob > > Luis Villa wrote: > > On Mon, 2004-03-29 at 15:14 +0100, Gervase Markham wrote: > > > > > Jakob Vad Nielsen wrote: > > > > > > > > > > Searching the Internet I've found some infomation about a XML-RPC API > > > > for Bugzilla that is supposed to exists. But I haven't been able to find > > > > the actual API. Is there such a thing? > > > > > > > > Can't see anything in CVS that indicates such an API. > > > > > > > You can access Bugzilla data as XML by issuing HTTP requests - is that > > > what an XML-RPC API is? :-) > > > > > > > I would guess Jakob is referring to the XML-RPC API implemented by Red > > Hat. It is in their tarballs > > (http://bugzilla.redhat.com/download/bugzilla-redhat-20031120.tar.gz) > > but extracting patches from there can be a bit of a PITA, and I have > > been surprised not to find patches for it in b.m.o. > > > > Luis > > > > - > > To view or change your list settings, click here: > > > > From Knueppel-Spenrath at t-online.de Wed Mar 31 18:46:52 2004 From: Knueppel-Spenrath at t-online.de (Knueppel-Spenrath) Date: Wed, 31 Mar 2004 20:46:52 +0200 Subject: patch list filled by email Message-ID: <406B121C.7030402@t-online.de> Hi, i've just installed bugzilla 2.17.7 on a machine, great work ;-) Now i'm wondering about the email format from cvs to bugzialla: Adding a comment to a bug is not really a problem, but adding the diffs doesn't work. I've got no idea so that bugzilla puts the diffs into the attachment list as a patch ;-( anyone an idea? thanks a lot, Dieter From tree at basistech.com Wed Mar 31 21:51:02 2004 From: tree at basistech.com (Tom Emerson) Date: Wed, 31 Mar 2004 16:51:02 -0500 Subject: About XML-RPC API In-Reply-To: <1080738974.15004.21.camel@localhost.localdomain> References: <40682270.4070102@nhst.no> <40682F37.1040602@mozilla.org> <1080570610.20928.12.camel@localhost.localdomain> <406AB0CC.3030403@nhst.no> <1080738974.15004.21.camel@localhost.localdomain> Message-ID: <16491.15686.486749.868518@magrathea.basistech.com> Luis Villa writes: > > 2. Is there any plans for implementing a XML-RPC api into the Bugzilla > > distribution? > > None that I have seen or been able to find, though I would think it is a > logical and important step (personally.) Why XML-RPC over SOAP? -- Tom Emerson Basis Technology Corp. Software Architect http://www.basistech.com "Beware the lollipop of mediocrity: lick it once and you suck forever" From dberlin at dberlin.org Wed Mar 31 22:04:01 2004 From: dberlin at dberlin.org (Daniel Berlin) Date: Wed, 31 Mar 2004 17:04:01 -0500 Subject: About XML-RPC API In-Reply-To: <16491.15686.486749.868518@magrathea.basistech.com> References: <40682270.4070102@nhst.no> <40682F37.1040602@mozilla.org> <1080570610.20928.12.camel@localhost.localdomain> <406AB0CC.3030403@nhst.no> <1080738974.15004.21.camel@localhost.localdomain> <16491.15686.486749.868518@magrathea.basistech.com> Message-ID: <51832706-835F-11D8-8BF3-000A95DA505C@dberlin.org> On Mar 31, 2004, at 4:51 PM, Tom Emerson wrote: > Luis Villa writes: >>> 2. Is there any plans for implementing a XML-RPC api into the >>> Bugzilla >>> distribution? >> >> None that I have seen or been able to find, though I would think it >> is a >> logical and important step (personally.) > > Why XML-RPC over SOAP? > It's not XML-RPC over SOAP, it's just XML-RPC. It's in redhat's bugzilla. I extracted it once into a standard bugzilla installation, it took me about 2 hours to do so. --Dan From louie at ximian.com Wed Mar 31 22:06:40 2004 From: louie at ximian.com (Luis Villa) Date: Wed, 31 Mar 2004 17:06:40 -0500 Subject: About XML-RPC API In-Reply-To: <51832706-835F-11D8-8BF3-000A95DA505C@dberlin.org> References: <40682270.4070102@nhst.no> <40682F37.1040602@mozilla.org> <1080570610.20928.12.camel@localhost.localdomain> <406AB0CC.3030403@nhst.no> <1080738974.15004.21.camel@localhost.localdomain> <16491.15686.486749.868518@magrathea.basistech.com> <51832706-835F-11D8-8BF3-000A95DA505C@dberlin.org> Message-ID: <1080770800.17539.40.camel@localhost.localdomain> On Wed, 2004-03-31 at 17:04 -0500, Daniel Berlin wrote: > On Mar 31, 2004, at 4:51 PM, Tom Emerson wrote: > > > Luis Villa writes: > >>> 2. Is there any plans for implementing a XML-RPC api into the > >>> Bugzilla > >>> distribution? > >> > >> None that I have seen or been able to find, though I would think it > >> is a > >> logical and important step (personally.) > > > > Why XML-RPC over SOAP? > > > It's not XML-RPC over SOAP, it's just XML-RPC. > > It's in redhat's bugzilla. I extracted it once into a standard bugzilla > installation, it took me about 2 hours to do so. Have those patches somewhere, Dan? :) Luis From tree at basistech.com Wed Mar 31 22:08:54 2004 From: tree at basistech.com (Tom Emerson) Date: Wed, 31 Mar 2004 17:08:54 -0500 Subject: About XML-RPC API In-Reply-To: <51832706-835F-11D8-8BF3-000A95DA505C@dberlin.org> References: <40682270.4070102@nhst.no> <40682F37.1040602@mozilla.org> <1080570610.20928.12.camel@localhost.localdomain> <406AB0CC.3030403@nhst.no> <1080738974.15004.21.camel@localhost.localdomain> <16491.15686.486749.868518@magrathea.basistech.com> <51832706-835F-11D8-8BF3-000A95DA505C@dberlin.org> Message-ID: <16491.16758.980346.709078@magrathea.basistech.com> Daniel Berlin writes: > > Why XML-RPC over SOAP? > > > It's not XML-RPC over SOAP, it's just XML-RPC. > > It's in redhat's bugzilla. I extracted it once into a standard > bugzilla installation, it took me about 2 hours to do so. My question was broader than that: ignoring the fact that the patch exists, is it worth discussing whether one of these RPC mechamisms would be better in the long run than the other. In particuylar. -- Tom Emerson Basis Technology Corp. Software Architect http://www.basistech.com "Beware the lollipop of mediocrity: lick it once and you suck forever" From dberlin at dberlin.org Wed Mar 31 22:16:47 2004 From: dberlin at dberlin.org (Daniel Berlin) Date: Wed, 31 Mar 2004 17:16:47 -0500 Subject: About XML-RPC API In-Reply-To: <1080770800.17539.40.camel@localhost.localdomain> References: <40682270.4070102@nhst.no> <40682F37.1040602@mozilla.org> <1080570610.20928.12.camel@localhost.localdomain> <406AB0CC.3030403@nhst.no> <1080738974.15004.21.camel@localhost.localdomain> <16491.15686.486749.868518@magrathea.basistech.com> <51832706-835F-11D8-8BF3-000A95DA505C@dberlin.org> <1080770800.17539.40.camel@localhost.localdomain> Message-ID: <19C9EBE5-8361-11D8-8BF3-000A95DA505C@dberlin.org> >> It's not XML-RPC over SOAP, it's just XML-RPC. >> >> It's in redhat's bugzilla. I extracted it once into a standard >> bugzilla >> installation, it took me about 2 hours to do so. > > Have those patches somewhere, Dan? :) > I didn't make the approriate changes to checksetup, etc. I just installed all the new modules it required. IE proper patches are more complex, but not prohibitively so. If you just want the ripped out XMLRPC stuff, i can redo the patch (I've since discarded it, none of our gcc developers have time to play with xml-rpc :P) pretty quickly. --Dan