From kevin.benton at amd.com Wed Jan 3 16:18:03 2007 From: kevin.benton at amd.com (Kevin Benton) Date: Wed, 03 Jan 2007 09:18:03 -0700 Subject: bz_lock_tables - how much, how often? In-Reply-To: <458E23BE.2010504@bugzilla.org> References: <458E23BE.2010504@bugzilla.org> Message-ID: <459BD73B.3060006@amd.com> David Miller wrote: > Fergus Sullivan wrote on 12/21/06 3:27 AM: >> i've noticed mysql.pm (2.22) includes the following code: > >> my bugzilla instance is a mixture of myisam an innodb. > > Bugzilla 2.22 was not written with InnoDB in mind. Your tables should > all be myISAM or you're probably asking for trouble. > > That said, there's been some debate about switching things to InnoDB, > and if that happens it'll probably be for 3.2 or so. > Hi Fergus, Any time Bugzilla asks MySQL for a lock, MySQL automatically clears the lock as soon as one of two things happen: 1) the connection is terminated, or 2) Bugzilla releases the lock. Kevin -- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: AMDLogo.png Type: image/png Size: 1784 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: kevin.benton.vcf Type: text/x-vcard Size: 915 bytes Desc: not available URL: From fredl at 3dn.nl Fri Jan 5 16:02:55 2007 From: fredl at 3dn.nl (Fred Leeflang) Date: Fri, 05 Jan 2007 17:02:55 +0100 Subject: GLUE version control and bugtracking abstraction layer Message-ID: <459E76AF.70509@3dn.nl> Hi, I just briefly mentioned something about this on the bugzilla IRC channel but since everybody's pretty busy, including myself, I thought I'd ask it here instead. I'm working on an opensource tool called 'GLUE'. The development stage is pre-alpha but things are coming along quite well. GLUE aims to be an abstraction layer between version control systems and bugtracking systems. A 'tutorial' or rather terse design for it can be found at http://glue.3dn.nl/tutorial.php When you glance over the tutorial you will hopefully understand the nature of my proposal. I want to try and access the bugzilla database through a webservice so I can query the bugzilla database for all sorts of relevant information about bugs and then link that information together with relevant information from version control systems. Obviously this could be do-able through accessing Bugzilla through it's web interface programmatically and parsing out the results but this would also be very tedious and prone to errors. So mkanat already pointed out the Webservice interface to bugzilla at http://www.bugzilla.org/docs/tip/html/api/ -> Bugzilla::WebService. I glanced over this and it seems that the webservices are rather limited at this point. I would love to help developping this some more and make bugzilla integrate with GLUE (or make GLUE integrate with bugzilla if you want :) Would you be interested in such a cooperation? Thanks, Fred Leeflang From lpsolit at gmail.com Sat Jan 6 15:26:50 2007 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Sat, 06 Jan 2007 16:26:50 +0100 Subject: Next Bugzilla meeting on Tuesday, January 9, at 19:00 GMT Message-ID: <459FBFBA.1000109@gmail.com> Hi all, and Happy New Year to those I didn't see yet. We had no Bugzilla meeting since mid-December due to vacation, Christmas and all. Our next meeting will take place next Tuesday, January 9, at 19.00 GMT (11:00 PST, 20:00 CET) in the #bugzilla-meeting channel, as usual. The agenda is available at http://wiki.mozilla.org/Bugzilla:Meetings Feel free to add your own suggestions. For the record, I also wrote the minutes for the last 2 meetings: http://wiki.mozilla.org/Bugzilla:Meetings:2006-11-28 http://wiki.mozilla.org/Bugzilla:Meetings:2006-12-12 Not sure this is still very helpful, but at least, we have them. See you on Tuesday on IRC, LpSolit From nic at worldofnic.org Sun Jan 7 19:54:38 2007 From: nic at worldofnic.org (Nicolas Doye) Date: Sun, 7 Jan 2007 19:54:38 +0000 Subject: Oracle support Message-ID: Hey all, after watching the non-development of Bug 189947for a while, I've decided to bite the bullet and develop this myself. I've started working on it, and I can post rubbish, untested, unfinished alpha code it, if people want. :-) I've started porting Bugzilla/DB/Pg.pm and Bugzilla/DB/Schema/Pg.pm to Oracle versions. I'll let you know how I get on. nic -- http://worldofnic.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From justdave at bugzilla.org Sun Jan 7 23:15:28 2007 From: justdave at bugzilla.org (David Miller) Date: Sun, 07 Jan 2007 18:15:28 -0500 Subject: GLUE version control and bugtracking abstraction layer In-Reply-To: <459E76AF.70509@3dn.nl> References: <459E76AF.70509@3dn.nl> Message-ID: <45A17F10.8070205@bugzilla.org> Fred Leeflang wrote on 1/5/07 11:02 AM: > So mkanat already pointed out the Webservice interface to bugzilla at > http://www.bugzilla.org/docs/tip/html/api/ -> Bugzilla::WebService. I > glanced > over this and it seems that the webservices are rather limited at this > point. > > I would love to help developping this some more and make bugzilla integrate > with GLUE (or make GLUE integrate with bugzilla if you want :) > > Would you be interested in such a cooperation? Of course we would. The webservice stuff is still pretty new. Getting additional development on that to have the features you need would probably be the best course of action. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From wicked at etlicon.fi Sun Jan 7 23:22:14 2007 From: wicked at etlicon.fi (Teemu Mannermaa) Date: Mon, 08 Jan 2007 01:22:14 +0200 Subject: Bugzilla prereqs now in rpmforge In-Reply-To: <45964109.7000705@bugzilla.org> References: <45964109.7000705@bugzilla.org> Message-ID: <45A180A6.9000003@etlicon.fi> On 30.12.2006 12:35, David Miller wrote: > As of this last week, all of the prereqs for Bugzilla 3.0 are now > packaged in rpmforge (dag/dries) for the benefit of anyone installing it > on RHEL or Fedora. Looks like DBI is also still too old. We require 1.41 while normal RHEL4 seems to ship only 1.40. -- Teemu Mannermaa "Anything is possible. It's all about probabilities." From justdave at bugzilla.org Sun Jan 7 23:38:25 2007 From: justdave at bugzilla.org (David Miller) Date: Sun, 07 Jan 2007 18:38:25 -0500 Subject: Bugzilla prereqs now in rpmforge In-Reply-To: <45A180A6.9000003@etlicon.fi> References: <45964109.7000705@bugzilla.org> <45A180A6.9000003@etlicon.fi> Message-ID: <45A18471.7070501@bugzilla.org> Teemu Mannermaa wrote on 1/7/07 6:22 PM: > On 30.12.2006 12:35, David Miller wrote: >> As of this last week, all of the prereqs for Bugzilla 3.0 are now >> packaged in rpmforge (dag/dries) for the benefit of anyone installing >> it on RHEL or Fedora. > > Looks like DBI is also still too old. We require 1.41 while normal RHEL4 > seems to ship only 1.40. You need the Web Application Stack from RHEL (it's a separate subscription). -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From kristis.makris at asu.edu Mon Jan 8 05:17:13 2007 From: kristis.makris at asu.edu (Kristis Makris) Date: Sun, 07 Jan 2007 22:17:13 -0700 Subject: GLUE version control and bugtracking abstraction layer In-Reply-To: <459E76AF.70509@3dn.nl> References: <459E76AF.70509@3dn.nl> Message-ID: <1168233433.3888.14.camel@syd.mkgnu.net> Hi Fred, On Fri, 2007-01-05 at 17:02 +0100, Fred Leeflang wrote: > Hi, > > I just briefly mentioned something about this on the bugzilla IRC channel > but since everybody's pretty busy, including myself, I thought I'd ask > it here > instead. > > I'm working on an opensource tool called 'GLUE'. The development stage > is pre-alpha but things are coming along quite well. GLUE aims to be > an abstraction layer between version control systems and bugtracking > systems. > A 'tutorial' or rather terse design for it can be found at > http://glue.3dn.nl/tutorial.php Your design seems, in some respects, similar to the Scmbug work: http://www.mkgnu.net/?q=scmbug http://files.mkgnu.net/files/scmbug/doc/latest_manual/html-single/manual.html#DESIGN For example, the current daemon protocol could be transformed into a SOAP-based protocol. We have a BTS API -- it's only used by the daemon. We don't have a VCS API -- VCS access goes from the VCS side to the daemon only; it's not bidirectional. And we don't have an Output API -- our VDD tool somewhat provides that, but currently is a daemon call. In a sense, we already made BTS and VCS systems GLUE compliant. But your design extends beyond what Scmbug has to sharing SBBs (somewhat like the Scmbug Merge tool). > When you glance over the tutorial you will hopefully understand the > nature of my > proposal. I want to try and access the bugzilla database through a > webservice > so I can query the bugzilla database for all sorts of relevant > information about bugs > and then link that information together with relevant information from > version > control systems. Obviously this could be do-able through accessing > Bugzilla through > it's web interface programmatically and parsing out the results but this > would also > be very tedious and prone to errors. > > So mkanat already pointed out the Webservice interface to bugzilla at > http://www.bugzilla.org/docs/tip/html/api/ -> Bugzilla::WebService. I > glanced > over this and it seems that the webservices are rather limited at this > point. > > I would love to help developping this some more and make bugzilla integrate > with GLUE (or make GLUE integrate with bugzilla if you want :) > > Would you be interested in such a cooperation? As a Scmbug developer, I would be greatly interested in extending Scmbug to fit your design. Convert the current protocol to SOAP, and extend it to become a general BTS protocol. Could you have a look over the Scmbug materials and see if Scmbug could be of help ? I'd hate for you to duplicate effort, after working on this for 2 years now. From ycombarnous at yahoo.fr Sun Jan 7 23:50:18 2007 From: ycombarnous at yahoo.fr (Barns) Date: Sun, 7 Jan 2007 15:50:18 -0800 (PST) Subject: windows.bugzilla.org In-Reply-To: <1165350533.2525.7.camel@es-lappy> References: <1165350533.2525.7.camel@es-lappy> Message-ID: <8210623.post@talk.nabble.com> This is great news. I did not dare installing apache yet on our windows box, mostly because of the time needed to read the settings and docs, as well as because there is no "official" SSL binaries. But it may be worth the upgrade with mod_perl support in 3.0. Regarding IIS, have you ever tried using the ISAPI DLL from activestate ? This could possibly boost performance, but I am not very knowledgeable on that. thanks, Yann -- View this message in context: http://www.nabble.com/windows.bugzilla.org-tf2764013.html#a8210623 Sent from the Bugzilla - Dev mailing list archive at Nabble.com. From mkanat at bugzilla.org Mon Jan 8 10:50:15 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 8 Jan 2007 02:50:15 -0800 Subject: Oracle support In-Reply-To: References: Message-ID: <20070108105017.9BFA818242@help.trusthosting.net> On Sun, 7 Jan 2007 19:54:38 +0000 "Nicolas Doye" wrote: > after watching the non-development of Bug > 189947for a > while, I've decided to bite the bullet and develop this myself. I've > started working on it, and I can post rubbish, untested, unfinished > alpha code it, if people want. :-) > > I've started porting Bugzilla/DB/Pg.pm and Bugzilla/DB/Schema/Pg.pm to > Oracle versions. I'll let you know how I get on. That's great! Any questions that you have, just come into #mozwebtools on irc.mozilla.org and ask me or any developer there. I won't be around much until Tuesday or Wednesday, but generally I'm often there during the day Pacific time. Also, you can ask any question in the bug itself and I'd be more than happy to help you out. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From nic at worldofnic.org Mon Jan 8 12:02:08 2007 From: nic at worldofnic.org (Nicolas Doye) Date: Mon, 8 Jan 2007 12:02:08 +0000 Subject: Oracle support In-Reply-To: <20070108105017.9BFA818242@help.trusthosting.net> References: <20070108105017.9BFA818242@help.trusthosting.net> Message-ID: Cool, thanks. nic > That's great! Any questions that you have, just come into > #mozwebtools on irc.mozilla.org and ask me or any developer there. I > won't be around much until Tuesday or Wednesday, but generally I'm often > there during the day Pacific time. > > Also, you can ask any question in the bug itself and I'd be more > than happy to help you out. > > -Max > -- > http://www.everythingsolved.com/ > Competent, Friendly Bugzilla Services. And Everything Else, too. > - > To view or change your list settings, click here: > > -- http://worldofnic.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From vashistabhargava at rediffmail.com Mon Jan 8 13:30:57 2007 From: vashistabhargava at rediffmail.com (Vashista Bhargava) Date: 8 Jan 2007 13:30:57 -0000 Subject: Oracle support Message-ID: <20070108133057.22764.qmail@webmail33.rediffmail.com> Hello Nicolas, Please don't work on Oracle module for Bugzilla. We at Oracle corp are working on that and currently in the testing phase. More details will follow in the coming days. Bhargava, Project Lead, Oracle Corp. On Mon, 08 Jan 2007 Nicolas Doye wrote : >Cool, thanks. > >nic > > >> That's great! Any questions that you have, just come into >>#mozwebtools on irc.mozilla.org and ask me or any developer there. I >>won't be around much until Tuesday or Wednesday, but generally I'm often >>there during the day Pacific time. >> >> Also, you can ask any question in the bug itself and I'd be more >>than happy to help you out. >> >> -Max >>-- >>http://www.everythingsolved.com/ >>Competent, Friendly Bugzilla Services. And Everything Else, too. >>- >>To view or change your list settings, click here: >> >> > > > >-- http://worldofnic.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From wicked at etlicon.fi Mon Jan 8 13:33:39 2007 From: wicked at etlicon.fi (Teemu Mannermaa) Date: Mon, 08 Jan 2007 15:33:39 +0200 Subject: Bugzilla prereqs now in rpmforge In-Reply-To: <45A18471.7070501@bugzilla.org> References: <45964109.7000705@bugzilla.org> <45A180A6.9000003@etlicon.fi> <45A18471.7070501@bugzilla.org> Message-ID: <45A24833.6000406@etlicon.com> On 8.1.2007 1:38, David Miller wrote: >> Looks like DBI is also still too old. We require 1.41 while normal >> RHEL4 seems to ship only 1.40. > You need the Web Application Stack from RHEL (it's a separate > subscription). I see. Unfortunately that only helps paying RHEL customers because RH doesn't seem to release sources for RHWAS. This means systems like CentOS won't have it and thus will have problem with Bugzilla requiring "too new" DBI. -- Teemu Mannermaa System Specialist "Anything is possible. It's all about probabilities." From lpsolit at gmail.com Mon Jan 8 16:05:59 2007 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Mon, 08 Jan 2007 17:05:59 +0100 Subject: Oracle support In-Reply-To: <20070108133057.22764.qmail@webmail33.rediffmail.com> References: <20070108133057.22764.qmail@webmail33.rediffmail.com> Message-ID: <45A26BE7.9010504@gmail.com> > Please don't work on Oracle module for Bugzilla. We at Oracle corp are working on that and currently in the testing phase. More details will follow in the coming days. Vashista, would it be possible for you to join us at the Bugzilla meeting tomorrow (see my last email for the channel on IRC and the time) to tell us a bit more about your progress on it? If not, please let us know how far you are, per email. Nice to hear from the Oracle corp again. We had no news for a long time. LpSolit From justdave at bugzilla.org Mon Jan 8 19:10:49 2007 From: justdave at bugzilla.org (David Miller) Date: Mon, 08 Jan 2007 14:10:49 -0500 Subject: Bugzilla prereqs now in rpmforge In-Reply-To: <45A24833.6000406@etlicon.com> References: <45964109.7000705@bugzilla.org> <45A180A6.9000003@etlicon.fi> <45A18471.7070501@bugzilla.org> <45A24833.6000406@etlicon.com> Message-ID: <45A29739.5070603@bugzilla.org> Teemu Mannermaa wrote on 1/8/07 8:33 AM: > On 8.1.2007 1:38, David Miller wrote: >>> Looks like DBI is also still too old. We require 1.41 while normal >>> RHEL4 seems to ship only 1.40. >> You need the Web Application Stack from RHEL (it's a separate >> subscription). > > I see. Unfortunately that only helps paying RHEL customers because RH > doesn't seem to release sources for RHWAS. This means systems like > CentOS won't have it and thus will have problem with Bugzilla requiring > "too new" DBI. Not sure how they can get away with that, it's all open source stuff, just more-current versions. I'll check into it. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From justdave at bugzilla.org Mon Jan 8 19:15:50 2007 From: justdave at bugzilla.org (David Miller) Date: Mon, 08 Jan 2007 14:15:50 -0500 Subject: Bugzilla prereqs now in rpmforge In-Reply-To: <45A29739.5070603@bugzilla.org> References: <45964109.7000705@bugzilla.org> <45A180A6.9000003@etlicon.fi> <45A18471.7070501@bugzilla.org> <45A24833.6000406@etlicon.com> <45A29739.5070603@bugzilla.org> Message-ID: <45A29866.50607@bugzilla.org> David Miller wrote on 1/8/07 2:10 PM: > Teemu Mannermaa wrote on 1/8/07 8:33 AM: >> On 8.1.2007 1:38, David Miller wrote: >>>> Looks like DBI is also still too old. We require 1.41 while normal >>>> RHEL4 seems to ship only 1.40. >>> You need the Web Application Stack from RHEL (it's a separate >>> subscription). >> >> I see. Unfortunately that only helps paying RHEL customers because RH >> doesn't seem to release sources for RHWAS. This means systems like >> CentOS won't have it and thus will have problem with Bugzilla >> requiring "too new" DBI. > > Not sure how they can get away with that, it's all open source stuff, > just more-current versions. I'll check into it. Oh, they still consider it beta, and they apparently don't post the beta stuff. Once it's final it'll be here: http://ftp.redhat.com/pub/redhat/linux/enterprise/4/en/ probably in a directory named RHWAS or similar. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From nic.doye at gmail.com Mon Jan 8 13:37:25 2007 From: nic.doye at gmail.com (Nicolas Doye) Date: Mon, 8 Jan 2007 13:37:25 +0000 Subject: Oracle support In-Reply-To: <20070108133057.22764.qmail@webmail33.rediffmail.com> References: <20070108133057.22764.qmail@webmail33.rediffmail.com> Message-ID: Well, the main thing is that someone does it. I was just looking for a bit of fun :-) I look forward to it, nic -------------- next part -------------- An HTML attachment was scrubbed... URL: From vashistabhargava at rediffmail.com Tue Jan 9 05:21:21 2007 From: vashistabhargava at rediffmail.com (Vashista Bhargava) Date: 9 Jan 2007 05:21:21 -0000 Subject: Oracle support Message-ID: <20070109052121.25817.qmail@webmail102.rediffmail.com> Well then I got into the trap hook line and sinker. Regarding the Oracle DB backend functionality, we'll post our progress in the coming days. Bhargava On Mon, 08 Jan 2007 Nicolas Doye wrote : >Well, the main thing is that someone does it. I was just looking for a bit >of fun :-) > >I look forward to it, > >nic -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkanat at bugzilla.org Tue Jan 9 06:59:07 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 8 Jan 2007 22:59:07 -0800 Subject: Oracle support In-Reply-To: <20070108133057.22764.qmail@webmail33.rediffmail.com> References: <20070108133057.22764.qmail@webmail33.rediffmail.com> Message-ID: <20070109065908.EBFD418242@help.trusthosting.net> On 8 Jan 2007 13:30:57 -0000 "Vashista Bhargava" wrote: > Please don't work on Oracle module for Bugzilla. We at Oracle corp > are working on that and currently in the testing phase. More details > will follow in the coming days. Hi Bhargava. That's really good to hear! Stay in communication with us on it, though. We have very particular code standards and particular ways we want to do some things, so posting a single monolithic patch that just "makes Bugzilla work with Oracle" won't work. I just don't want you guys to do a lot of work and then have trouble getting it actually accepted--stay in communication with us and we can explain to you the best way to actually get things accepted once it's all complete. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From kevin.benton at amd.com Tue Jan 9 21:00:42 2007 From: kevin.benton at amd.com (Kevin Benton) Date: Tue, 09 Jan 2007 14:00:42 -0700 Subject: Impact Table Implementation Message-ID: <45A4027A.8060601@amd.com> Hi all, I'm implementing an impact table where product/component/version A impacts product/component/version B. As a result, we're auto-creating a bug for B when a bug for A is created. My challenge is determining how others think this should be implemented. I've already made these changes to the versions table: versions => { FIELDS => [ value => {TYPE => 'varchar(64)', NOTNULL => 1}, product_id => {TYPE => 'INT2', NOTNULL => 1}, component_id => {TYPE => 'INT2', NOTNULL => 0}, ], INDEXES => [ versions_product_id_idx => {FIELDS => [qw(product_id value)], TYPE => 'UNIQUE'}, versions_component_id_idx => {FIELDS => [qw(product_id component_id value)], TYPE => 'UNIQUE'}, ], }, Note the addition of the component_id and the allowance for it being NULL. In other words, this allows for a no-impact change to the rest of Bugzilla but allows me to specify versions at the component level. Next, I am creating impacts and impact_map tables: impacts => { FIELDS => [ impact_id => {TYPE => 'MEDIUMSERIAL', NOTNULL => 1, PRIMARYKEY => 1}, product_id => {TYPE => 'INT2', NOTNULL => 1}, component_id => {TYPE => 'INT2', NOTNULL => 0}, version => {TYPE => 'varchar(64)', NOTNULL => 1}, ], INDEXES => [ impactss_product_id_idx => {FIELDS => [qw(product_id version)], TYPE => 'UNIQUE'}, impactss_component_id_idx => {FIELDS => [qw(product_id component_id version)], TYPE => 'UNIQUE'}, ], }, impact_map => { FIELDS => [ impacting_id => {TYPE => 'INT3', NOTNULL => 1}, impacted_id => {TYPE => 'INT3', NOTNULL => 1}, ], INDEXES => { impact_map_idx => {FIELDS => [qw(impacting_id impacted_id)], TYPE => 'UNIQUE'}, ], } What do you think about these changes to Schema.pm? Do you see any hidden gotcha's here? I know we're technically frozen for 3.0, however, there's a business need to get this implemented here and I wanted to make sure it wasn't going to break anything for 3.2. I'm also looking at possibly implementing this through Hooks, but wanted to get feedback here first. Kevin -- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: AMDLogo.png Type: image/png Size: 1784 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: kevin.benton.vcf Type: text/x-vcard Size: 892 bytes Desc: not available URL: From after.fallout at gmail.com Tue Jan 9 22:40:44 2007 From: after.fallout at gmail.com (Bill Barry) Date: Tue, 09 Jan 2007 17:40:44 -0500 Subject: Impact Table Implementation In-Reply-To: <45A4027A.8060601@amd.com> References: <45A4027A.8060601@amd.com> Message-ID: <45A419EC.4070404@gmail.com> It looks neat, I am not sure what you are trying to accomplish though. Is this something like "any bug in product 1.component a version x automatically creates a bug in product 2.component b version y" or more along the lines "any bug in product 1.component a version x has some affect on: (p2.comp b v.y, p2.comp c v.z, p1.comp a v.x-1)" Kevin Benton wrote: > Hi all, > > I'm implementing an impact table where product/component/version A > impacts product/component/version B. As a result, we're auto-creating > a bug for B when a bug for A is created. My challenge is determining > how others think this should be implemented. I've already made these > changes to the versions table: > > versions => { > FIELDS => [ > value => {TYPE => 'varchar(64)', NOTNULL => 1}, > product_id => {TYPE => 'INT2', NOTNULL => 1}, > component_id => {TYPE => 'INT2', NOTNULL => 0}, > ], > INDEXES => [ > versions_product_id_idx => {FIELDS => [qw(product_id > value)], > TYPE => 'UNIQUE'}, > versions_component_id_idx => {FIELDS => [qw(product_id > component_id > value)], > TYPE => 'UNIQUE'}, > ], > }, > > Note the addition of the component_id and the allowance for it being > NULL. In other words, this allows for a no-impact change to the rest > of Bugzilla but allows me to specify versions at the component level. > > Next, I am creating impacts and impact_map tables: > > impacts => { > FIELDS => [ > impact_id => {TYPE => 'MEDIUMSERIAL', > NOTNULL => 1, > PRIMARYKEY => 1}, > product_id => {TYPE => 'INT2', NOTNULL => 1}, > component_id => {TYPE => 'INT2', NOTNULL => 0}, > version => {TYPE => 'varchar(64)', NOTNULL => 1}, > ], > INDEXES => [ > impactss_product_id_idx => {FIELDS => [qw(product_id > version)], > TYPE => 'UNIQUE'}, > impactss_component_id_idx => {FIELDS => [qw(product_id > component_id > version)], > TYPE => 'UNIQUE'}, > ], > }, > > impact_map => { > FIELDS => [ > impacting_id => {TYPE => 'INT3', NOTNULL => 1}, > impacted_id => {TYPE => 'INT3', NOTNULL => 1}, > ], > INDEXES => { > impact_map_idx => {FIELDS => [qw(impacting_id impacted_id)], > TYPE => 'UNIQUE'}, > ], > } > > What do you think about these changes to Schema.pm? Do you see any > hidden gotcha's here? I know we're technically frozen for 3.0, > however, there's a business need to get this implemented here and I > wanted to make sure it wasn't going to break anything for 3.2. > > I'm also looking at possibly implementing this through Hooks, but > wanted to get feedback here first. > > Kevin > > -- > - > To view or change your list settings, click here: > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 1784 bytes Desc: not available URL: From kevin.benton at amd.com Tue Jan 9 23:24:24 2007 From: kevin.benton at amd.com (Kevin Benton) Date: Tue, 09 Jan 2007 16:24:24 -0700 Subject: Impact Table Implementation In-Reply-To: <45A419EC.4070404@gmail.com> References: <45A4027A.8060601@amd.com> <45A419EC.4070404@gmail.com> Message-ID: <45A42428.4080601@amd.com> Bill Barry wrote: > It looks neat, I am not sure what you are trying to accomplish though. > Is this something like "any bug in product 1.component a version x > automatically creates a bug in product 2.component b version y" That's exactly what I'm after. :) To give a more concrete example, when a bug is found in Mozilla Sunbird version x, it's known that it's likely to also impact the corresponding Lightning extension version as well. Therefore, file both bugs simultaneously unless the user specifies not to, making the auto-filed bugs dependent on the manually filed bug. Since "stuff" is reusable, we want to be aware when something that's been re-used has a bug in it and notify the proper "officials" that it's likely that the re-used "thing" has problems. The "official" can then decide whether or not to keep the issue or discard it. In our case, we've chosen specifically not to cascade impacts because of the mess it'll be likely to create. So, if A impacts B (specified in the impact_map table) and B impacts C (similarly specified), filing a bug against A auto-files a bug against B, but not C because no impact has been directly specified in the impact_map table. This also prevents impact loops (A depends on B depends on C depends on A). Any impact that is not explicitly specified is not offered to users. I almost forgot to add - there is another field in the impact_map table - is_optional which specifies when an impact can be turned off by a user. So - if issues in Product A always impact Product B, the user is not given the option to turn off auto-filing of the additional bug (assuming is_optional is set to false). Kevin > or more along the lines "any bug in product 1.component a version x > has some affect on: (p2.comp b v.y, p2.comp c v.z, p1.comp a v.x-1)" > > Kevin Benton wrote: >> Hi all, >> >> I'm implementing an impact table where product/component/version A >> impacts product/component/version B. As a result, we're >> auto-creating a bug for B when a bug for A is created. My challenge >> is determining how others think this should be implemented. I've >> already made these changes to the versions table: >> >> versions => { >> FIELDS => [ >> value => {TYPE => 'varchar(64)', NOTNULL => 1}, >> product_id => {TYPE => 'INT2', NOTNULL => 1}, >> component_id => {TYPE => 'INT2', NOTNULL => 0}, >> ], >> INDEXES => [ >> versions_product_id_idx => {FIELDS => [qw(product_id >> value)], >> TYPE => 'UNIQUE'}, >> versions_component_id_idx => {FIELDS => [qw(product_id >> component_id >> value)], >> TYPE => 'UNIQUE'}, >> ], >> }, >> >> Note the addition of the component_id and the allowance for it being >> NULL. In other words, this allows for a no-impact change to the rest >> of Bugzilla but allows me to specify versions at the component level. >> >> Next, I am creating impacts and impact_map tables: >> >> impacts => { >> FIELDS => [ >> impact_id => {TYPE => 'MEDIUMSERIAL', >> NOTNULL => 1, >> PRIMARYKEY => 1}, >> product_id => {TYPE => 'INT2', NOTNULL => 1}, >> component_id => {TYPE => 'INT2', NOTNULL => 0}, >> version => {TYPE => 'varchar(64)', NOTNULL => 1}, >> ], >> INDEXES => [ >> impactss_product_id_idx => {FIELDS => [qw(product_id >> version)], >> TYPE => 'UNIQUE'}, >> impactss_component_id_idx => {FIELDS => [qw(product_id >> component_id >> version)], >> TYPE => 'UNIQUE'}, >> ], >> }, >> >> impact_map => { >> FIELDS => [ >> impacting_id => {TYPE => 'INT3', NOTNULL => 1}, >> impacted_id => {TYPE => 'INT3', NOTNULL => 1}, >> ], >> INDEXES => { >> impact_map_idx => {FIELDS => [qw(impacting_id impacted_id)], >> TYPE => 'UNIQUE'}, >> ], >> } >> >> What do you think about these changes to Schema.pm? Do you see any >> hidden gotcha's here? I know we're technically frozen for 3.0, >> however, there's a business need to get this implemented here and I >> wanted to make sure it wasn't going to break anything for 3.2. >> >> I'm also looking at possibly implementing this through Hooks, but >> wanted to get feedback here first. >> >> Kevin >> >> -- >> - >> To view or change your list settings, click here: >> >> > -- -------------- next part -------------- A non-text attachment was scrubbed... Name: kevin.benton.vcf Type: text/x-vcard Size: 892 bytes Desc: not available URL: From vashistabhargava at rediffmail.com Wed Jan 10 05:57:53 2007 From: vashistabhargava at rediffmail.com (Vashista Bhargava) Date: 10 Jan 2007 05:57:53 -0000 Subject: Oracle support Message-ID: <20070110055753.5317.qmail@webmail62.rediffmail.com> ? Sure Max. Bhargava On Tue, 09 Jan 2007 Max Kanat-Alexander wrote : >On 8 Jan 2007 13:30:57 -0000 "Vashista Bhargava" > wrote: > > Please don't work on Oracle module for Bugzilla. We at Oracle corp > > are working on that and currently in the testing phase. More details > > will follow in the coming days. > > Hi Bhargava. That's really good to hear! Stay in communication >with us on it, though. We have very particular code standards and >particular ways we want to do some things, so posting a single >monolithic patch that just "makes Bugzilla work with Oracle" won't work. > > I just don't want you guys to do a lot of work and then have >trouble getting it actually accepted--stay in communication with us and >we can explain to you the best way to actually get things accepted once >it's all complete. > > -Max >-- >http://www.everythingsolved.com/ >Competent, Friendly Bugzilla Services. And Everything Else, too. >- >To view or change your list settings, click here: > -------------- next part -------------- An HTML attachment was scrubbed... URL: From justdave at bugzilla.org Wed Jan 10 06:47:54 2007 From: justdave at bugzilla.org (David Miller) Date: Wed, 10 Jan 2007 01:47:54 -0500 Subject: Oracle support In-Reply-To: <20070110055753.5317.qmail@webmail62.rediffmail.com> References: <20070110055753.5317.qmail@webmail62.rediffmail.com> Message-ID: <45A48C1A.8040407@bugzilla.org> One thing that would probably help is for you to get a Bugzilla account and reassign the main Oracle tracking bug to yourself (or ask one of us to assign it once you have your Bugzilla account set up). Then we know where it's coming from. The bugs blocking that one will of course be useful things to look at, and of course, if you need to make changes to anything outside of the Bugzilla/DB/Oracle.pm file those should be filed as separate bugs blocking the Oracle bug so those can get reviewed and checked in. Vashista Bhargava wrote on 1/10/07 12:57 AM: > > Sure Max. > > Bhargava > > On Tue, 09 Jan 2007 Max Kanat-Alexander wrote : > >On 8 Jan 2007 13:30:57 -0000 "Vashista Bhargava" > > wrote: > > > Please don't work on Oracle module for Bugzilla. We at Oracle corp > > > are working on that and currently in the testing phase. More details > > > will follow in the coming days. > > > > Hi Bhargava. That's really good to hear! Stay in communication > >with us on it, though. We have very particular code standards and > >particular ways we want to do some things, so posting a single > >monolithic patch that just "makes Bugzilla work with Oracle" won't work. > > > > I just don't want you guys to do a lot of work and then have > >trouble getting it actually accepted--stay in communication with us and > >we can explain to you the best way to actually get things accepted once > >it's all complete. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From nic at worldofnic.org Wed Jan 10 09:49:18 2007 From: nic at worldofnic.org (Nicolas Doye) Date: Wed, 10 Jan 2007 09:49:18 +0000 Subject: Oracle support In-Reply-To: References: <20070110055753.5317.qmail@webmail62.rediffmail.com> <45A48C1A.8040407@bugzilla.org> Message-ID: Stating the obvious, but you have to add the relevant hash to the DB choice options in checksetup.pl as well as write the new Bugzilla/DB/Oracle.pm and Bugzilla/DB/Schema/Oracle.pm. nic On 10/01/07, David Miller wrote: > > > One thing that would probably help is for you to get a Bugzilla account > and reassign the main Oracle tracking bug to yourself (or ask one of us > to assign it once you have your Bugzilla account set up). Then we know > where it's coming from. The bugs blocking that one will of course be > useful things to look at, and of course, if you need to make changes to > anything outside of the Bugzilla/DB/Oracle.pm file those should be filed > as separate bugs blocking the Oracle bug so those can get reviewed and > checked in. > > Vashista Bhargava wrote on 1/10/07 12:57 AM: > > > > Sure Max. > > > > Bhargava > > > > On Tue, 09 Jan 2007 Max Kanat-Alexander wrote : > > >On 8 Jan 2007 13:30:57 -0000 "Vashista Bhargava" > > > wrote: > > > > Please don't work on Oracle module for Bugzilla. We at Oracle corp > > > > are working on that and currently in the testing phase. More > details > > > > will follow in the coming days. > > > > > > Hi Bhargava. That's really good to hear! Stay in communication > > >with us on it, though. We have very particular code standards and > > >particular ways we want to do some things, so posting a single > > >monolithic patch that just "makes Bugzilla work with Oracle" won't > work. > > > > > > I just don't want you guys to do a lot of work and then have > > >trouble getting it actually accepted--stay in communication with us > and > > >we can explain to you the best way to actually get things accepted > once > > >it's all complete. > > > > -- > Dave Miller http://www.justdave.net/ > System Administrator, Mozilla Corporation http://www.mozilla.com/ > Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ > - > To view or change your list settings, click here: > < http://bugzilla.org/cgi-bin/mj_wwwusr?user=nic at worldofnic.org> > -- http://worldofnic.org -- http://worldofnic.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From lpsolit at gmail.com Wed Jan 10 14:24:20 2007 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Wed, 10 Jan 2007 15:24:20 +0100 Subject: Minutes of the last Bugzilla meeting Message-ID: <45A4F714.3080205@gmail.com> We had a Bugzilla meeting yesterday. You can read the minutes there: http://wiki.mozilla.org/Bugzilla:Meetings:2007-01-09 or below: * Max Kanat-Alexander (mkanat) and Fr?d?ric Buclin (LpSolit) are now allowed to grant approval on bugs. So the team of approvers for the Bugzilla product is now justdave, myk, mkanat and LpSolit. * mkanat will check whether the last webservice bug is really a blocker for 3.0 or not. That's the very last bug remaining on our roadmap for 3.0. * No major problems found following the upgrade of bugzilla.mozilla.org (aka b.m.o). Most serious bugs were fixed within 48-72 hours. b.m.o nows runs smoothly with mod_perl enabled. Thanks to justdave and reed for the hard work before and during the upgrade. * We decided to drop the 2.23.4 release. We got enough feedback since the upgrade of the b.m.o installation 2 weeks ago to feel confident with our current code. So our next release will be 3.0 RC1. * We don't agree whether the Bugzilla project should have its own Bugzilla installation (e.g. bugzilla.bugzilla.org) or not. Some of us see dogfood as a good way to test our own code. One drawback is that moving bugs between Mozilla products (e.g. the mozilla.org or b.m.o products) and the Bugzilla product would be a pain. This would also break saved searches which are not able to query 2 separate installations in one shot. Also, users would probably hate to have 2 separate accounts to report bugs. * The QA team will have to redo all QA tests again as we finally didn't release 2.22.2 and 2.23.4 on mid-December, despite QA tests were all done and passed successfully. There has been too many checkins since the b.m.o upgrade so that new tests are required again. As we will move directly to 3.0 RC1, the QA team will wait for all remaining blockers to be fixed before running them again, though. * 7 blockers left to fix before releasing 3.0 RC1. 3 of them only affect the bugzilla.org website (updating the documentation, documenting new features, building required RPM packages for distros which don't have them). * 3.0 RC1 won't be ready before the second half of February, probably. * We will have some help from the Mozilla Corporation for the Press Release when Bugzilla 3.0 will come out. * "Make Bugzilla easily pluggable" summaries where Bugzilla should go for future major releases. In other words, it should be easier for 3rd parties to write plugins. This will let us focus on the bug tracking tool aspect of the product, but allowing extensions to be added. * Our next meeting will take place on January 23, same time. LpSolit From after.fallout at gmail.com Wed Jan 10 19:34:17 2007 From: after.fallout at gmail.com (Bill Barry) Date: Wed, 10 Jan 2007 14:34:17 -0500 Subject: Impact Table Implementation In-Reply-To: <45A42428.4080601@amd.com> References: <45A4027A.8060601@amd.com> <45A419EC.4070404@gmail.com> <45A42428.4080601@amd.com> Message-ID: <45A53FB9.1040008@gmail.com> Kevin Benton wrote: > Bill Barry wrote: >> It looks neat, I am not sure what you are trying to accomplish though. >> Is this something like "any bug in product 1.component a version x >> automatically creates a bug in product 2.component b version y" > That's exactly what I'm after. :) Cool, this would work well for branches / forks as well. From justdave at bugzilla.org Wed Jan 10 20:41:08 2007 From: justdave at bugzilla.org (David Miller) Date: Wed, 10 Jan 2007 15:41:08 -0500 Subject: Minutes of the last Bugzilla meeting In-Reply-To: <45A4F714.3080205@gmail.com> References: <45A4F714.3080205@gmail.com> Message-ID: <45A54F64.8090009@bugzilla.org> Fr?d?ric Buclin wrote on 1/10/07 9:24 AM: > * We will have some help from the Mozilla Corporation for the Press > Release when Bugzilla 3.0 will come out. What I said in the meeting was: 12:21:47 <@justdave> oh, some other news, MoCo is probably going to help us with some minimal PR surrounding the 3.0 release That says "probably," not "will." PR in this context also means public/press relations as a general concept, not necessarily just a press release (though that may end up being all it is). I've corrected the minutes entry on the wiki to read: * We will probably have some kind of help from the Mozilla Corporation with public/press relations when Bugzilla 3.0 comes out. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From lpsolit at gmail.com Wed Jan 10 20:50:25 2007 From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Wed, 10 Jan 2007 21:50:25 +0100 Subject: Minutes of the last Bugzilla meeting In-Reply-To: <45A54F64.8090009@bugzilla.org> References: <45A4F714.3080205@gmail.com> <45A54F64.8090009@bugzilla.org> Message-ID: <45A55191.3090805@gmail.com> > I've corrected the minutes entry on the wiki to read: > > * We will probably have some kind of help from the Mozilla Corporation > with public/press relations when Bugzilla 3.0 comes out. OK, sorry for the mistake. I didn't look close enough at the exact wording you used. LpSolit From nic at worldofnic.org Wed Jan 10 20:58:01 2007 From: nic at worldofnic.org (Nicolas Doye) Date: Wed, 10 Jan 2007 20:58:01 +0000 Subject: Minutes of the last Bugzilla meeting In-Reply-To: <45A55191.3090805@gmail.com> References: <45A4F714.3080205@gmail.com> <45A54F64.8090009@bugzilla.org> <45A55191.3090805@gmail.com> Message-ID: Did the Oracle people say anything at the meeting? nic On 10/01/07, Fr?d?ric Buclin wrote: > > > I've corrected the minutes entry on the wiki to read: > > > > * We will probably have some kind of help from the Mozilla Corporation > > with public/press relations when Bugzilla 3.0 comes out. > > > OK, sorry for the mistake. I didn't look close enough at the exact > wording you used. > > LpSolit > - > To view or change your list settings, click here: > > -- http://worldofnic.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From lpsolit at gmail.com Wed Jan 10 21:02:00 2007 From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Wed, 10 Jan 2007 22:02:00 +0100 Subject: Minutes of the last Bugzilla meeting In-Reply-To: References: <45A4F714.3080205@gmail.com> <45A54F64.8090009@bugzilla.org> <45A55191.3090805@gmail.com> Message-ID: <45A55448.7030604@gmail.com> > Did the Oracle people say anything at the meeting? Nobody from Oracle was present. LpSolit From kevin.benton at amd.com Wed Jan 10 21:39:29 2007 From: kevin.benton at amd.com (Kevin Benton) Date: Wed, 10 Jan 2007 14:39:29 -0700 Subject: Bugzilla/Components.pm Message-ID: <45A55D11.6010106@amd.com> I am confused: I noticed that the following code is in Bugzilla/Components.pm use constant DB_COLUMNS => qw( id name product_id initialowner initialqacontact description ); I also found the definition of the Components table is in Bugzilla/DB/Schema.pm: components => { FIELDS => [ id => {TYPE => 'SMALLSERIAL', NOTNULL => 1, PRIMARYKEY => 1}, name => {TYPE => 'varchar(64)', NOTNULL => 1}, product_id => {TYPE => 'INT2', NOTNULL => 1}, initialowner => {TYPE => 'INT3', NOTNULL => 1}, initialqacontact => {TYPE => 'INT3'}, description => {TYPE => 'MEDIUMTEXT', NOTNULL => 1}, ], INDEXES => [ components_product_id_idx => {FIELDS => [qw(product_id name)], TYPE => 'UNIQUE'}, components_name_idx => ['name'], ], }, I'm wondering, why do we define the elements of the component table twice? Why not just use the definition from Bugzilla/DB/Schema.pm ? Kevin -- -------------- next part -------------- A non-text attachment was scrubbed... Name: kevin.benton.vcf Type: text/x-vcard Size: 892 bytes Desc: not available URL: From gerv at mozilla.org Wed Jan 10 23:18:24 2007 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 10 Jan 2007 23:18:24 +0000 Subject: Minutes of the last Bugzilla meeting In-Reply-To: <45A4F714.3080205@gmail.com> References: <45A4F714.3080205@gmail.com> Message-ID: <45A57440.2090908@mozilla.org> Fr?d?ric Buclin wrote: > * We don't agree whether the Bugzilla project should have its own > Bugzilla installation (e.g. bugzilla.bugzilla.org) or not. Some of us > see dogfood as a good way to test our own code. One drawback is that > moving bugs between Mozilla products (e.g. the mozilla.org or b.m.o > products) and the Bugzilla product would be a pain. ...then we fix moving. > This would also > break saved searches which are not able to query 2 separate > installations in one shot. ...then we fix saved searches. > Also, users would probably hate to have 2 > separate accounts to report bugs. ...then we fix it so we can use a separate database for logins, or use LDAP. This dogfood stuff works really well ;-) Gerv From gerv at mozilla.org Wed Jan 10 23:19:18 2007 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 10 Jan 2007 23:19:18 +0000 Subject: Minutes of the last Bugzilla meeting In-Reply-To: <45A54F64.8090009@bugzilla.org> References: <45A4F714.3080205@gmail.com> <45A54F64.8090009@bugzilla.org> Message-ID: <45A57476.10607@mozilla.org> David Miller wrote: > 12:21:47 <@justdave> oh, some other news, MoCo is probably going to help > us with some minimal PR surrounding the 3.0 release > > That says "probably," not "will." PR in this context also means > public/press relations as a general concept, not necessarily just a > press release (though that may end up being all it is). As Bugzilla is not a MoCo product, MoFo may also be able to help here; we've done so for Camino and Seamonkey in the past. Gerv From mkanat at bugzilla.org Thu Jan 11 01:40:17 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 10 Jan 2007 17:40:17 -0800 Subject: Bugzilla/Components.pm In-Reply-To: <45A55D11.6010106@amd.com> References: <45A55D11.6010106@amd.com> Message-ID: <20070111014018.C2AEE18170@help.trusthosting.net> On Wed, 10 Jan 2007 14:39:29 -0700 "Kevin Benton" wrote: > I'm wondering, why do we define the elements of the component table > twice? Why not just use the definition from Bugzilla/DB/Schema.pm ? Look at DB_COLUMNS in every single Bugzilla::Object derivative, and see if they all match up with the exact schema. Bugzilla::Bug is a great example. But it might be good to have a default for DB_COLUMNS that reads from bz_schema if it's not specified. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From kevin.benton at amd.com Thu Jan 11 16:13:56 2007 From: kevin.benton at amd.com (Kevin Benton) Date: Thu, 11 Jan 2007 09:13:56 -0700 Subject: Bugzilla/Components.pm In-Reply-To: <20070111014018.C2AEE18170@help.trusthosting.net> References: <45A55D11.6010106@amd.com> <20070111014018.C2AEE18170@help.trusthosting.net> Message-ID: <45A66244.8050200@amd.com> Max Kanat-Alexander wrote: > On Wed, 10 Jan 2007 14:39:29 -0700 "Kevin Benton" > wrote: > >> I'm wondering, why do we define the elements of the component table >> twice? Why not just use the definition from Bugzilla/DB/Schema.pm ? >> > > Look at DB_COLUMNS in every single Bugzilla::Object derivative, and > see if they all match up with the exact schema. Bugzilla::Bug is a > great example. > > But it might be good to have a default for DB_COLUMNS that > reads from bz_schema if it's not specified. > > -Max > If nothing else, when a derivative is not required, only specifying schema items once (presumably in Schema.pm) certainly makes updating the schema and interactions easier. :) I suggest we work toward removing duplicate definitions like the example I gave originally for code maintainability purposes. :) If nothing else, it seems that we ought to at least ask Schema.pm for the type definition as opposed to re-coding it again in another area - again for maintainability reasons. I also wonder if moving the database upgrade section of checksetup.pl into Schema.pm also makes sense so it's all in one place, possibly to Schema::check_and_upgrade_db(). Again, I say this because I'm thinking about maintainability - if all the core Schema changes are limited to Schema.pm, I believe that it should make it easier for maintainers to keep the number of files they touch down when making changes to the schema itself. Back to my version per component work... :) Kevin -- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: AMDLogo.png Type: image/png Size: 1784 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: kevin.benton.vcf Type: text/x-vcard Size: 892 bytes Desc: not available URL: From mkanat at bugzilla.org Thu Jan 11 21:17:31 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 11 Jan 2007 13:17:31 -0800 Subject: Bugzilla/Components.pm In-Reply-To: <45A66244.8050200@amd.com> References: <45A55D11.6010106@amd.com> <20070111014018.C2AEE18170@help.trusthosting.net> <45A66244.8050200@amd.com> Message-ID: <20070111211710.D32BB18170@help.trusthosting.net> On Thu, 11 Jan 2007 09:13:56 -0700 "Kevin Benton" wrote: > I also wonder if moving the database upgrade section of checksetup.pl > into Schema.pm also makes sense so it's all in one place, possibly to > Schema::check_and_upgrade_db(). No, DB::Schema is restricted from ever touching the database. (That's the architecture.) It makes more architectural sense to have installation things inside of the Bugzilla::Install packages, because installation modules have certain restrictions that other modules don't. (For example, standard Bugzilla modules can assume that installation has been completed, Install modules can't.) -Max From gunnar at wagenknecht.org Thu Jan 11 13:22:05 2007 From: gunnar at wagenknecht.org (Gunnar Wagenknecht) Date: Thu, 11 Jan 2007 14:22:05 +0100 Subject: Minutes of the last Bugzilla meeting In-Reply-To: <45A4F714.3080205@gmail.com> References: <45A4F714.3080205@gmail.com> Message-ID: Fr?d?ric Buclin wrote: > * 3.0 RC1 won't be ready before the second half of February, probably. Will the skin redesign exposed at b.m.o be part of Bugzilla 3.0? I've checked out the latest code from head and the show bug page looks different from what is exposed as b.m.o. CU, Gunnar -- Gunnar Wagenknecht gunnar at wagenknecht.org http://wagenknecht.org/ From justdave at bugzilla.org Mon Jan 15 04:46:06 2007 From: justdave at bugzilla.org (David Miller) Date: Sun, 14 Jan 2007 23:46:06 -0500 Subject: Minutes of the last Bugzilla meeting In-Reply-To: References: <45A4F714.3080205@gmail.com> Message-ID: <45AB070E.2080205@bugzilla.org> Gunnar Wagenknecht wrote on 1/11/07 8:22 AM: > Fr?d?ric Buclin wrote: >> * 3.0 RC1 won't be ready before the second half of February, probably. > > Will the skin redesign exposed at b.m.o be part of Bugzilla 3.0? I've > checked out the latest code from head and the show bug page looks > different from what is exposed as b.m.o. That's a matter of some debate. :) A lot of what wound up going in there is pretty Firefox-centric. There are some of the concepts that got put in there getting put into CVS though, but not all. Feel free to discuss if there's parts of it you like that haven't made it into CVS yet. :) (probably ought to start a new thread though so people notice it and don't think it's just meeting followup) -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From after.fallout at gmail.com Mon Jan 15 14:54:32 2007 From: after.fallout at gmail.com (Bill Barry) Date: Mon, 15 Jan 2007 09:54:32 -0500 Subject: Minutes of the last Bugzilla meeting In-Reply-To: References: <45A4F714.3080205@gmail.com> Message-ID: <45AB95A8.9030402@gmail.com> Gunnar Wagenknecht wrote: > Fr?d?ric Buclin wrote: > >> * 3.0 RC1 won't be ready before the second half of February, probably. >> > > Will the skin redesign exposed at b.m.o be part of Bugzilla 3.0? I've > checked out the latest code from head and the show bug page looks > different from what is exposed as b.m.o. > > CU, Gunnar > > I would rather it didn't get in (at least not as the default). While it is great for reporters and people looking for bugs, I think it is worse for the people actually fixing the bugs. In a bug you now scroll all the way to the bottom to read the last couple comments, then scroll back to the top to change some aspect of the bug, and then back to the bottom to add a comment or reassign it. (note, I am talking about show_bug, nothing else) -------------- next part -------------- An HTML attachment was scrubbed... URL: From lpsolit at gmail.com Mon Jan 15 16:12:53 2007 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Mon, 15 Jan 2007 17:12:53 +0100 Subject: Minutes of the last Bugzilla meeting In-Reply-To: <45AB95A8.9030402@gmail.com> References: <45A4F714.3080205@gmail.com> <45AB95A8.9030402@gmail.com> Message-ID: <45ABA805.1050304@gmail.com> > is great for reporters and people looking for bugs, I think it is worse > for the people actually fixing the bugs. In a bug you now scroll all the > way to the bottom to read the last couple comments, then scroll back to > the top to change some aspect of the bug, and then back to the bottom to > add a comment or reassign it. That's one of the reasons some of us dislike the UI on b.m.o. For triagers and QA people who don't need to comment, but only to change some fields, it's a pain to scroll up and down all the time. Another question of debate is the place where the keywords, status whiteboard and URL fields are. Probably they shouldn't be so high in the page, as most(?) of us probably don't use or need them. The assignee and target milestone seem more important. But this is really a question of taste, and as long as there is no consensus, we will probably keep the current UI which is by far not perfect, but much better than the one we currently have in 2.22. One part of the UI which will be ported upstream for 3.0 is the attachment table (the patch is currently under review) as there is a good consensus about it. LpSolit From gerv at mozilla.org Mon Jan 15 16:23:44 2007 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 15 Jan 2007 16:23:44 +0000 Subject: Minutes of the last Bugzilla meeting In-Reply-To: <45ABA805.1050304@gmail.com> References: <45A4F714.3080205@gmail.com> <45AB95A8.9030402@gmail.com> <45ABA805.1050304@gmail.com> Message-ID: <45ABAA90.2020402@mozilla.org> Fr?d?ric Buclin wrote: > That's one of the reasons some of us dislike the UI on b.m.o. For > triagers and QA people who don't need to comment, but only to change > some fields, it's a pain to scroll up and down all the time. Yes. It seems to me that the important parts of the page to most people are the fields, the comment box and the most recent comment. With the previous layout, you could get them all together by reversing the direction of the comments. (I never tried that, but I'd be willing to give it a go.) But with the new layout, they are miles apart whatever direction you have the comments in, because the comment box is always at the bottom. We should at least have a Commit button up the top as well (and space the other Commit button further from the knob, but that's another point). > Another question of debate is the place where the keywords, status > whiteboard and URL fields are. Probably they shouldn't be so high in the > page, as most(?) of us probably don't use or need them. The assignee and > target milestone seem more important. I certainly have to keep hunting around to find the assignee. > But this is really a question of > taste, and as long as there is no consensus, we will probably keep the > current UI which is by far not perfect, but much better than the one we > currently have in 2.22. Well, there may be no consensus, but there is "what people are used to"; and in absence of consensus, something which doesn't force everyone to retrain should be preferred. > One part of the UI which will be ported upstream for 3.0 is the > attachment table (the patch is currently under review) as there is a > good consensus about it. I agree; I like it, apart from I think some of the fonts are a bit small. Gerv From after.fallout at gmail.com Mon Jan 15 16:48:55 2007 From: after.fallout at gmail.com (Bill Barry) Date: Mon, 15 Jan 2007 11:48:55 -0500 Subject: Minutes of the last Bugzilla meeting In-Reply-To: <45ABA805.1050304@gmail.com> References: <45A4F714.3080205@gmail.com> <45AB95A8.9030402@gmail.com> <45ABA805.1050304@gmail.com> Message-ID: <45ABB077.60100@gmail.com> Fr?d?ric Buclin wrote: >> is great for reporters and people looking for bugs, I think it is >> worse for the people actually fixing the bugs. In a bug you now >> scroll all the way to the bottom to read the last couple comments, >> then scroll back to the top to change some aspect of the bug, and >> then back to the bottom to add a comment or reassign it. > > That's one of the reasons some of us dislike the UI on b.m.o. For > triagers and QA people who don't need to comment, but only to change > some fields, it's a pain to scroll up and down all the time. > > Another question of debate is the place where the keywords, status > whiteboard and URL fields are. Probably they shouldn't be so high in > the page, as most(?) of us probably don't use or need them. The > assignee and target milestone seem more important. But this is really > a question of taste, and as long as there is no consensus, we will > probably keep the current UI which is by far not perfect, but much > better than the one we currently have in 2.22. In our bugzilla (stellarfinancial) most of the users use keywords, status whiteboard, and assignee. The url field is not important, neither is target milestone, hardware or OS. We will be implementing a custom type field (https://bugzilla.mozilla.org/show_bug.cgi?id=9412) or waiting for it to be implemented in cvs and this field will be important to us. I have experimented with creating two separate bug pages (edit-bug and view-bug) to try to resolve this issue, but I don't feel like I have gotten positive feedback on it (https://bugzilla.mozilla.org/show_bug.cgi?id=345674, ignore colors; I am colorblind, they wont stay, they are just there to help identify sections on the page). The eventual idea would be to have a user pref about which to initially display on a bug and then allow a user to switch between the two. > > One part of the UI which will be ported upstream for 3.0 is the > attachment table (the patch is currently under review) as there is a > good consensus about it. What bug is this? Have we looked at considering the darwin bugzilla's extra features on their attachment tables (highlight row when mouseover for example)? > > LpSolit > - > To view or change your list settings, click here: > > From kevin.benton at amd.com Mon Jan 15 17:08:38 2007 From: kevin.benton at amd.com (Kevin Benton) Date: Mon, 15 Jan 2007 10:08:38 -0700 Subject: show_bug.cgi display layout (was: Minutes of the last Bugzilla meeting) In-Reply-To: <45ABB077.60100@gmail.com> References: <45A4F714.3080205@gmail.com> <45AB95A8.9030402@gmail.com> <45ABA805.1050304@gmail.com> <45ABB077.60100@gmail.com> Message-ID: <45ABB516.80003@amd.com> Bill Barry wrote: > Fr?d?ric Buclin wrote: >>> is great for reporters and people looking for bugs, I think it is >>> worse for the people actually fixing the bugs. In a bug you now >>> scroll all the way to the bottom to read the last couple comments, >>> then scroll back to the top to change some aspect of the bug, and >>> then back to the bottom to add a comment or reassign it. >> >> That's one of the reasons some of us dislike the UI on b.m.o. For >> triagers and QA people who don't need to comment, but only to change >> some fields, it's a pain to scroll up and down all the time. >> >> Another question of debate is the place where the keywords, status >> whiteboard and URL fields are. Probably they shouldn't be so high in >> the page, as most(?) of us probably don't use or need them. The >> assignee and target milestone seem more important. But this is really >> a question of taste, and as long as there is no consensus, we will >> probably keep the current UI which is by far not perfect, but much >> better than the one we currently have in 2.22. > In our bugzilla (stellarfinancial) most of the users use keywords, > status whiteboard, and assignee. The url field is not important, > neither is target milestone, hardware or OS. We will be implementing a > custom type field (https://bugzilla.mozilla.org/show_bug.cgi?id=9412) > or waiting for it to be implemented in cvs and this field will be > important to us. > > I have experimented with creating two separate bug pages (edit-bug and > view-bug) to try to resolve this issue, but I don't feel like I have > gotten positive feedback on it > (https://bugzilla.mozilla.org/show_bug.cgi?id=345674, ignore colors; I > am colorblind, they wont stay, they are just there to help identify > sections on the page). The eventual idea would be to have a user pref > about which to initially display on a bug and then allow a user to > switch between the two. >> >> One part of the UI which will be ported upstream for 3.0 is the >> attachment table (the patch is currently under review) as there is a >> good consensus about it. > What bug is this? Have we looked at considering the darwin bugzilla's > extra features on their attachment tables (highlight row when > mouseover for example)? >> >> LpSolit >> > If I remember correctly, there was a very nice AJAX solution that allowed users to move parts of the bug display around changing the basic layout to suit their needs. I don't know if it makes sense to consider something similar here, though I don't think it's fair to ask that it would land in 3.0. My suggestion is that we allow certain blocks to 1) be collapsible, and 2) be shiftable - meaning that the sequence can be changed. For example, some want the comment entry block at the bottom. Some want it below the fields listing. Some don't want to see certain parts of the bug display (flags for example). By allowing blocks to be collapsible and shiftable, users can move what they need to see first to the top of a bug. I agree with the other commenter that mentioned that they thought there ought to be a commit button near the top of the bug (I think it was LpSolit). In any case, I think we ought to also implement Javascript that checks to see if any field on the form has been changed before allowing users to hit their back button or click on one of the page's links. That way, users can't leave a page without being given the opportunity to submit the changes first. I don't know if this has already been done in 3.0 yet, though I think it's becoming more and more critical as our user interface becomes more user-friendly. Many applications now auto-submit so users don't have to click on a submit button, making it more likely that users will forget to click a submit button so their changes aren't lost. Kevin -- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: AMDLogo.png Type: image/png Size: 1784 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: kevin.benton.vcf Type: text/x-vcard Size: 892 bytes Desc: not available URL: From gerv at mozilla.org Mon Jan 15 17:20:13 2007 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 15 Jan 2007 17:20:13 +0000 Subject: show_bug.cgi display layout In-Reply-To: <45ABB516.80003@amd.com> References: <45A4F714.3080205@gmail.com> <45AB95A8.9030402@gmail.com> <45ABA805.1050304@gmail.com> <45ABB077.60100@gmail.com> <45ABB516.80003@amd.com> Message-ID: <45ABB7CD.8090601@mozilla.org> Kevin Benton wrote: > My suggestion is that we allow certain blocks to 1) > be collapsible, and 2) be shiftable - meaning that the sequence can be > changed. For example, some want the comment entry block at the bottom. > Some want it below the fields listing. Some don't want to see certain > parts of the bug display (flags for example). By allowing blocks to be > collapsible and shiftable, users can move what they need to see first to > the top of a bug. My concern about this would be that it would severely restrain our ability to make later changes to the underlying template. If a thousand people have made and stored particular arrangements, we would have an obligation to keep them all working and looking roughly the same. There's no way we could do that testing even if we wanted to. Gerv From kevin.benton at amd.com Mon Jan 15 17:31:03 2007 From: kevin.benton at amd.com (Kevin Benton) Date: Mon, 15 Jan 2007 10:31:03 -0700 Subject: show_bug.cgi display layout In-Reply-To: <45ABB7CD.8090601@mozilla.org> References: <45A4F714.3080205@gmail.com> <45AB95A8.9030402@gmail.com> <45ABA805.1050304@gmail.com> <45ABB077.60100@gmail.com> <45ABB516.80003@amd.com> <45ABB7CD.8090601@mozilla.org> Message-ID: <45ABBA57.1040501@amd.com> Gervase Markham wrote: > Kevin Benton wrote: >> My suggestion is that we allow certain blocks to 1) be collapsible, >> and 2) be shiftable - meaning that the sequence can be changed. For >> example, some want the comment entry block at the bottom. Some want >> it below the fields listing. Some don't want to see certain parts of >> the bug display (flags for example). By allowing blocks to be >> collapsible and shiftable, users can move what they need to see first >> to the top of a bug. > > My concern about this would be that it would severely restrain our > ability to make later changes to the underlying template. If a > thousand people have made and stored particular arrangements, we would > have an obligation to keep them all working and looking roughly the > same. There's no way we could do that testing even if we wanted to. HI Gerv, It seems to me that with the advent of custom fields, that this would be a reasonable requirement - to be able to shift where certain blocks of fields appear. I'm not suggesting that we allow all fields to appear in a random order. That's something individual site admins can accomplish through their own custom templates. OTOH, I do think it's fair to suggest that a block of fields should be semi-movable meaning that it would have a certain list of areas where it could appear. Maybe I'm over-reaching with this request from a testing standpoint, but from a usability perspective, I believe it would add a lot to the interface by making blocks of fields movable and/or collapsible in a semi-limited fashion. Kevin -- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: AMDLogo.png Type: image/png Size: 1784 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: kevin.benton.vcf Type: text/x-vcard Size: 892 bytes Desc: not available URL: From after.fallout at gmail.com Mon Jan 15 17:44:49 2007 From: after.fallout at gmail.com (Bill Barry) Date: Mon, 15 Jan 2007 12:44:49 -0500 Subject: show_bug.cgi display layout In-Reply-To: <45ABB516.80003@amd.com> References: <45A4F714.3080205@gmail.com> <45AB95A8.9030402@gmail.com> <45ABA805.1050304@gmail.com> <45ABB077.60100@gmail.com> <45ABB516.80003@amd.com> Message-ID: <45ABBD91.7010800@gmail.com> Kevin Benton wrote: > If I remember correctly, there was a very nice AJAX solution that > allowed users to move parts of the bug display around changing the > basic layout to suit their needs. As far as I know, this was just for the home page screen and it only involved saved search buglists. > I don't know if it makes sense to consider something similar here, > though I don't think it's fair to ask that it would land in 3.0. My > suggestion is that we allow certain blocks to 1) be collapsible, Good. Or simply that several less used blocks occupy the same space in client side tabs. > and 2) be shiftable - meaning that the sequence can be changed. For > example, some want the comment entry block at the bottom. Some want > it below the fields listing. Some don't want to see certain parts of > the bug display (flags for example). By allowing blocks to be > collapsible and shiftable, users can move what they need to see first > to the top of a bug. That could quickly become a nightmare for changes we may want to make to the templates sometime in the future. We would need to tread very carefully into these waters. > I agree with the other commenter that mentioned that they thought > there ought to be a commit button near the top of the bug (I think it > was LpSolit). Yes, definitely needed. A small (hidden by default) comment box would be welcome (by me) as well. Display it when a user clicks on a # symbol (or something like that) in the gray bug header bar. On that matter, it could be shown when you click the edit link in the bar. Then again, the bmo is a place to fix bugs, not a forum. Having the comment box so far down the page does seem to make it a little less inviting. > > In any case, I think we ought to also implement Javascript that checks > to see if any field on the form has been changed before allowing users > to hit their back button or click on one of the page's links. That > way, users can't leave a page without being given the opportunity to > submit the changes first. I don't know if this has already been done > in 3.0 yet, though I think it's becoming more and more critical as our > user interface becomes more user-friendly. Many applications now > auto-submit so users don't have to click on a submit button, making it > more likely that users will forget to click a submit button so their > changes aren't lost. Providing visual notification of changes would be good too. Is there some sort of :changed pseudo class for form elements? That would be an ideal starting point for this, something like: :changed { font-weight: bold; background-color: #e0e0ff; } > > Kevin > > -- > - > To view or change your list settings, click here: > > From after.fallout at gmail.com Mon Jan 15 19:28:52 2007 From: after.fallout at gmail.com (Bill Barry) Date: Mon, 15 Jan 2007 14:28:52 -0500 Subject: buglist "dupe of" column Message-ID: <45ABD5F4.5020402@gmail.com> Approx. how much work would it take to make a dupe of column that would show the bug number a bug has been resolved duplicate of (and have a link to it)? A lot of searches on bmo (and probably other public bugzillas) get many bugs that are resolved/verified duplicates and I think it would be quite handy to have a link to the bug that they are a dupe of (so you can quickly find the status of that bug). From vseerror at Lehigh.EDU Mon Jan 15 22:40:28 2007 From: vseerror at Lehigh.EDU (Wayne Mery) Date: Mon, 15 Jan 2007 17:40:28 -0500 Subject: show_bug.cgi display layout In-Reply-To: <45ABBD91.7010800@gmail.com> References: <45A4F714.3080205@gmail.com> <45AB95A8.9030402@gmail.com> <45ABA805.1050304@gmail.com> <45ABB077.60100@gmail.com> <45ABB516.80003@amd.com> <45ABBD91.7010800@gmail.com> Message-ID: <45AC02DC.8070009@lehigh.edu> Approximately half of you mentioned placement of the comment box. Perhaps this issue can be more easily addressed (with concensus) than other issues? However, I submit even 2.22's top placement (which for those with editbug seems to be the concensus preference) is not ideal. I must scroll to see the first or most recent comments or get past attachments section (which I rarely need to see) and then scroll back up to change any fields. I'd really rather see everything at once, or at least not have to scroll much more than one page. Has anyone tested a side-by-side arrangement? That is, have comments start at the top of page in a scrollable column of their own next to the labels? I'd appreciate your comments on an example I've mocked up http://i13.tinypic.com/2wehvg7.png Can it be mocked up on landfill? For reporters and the like who don't have edit privs - 2.23's bottom placement might encourage users to read the latest comments before commenting themselves. OTOH 2.22's top placement, below attachments and above comment 0, encourages nothing IMO - reading of the reporter's STR or the last comments. So perhaps 2.23's setup is better. From lpsolit at gmail.com Mon Jan 15 22:47:49 2007 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Mon, 15 Jan 2007 23:47:49 +0100 Subject: show_bug.cgi display layout In-Reply-To: <45AC02DC.8070009@lehigh.edu> References: <45A4F714.3080205@gmail.com> <45AB95A8.9030402@gmail.com> <45ABA805.1050304@gmail.com> <45ABB077.60100@gmail.com> <45ABB516.80003@amd.com> <45ABBD91.7010800@gmail.com> <45AC02DC.8070009@lehigh.edu> Message-ID: <45AC0495.2060803@gmail.com> > Approximately half of you mentioned placement of the comment box. > Perhaps this issue can be more easily addressed (with concensus) than > other issues? This issue is specific to b.m.o. Has nothing to do with Bugzilla 3.0. > Has anyone tested a side-by-side arrangement? That is, have comments > start at the top of page in a scrollable column of their own next to the > labels? > > I'd appreciate your comments on an example I've mocked up I have to scroll horizontally to see comments. Meaning that you should narrow the left column, meaning that you would have to scroll even more to see all fields. Not sure that's a good idea. From vseerror at Lehigh.EDU Mon Jan 15 23:05:21 2007 From: vseerror at Lehigh.EDU (Wayne Mery) Date: Mon, 15 Jan 2007 18:05:21 -0500 Subject: show_bug.cgi display layout In-Reply-To: <45AC0495.2060803@gmail.com> References: <45A4F714.3080205@gmail.com> <45AB95A8.9030402@gmail.com> <45ABA805.1050304@gmail.com> <45ABB077.60100@gmail.com> <45ABB516.80003@amd.com> <45ABBD91.7010800@gmail.com> <45AC02DC.8070009@lehigh.edu> <45AC0495.2060803@gmail.com> Message-ID: <45AC08B1.90501@lehigh.edu> On 1/15/2007 5:47 PM, Fr?d?ric Buclin wrote: > I have to scroll horizontally to see comments. Meaning that you should > narrow the left column, meaning that you would have to scroll even more > to see all fields. Not sure that's a good idea. what screen size are you using? As you state it of course it's not a good idea ... but then it does depends on one's screen size, font size and how one arranges the left two columns (but not necessarily all three). For myself I can see it working very nicely, should be technically feasible to implement, and better (for me) than all the currently available choices. Post 3.0, are there any UI objectives? And what are constraints will/should be placed on ideas that are submitted? Is the "personalities" project still a factor? From lpsolit at gmail.com Mon Jan 15 23:10:57 2007 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Tue, 16 Jan 2007 00:10:57 +0100 Subject: show_bug.cgi display layout In-Reply-To: <45AC08B1.90501@lehigh.edu> References: <45A4F714.3080205@gmail.com> <45AB95A8.9030402@gmail.com> <45ABA805.1050304@gmail.com> <45ABB077.60100@gmail.com> <45ABB516.80003@amd.com> <45ABBD91.7010800@gmail.com> <45AC02DC.8070009@lehigh.edu> <45AC0495.2060803@gmail.com> <45AC08B1.90501@lehigh.edu> Message-ID: <45AC0A01.6000401@gmail.com> > what screen size are you using? 17", 1024 x 768 pixels. > Post 3.0, are there any UI objectives? And what are constraints > will/should be placed on ideas that are submitted? Currently no strong post-3.0 objective. We will discuss about this as soon as 3.0 RC1 is released and the trunk open again for development. One direction is to make Bugzilla usable on small devices. > Is the "personalities" project still a factor? This project is pretty dead AFAIK. gerv is the one who was working on it. He could tell us more about it. LpSolit From justdave at bugzilla.org Tue Jan 16 00:10:39 2007 From: justdave at bugzilla.org (David Miller) Date: Mon, 15 Jan 2007 19:10:39 -0500 Subject: buglist "dupe of" column In-Reply-To: <45ABD5F4.5020402@gmail.com> References: <45ABD5F4.5020402@gmail.com> Message-ID: <45AC17FF.50901@bugzilla.org> Bill Barry wrote on 1/15/07 2:28 PM: > Approx. how much work would it take to make a dupe of column that would > show the bug number a bug has been resolved duplicate of (and have a > link to it)? > > A lot of searches on bmo (and probably other public bugzillas) get many > bugs that are resolved/verified duplicates and I think it would be quite > handy to have a link to the bug that they are a dupe of (so you can > quickly find the status of that bug). It already does this. If a bug is resolved duplicate, the Resolution field shows "DUPLICATE of 12345" where 12345 is the bug number and is linked to it. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From after.fallout at gmail.com Tue Jan 16 00:15:11 2007 From: after.fallout at gmail.com (Bill Barry) Date: Mon, 15 Jan 2007 19:15:11 -0500 Subject: show_bug.cgi display layout In-Reply-To: <45AC02DC.8070009@lehigh.edu> References: <45A4F714.3080205@gmail.com> <45AB95A8.9030402@gmail.com> <45ABA805.1050304@gmail.com> <45ABB077.60100@gmail.com> <45ABB516.80003@amd.com> <45ABBD91.7010800@gmail.com> <45AC02DC.8070009@lehigh.edu> Message-ID: <45AC190F.8040607@gmail.com> Wayne Mery wrote: > Approximately half of you mentioned placement of the comment box. > Perhaps this issue can be more easily addressed (with concensus) than > other issues? > > However, I submit even 2.22's top placement (which for those with > editbug seems to be the concensus preference) is not ideal. I must > scroll to see the first or most recent comments or get past > attachments section (which I rarely need to see) and then scroll back > up to change any fields. I'd really rather see everything at once, or > at least not have to scroll much more than one page. > > Has anyone tested a side-by-side arrangement? That is, have comments > start at the top of page in a scrollable column of their own next to > the labels? > > I'd appreciate your comments on an example I've mocked up > http://i13.tinypic.com/2wehvg7.png Can it be mocked up on landfill? I remember somewhere before a discussion about making it two columns like that, but the central issue was that the two pages would be too wide for a bugzilla page. The reason it is too wide in many cases is that several of the fields can potentially have long values (product, component, assigned to and milestone) and that the attachments table spans the entire page (and sometimes has long names there, like a full cvs file path) > > > For reporters and the like who don't have edit privs - 2.23's bottom > placement might encourage users to read the latest comments before > commenting themselves. OTOH 2.22's top placement, below attachments > and above comment 0, encourages nothing IMO - reading of the > reporter's STR or the last comments. So perhaps 2.23's setup is better. The placement at the bottom is only at bmo, (and it is good there, I think). However, for a general installation, the comment box placement at the bottom is not something I would want. For a clean idea of what 2.23 looks like, visit: http://landfill.bugzilla.org/bugzilla-tip > - > To view or change your list settings, click here: > > From kevin.benton at amd.com Tue Jan 16 00:35:20 2007 From: kevin.benton at amd.com (Kevin Benton) Date: Mon, 15 Jan 2007 17:35:20 -0700 Subject: show_bug.cgi display layout In-Reply-To: <45AC0495.2060803@gmail.com> References: <45A4F714.3080205@gmail.com> <45AB95A8.9030402@gmail.com> <45ABA805.1050304@gmail.com> <45ABB077.60100@gmail.com> <45ABB516.80003@amd.com> <45ABBD91.7010800@gmail.com> <45AC02DC.8070009@lehigh.edu> <45AC0495.2060803@gmail.com> Message-ID: <45AC1DC8.5010802@amd.com> Fr?d?ric Buclin wrote: >> Approximately half of you mentioned placement of the comment box. >> Perhaps this issue can be more easily addressed (with concensus) than >> other issues? > > This issue is specific to b.m.o. Has nothing to do with Bugzilla 3.0. > > >> Has anyone tested a side-by-side arrangement? That is, have comments >> start at the top of page in a scrollable column of their own next to >> the labels? >> >> I'd appreciate your comments on an example I've mocked up > > > I have to scroll horizontally to see comments. Meaning that you should > narrow the left column, meaning that you would have to scroll even > more to see all fields. Not sure that's a good idea. > I agree with you, LpSolit - I don't want to be forced to make my Bugzilla browser window full-screen just so I can see comments without horizontally scrolling. I also feel that white space on the screen is a good thing It just occurred to me - we're not using an anchor index (list) at all. An anchor index at the top of the bug display would help users jump to the appropriate section and does not have any negative impact on testing. The only question I have is if the user is interactively editing and they click on an anchor, do they clear their input or does it remain where it was? That answer may be browser-dependent. Just thinking out loud :) At some point, we may want to consider multiple bug views through a navigation bar on the LHS. This would give users the ability to see specific pre-defined views that don't necessarily display all the fields, comments or activity. There is value in limiting the view to "just the facts" that I need to get my job done. I think each of us would agree that few people want everything in the order given depending on what they're doing. There are times when we take the role of developer, QA, reporter, etc. Depending on our role, we care about different parts of the bug first. RT actually does a fair job of implementing this through tabbed views of bugs. Kevin -- -------------- next part -------------- A non-text attachment was scrubbed... Name: kevin.benton.vcf Type: text/x-vcard Size: 892 bytes Desc: not available URL: From after.fallout at gmail.com Tue Jan 16 01:00:14 2007 From: after.fallout at gmail.com (Bill Barry) Date: Mon, 15 Jan 2007 20:00:14 -0500 Subject: show_bug.cgi display layout In-Reply-To: <45AC0A01.6000401@gmail.com> References: <45A4F714.3080205@gmail.com> <45AB95A8.9030402@gmail.com> <45ABA805.1050304@gmail.com> <45ABB077.60100@gmail.com> <45ABB516.80003@amd.com> <45ABBD91.7010800@gmail.com> <45AC02DC.8070009@lehigh.edu> <45AC0495.2060803@gmail.com> <45AC08B1.90501@lehigh.edu> <45AC0A01.6000401@gmail.com> Message-ID: <45AC239E.6060207@gmail.com> Fr?d?ric Buclin wrote: >> what screen size are you using? > > 17", 1024 x 768 pixels. > > >> Post 3.0, are there any UI objectives? And what are constraints >> will/should be placed on ideas that are submitted? > > Currently no strong post-3.0 objective. We will discuss about this as > soon as 3.0 RC1 is released and the trunk open again for development. > One direction is to make Bugzilla usable on small devices. I have a couple of objectives for post 3.0 that I want to push (in no particular order): 1. making it very easy to script against and integrate with (email_in goes almost all the way here, I only want a little more; something to query from the command line with, and to retrieve the new bug number when you submit an email through the email_in interface) 2. a contrib patch to allow secure authenticated inbound emails (I'd love to be able to reply to a bugzilla email and get my comment in on the bug; even better would be to be able to modify the bug using the @param syntax). I don't know how this should be done though (I do know that email_in shouldn't be touched to allow this) specific to web UI: 3. better use of the header links section (I think your own saved searches should go there: "Home | New | Search | saved 1 | saved 2 | saved 3", no "My bugs", no shared searches) 4. put a searchbox and a couple links in the top right corner (the searchbox from the homepage, and underneath it put "My bugs | prefs | logout user at domain" 5. display the version in the footer on every page (pref bottom right in a float box that takes up no height) 6. make the tabs smaller (I hate that enormous tab in the search page and user preferences) 7. make it easier to get around the admin sections (https://bugzilla.mozilla.org/show_bug.cgi?id=325487) 8. bug types: https://bugzilla.mozilla.org/show_bug.cgi?id=9412 9. more bug views (currently we have edit, print, and xml; a slimmed down edit would be nice with things rearranged) for an example of what I am talking about (items 3,4,5): https://systems-300.stellarfinancial.com/bugzilla-tip/ png attachment: https://bugzilla.mozilla.org/attachment.cgi?id=230646 bug for items 3 and 4: https://bugzilla.mozilla.org/show_bug.cgi?id=345229 demo of smaller tabs (ignore colors): https://bugzilla.mozilla.org/attachment.cgi?id=232221 (on a bug about show_bug UI: https://bugzilla.mozilla.org/show_bug.cgi?id=345674) A couple things I think would be nice: linkify the status whiteboard label to a comment # if there is a comment number in the whiteboard rows highlight on mouseover in the attachments table and buglists (just a little bit to make it easy to identify the whole row) alternating rows in buglist alternate in color in all possible cases (don't modify the background color because of a priority/severity) second skin *note, I haven't voted on any of these, or submitted patches (or bugs) to some of the items in this mail due to lack of time, and that I didn't want to derail 3.0 (I feel that mod_perl, custom fields and email_in are some of the most important features ever to be released in bugzilla, and they should get out as soon as possible). I will not submit any new patches on any of these at least until 3.0 branches. > > >> Is the "personalities" project still a factor? > > This project is pretty dead AFAIK. gerv is the one who was working on > it. He could tell us more about it. > > > LpSolit > - > To view or change your list settings, click here: > > From after.fallout at gmail.com Tue Jan 16 01:15:34 2007 From: after.fallout at gmail.com (Bill Barry) Date: Mon, 15 Jan 2007 20:15:34 -0500 Subject: show_bug.cgi display layout In-Reply-To: <45AC1DC8.5010802@amd.com> References: <45A4F714.3080205@gmail.com> <45AB95A8.9030402@gmail.com> <45ABA805.1050304@gmail.com> <45ABB077.60100@gmail.com> <45ABB516.80003@amd.com> <45ABBD91.7010800@gmail.com> <45AC02DC.8070009@lehigh.edu> <45AC0495.2060803@gmail.com> <45AC1DC8.5010802@amd.com> Message-ID: <45AC2736.9080704@gmail.com> Kevin Benton wrote: > Fr?d?ric Buclin wrote: >>> Approximately half of you mentioned placement of the comment box. >>> Perhaps this issue can be more easily addressed (with concensus) >>> than other issues? >> >> This issue is specific to b.m.o. Has nothing to do with Bugzilla 3.0. >> >> >>> Has anyone tested a side-by-side arrangement? That is, have >>> comments start at the top of page in a scrollable column of their >>> own next to the labels? >>> >>> I'd appreciate your comments on an example I've mocked up >> >> >> I have to scroll horizontally to see comments. Meaning that you >> should narrow the left column, meaning that you would have to scroll >> even more to see all fields. Not sure that's a good idea. >> > I agree with you, LpSolit - I don't want to be forced to make my > Bugzilla browser window full-screen just so I can see comments without > horizontally scrolling. I also feel that white space on the screen is > a good thing > > It just occurred to me - we're not using an anchor index (list) at > all. An anchor index at the top of the bug display would help users > jump to the appropriate section and does not have any negative impact > on testing. The only question I have is if the user is interactively > editing and they click on an anchor, do they clear their input or does > it remain where it was? That answer may be browser-dependent. Just > thinking out loud :) > > At some point, we may want to consider multiple bug views through a > navigation bar on the LHS. This would give users the ability to see > specific pre-defined views that don't necessarily display all the > fields, comments or activity. There is value in limiting the view to > "just the facts" that I need to get my job done. I think each of us > would agree that few people want everything in the order given > depending on what they're doing. There are times when we take the > role of developer, QA, reporter, etc. Depending on our role, we care > about different parts of the bug first. RT actually does a fair job > of implementing this through tabbed views of bugs. I'd rather the navbar across the top and to include activity log and votes. Menus down the sides seem to always waste space underneath them We would only want a very limited number of such views though. I'd say 6 max and I would try to stick to 5 if it wasn't a big deal: edit (pretty much current HEAD) bmo style view (something like kde bugzilla, except even simpler when you first look at it; give it client side tabs to get at functionality, like the tabs at the bottom of https://bugzilla.mozilla.org/attachment.cgi?id=232603) print xml (this wouldn't show up in the tab) And the default should be controlled by a user pref. If we are going to worry about the role of the user, it would probably be good to have a different my bugs link for different users. QA people (at least here at stellar financial) seem to almost never have anything useful in "My bugs" because they need to deal with the bugs later in the cycle(when resolved and close to resolved). > > Kevin > > - > To view or change your list settings, click here: > > From after.fallout at gmail.com Tue Jan 16 01:18:51 2007 From: after.fallout at gmail.com (Bill Barry) Date: Mon, 15 Jan 2007 20:18:51 -0500 Subject: buglist "dupe of" column In-Reply-To: <45AC17FF.50901@bugzilla.org> References: <45ABD5F4.5020402@gmail.com> <45AC17FF.50901@bugzilla.org> Message-ID: <45AC27FB.8050007@gmail.com> David Miller wrote: > Bill Barry wrote on 1/15/07 2:28 PM: >> Approx. how much work would it take to make a dupe of column that >> would show the bug number a bug has been resolved duplicate of (and >> have a link to it)? >> >> A lot of searches on bmo (and probably other public bugzillas) get >> many bugs that are resolved/verified duplicates and I think it would >> be quite handy to have a link to the bug that they are a dupe of (so >> you can quickly find the status of that bug). > > It already does this. If a bug is resolved duplicate, the Resolution > field shows "DUPLICATE of 12345" where 12345 is the bug number and is > linked to it. > I meant in buglist.cgi, not on the bug proper. buglist just has "RESO DUPL". Change columns (colchange.cgi) does not have "duplicate of". From mkanat at bugzilla.org Tue Jan 16 02:33:11 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 15 Jan 2007 18:33:11 -0800 Subject: show_bug.cgi display layout In-Reply-To: <45AC239E.6060207@gmail.com> References: <45A4F714.3080205@gmail.com> <45AB95A8.9030402@gmail.com> <45ABA805.1050304@gmail.com> <45ABB077.60100@gmail.com> <45ABB516.80003@amd.com> <45ABBD91.7010800@gmail.com> <45AC02DC.8070009@lehigh.edu> <45AC0495.2060803@gmail.com> <45AC08B1.90501@lehigh.edu> <45AC0A01.6000401@gmail.com> <45AC239E.6060207@gmail.com> Message-ID: <20070116023312.E7DAF18170@help.trusthosting.net> On Mon, 15 Jan 2007 20:00:14 -0500 Bill Barry wrote: > 1. making it very easy to script against and integrate with There is already a tool to do a command line query. There is already an XML-RPC interface. > retrieve the new bug number when you submit an email through the > email_in interface) That's a good idea. Please file a bug. > 2. a contrib patch to allow secure authenticated inbound emails This doesn't have to be contrib. I already have code that does this, I just have to wait for copyright release on it. We have already planned to do this. > 3. better use of the header links section (I think your own saved > searches should go there: Some people have 50 saved searches. > 4. put a searchbox and a couple links in the top right corner That's not necessary--those links are already there in the standard header. > 5. display the version in the footer on every page (pref bottom right > in a float box that takes up no height) It's already in the header. Are you looking at bmo instead of actual upstream? > 8. bug types: https://bugzilla.mozilla.org/show_bug.cgi?id=9412 Note that that's trivially implemented by adding a "cf_type" select field in your own Bugzilla. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From mkanat at bugzilla.org Tue Jan 16 02:35:14 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 15 Jan 2007 18:35:14 -0800 Subject: buglist "dupe of" column In-Reply-To: <45AC27FB.8050007@gmail.com> References: <45ABD5F4.5020402@gmail.com> <45AC17FF.50901@bugzilla.org> <45AC27FB.8050007@gmail.com> Message-ID: <20070116023515.219D418170@help.trusthosting.net> On Mon, 15 Jan 2007 20:18:51 -0500 Bill Barry wrote: > I meant in buglist.cgi, not on the bug proper. buglist just has "RESO > DUPL". Change columns (colchange.cgi) does not have "duplicate of". See: https://bugzilla.mozilla.org/show_bug.cgi?id=204209 Also, please trim emails you reply to. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From lpsolit at gmail.com Tue Jan 16 09:43:06 2007 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Tue, 16 Jan 2007 10:43:06 +0100 Subject: show_bug.cgi display layout In-Reply-To: <20070116023312.E7DAF18170@help.trusthosting.net> References: <45A4F714.3080205@gmail.com> <45AB95A8.9030402@gmail.com> <45ABA805.1050304@gmail.com> <45ABB077.60100@gmail.com> <45ABB516.80003@amd.com> <45ABBD91.7010800@gmail.com> <45AC02DC.8070009@lehigh.edu> <45AC0495.2060803@gmail.com> <45AC08B1.90501@lehigh.edu> <45AC0A01.6000401@gmail.com> <45AC239E.6060207@gmail.com> <20070116023312.E7DAF18170@help.trusthosting.net> Message-ID: <45AC9E2A.9090909@gmail.com> >> 5. display the version in the footer on every page (pref bottom right >> in a float box that takes up no height) No, this won't happen. This information is not important enough to be displayed everywhere. There are more important stuff to display in the footer. We already rejected such a request (WONTFIX). LpSolit From lpsolit at gmail.com Tue Jan 16 09:46:21 2007 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Tue, 16 Jan 2007 10:46:21 +0100 Subject: show_bug.cgi display layout In-Reply-To: <45AC2736.9080704@gmail.com> References: <45A4F714.3080205@gmail.com> <45AB95A8.9030402@gmail.com> <45ABA805.1050304@gmail.com> <45ABB077.60100@gmail.com> <45ABB516.80003@amd.com> <45ABBD91.7010800@gmail.com> <45AC02DC.8070009@lehigh.edu> <45AC0495.2060803@gmail.com> <45AC1DC8.5010802@amd.com> <45AC2736.9080704@gmail.com> Message-ID: <45AC9EED.1010707@gmail.com> > I'd rather the navbar across the top and to include activity log and > votes. Menus down the sides seem to always waste space underneath them > We would only want a very limited number of such views though. Not sure this will happen in the near future. Several of us prefer to see all the data in the same page, without having to go from tab to tab. From after.fallout at gmail.com Tue Jan 16 13:38:00 2007 From: after.fallout at gmail.com (Bill Barry) Date: Tue, 16 Jan 2007 08:38:00 -0500 Subject: show_bug.cgi display layout In-Reply-To: <45AC9EED.1010707@gmail.com> References: <45A4F714.3080205@gmail.com> <45AB95A8.9030402@gmail.com> <45ABA805.1050304@gmail.com> <45ABB077.60100@gmail.com> <45ABB516.80003@amd.com> <45ABBD91.7010800@gmail.com> <45AC02DC.8070009@lehigh.edu> <45AC0495.2060803@gmail.com> <45AC1DC8.5010802@amd.com> <45AC2736.9080704@gmail.com> <45AC9EED.1010707@gmail.com> Message-ID: <45ACD538.9060409@gmail.com> Fr?d?ric Buclin wrote: >> I'd rather the navbar across the top and to include activity log and >> votes. Menus down the sides seem to always waste space underneath them >> We would only want a very limited number of such views though. > > > Not sure this will happen in the near future. Several of us prefer to > see all the data in the same page, without having to go from tab to tab. We already do go to other pages to see the activity log and votes (I prefer to see everything on one page as well). This would mean that instead of the links in related actions section they would be tabs. > - > To view or change your list settings, click here: > > From after.fallout at gmail.com Tue Jan 16 14:11:52 2007 From: after.fallout at gmail.com (Bill Barry) Date: Tue, 16 Jan 2007 09:11:52 -0500 Subject: show_bug.cgi display layout In-Reply-To: <20070116023312.E7DAF18170@help.trusthosting.net> References: <45A4F714.3080205@gmail.com> <45AB95A8.9030402@gmail.com> <45ABA805.1050304@gmail.com> <45ABB077.60100@gmail.com> <45ABB516.80003@amd.com> <45ABBD91.7010800@gmail.com> <45AC02DC.8070009@lehigh.edu> <45AC0495.2060803@gmail.com> <45AC08B1.90501@lehigh.edu> <45AC0A01.6000401@gmail.com> <45AC239E.6060207@gmail.com> <20070116023312.E7DAF18170@help.trusthosting.net> Message-ID: <45ACDD28.6060208@gmail.com> >> 2. a contrib patch to allow secure authenticated inbound emails >> > > This doesn't have to be contrib. I already have code that does > this, I just have to wait for copyright release on it. We have already > planned to do this. > How would you do this? Client certs? GPG? I have a script that will allow inbound email from the inside of our network (it works very much like fetchmail, in fact I bet it could be replaced with fetchmail), but it doesn't authenticate in any way. An authentication mechanism that anyone can use without getting in the way of normal email sending/recieving (through outlook and exchange) would be awesome (I could open the script up to the outside) but I haven't figured out how to do it. > >> 3. better use of the header links section (I think your own saved >> searches should go there: >> > > Some people have 50 saved searches. > So have the ability to show your saved searches in the header and/or footer in user prefs. >> 5. display the version in the footer on every page (pref bottom right >> in a float box that takes up no height) >> > > It's already in the header. Are you looking at bmo instead of > actual upstream? > Because I have replaced it in the header with a searchbox, I moved it to the footer. The header is much more valuable space than the footer and should be wisely used. > >> 8. bug types: https://bugzilla.mozilla.org/show_bug.cgi?id=9412 >> > > Note that that's trivially implemented by adding a "cf_type" > select field in your own Bugzilla. > Which is exactly what I am doing (and what the bug says). The only reason I haven't done it yet is that you say in the bug that we should have it in mainline bugzilla for 3.0 (or 3.2). If it gets in to the main bugzilla would this cause any issues for those of us that have already implemented a custom field with the same name? Is this a testcase that has been considered? > > -Max > From after.fallout at gmail.com Tue Jan 16 14:18:02 2007 From: after.fallout at gmail.com (Bill Barry) Date: Tue, 16 Jan 2007 09:18:02 -0500 Subject: buglist "dupe of" column In-Reply-To: <20070116023515.219D418170@help.trusthosting.net> References: <45ABD5F4.5020402@gmail.com> <45AC17FF.50901@bugzilla.org> <45AC27FB.8050007@gmail.com> <20070116023515.219D418170@help.trusthosting.net> Message-ID: <45ACDE9A.4090106@gmail.com> Max Kanat-Alexander wrote: > See: https://bugzilla.mozilla.org/show_bug.cgi?id=204209 > I guess that needs to be done first? I had imagined a left join to duplicates in buglist if the column is set to be displayed by the user. From lpsolit at gmail.com Tue Jan 16 16:27:07 2007 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Tue, 16 Jan 2007 17:27:07 +0100 Subject: show_bug.cgi display layout In-Reply-To: <45ACDD28.6060208@gmail.com> References: <45A4F714.3080205@gmail.com> <45AB95A8.9030402@gmail.com> <45ABA805.1050304@gmail.com> <45ABB077.60100@gmail.com> <45ABB516.80003@amd.com> <45ABBD91.7010800@gmail.com> <45AC02DC.8070009@lehigh.edu> <45AC0495.2060803@gmail.com> <45AC08B1.90501@lehigh.edu> <45AC0A01.6000401@gmail.com> <45AC239E.6060207@gmail.com> <20070116023312.E7DAF18170@help.trusthosting.net> <45ACDD28.6060208@gmail.com> Message-ID: <45ACFCDB.30405@gmail.com> > have it in mainline bugzilla for 3.0 (or 3.2). If it gets in to the main > bugzilla would this cause any issues for those of us that have already > implemented a custom field with the same name? Is this a testcase that > has been considered? All custom field names begin with "cf_". None of the fields implemented upstream will have such name, never. So this is not an issue. In this specific case, you would have "type" and "cf_type", which is not a problem. From kevin.benton at amd.com Tue Jan 16 18:08:25 2007 From: kevin.benton at amd.com (Kevin Benton) Date: Tue, 16 Jan 2007 11:08:25 -0700 Subject: show_bug.cgi display layout In-Reply-To: <45ACDD28.6060208@gmail.com> References: <45A4F714.3080205@gmail.com> <45AB95A8.9030402@gmail.com> <45ABA805.1050304@gmail.com> <45ABB077.60100@gmail.com> <45ABB516.80003@amd.com> <45ABBD91.7010800@gmail.com> <45AC02DC.8070009@lehigh.edu> <45AC0495.2060803@gmail.com> <45AC08B1.90501@lehigh.edu> <45AC0A01.6000401@gmail.com> <45AC239E.6060207@gmail.com> <20070116023312.E7DAF18170@help.trusthosting.net> <45ACDD28.6060208@gmail.com> Message-ID: <45AD1499.4090902@amd.com> Bill Barry wrote: > >>> 2. a contrib patch to allow secure authenticated inbound emails >>> >> >> This doesn't have to be contrib. I already have code that does >> this, I just have to wait for copyright release on it. We have already >> planned to do this. >> > How would you do this? Client certs? GPG? > I have a script that will allow inbound email from the inside of our > network (it works very much like fetchmail, in fact I bet it could be > replaced with fetchmail), but it doesn't authenticate in any way. An > authentication mechanism that anyone can use without getting in the > way of normal email sending/recieving (through outlook and exchange) > would be awesome (I could open the script up to the outside) but I > haven't figured out how to do it. >> >>> 3. better use of the header links section (I think your own saved >>> searches should go there: >>> >> >> Some people have 50 saved searches. >> > So have the ability to show your saved searches in the header and/or > footer in user prefs. >>> 5. display the version in the footer on every page (pref bottom right >>> in a float box that takes up no height) >>> >> >> It's already in the header. Are you looking at bmo instead of >> actual upstream? >> > Because I have replaced it in the header with a searchbox, I moved it > to the footer. The header is much more valuable space than the footer > and should be wisely used. > Hi Max, I was just thinking - for those that have a high number of saved searches, it might be useful to allow the user to specify that they want their searches in a pull-down menu rather than taking up so much space in the "saved searches" section of the header/footer. That would save a bunch of space and still keep it at the top where it's most likely to be used / needed. It would probably be best if users can configure whether or not they see their saved searches in a pull-down and whether or not they appear in the header, footer, or both. Of course, brainstorming a bit, it might also be nice if users could group their saved searches so they would not only appear in a certain order, but if pull-downs are enabled, multiple pull-downs could be offered. Kevin -- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: AMDLogo.png Type: image/png Size: 1784 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: kevin.benton.vcf Type: text/x-vcard Size: 892 bytes Desc: not available URL: From after.fallout at gmail.com Tue Jan 16 20:00:23 2007 From: after.fallout at gmail.com (Bill Barry) Date: Tue, 16 Jan 2007 15:00:23 -0500 Subject: bug 9412 - custom type field (was: show_bug.cgi display layout) In-Reply-To: <45ACFCDB.30405@gmail.com> References: <45A4F714.3080205@gmail.com> <45AB95A8.9030402@gmail.com> <45ABA805.1050304@gmail.com> <45ABB077.60100@gmail.com> <45ABB516.80003@amd.com> <45ABBD91.7010800@gmail.com> <45AC02DC.8070009@lehigh.edu> <45AC0495.2060803@gmail.com> <45AC08B1.90501@lehigh.edu> <45AC0A01.6000401@gmail.com> <45AC239E.6060207@gmail.com> <20070116023312.E7DAF18170@help.trusthosting.net> <45ACDD28.6060208@gmail.com> <45ACFCDB.30405@gmail.com> Message-ID: <45AD2ED7.6050506@gmail.com> Fr?d?ric Buclin wrote: >> have it in mainline bugzilla for 3.0 (or 3.2). If it gets in to the >> main bugzilla would this cause any issues for those of us that have >> already implemented a custom field with the same name? Is this a >> testcase that has been considered? > > All custom field names begin with "cf_". None of the fields > implemented upstream will have such name, never. So this is not an > issue. In this specific case, you would have "type" and "cf_type", > which is not a problem. Yes, but if I create a custom field with a label "Type" and values "Enhancement" "Defect" "Task" "Meta" "Question" and "Feature" and start using it, there will be a cf_type field in the database. When bug 9412 gets resolved there would be a "Type" field with a type field in the database. What would I expect to do there (probably migrate my field into the new supported one)? Max appears to suggest at the end of 9412 that Type should be a custom field that ships with bugzilla. From justdave at bugzilla.org Tue Jan 16 20:02:56 2007 From: justdave at bugzilla.org (David Miller) Date: Tue, 16 Jan 2007 15:02:56 -0500 Subject: memory usage in mod_perl Message-ID: <45AD2F70.7050604@bugzilla.org> So we knew memory usage was going to be higher with mod_perl enabled, but this is a little ridiculous. :) So b.m.o ran fine for a week or two after enabling mod_perl, but it's had to be rebooted twice in the last 3 days because it plain ran out of memory. It's got 4GB on it with 2GB swap. Most of the httpd processes are staying in the 30 to 50 MB range for RAM usage (which is about what we expected). But we eventually get more and more of them that start using up 350MB and even up to 635MB of RAM for the one listener. Some of these happen within a few minutes of rebooting. The problem comes when we start getting lots of requests at once so it starts adding listeners. If anyone has any ideas where to look or how to debug it, that'd be great, but it kinda smells like something's leaking. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From bbaetz at acm.org Tue Jan 16 20:20:52 2007 From: bbaetz at acm.org (Bradley Baetz) Date: Wed, 17 Jan 2007 07:20:52 +1100 Subject: memory usage in mod_perl In-Reply-To: <45AD2F70.7050604@bugzilla.org> References: <45AD2F70.7050604@bugzilla.org> Message-ID: <99435f5b0701161220m58f90230uefba36e5d48adffa@mail.gmail.com> On 17/01/07, David Miller wrote: > So we knew memory usage was going to be higher with mod_perl enabled, > but this is a little ridiculous. :) It shouldn't be higher. It should be less because the various perl modules are preloaded and shared. > So b.m.o ran fine for a week or two after enabling mod_perl, but it's > had to be rebooted twice in the last 3 days because it plain ran out of > memory. It's got 4GB on it with 2GB swap. Add a hook that checks the process memory and exits if its more than a certain amount? ;) > Most of the httpd processes are staying in the 30 to 50 MB range for RAM > usage (which is about what we expected). But we eventually get more and > more of them that start using up 350MB and even up to 635MB of RAM for > the one listener. Some of these happen within a few minutes of > rebooting. The problem comes when we start getting lots of requests at > once so it starts adding listeners. How big were they before mod_perl? For the 30-50MB ones, how much is shared with other processes? > If anyone has any ideas where to look or how to debug it, that'd be > great, but it kinda smells like something's leaking. Apache::Status, with appropriate B:: modules installed. Add some logging to check that the cleanuphandler is being run Bradley From lpsolit at gmail.com Tue Jan 16 21:43:30 2007 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Tue, 16 Jan 2007 22:43:30 +0100 Subject: show_bug.cgi display layout In-Reply-To: <45AD1499.4090902@amd.com> References: <45A4F714.3080205@gmail.com> <45AB95A8.9030402@gmail.com> <45ABA805.1050304@gmail.com> <45ABB077.60100@gmail.com> <45ABB516.80003@amd.com> <45ABBD91.7010800@gmail.com> <45AC02DC.8070009@lehigh.edu> <45AC0495.2060803@gmail.com> <45AC08B1.90501@lehigh.edu> <45AC0A01.6000401@gmail.com> <45AC239E.6060207@gmail.com> <20070116023312.E7DAF18170@help.trusthosting.net> <45ACDD28.6060208@gmail.com> <45AD1499.4090902@amd.com> Message-ID: <45AD4702.1030404@gmail.com> > I was just thinking - for those that have a high number of saved searches, it > might be useful to allow the user to specify that they want their searches in a > pull-down menu rather than taking up so much space in the "saved searches" > section of the header/footer. You should first look at b.m.o. We already have a bug for it. :) > course, brainstorming a bit, it might also be nice if users could group their > saved searches so they would not only appear in a certain order, but if > pull-downs are enabled, multiple pull-downs could be offered. We also have a bug about ordering saved searches. ;) From lpsolit at gmail.com Tue Jan 16 21:47:31 2007 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Tue, 16 Jan 2007 22:47:31 +0100 Subject: bug 9412 - custom type field In-Reply-To: <45AD2ED7.6050506@gmail.com> References: <45A4F714.3080205@gmail.com> <45AB95A8.9030402@gmail.com> <45ABA805.1050304@gmail.com> <45ABB077.60100@gmail.com> <45ABB516.80003@amd.com> <45ABBD91.7010800@gmail.com> <45AC02DC.8070009@lehigh.edu> <45AC0495.2060803@gmail.com> <45AC08B1.90501@lehigh.edu> <45AC0A01.6000401@gmail.com> <45AC239E.6060207@gmail.com> <20070116023312.E7DAF18170@help.trusthosting.net> <45ACDD28.6060208@gmail.com> <45ACFCDB.30405@gmail.com> <45AD2ED7.6050506@gmail.com> Message-ID: <45AD47F3.8090705@gmail.com> > Max appears to suggest at the end of 9412 that Type should be a custom > field that ships with bugzilla. This may be dangerous as all custom field names are of the form cf_foo and we don't know which names have already been used. Official fields will have a name which won't collide with those, though. We will probably add an attribute to fields allowing us to enable/disable these fields from editfields.cgi. Another example is the status whiteboard. LpSolit From kevin.benton at amd.com Tue Jan 16 21:50:43 2007 From: kevin.benton at amd.com (Kevin Benton) Date: Tue, 16 Jan 2007 14:50:43 -0700 Subject: show_bug.cgi display layout In-Reply-To: <45AD4702.1030404@gmail.com> References: <45A4F714.3080205@gmail.com> <45AB95A8.9030402@gmail.com> <45ABA805.1050304@gmail.com> <45ABB077.60100@gmail.com> <45ABB516.80003@amd.com> <45ABBD91.7010800@gmail.com> <45AC02DC.8070009@lehigh.edu> <45AC0495.2060803@gmail.com> <45AC08B1.90501@lehigh.edu> <45AC0A01.6000401@gmail.com> <45AC239E.6060207@gmail.com> <20070116023312.E7DAF18170@help.trusthosting.net> <45ACDD28.6060208@gmail.com> <45AD1499.4090902@amd.com> <45AD4702.1030404@gmail.com> Message-ID: <45AD48B3.2080607@amd.com> Fr?d?ric Buclin wrote: >> I was just thinking - for those that have a high number of saved >> searches, it might be useful to allow the user to specify that they >> want their searches in a pull-down menu rather than taking up so much >> space in the "saved searches" section of the header/footer. > > You should first look at b.m.o. We already have a bug for it. :) > >> course, brainstorming a bit, it might also be nice if users could >> group their saved searches so they would not only appear in a certain >> order, but if pull-downs are enabled, multiple pull-downs could be >> offered. > > We also have a bug about ordering saved searches. ;) You're right - I should have looked first - I'm glad I'm not the only one thinking this stuff up 8-) :-P 8-) -- -------------- next part -------------- A non-text attachment was scrubbed... Name: kevin.benton.vcf Type: text/x-vcard Size: 892 bytes Desc: not available URL: From lpsolit at gmail.com Tue Jan 16 21:57:30 2007 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Tue, 16 Jan 2007 22:57:30 +0100 Subject: show_bug.cgi display layout In-Reply-To: <45AD48B3.2080607@amd.com> References: <45A4F714.3080205@gmail.com> <45AB95A8.9030402@gmail.com> <45ABA805.1050304@gmail.com> <45ABB077.60100@gmail.com> <45ABB516.80003@amd.com> <45ABBD91.7010800@gmail.com> <45AC02DC.8070009@lehigh.edu> <45AC0495.2060803@gmail.com> <45AC08B1.90501@lehigh.edu> <45AC0A01.6000401@gmail.com> <45AC239E.6060207@gmail.com> <20070116023312.E7DAF18170@help.trusthosting.net> <45ACDD28.6060208@gmail.com> <45AD1499.4090902@amd.com> <45AD4702.1030404@gmail.com> <45AD48B3.2080607@amd.com> Message-ID: <45AD4A4A.30404@gmail.com> > I'm glad I'm not the only one thinking this stuff up Who said the other ones requesting this feature are sane persons? :-D From kevin.benton at amd.com Tue Jan 16 21:59:50 2007 From: kevin.benton at amd.com (Kevin Benton) Date: Tue, 16 Jan 2007 14:59:50 -0700 Subject: show_bug.cgi display layout In-Reply-To: <45AD4A4A.30404@gmail.com> References: <45A4F714.3080205@gmail.com> <45AB95A8.9030402@gmail.com> <45ABA805.1050304@gmail.com> <45ABB077.60100@gmail.com> <45ABB516.80003@amd.com> <45ABBD91.7010800@gmail.com> <45AC02DC.8070009@lehigh.edu> <45AC0495.2060803@gmail.com> <45AC08B1.90501@lehigh.edu> <45AC0A01.6000401@gmail.com> <45AC239E.6060207@gmail.com> <20070116023312.E7DAF18170@help.trusthosting.net> <45ACDD28.6060208@gmail.com> <45AD1499.4090902@amd.com> <45AD4702.1030404@gmail.com> <45AD48B3.2080607@amd <45AD4A4A.30404@gmail.com> Message-ID: <45AD4AD6.2040901@amd.com> Fr?d?ric Buclin wrote: >> I'm glad I'm not the only one thinking this stuff up > > > Who said the other ones requesting this feature are sane persons? :-D > - > To view or change your list settings, click here: > > > > LOL :-P 8-) -- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: AMDLogo.png Type: image/png Size: 1784 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: kevin.benton.vcf Type: text/x-vcard Size: 892 bytes Desc: not available URL: From mkanat at bugzilla.org Tue Jan 16 22:59:31 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 16 Jan 2007 14:59:31 -0800 Subject: show_bug.cgi display layout In-Reply-To: <45ACDD28.6060208@gmail.com> References: <45A4F714.3080205@gmail.com> <45AB95A8.9030402@gmail.com> <45ABA805.1050304@gmail.com> <45ABB077.60100@gmail.com> <45ABB516.80003@amd.com> <45ABBD91.7010800@gmail.com> <45AC02DC.8070009@lehigh.edu> <45AC0495.2060803@gmail.com> <45AC08B1.90501@lehigh.edu> <45AC0A01.6000401@gmail.com> <45AC239E.6060207@gmail.com> <20070116023312.E7DAF18170@help.trusthosting.net> <45ACDD28.6060208@gmail.com> Message-ID: <20070116225932.2886118170@help.trusthosting.net> On Tue, 16 Jan 2007 09:11:52 -0500 Bill Barry wrote: > > This doesn't have to be contrib. I already have code that > > does this, I just have to wait for copyright release on it. We have > > already planned to do this. > > > How would you do this? Client certs? GPG? GPG. As I said, I've already written the code. Then, after GPG, we will be implementing a challenge-response mechanism for non-GPG emails. (Sort of like how you confirm for subscribing to a mailing list.) -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From mkanat at bugzilla.org Tue Jan 16 23:11:38 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 16 Jan 2007 15:11:38 -0800 Subject: memory usage in mod_perl In-Reply-To: <99435f5b0701161220m58f90230uefba36e5d48adffa@mail.gmail.com> References: <45AD2F70.7050604@bugzilla.org> <99435f5b0701161220m58f90230uefba36e5d48adffa@mail.gmail.com> Message-ID: <20070116231139.88D4118170@help.trusthosting.net> On Wed, 17 Jan 2007 07:20:52 +1100 "Bradley Baetz" wrote: > It shouldn't be higher. It should be less because the various perl > modules are preloaded and shared. No, it's higher. Without mod_perl, all memory usage is transient. With mod_perl, once something is loaded into one httpd child, it stays there forever. Also, because of copy-on-write, modules aren't really shared. Also, I think some shared memory stuff that mod_perl needs may be broken on the RHEL4 kernel. I asked about this on the mod_perl list, and they said, "No, your memory usage looks totally normal." > > So b.m.o ran fine for a week or two after enabling mod_perl, but > > it's had to be rebooted twice in the last 3 days because it plain > > ran out of memory. It's got 4GB on it with 2GB swap. The usual solution for this is to set MaxRequestsPerChild. > > If anyone has any ideas where to look or how to debug it, that'd be > > great, but it kinda smells like something's leaking. Nothing is leaking. Well, except the primary design of perl. :-( Here's the problem: When perl allocates memory for a variable, it doesn't release it. Ever. Until it dies. But in mod_perl, it never dies! So, say somebody loads a list of 10,000 bugs. The memory for that 10,000 bugs is never released by the perl interpreter, even though it destroys the variable when the script exits. If you know what specific variable is causing the problem, you can "undef $var" before your subroutine exits, and that can handle it. But you have to specifically undef it for perl to release it. Ideally what we need is something that can walk the whole perl memory structure and manually release the memory of unused variables. But I haven't found such a thing, and I don't know enough about perl internals to write such a thing. Something like Devel::Gladiator might be a place to start, for anybody interested. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From after.fallout at gmail.com Wed Jan 17 00:08:28 2007 From: after.fallout at gmail.com (Bill Barry) Date: Tue, 16 Jan 2007 19:08:28 -0500 Subject: show_bug.cgi display layout In-Reply-To: <20070116225932.2886118170@help.trusthosting.net> References: <45A4F714.3080205@gmail.com> <45AB95A8.9030402@gmail.com> <45ABA805.1050304@gmail.com> <45ABB077.60100@gmail.com> <45ABB516.80003@amd.com> <45ABBD91.7010800@gmail.com> <45AC02DC.8070009@lehigh.edu> <45AC0495.2060803@gmail.com> <45AC08B1.90501@lehigh.edu> <45AC0A01.6000401@gmail.com> <45AC239E.6060207@gmail.com> <20070116023312.E7DAF18170@help.trusthosting.net> <45ACDD28.6060208@gmail.com> <20070116225932.2886118170@help.trusthosting.net> Message-ID: <45AD68FC.50701@gmail.com> > Then, after GPG, we will be implementing a challenge-response > mechanism for non-GPG emails. (Sort of like how you confirm for > subscribing to a mailing list.) > I hadn't thought of that, good idea (put the authentication out to whether or not the user can authenticate to their mail server) From justdave at bugzilla.org Wed Jan 17 00:53:19 2007 From: justdave at bugzilla.org (David Miller) Date: Tue, 16 Jan 2007 19:53:19 -0500 Subject: memory usage in mod_perl In-Reply-To: <20070116231139.88D4118170@help.trusthosting.net> References: <45AD2F70.7050604@bugzilla.org> <99435f5b0701161220m58f90230uefba36e5d48adffa@mail.gmail.com> <20070116231139.88D4118170@help.trusthosting.net> Message-ID: <45AD737F.2000508@bugzilla.org> Max Kanat-Alexander wrote on 1/16/07 6:11 PM: > The usual solution for this is to set MaxRequestsPerChild. Yeah, I've been doing that. It started out at 4000. I've cut it in half every time the machine got close (or passed) exhausting memory. It's down to 100 now. (It was at 250 last time it crashed). >>> If anyone has any ideas where to look or how to debug it, that'd be >>> great, but it kinda smells like something's leaking. > > When perl allocates memory for a variable, it doesn't release > it. Ever. Until it dies. > > But in mod_perl, it never dies! So, say somebody loads a list > of 10,000 bugs. The memory for that 10,000 bugs is never released by > the perl interpreter, even though it destroys the variable when the > script exits. > > If you know what specific variable is causing the problem, you > can "undef $var" before your subroutine exits, and that can handle it. > But you have to specifically undef it for perl to release it. I was guessing that's probably what it was. We don't have a whole lot of variables that are likely to occupy huge amounts of memory. A buglist is a darn good candidate. A good start would probably be undef'ing the bug object cache in our cleanup handler. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From mkanat at bugzilla.org Wed Jan 17 00:56:33 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 16 Jan 2007 16:56:33 -0800 Subject: memory usage in mod_perl In-Reply-To: <45AD737F.2000508@bugzilla.org> References: <45AD2F70.7050604@bugzilla.org> <99435f5b0701161220m58f90230uefba36e5d48adffa@mail.gmail.com> <20070116231139.88D4118170@help.trusthosting.net> <45AD737F.2000508@bugzilla.org> Message-ID: <20070117005634.325C418170@help.trusthosting.net> On Tue, 16 Jan 2007 19:53:19 -0500 David Miller wrote: > I was guessing that's probably what it was. We don't have a whole > lot of variables that are likely to occupy huge amounts of memory. A > buglist is a darn good candidate. A good start would probably be > undef'ing the bug object cache in our cleanup handler. Yeah, that is a good idea, and I'd love to do it. The problem is that we can't get that variable anymore--it's actually been undefined by perl, but perl didn't release the memory. Basically what I'd really love to do is force perl to release all unallocated memory, but I have *no* idea how to go about that. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From justdave at bugzilla.org Wed Jan 17 00:57:07 2007 From: justdave at bugzilla.org (David Miller) Date: Tue, 16 Jan 2007 19:57:07 -0500 Subject: memory usage in mod_perl In-Reply-To: <45AD737F.2000508@bugzilla.org> References: <45AD2F70.7050604@bugzilla.org> <99435f5b0701161220m58f90230uefba36e5d48adffa@mail.gmail.com> <20070116231139.88D4118170@help.trusthosting.net> <45AD737F.2000508@bugzilla.org> Message-ID: <45AD7463.1000508@bugzilla.org> David Miller wrote on 1/16/07 7:53 PM: > Max Kanat-Alexander wrote on 1/16/07 6:11 PM: >> If you know what specific variable is causing the problem, you >> can "undef $var" before your subroutine exits, and that can handle it. >> But you have to specifically undef it for perl to release it. > > I was guessing that's probably what it was. We don't have a whole lot > of variables that are likely to occupy huge amounts of memory. A > buglist is a darn good candidate. A good start would probably be > undef'ing the bug object cache in our cleanup handler. Another good candidate would be the dependency hashes in showdependencygraph.cgi -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From justdave at bugzilla.org Wed Jan 17 01:07:41 2007 From: justdave at bugzilla.org (David Miller) Date: Tue, 16 Jan 2007 20:07:41 -0500 Subject: memory usage in mod_perl In-Reply-To: <20070117005634.325C418170@help.trusthosting.net> References: <45AD2F70.7050604@bugzilla.org> <99435f5b0701161220m58f90230uefba36e5d48adffa@mail.gmail.com> <20070116231139.88D4118170@help.trusthosting.net> <45AD737F.2000508@bugzilla.org> <20070117005634.325C418170@help.trusthosting.net> Message-ID: <45AD76DD.7010402@bugzilla.org> Max Kanat-Alexander wrote on 1/16/07 7:56 PM: > On Tue, 16 Jan 2007 19:53:19 -0500 David Miller > wrote: >> I was guessing that's probably what it was. We don't have a whole >> lot of variables that are likely to occupy huge amounts of memory. A >> buglist is a darn good candidate. A good start would probably be >> undef'ing the bug object cache in our cleanup handler. > > Yeah, that is a good idea, and I'd love to do it. The problem is > that we can't get that variable anymore--it's actually been undefined by > perl, but perl didn't release the memory. > > Basically what I'd really love to do is force perl to release > all unallocated memory, but I have *no* idea how to go about that. You probably have to walk the hash and undef all the things in it. If you just undef the hash you leave a bunch of orphaned references. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From mkanat at bugzilla.org Wed Jan 17 01:21:23 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 16 Jan 2007 17:21:23 -0800 Subject: memory usage in mod_perl In-Reply-To: <45AD76DD.7010402@bugzilla.org> References: <45AD2F70.7050604@bugzilla.org> <99435f5b0701161220m58f90230uefba36e5d48adffa@mail.gmail.com> <20070116231139.88D4118170@help.trusthosting.net> <45AD737F.2000508@bugzilla.org> <20070117005634.325C418170@help.trusthosting.net> <45AD76DD.7010402@bugzilla.org> Message-ID: <20070117012124.6A58F18170@help.trusthosting.net> On Tue, 16 Jan 2007 20:07:41 -0500 David Miller wrote: > You probably have to walk the hash and undef all the things in it. > If you just undef the hash you leave a bunch of orphaned references. Yes, but *what hash*? In a CleanupHandler, no variables are available. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From justdave at bugzilla.org Wed Jan 17 01:53:06 2007 From: justdave at bugzilla.org (David Miller) Date: Tue, 16 Jan 2007 20:53:06 -0500 Subject: memory usage in mod_perl In-Reply-To: <20070117012124.6A58F18170@help.trusthosting.net> References: <45AD2F70.7050604@bugzilla.org> <99435f5b0701161220m58f90230uefba36e5d48adffa@mail.gmail.com> <20070116231139.88D4118170@help.trusthosting.net> <45AD737F.2000508@bugzilla.org> <20070117005634.325C418170@help.trusthosting.net> <45AD76DD.7010402@bugzilla.org> <20070117012124.6A58F18170@help.trusthosting.net> Message-ID: <45AD8182.9010503@bugzilla.org> Max Kanat-Alexander wrote on 1/16/07 8:21 PM: > On Tue, 16 Jan 2007 20:07:41 -0500 David Miller > wrote: >> You probably have to walk the hash and undef all the things in it. >> If you just undef the hash you leave a bunch of orphaned references. > > Yes, but *what hash*? In a CleanupHandler, no variables are > available. It's all in $vars at the point it gets dumped to the template. Perhaps recursively nuking $vars after the templates are displayed before exiting would work. On the other hand, that would be bad if we had stuck a reference to anything that should stay cached in $vars. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From bbaetz at acm.org Wed Jan 17 10:48:27 2007 From: bbaetz at acm.org (Bradley Baetz) Date: Wed, 17 Jan 2007 21:48:27 +1100 Subject: memory usage in mod_perl In-Reply-To: <45AD8182.9010503@bugzilla.org> References: <45AD2F70.7050604@bugzilla.org> <99435f5b0701161220m58f90230uefba36e5d48adffa@mail.gmail.com> <20070116231139.88D4118170@help.trusthosting.net> <45AD737F.2000508@bugzilla.org> <20070117005634.325C418170@help.trusthosting.net> <45AD76DD.7010402@bugzilla.org> <20070117012124.6A58F18170@help.trusthosting.net> <45AD8182.9010503@bugzilla.org> Message-ID: <99435f5b0701170248g1946f6d3n8aaca5dff67cf29d@mail.gmail.com> On 17/01/07, David Miller wrote: > Max Kanat-Alexander wrote on 1/16/07 8:21 PM: > > On Tue, 16 Jan 2007 20:07:41 -0500 David Miller > > wrote: > >> You probably have to walk the hash and undef all the things in it. > >> If you just undef the hash you leave a bunch of orphaned references. > > > > Yes, but *what hash*? In a CleanupHandler, no variables are > > available. > > It's all in $vars at the point it gets dumped to the template. Perhaps > recursively nuking $vars after the templates are displayed before > exiting would work. Yeah, but $vars isn't global, is it? Perl does free up memory unless you end up with cycles; strictly speaking its libc/the kernel that won't ever free it up. > On the other hand, that would be bad if we had stuck a reference to > anything that should stay cached in $vars. Not across requests, though. Bradley From mkanat at bugzilla.org Wed Jan 17 12:57:49 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 17 Jan 2007 04:57:49 -0800 Subject: memory usage in mod_perl In-Reply-To: <99435f5b0701170248g1946f6d3n8aaca5dff67cf29d@mail.gmail.com> References: <45AD2F70.7050604@bugzilla.org> <99435f5b0701161220m58f90230uefba36e5d48adffa@mail.gmail.com> <20070116231139.88D4118170@help.trusthosting.net> <45AD737F.2000508@bugzilla.org> <20070117005634.325C418170@help.trusthosting.net> <45AD76DD.7010402@bugzilla.org> <20070117012124.6A58F18170@help.trusthosting.net> <45AD8182.9010503@bugzilla.org> <99435f5b0701170248g1946f6d3n8aaca5dff67cf29d@mail.gmail.com> Message-ID: <20070117125724.DA9CA18170@help.trusthosting.net> On Wed, 17 Jan 2007 21:48:27 +1100 "Bradley Baetz" wrote: > Perl does free up memory unless you end up with cycles; strictly > speaking its libc/the kernel that won't ever free it up. No, it's perl that doesn't return it to the kernel: http://perl.apache.org/docs/1.0/guide/performance.html#Memory_leakage > Not across requests, though. Right, we don't manually cache anything across requests. -Max From jake at bugzilla.org Wed Jan 17 13:22:41 2007 From: jake at bugzilla.org (Jake) Date: Wed, 17 Jan 2007 08:22:41 -0500 (EST) Subject: memory usage in mod_perl In-Reply-To: <20070117125724.DA9CA18170@help.trusthosting.net> References: <45AD2F70.7050604@bugzilla.org> <99435f5b0701161220m58f90230uefba36e5d48adffa@mail.gmail.com> <20070116231139.88D4118170@help.trusthosting.net> <45AD737F.2000508@bugzilla.org> <20070117005634.325C418170@help.trusthosting.net> <45AD76DD.7010402@bugzilla.org> <20070117012124.6A58F18170@help.trusthosting.net> <45AD8182.9010503@bugzilla.org> <99435f5b0701170248g1946f6d3n8aaca5dff67cf29d@mail.gmail.com> <20070117125724.DA9CA18170@help.trusthosting.net> Message-ID: <28974.208.20.196.122.1169040161.squirrel@mail.secure.steenhagen.us> > On Wed, 17 Jan 2007 21:48:27 +1100 "Bradley Baetz" > wrote: >> Perl does free up memory unless you end up with cycles; strictly >> speaking its libc/the kernel that won't ever free it up. > > No, it's perl that doesn't return it to the kernel: > > http://perl.apache.org/docs/1.0/guide/performance.html#Memory_leakage According to that link, Perl won't return it to the kernel, but it will reuse it. So unless there's a ton of memory all being used at the exact same time on a thread, it doesn't seem like even a long buglist should cause memory usage to climb to 350MB. Even if 20 people loaded buglists that happened to take up 10MB of RAM each (which seems like quite a bit to me!), that should only be 200MB of total RAM. And that would require the unfortunate luck of those 20 people all hitting the same mod_perl thread. But as soon as their buglist is loaded, Perl should start reusing that RAM. Do attachments get cached in memory? Could those be what's causing memory usage to spike? From mkanat at bugzilla.org Wed Jan 17 13:54:37 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 17 Jan 2007 05:54:37 -0800 Subject: memory usage in mod_perl In-Reply-To: <28974.208.20.196.122.1169040161.squirrel@mail.secure.steenhagen.us> References: <45AD2F70.7050604@bugzilla.org> <99435f5b0701161220m58f90230uefba36e5d48adffa@mail.gmail.com> <20070116231139.88D4118170@help.trusthosting.net> <45AD737F.2000508@bugzilla.org> <20070117005634.325C418170@help.trusthosting.net> <45AD76DD.7010402@bugzilla.org> <20070117012124.6A58F18170@help.trusthosting.net> <45AD8182.9010503@bugzilla.org> <99435f5b0701170248g1946f6d3n8aaca5dff67cf29d@mail.gmail.com> <20070117125724.DA9CA18170@help.trusthosting.net> <28974.208.20.196.122.1169040161.squirrel@mail.secure.steenhagen.us> Message-ID: <20070117135412.19A9E18170@help.trusthosting.net> On Wed, 17 Jan 2007 08:22:41 -0500 (EST) "Jake" wrote: > According to that link, Perl won't return it to the kernel, but it > will reuse it. So unless there's a ton of memory all being used at > the exact same time on a thread, it doesn't seem like even a long > buglist should cause memory usage to climb to 350MB. Well, it's per-process, not per-thread, if that makes a difference in your understanding. We don't use a threaded MPM, and in fact Bugzilla won't work under a threaded MPM. So the threads aren't sharing anything, really. They share some memory for the compiled modules and compiled CGIs, but that's it. That 350MB is every single memory allocation made during the page call, and all of the HTML and template code needed to display that thing. I just checked on landfill, and loading every bug that's in landfill (4726 bugs) on a single buglist page causes Apache to allocate 40MB of memory on top of whatever it already has for that process. Given all of the template code and modules, that doesn't seem like an unreasonable amount to me. The Template Toolkit is not memory-efficient. Although I would be interested to know the breakdown of memory usage of such a buglist. But without an understanding of perl's internals (which I mostly lack), it's hard to write a script that will explain that to me, when the memory is not allocated to any particular variable. > And that would require the unfortunate luck of those 20 > people all hitting the same mod_perl thread. No, they'd all have to hit separate ones. Otherwise, as you pointed out, perl would re-use the memory. > But as soon as their > buglist is loaded, Perl should start reusing that RAM. Only that httpd process will re-use the RAM. > Do attachments get cached in memory? Could those be what's causing > memory usage to spike? Nothing gets cached in memory. But any display of anything allocates memory under mod_perl, and that memory won't be returned to the kernel. -Max From after.fallout at gmail.com Wed Jan 17 14:47:04 2007 From: after.fallout at gmail.com (Bill Barry) Date: Wed, 17 Jan 2007 09:47:04 -0500 Subject: memory usage in mod_perl In-Reply-To: <20070117135412.19A9E18170@help.trusthosting.net> References: <45AD2F70.7050604@bugzilla.org> <99435f5b0701161220m58f90230uefba36e5d48adffa@mail.gmail.com> <20070116231139.88D4118170@help.trusthosting.net> <45AD737F.2000508@bugzilla.org> <20070117005634.325C418170@help.trusthosting.net> <45AD76DD.7010402@bugzilla.org> <20070117012124.6A58F18170@help.trusthosting.net> <45AD8182.9010503@bugzilla.org> <99435f5b0701170248g1946f6d3n8aaca5dff67cf29d@mail.gmail.com> <20070117125724.DA9CA18170@help.trusthosting.net> <28974.208.20.196.122.1169040161.squirrel@mail.secure.steenhagen.us> <20070117135412.19A9E18170@help.trusthosting.net> Message-ID: <45AE36E8.8030604@gmail.com> Max Kanat-Alexander wrote: > On Wed, 17 Jan 2007 08:22:41 -0500 (EST) "Jake" > wrote: > >> According to that link, Perl won't return it to the kernel, but it >> will reuse it. So unless there's a ton of memory all being used at >> the exact same time on a thread, it doesn't seem like even a long >> buglist should cause memory usage to climb to 350MB. >> Dependency graphs might be able to do it (especially the show all dependencies on all bugs one). They hit the server pretty hard. > That 350MB is every single memory allocation made during the > page call, and all of the HTML and template code needed to display that > thing. > I thought it was every memory allocation across all page calls at the time. mod_perl causes everything to run within the same process, and doesn't do very optimistic GC (if any at all). > I just checked on landfill, and loading every bug that's in > landfill (4726 bugs) on a single buglist page causes Apache to allocate > 40MB of memory on top of whatever it already has for that process. > How about the Long Summary? > Although I would be interested to know the breakdown of memory > usage of such a buglist. But without an understanding of perl's > internals (which I mostly lack), it's hard to write a script that will > explain that to me, when the memory is not allocated to any particular > variable. > Would getting everything from within each namespace help? I am not sure how to get non allocated memory that perl is using, but getting stuff pointed at by variables will at least provide hints where we should consider optimizing wouldn't it? We would need to put some sort of watch script in at various points of each cgi and actually use it (on bmo) for a little while to profile. I don't think these sort of issues will be found nearly as quickly (if ever) on any smaller or less used Bugzilla. From lpsolit at gmail.com Wed Jan 17 17:46:42 2007 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Wed, 17 Jan 2007 18:46:42 +0100 Subject: memory usage in mod_perl In-Reply-To: <99435f5b0701170248g1946f6d3n8aaca5dff67cf29d@mail.gmail.com> References: <45AD2F70.7050604@bugzilla.org> <99435f5b0701161220m58f90230uefba36e5d48adffa@mail.gmail.com> <20070116231139.88D4118170@help.trusthosting.net> <45AD737F.2000508@bugzilla.org> <20070117005634.325C418170@help.trusthosting.net> <45AD76DD.7010402@bugzilla.org> <20070117012124.6A58F18170@help.trusthosting.net> <45AD8182.9010503@bugzilla.org> <99435f5b0701170248g1946f6d3n8aaca5dff67cf29d@mail.gmail.com> Message-ID: <45AE6102.2010103@gmail.com> > Yeah, but $vars isn't global, is it? Right, we have no more global variables, including $vars (which was previously known as $::vars). From gerv at mozilla.org Thu Jan 18 20:45:50 2007 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 18 Jan 2007 20:45:50 +0000 Subject: show_bug.cgi display layout In-Reply-To: <45AC0A01.6000401@gmail.com> References: <45A4F714.3080205@gmail.com> <45AB95A8.9030402@gmail.com> <45ABA805.1050304@gmail.com> <45ABB077.60100@gmail.com> <45ABB516.80003@amd.com> <45ABBD91.7010800@gmail.com> <45AC02DC.8070009@lehigh.edu> <45AC0495.2060803@gmail.com> <45AC08B1.90501@lehigh.edu> <45AC0A01.6000401@gmail.com> Message-ID: <45AFDC7E.4080302@mozilla.org> Fr?d?ric Buclin wrote: > Currently no strong post-3.0 objective. We will discuss about this as > soon as 3.0 RC1 is released and the trunk open again for development. > One direction is to make Bugzilla usable on small devices. Do we have strong use cases for this, in terms of actual people saying "Yes, I would use Bugzilla from my handheld if I could"? >> Is the "personalities" project still a factor? > > This project is pretty dead AFAIK. gerv is the one who was working on > it. He could tell us more about it. It can be used in its current state; more work would improve it. The idea is to work out who our target audience is. If we are agreed that we've got it, then we're done. If we're not agreed, we need to think about it some more. Gerv From gerv at mozilla.org Thu Jan 18 20:48:56 2007 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 18 Jan 2007 20:48:56 +0000 Subject: show_bug.cgi display layout In-Reply-To: <45AC239E.6060207@gmail.com> References: <45A4F714.3080205@gmail.com> <45AB95A8.9030402@gmail.com> <45ABA805.1050304@gmail.com> <45ABB077.60100@gmail.com> <45ABB516.80003@amd.com> <45ABBD91.7010800@gmail.com> <45AC02DC.8070009@lehigh.edu> <45AC0495.2060803@gmail.com> <45AC08B1.90501@lehigh.edu> <45AC0A01.6000401@gmail.com> <45AC239E.6060207@gmail.com> Message-ID: <45AFDD38.5040105@mozilla.org> Bill Barry wrote: > 8. bug types: https://bugzilla.mozilla.org/show_bug.cgi?id=9412 I was working on a possible migration to Bugzilla the other day, and recommended they combine their current "bug/enhancement" field with the severity field, as Bugzilla has it, during the migration - i.e. that Bugzilla's way is better than their way. Despite what bug 9412 says, enhancements don't have a severity. They have a priority, and they might have an estimate (in time-tracking) but they don't have a severity. Splitting the field up in mainline Bugzilla is, IMO, a mistake. Gerv From gerv at mozilla.org Thu Jan 18 20:51:26 2007 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 18 Jan 2007 20:51:26 +0000 Subject: show_bug.cgi display layout In-Reply-To: <45AD1499.4090902@amd.com> References: <45A4F714.3080205@gmail.com> <45AB95A8.9030402@gmail.com> <45ABA805.1050304@gmail.com> <45ABB077.60100@gmail.com> <45ABB516.80003@amd.com> <45ABBD91.7010800@gmail.com> <45AC02DC.8070009@lehigh.edu> <45AC0495.2060803@gmail.com> <45AC08B1.90501@lehigh.edu> <45AC0A01.6000401@gmail.com> <45AC239E.6060207@gmail.com> <20070116023312.E7DAF18170@help.trusthosting.net> <45ACDD28.6060208@gmail.com> <45AD1499.4090902@amd.com> Message-ID: <45AFDDCE.30902@mozilla.org> Kevin Benton wrote: > I was just thinking - for those that have a high number of saved > searches, it might be useful to allow the user to specify that they want > their searches in a pull-down menu rather than taking up so much space > in the "saved searches" section of the header/footer. I tried this on a mock-up once. I remember Myk had some usability issues with it. > That would save a > bunch of space and still keep it at the top where it's most likely to be > used / needed. But makes each saved search a click - scroll - click instead of just a click. And it's worse with a longer list. > It would probably be best if users can configure whether > or not they see their saved searches in a pull-down and whether or not > they appear in the header, footer, or both. That's the second or third time in this thread that someone has suggested making a UI feature "configurable" in case some people don't like it. We are in danger of getting Mozilla Suite-itis here. We should use established usability principles to work out what's best, and do that. That's why, for example, we've resisted having comments in non-fixed-width fonts or wider than 80 chars. Gerv From gerv at mozilla.org Thu Jan 18 20:52:57 2007 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 18 Jan 2007 20:52:57 +0000 Subject: show_bug.cgi display layout In-Reply-To: <45ACD538.9060409@gmail.com> References: <45A4F714.3080205@gmail.com> <45AB95A8.9030402@gmail.com> <45ABA805.1050304@gmail.com> <45ABB077.60100@gmail.com> <45ABB516.80003@amd.com> <45ABBD91.7010800@gmail.com> <45AC02DC.8070009@lehigh.edu> <45AC0495.2060803@gmail.com> <45AC1DC8.5010802@amd.com> <45AC2736.9080704@gmail.com> <45AC9EED.1010707@gmail.com> <45ACD538.9060409@gmail.com> Message-ID: <45AFDE29.4080507@mozilla.org> Bill Barry wrote: > We already do go to other pages to see the activity log and votes Yes, but they are very infrequently viewed. I can count the number of times I've looked at either in the past year on the fingers of one hand. If things are too complex for some users, make them a simpler template with just the fields they care about, triggered by group membership. Gerv From after.fallout at gmail.com Thu Jan 18 21:35:40 2007 From: after.fallout at gmail.com (Bill Barry) Date: Thu, 18 Jan 2007 16:35:40 -0500 Subject: show_bug.cgi display layout In-Reply-To: <45AFDC7E.4080302@mozilla.org> References: <45A4F714.3080205@gmail.com> <45AB95A8.9030402@gmail.com> <45ABA805.1050304@gmail.com> <45ABB077.60100@gmail.com> <45ABB516.80003@amd.com> <45ABBD91.7010800@gmail.com> <45AC02DC.8070009@lehigh.edu> <45AC0495.2060803@gmail.com> <45AC08B1.90501@lehigh.edu> <45AC0A01.6000401@gmail.com> <45AFDC7E.4080302@mozilla.org> Message-ID: <45AFE82C.1030408@gmail.com> > Do we have strong use cases for this, in terms of actual people saying > "Yes, I would use Bugzilla from my handheld if I could"? If the inbound email interface ends up working well enough, I would rather use that; but yes, I would use bugzilla on my handheld (and so would 6 others at Stellar; we all already receive the bugmail on our phones, the ability to modify a bug while not in front of a computer is a welcome opportunity). From after.fallout at gmail.com Thu Jan 18 22:10:48 2007 From: after.fallout at gmail.com (Bill Barry) Date: Thu, 18 Jan 2007 17:10:48 -0500 Subject: show_bug.cgi display layout In-Reply-To: <45AFDD38.5040105@mozilla.org> References: <45A4F714.3080205@gmail.com> <45AB95A8.9030402@gmail.com> <45ABA805.1050304@gmail.com> <45ABB077.60100@gmail.com> <45ABB516.80003@amd.com> <45ABBD91.7010800@gmail.com> <45AC02DC.8070009@lehigh.edu> <45AC0495.2060803@gmail.com> <45AC08B1.90501@lehigh.edu> <45AC0A01.6000401@gmail.com> <45AC239E.6060207@gmail.com> <45AFDD38.5040105@mozilla.org> Message-ID: <45AFF068.90103@gmail.com> > Despite what bug 9412 says, enhancements don't have a severity. They > have a priority, and they might have an estimate (in time-tracking) > but they don't have a severity. Splitting the field up in mainline > Bugzilla is, IMO, a mistake. From bugzilla's documentation on a priority: -- This field describes the importance and order in which a bug should be fixed. This field is utilized by the programmers/engineers to prioritize their work to be done. The available priorities range from *P1* (most important) to *P5* (least important.) -- Priorities describe what a *programmer* and/or his/her superiors feel should be done, and a general order of how to do them. While an enhancement does not have a severity in the usual sense of the word (the impact that the defect has in its existing form as the report is filed), the aspects of implementing an enhancement (a modification of the system to allow a new use or better use of some system aspect) do indeed have an impact on the system, and hence a risk assessment including the details of how much an impact that enhancement will cause justifies the severity of an enhancement. Another aspect of bug 9412 is that there are bugs in bugzilla that are neither defects (on the product itself) nor enhancements. In the current system these items are hard to search for without implementing specialized nomenclature (meta keyword, questions about documentation/code/..., tasks to remember to test under a certain configuration, etc.). These issues make it harder to switch from bugzilla to bugzilla (or to any other issue tracker). By implementing a standardized system for identifying these items we would make not only the task of using multiple systems easier, but also the task of migrating data between these systems easier. In my opinion the Milestone field is a mistake. I think it would have been superior to use special milestone bugs and dependencies to make it very simple to see how multiple bugs are related. A milestone bug would also have the added benefit of having a deadline. From gerv at mozilla.org Thu Jan 18 22:21:10 2007 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 18 Jan 2007 22:21:10 +0000 Subject: show_bug.cgi display layout In-Reply-To: <45AFF068.90103@gmail.com> References: <45A4F714.3080205@gmail.com> <45AB95A8.9030402@gmail.com> <45ABA805.1050304@gmail.com> <45ABB077.60100@gmail.com> <45ABB516.80003@amd.com> <45ABBD91.7010800@gmail.com> <45AC02DC.8070009@lehigh.edu> <45AC0495.2060803@gmail.com> <45AC08B1.90501@lehigh.edu> <45AC0A01.6000401@gmail.com> <45AC239E.6060207@gmail.com> <45AFDD38.5040105@mozilla.org> <45AFF068.90103@gmail.com> Message-ID: <45AFF2D6.1060507@mozilla.org> Bill Barry wrote: > Priorities describe what a *programmer* and/or his/her superiors feel > should be done, and a general order of how to do them. Right. > While an enhancement does not have a severity in the usual sense of the > word (the impact that the defect has in its existing form as the report > is filed), the aspects of implementing an enhancement (a modification of > the system to allow a new use or better use of some system aspect) do > indeed have an impact on the system, and hence a risk assessment > including the details of how much an impact that enhancement will cause > justifies the severity of an enhancement. Severity is not the result of a risk assessment on the impact of a fix. It's a measurement of how much of a problem the bug is for how many users. If the thing in question is a problem for users in that sense, then fixing it isn't an enhancement. > Another aspect of bug 9412 is that there are bugs in bugzilla that are > neither defects (on the product itself) nor enhancements. Such as what? And is Bugzilla actually appropriate for tracking them? > In my opinion the Milestone field is a mistake. I think it would have > been superior to use special milestone bugs and dependencies to make it > very simple to see how multiple bugs are related. A milestone bug would > also have the added benefit of having a deadline. You could implement any bug grouping in terms of dependencies - we could eliminate the OS field and have an "OS/2" tracking bug on which all OS/2 bugs depend. You would need to argue why Milestone is uniquely suitable for abolishment and replacement in this way. It would certainly make searching harder to do. How do you search for bugs fixed in the last three releases? "Depends on bug 12342, 16536 and 19354". Hang on - or was it 19345? :-) Gerv From lpsolit at gmail.com Thu Jan 18 22:22:22 2007 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Thu, 18 Jan 2007 23:22:22 +0100 Subject: show_bug.cgi display layout In-Reply-To: <45AFF068.90103@gmail.com> References: <45A4F714.3080205@gmail.com> <45AB95A8.9030402@gmail.com> <45ABA805.1050304@gmail.com> <45ABB077.60100@gmail.com> <45ABB516.80003@amd.com> <45ABBD91.7010800@gmail.com> <45AC02DC.8070009@lehigh.edu> <45AC0495.2060803@gmail.com> <45AC08B1.90501@lehigh.edu> <45AC0A01.6000401@gmail.com> <45AC239E.6060207@gmail.com> <45AFDD38.5040105@mozilla.org> <45AFF068.90103@gmail.com> Message-ID: <45AFF31E.8080504@gmail.com> > In my opinion the Milestone field is a mistake. I think it would have > been superior to use special milestone bugs and dependencies to make it > very simple to see how multiple bugs are related. A milestone bug would > also have the added benefit of having a deadline. Milestones *are* useful, much more than all these meta bugs which are often created because some developer or user is interested in keeping track on some specific feature and wants a way to quickly find them. But now that we can tag bugs, this makes meta bugs pretty obsolete in most cases. Moreover, you always have to remember to block the "milestone" bug, and more important, to remember what its ID or alias is. Pretty annoying and prone to errors. About deadlines, you can add milestones such as "2007-01-18" if you want to. LpSolit From dwilliss at microimages.com Thu Jan 18 22:46:04 2007 From: dwilliss at microimages.com (Dave Williss) Date: Thu, 18 Jan 2007 16:46:04 -0600 Subject: show_bug.cgi display layout In-Reply-To: <45AFF068.90103@gmail.com> References: <45A4F714.3080205@gmail.com> <45AB95A8.9030402@gmail.com> <45ABA805.1050304@gmail.com> <45ABB077.60100@gmail.com> <45ABB516.80003@amd.com> <45ABBD91.7010800@gmail.com> <45AC02DC.8070009@lehigh.edu> <45AC0495.2060803@gmail.com> <45AC08B1.90501@lehigh.edu> <45AC0A01.6000401@gmail.com> <45AC239E.6060207@gmail.com> <45AFDD38.5040105@mozilla.org> <45AFF068.90103@gmail.com> Message-ID: <45AFF8AC.8050504@microimages.com> Bill Barry wrote: > In my opinion the Milestone field is a mistake. I think it would have > been superior to use special milestone bugs and dependencies to make > it very simple to see how multiple bugs are related. A milestone bug > would also have the added benefit of having a deadline. We (at my company) use the Target Milestone for two different things: * To indicate what version a bug was fixed in. For example, there may be a bug that was reported in version 1.0 but nobody got around to fixing it until 2.1. In this sense, the target is never set until the bug is resolved. We also have a script that runs every night via cron to check the database and annoy people who forget to set the target milestone when resolving bugs. If I felt like customizing our templates locally, I'd rename it "Resolved In:" * To indicate what version we'd _like_ something fixed, which is what I believe the field was actually intended for. For that, I agree with Bill that a special Milestone bug dependency would be better. We also use the Status Whiteboard to keep track of clients who need to be notified via email when something is fixed. We can't use the cc list for this because 1) our bugzilla is on a private LAN with no connection to the internet for security reasons. 2) If we add all our clients as users, they'd show up not only on the CC list but on the Assigned To and QC Contact lists. We'd really like a way to add a custom field that worked like the CC list but pulled from a different user table (actually an SQL query from the actual client database would be _really_ nice) and just didn't try to send out the email. However, now I'm digressing into wish-list sorts of things. From myk at mozilla.org Thu Jan 18 22:58:03 2007 From: myk at mozilla.org (Myk Melez) Date: Thu, 18 Jan 2007 14:58:03 -0800 Subject: show_bug.cgi display layout In-Reply-To: <45AFDE29.4080507@mozilla.org> References: <45A4F714.3080205@gmail.com> <45AB95A8.9030402@gmail.com> <45ABA805.1050304@gmail.com> <45ABB077.60100@gmail.com> <45ABB516.80003@amd.com> <45ABBD91.7010800@gmail.com> <45AC02DC.8070009@lehigh.edu> <45AC0495.2060803@gmail.com> <45AC1DC8.5010802@amd.com> <45AC2736.9080704@gmail.com> <45AC9EED.1010707@gmail.com> <45ACD538.9060409@gmail.com> <45AFDE29.4080507@mozilla.org> Message-ID: <45AFFB7B.8000709@mozilla.org> Gervase Markham wrote: > Bill Barry wrote: >> We already do go to other pages to see the activity log and votes > > Yes, but they are very infrequently viewed. I can count the number of > times I've looked at either in the past year on the fingers of one hand. I can't, for activity anyway. I look at it regularly, especially when triaging bugs. But maybe I'm an exceptional case. In any case, I'm not particularly interested in where the links are, but I would like the actual information to be mixed in with the comments, since it often provides context for those comments. -myk From vseerror at Lehigh.EDU Fri Jan 19 03:08:50 2007 From: vseerror at Lehigh.EDU (Wayne Mery) Date: Thu, 18 Jan 2007 22:08:50 -0500 Subject: show_bug.cgi display layout In-Reply-To: <45AFFB7B.8000709@mozilla.org> References: <45A4F714.3080205@gmail.com> <45AB95A8.9030402@gmail.com> <45ABA805.1050304@gmail.com> <45ABB077.60100@gmail.com> <45ABB516.80003@amd.com> <45ABBD91.7010800@gmail.com> <45AC02DC.8070009@lehigh.edu> <45AC0495.2060803@gmail.com> <45AC1DC8.5010802@amd.com> <45AC2736.9080704@gmail.com> <45AC9EED.1010707@gmail.com> <45ACD538.9060409@gmail.com> <45AFDE29.4080507@mozilla.org> <45AFFB7B.8000709@mozilla.org> Message-ID: <45B03642.7010503@lehigh.edu> On 1/18/2007 5:58 PM, Myk Melez wrote: > Gervase Markham wrote: >> Bill Barry wrote: >>> We already do go to other pages to see the activity log and votes >> >> Yes, but they are very infrequently viewed. I can count the number of >> times I've looked at either in the past year on the fingers of one hand. > I can't, for activity anyway. I look at it regularly, especially when > triaging bugs. But maybe I'm an exceptional case. > > In any case, I'm not particularly interested in where the links are, but > I would like the actual information to be mixed in with the comments, > since it often provides context for those comments. > > -myk from a triage standpoint, my use of activity is ~10-20%, which definitely is more than two hands, a nose and two feet :) - the reason being you often want to see the reason/description of why a change (summary, dependency, status etc) was made. For a developer or manager I have not doubt it's close to zero. From luis at tieguy.org Fri Jan 19 03:14:14 2007 From: luis at tieguy.org (Luis Villa) Date: Thu, 18 Jan 2007 22:14:14 -0500 Subject: show_bug.cgi display layout In-Reply-To: <45B03642.7010503@lehigh.edu> References: <45A4F714.3080205@gmail.com> <45AC02DC.8070009@lehigh.edu> <45AC0495.2060803@gmail.com> <45AC1DC8.5010802@amd.com> <45AC2736.9080704@gmail.com> <45AC9EED.1010707@gmail.com> <45ACD538.9060409@gmail.com> <45AFDE29.4080507@mozilla.org> <45AFFB7B.8000709@mozilla.org> <45B03642.7010503@lehigh.edu> Message-ID: <2cb10c440701181914o466d0663q6c161e5c91b00334@mail.gmail.com> On 1/18/07, Wayne Mery wrote: > On 1/18/2007 5:58 PM, Myk Melez wrote: > > Gervase Markham wrote: > >> Bill Barry wrote: > >>> We already do go to other pages to see the activity log and votes > >> > >> Yes, but they are very infrequently viewed. I can count the number of > >> times I've looked at either in the past year on the fingers of one hand. > > I can't, for activity anyway. I look at it regularly, especially when > > triaging bugs. But maybe I'm an exceptional case. > > > > In any case, I'm not particularly interested in where the links are, but > > I would like the actual information to be mixed in with the comments, > > since it often provides context for those comments. > > > > -myk > > from a triage standpoint, my use of activity is ~10-20%, which > definitely is more than two hands, a nose and two feet :) - the reason > being you often want to see the reason/description of why a change > (summary, dependency, status etc) was made. > > For a developer or manager I have not doubt it's close to zero. A good manager uses it all the time, for the same reason you give for a triager's use of it. I'd venture to say a good developer should use it too, since a good developer should understand why something is high or low priority, and who made it that way, but that may be too much to ask ;) Luis (once a manager, though admittedly not a good one ;) From after.fallout at gmail.com Fri Jan 19 14:37:02 2007 From: after.fallout at gmail.com (Bill Barry) Date: Fri, 19 Jan 2007 09:37:02 -0500 Subject: show_bug.cgi display layout In-Reply-To: <45AFF2D6.1060507@mozilla.org> References: <45A4F714.3080205@gmail.com> <45AB95A8.9030402@gmail.com> <45ABA805.1050304@gmail.com> <45ABB077.60100@gmail.com> <45ABB516.80003@amd.com> <45ABBD91.7010800@gmail.com> <45AC02DC.8070009@lehigh.edu> <45AC0495.2060803@gmail.com> <45AC08B1.90501@lehigh.edu> <45AC0A01.6000401@gmail.com> <45AC239E.6060207@gmail.com> <45AFDD38.5040105@mozilla.org> <45AFF068.90103@gmail.com> <45AFF2D6.1060507@mozilla.org> Message-ID: <45B0D78E.5080808@gmail.com> > Severity is not the result of a risk assessment on the impact of a > fix. It's a measurement of how much of a problem the bug is for how > many users. If the thing in question is a problem for users in that > sense, then fixing it isn't an enhancement. If it is a change that allows a user to use the system in a way not intended by the original requirements document, then it needs design decisions to be made about it (as opposed to just giving it to a developer to fix it the way the bug describes) and is an enhancement. Another difference is that while a bug decribes a problem with some known (at the time of writing the bug, perhaps not before) test case. An enhancement on the other hand requires new test cases. > >> Another aspect of bug 9412 is that there are bugs in bugzilla that >> are neither defects (on the product itself) nor enhancements. > > Such as what? And is Bugzilla actually appropriate for tracking them? As that bug describes: https://bugzilla.mozilla.org/show_bug.cgi?id=9412#c37 > >> In my opinion the Milestone field is a mistake. I think it would have >> been superior to use special milestone bugs and dependencies to make >> it very simple to see how multiple bugs are related. A milestone bug >> would also have the added benefit of having a deadline. > > You could implement any bug grouping in terms of dependencies - we > could eliminate the OS field and have an "OS/2" tracking bug on which > all OS/2 bugs depend. You would need to argue why Milestone is > uniquely suitable for abolishment and replacement in this way. I don't like, nor do I think OS and Hardware are particularly useful either. They allow you to find more specific test cases, and make triaging easier, but as single select fields their usefulness is limited. I think it would work much better these were right underneath the comment section and put in a label "Affects" which would then put in the comments "Affects OSxxxx on Hw####" as the last bit of text in each comment where a user selects something from the lists. I argue that they don't make searching for bugs any easier because I see it happen where people cannot find duplicate bugs because they consistently search for "Windows XP / All" or "OS X / Macintosh" when they are looking for a bug that affects all systems, or has only ever before been seen in "Linux / PC" Milestone is uniquely suited (compared to hardware and OS) because it is truly a single select field (rather than a field that due to another long standing bug in Bugzilla only allows one value: https://bugzilla.mozilla.org/show_bug.cgi?id=9468). Milestone is not unique compared to Version and if it was designed to be the version fixed in (as Dave said in another reply on this thread) it would be very useful (but again both could very easily be replaced with dependencies on specially typed bugs). > > It would certainly make searching harder to do. How do you search for > bugs fixed in the last three releases? "Depends on bug 12342, 16536 > and 19354". Hang on - or was it 19345? :-) Aliases, we already have them to make finding special bugs easier, why not use them: blocks "next_rel" blocks "future" blocks "Bugzilla 3.2" depends on "reflow" depends on "gecko_units" depends on "Bugzilla 2.10" and blocks "Bugzilla 2.18" From kevin.benton at amd.com Fri Jan 19 16:49:25 2007 From: kevin.benton at amd.com (Kevin Benton) Date: Fri, 19 Jan 2007 09:49:25 -0700 Subject: show_bug.cgi display layout In-Reply-To: <45B0D78E.5080808@gmail.com> References: <45A4F714.3080205@gmail.com> <45AB95A8.9030402@gmail.com> <45ABA805.1050304@gmail.com> <45ABB077.60100@gmail.com> <45ABB516.80003@amd.com> <45ABBD91.7010800@gmail.com> <45AC02DC.8070009@lehigh.edu> <45AC0495.2060803@gmail.com> <45AC08B1.90501@lehigh.edu> <45AC0A01.6000401@gmail.com> <45AC239E.6060207@gmail.com> <45AFDD38.5040105@mozilla.org> <45AFF068.90103@gmail.com> <45AFF2D6.1060507@mozilla.org> <45B0D78E.5080808@gmail.com> Message-ID: <45B0F695.7070805@amd.com> Bill Barry wrote: > >> Severity is not the result of a risk assessment on the impact of a >> fix. It's a measurement of how much of a problem the bug is for how >> many users. If the thing in question is a problem for users in that >> sense, then fixing it isn't an enhancement. > If it is a change that allows a user to use the system in a way not > intended by the original requirements document, then it needs design > decisions to be made about it (as opposed to just giving it to a > developer to fix it the way the bug describes) and is an enhancement. > Since the severities are now customizable, it's possible to set your own definitions and include things like Enhancement is Business Critical, Enhancement is Needed, Enhancement is Wanted, etc... That would allow your customer to specify how important the enhancement request was to them. > Another difference is that while a bug decribes a problem with some > known (at the time of writing the bug, perhaps not before) test case. > An enhancement on the other hand requires new test cases. A well-written enhancement request includes an adequate specification, thus providing a minimal set of test cases. Many times, however, when an enhancement request is made, there isn't enough information available to make a good (set of) test case(s). As I see it, determining good test cases for an enhancement request requires that it's feasible to write the enhancement first, then if so, write the test cases. >> >>> Another aspect of bug 9412 is that there are bugs in bugzilla that >>> are neither defects (on the product itself) nor enhancements. >> >> Such as what? And is Bugzilla actually appropriate for tracking them? > As that bug describes: > https://bugzilla.mozilla.org/show_bug.cgi?id=9412#c37 > ... errata, documentation tracking issues, status trackers, ... >> >>> In my opinion the Milestone field is a mistake. I think it would >>> have been superior to use special milestone bugs and dependencies to >>> make it very simple to see how multiple bugs are related. A >>> milestone bug would also have the added benefit of having a deadline. >> >> You could implement any bug grouping in terms of dependencies - we >> could eliminate the OS field and have an "OS/2" tracking bug on which >> all OS/2 bugs depend. You would need to argue why Milestone is >> uniquely suitable for abolishment and replacement in this way. > I don't like, nor do I think OS and Hardware are particularly useful > either. They allow you to find more specific test cases, and make > triaging easier, but as single select fields their usefulness is > limited. I think it would work much better these were right underneath > the comment section and put in a label "Affects" which would then put > in the comments "Affects OSxxxx on Hw####" as the last bit of text in > each comment where a user selects something from the lists. I argue > that they don't make searching for bugs any easier because I see it > happen where people cannot find duplicate bugs because they > consistently search for "Windows XP / All" or "OS X / Macintosh" when > they are looking for a bug that affects all systems, or has only ever > before been seen in "Linux / PC" > We agree to disagree then. When your QA team requires that a bug is filed per impacted Hardware & OS so that their work is tracked in each bug separately, then OS and Hardware as single-select fields are very meaningful. There's nothing wrong with adding an OS or Hardware label that others agree includes a group of platforms. > Milestone is uniquely suited (compared to hardware and OS) because it > is truly a single select field (rather than a field that due to > another long standing bug in Bugzilla only allows one value: > https://bugzilla.mozilla.org/show_bug.cgi?id=9468). Milestone is not > unique compared to Version and if it was designed to be the version > fixed in (as Dave said in another reply on this thread) it would be > very useful (but again both could very easily be replaced with > dependencies on specially typed bugs). I agree that it seems that Milestone could be better if it were directly tied to the versions table. I also agree that there are times when it's useful to track found_in_rev versus fixed_in_rev versus planned_for_rev. I've been side-tracked from finishing up my impact table, however, one of my implementations in that update is to incorporate versions at the component level. Here, we actually track all three of these version fields. Milestones has been changed to planned_for_rev. Version has been changed to found_in_rev. A new field (fixed_in_rev) was added so we know exactly when a version was fixed, not just when was it originally planned for. We're considering incorporating also_in_revs so we know when a fix is applied to a number of versions. >> >> It would certainly make searching harder to do. How do you search for >> bugs fixed in the last three releases? "Depends on bug 12342, 16536 >> and 19354". Hang on - or was it 19345? :-) > Aliases, we already have them to make finding special bugs easier, why > not use them: > blocks "next_rel" > blocks "future" > blocks "Bugzilla 3.2" > depends on "reflow" > depends on "gecko_units" > depends on "Bugzilla 2.10" and blocks "Bugzilla 2.18" Because you can only have one alias pointing to a single bug in the entire DB. Using a milestone, keyword or flag makes more sense. -- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: AMDLogo.png Type: image/png Size: 1784 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: kevin.benton.vcf Type: text/x-vcard Size: 915 bytes Desc: not available URL: From after.fallout at gmail.com Sat Jan 20 13:09:39 2007 From: after.fallout at gmail.com (bill barry) Date: Sat, 20 Jan 2007 08:09:39 -0500 Subject: show_bug.cgi display layout In-Reply-To: <45B0F695.7070805@amd.com> References: <45A4F714.3080205@gmail.com> <45AC0495.2060803@gmail.com> <45AC08B1.90501@lehigh.edu> <45AC0A01.6000401@gmail.com> <45AC239E.6060207@gmail.com> <45AFDD38.5040105@mozilla.org> <45AFF068.90103@gmail.com> <45AFF2D6.1060507@mozilla.org> <45B0D78E.5080808@gmail.com> <45B0F695.7070805@amd.com> Message-ID: > It would certainly make searching harder to do. How do you search for bugs > fixed in the last three releases? "Depends on bug 12342, 16536 and 19354". > Hang on - or was it 19345? :-) > > Aliases, we already have them to make finding special bugs easier, why not > use them: > blocks "next_rel" > blocks "future" > blocks "Bugzilla 3.2" > depends on "reflow" > depends on "gecko_units" > depends on "Bugzilla 2.10" and blocks "Bugzilla 2.18" > > > Because you can only have one alias pointing to a single bug in the entire > DB. Using a milestone, keyword or flag makes more sense. > Why would you need an alias to point to more than one bug? There should only be one bug for a release of a particular product. I am not sure I grasp your point. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerv at mozilla.org Sat Jan 20 16:33:05 2007 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 20 Jan 2007 16:33:05 +0000 Subject: show_bug.cgi display layout In-Reply-To: <45B0F695.7070805@amd.com> References: <45A4F714.3080205@gmail.com> <45AB95A8.9030402@gmail.com> <45ABA805.1050304@gmail.com> <45ABB077.60100@gmail.com> <45ABB516.80003@amd.com> <45ABBD91.7010800@gmail.com> <45AC02DC.8070009@lehigh.edu> <45AC0495.2060803@gmail.com> <45AC08B1.90501@lehigh.edu> <45AC0A01.6000401@gmail.com> <45AC239E.6060207@gmail.com> <45AFDD38.5040105@mozilla.org> <45AFF068.90103@gmail.com> <45AFF2D6.1060507@mozilla.org> <45B0D78E.5080808@gmail.com> <45B0F695.7070805@amd.com> Message-ID: <45B24441.7030908@mozilla.org> Kevin Benton wrote: > Since the severities are now customizable, it's possible to set your own > definitions and include things like Enhancement is Business Critical, > Enhancement is Needed, Enhancement is Wanted, etc... But those are not severities, they are priorities (which are also customisable.) "Business Critical", for example, is clearly a priority, not a severity. >>> Such as what? And is Bugzilla actually appropriate for tracking them? >> As that bug describes: >> https://bugzilla.mozilla.org/show_bug.cgi?id=9412#c37 >> > ... errata, documentation tracking issues, status trackers, ... Errata is another name for bugs. Documentation tracking issues is a euphemism for bugs in the documentation. Bugzilla tracks these things fine today for loads of people. Gerv From Guillaume.Rousse at inria.fr Sun Jan 21 19:47:25 2007 From: Guillaume.Rousse at inria.fr (Guillaume Rousse) Date: Sun, 21 Jan 2007 20:47:25 +0100 Subject: Difficulties to interface with bugzilla API Message-ID: <45B3C34D.9090006@inria.fr> Hello. I'm interfacing with bugzilla from another perl application. The interface code is available at http://www.zarb.org/cgi-bin/viewvc.cgi/soft/core/trunk/lib/Youri/Bugzilla.pm?root=youri&view=markup They are some issues that make me thinks than current Bugzilla API is quite misadapted to a general usage scenario, meaning not from bugzilla CGI or mod_perl handlers. First, loading Bugzilla module, the main API entry point, immediatly triggers environment cleanup, such as deleting PATH, for instance. This may be adequate from CGI programs, but for trusted environment, this has heavy side-effects. I had to localize ENV for avoiding it. Second, the END block at the end of this module close database connection. As END block are processed LIFO, this means calling code has no chance to finish any live statement handle before it occurs. I had to avoid using Bugzilla::dbh, and call Bugzilla::DB::connect directly in order to avoid it. I could have faked mod_perl environment also, but this has additional side-effect than make this trick unusable. From mkanat at bugzilla.org Sun Jan 21 21:17:55 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sun, 21 Jan 2007 13:17:55 -0800 Subject: Difficulties to interface with bugzilla API In-Reply-To: <45B3C34D.9090006@inria.fr> References: <45B3C34D.9090006@inria.fr> Message-ID: <20070121211756.D1C2618171@help.trusthosting.net> On Sun, 21 Jan 2007 20:47:25 +0100 Guillaume Rousse wrote: > I'm interfacing with bugzilla from another perl application. The > interface code is available at > http://www.zarb.org/cgi-bin/viewvc.cgi/soft/core/trunk/lib/Youri/Bugzilla.pm?root=youri&view=markup The problem that you're experiencing is that the Bugzilla:: namespace is not an API. It's just our internal libraries for Bugzilla. The API for Bugzilla is the XML-RPC webservice. And if you want to write an extension, the thing to do is to use the Bugzilla::Hook mechanism. You can also hook templates, and the Parameters are pluggable. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From jake at bugzilla.org Sun Jan 21 23:58:20 2007 From: jake at bugzilla.org (Jake) Date: Sun, 21 Jan 2007 18:58:20 -0500 Subject: Minutes of the last Bugzilla meeting In-Reply-To: <45A57440.2090908@mozilla.org> References: <45A4F714.3080205@gmail.com> <45A57440.2090908@mozilla.org> Message-ID: <45B3FE1C.8050809@bugzilla.org> Gervase Markham wrote: > Fr?d?ric Buclin wrote: >> Also, users would probably hate to have 2 separate accounts to report >> bugs. > > ...then we fix it so we can use a separate database for logins, or use > LDAP. Or OpenID :) From Guillaume.Rousse at inria.fr Tue Jan 23 10:46:52 2007 From: Guillaume.Rousse at inria.fr (Guillaume Rousse) Date: Tue, 23 Jan 2007 11:46:52 +0100 Subject: Difficulties to interface with bugzilla API In-Reply-To: <20070121211756.D1C2618171@help.trusthosting.net> References: <45B3C34D.9090006@inria.fr> <20070121211756.D1C2618171@help.trusthosting.net> Message-ID: <45B5E79C.40206@inria.fr> Max Kanat-Alexander wrote: > On Sun, 21 Jan 2007 20:47:25 +0100 Guillaume Rousse > wrote: >> I'm interfacing with bugzilla from another perl application. The >> interface code is available at >> http://www.zarb.org/cgi-bin/viewvc.cgi/soft/core/trunk/lib/Youri/Bugzilla.pm?root=youri&view=markup > > The problem that you're experiencing is that the Bugzilla:: > namespace is not an API. It's just our internal libraries for Bugzilla. > > The API for Bugzilla is the XML-RPC webservice. For a local interaction in the same langage, involving low-level database access, that's not really suited... > And if you want > to write an extension, the thing to do is to use the Bugzilla::Hook > mechanism. You can also hook templates, and the Parameters are > pluggable. I don't want to call code from bugzilla, I want to access bugzilla database, as all command lines tools shipped with bugzilla do. Current implementation enforce some policies in a way that make them mandatory, instead of just being configurable with proper defaults. Admin scripts such as whineatnews.pl, for instance, don't have taint mode activated, because they don't need it. Why should them face cgi-oriented measures such as ENV cleaning, for instance ? From mkanat at bugzilla.org Tue Jan 23 18:39:52 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 23 Jan 2007 10:39:52 -0800 Subject: Difficulties to interface with bugzilla API In-Reply-To: <45B5E79C.40206@inria.fr> References: <45B3C34D.9090006@inria.fr> <20070121211756.D1C2618171@help.trusthosting.net> <45B5E79C.40206@inria.fr> Message-ID: <20070123183952.5A45218171@help.trusthosting.net> On Tue, 23 Jan 2007 11:46:52 +0100 Guillaume Rousse wrote: > Max Kanat-Alexander wrote: > > On Sun, 21 Jan 2007 20:47:25 +0100 Guillaume Rousse > > wrote: > Admin scripts such as whineatnews.pl, for instance, don't have taint > mode activated, because they don't need it. Why should them face > cgi-oriented measures such as ENV cleaning, for instance ? I agree with you there--they shouldn't. In fact, I was going to file a bug on that one day, so that we didn't have to keep fixing $ENV for non-tainted scripts. However, Bugzilla.pm, as useful as it is, is intended to be used by Bugzilla code only. And it's certainly not intended to be subclassed. :-) If you could show us an example extension (the whole code of it, somewhere online) that you feel could benefit from certain enhancements to Bugzilla, that would be helpful in our seeing how people want to write plugins. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From luis.villa at gmail.com Wed Jan 24 16:41:25 2007 From: luis.villa at gmail.com (Luis Villa) Date: Wed, 24 Jan 2007 11:41:25 -0500 Subject: Minutes of the last Bugzilla meeting In-Reply-To: <45B3FE1C.8050809@bugzilla.org> References: <45A4F714.3080205@gmail.com> <45A57440.2090908@mozilla.org> <45B3FE1C.8050809@bugzilla.org> Message-ID: <2cb10c440701240841s1305a9b7odce5e76950785202@mail.gmail.com> On 1/21/07, Jake wrote: > Gervase Markham wrote: > > Fr?d?ric Buclin wrote: > >> Also, users would probably hate to have 2 separate accounts to report > >> bugs. > > > > ...then we fix it so we can use a separate database for logins, or use > > LDAP. > > > Or OpenID :) Having finally created an openid account, I've seen the light and heartily second this request. Should make all of our lives much easier when it is more widely deployed. Luis From kevin.benton at amd.com Wed Jan 24 17:03:05 2007 From: kevin.benton at amd.com (Kevin Benton) Date: Wed, 24 Jan 2007 10:03:05 -0700 Subject: Komodo IDE 4 released Message-ID: <45B79149.2010500@amd.com> Hi all, For those that are interested, Komodo IDE 4.0 was released yesterday. The new free Komodo Edit 4.0 is still in beta form (b5) but is expected to be released soon. Komodo Edit is based on Komodo IDE and is not as powerful as the old Personal License, but it's completely free (i.e. no "for non-commercial use only" license restriction). Komodo IDE is the full-featured professional license version of Komodo. Both these products can be found at http://www.activestate.com/ Sorry for the spam, but I know a lot of the developers here use Komodo for development. Kevin -- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: AMDLogo.png Type: image/png Size: 1784 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: kevin.benton.vcf Type: text/x-vcard Size: 892 bytes Desc: not available URL: From justdave at bugzilla.org Thu Jan 25 06:38:36 2007 From: justdave at bugzilla.org (David Miller) Date: Thu, 25 Jan 2007 01:38:36 -0500 Subject: twice-daily synced git repo for Bugzilla now available Message-ID: <45B8506C.9020505@bugzilla.org> -------- Original Message -------- Subject: Re: [justdave at bugzilla.org: Re: Bugzilla CVS repo copy?] Date: Wed, 24 Jan 2007 23:02:31 -0500 From: Kristian H?gsberg To: Daniel Stone , justdave at bugzilla.org References: <20070124232040.GL1140 at fooishbar.org> All done, gitweb here: http://gitweb.freedesktop.org/?p=users/krh/bugzilla.git;a=summary and clone it using $ git clone git://people.freedesktop.org/~krh/bugzilla.git Dave, feel free to pass this on to the bugzilla developer community. I've set up a cron job to rsync the cvs repo and incrementally import into the git mirror two times daily. A full git clone of bugzilla takes up $ du -hs bugzilla 23M bugzilla of which all the history data is $ du -hs bugzilla/.git 18M bugzilla/.git compared with: $ du -hs bugzilla-cvs-repo/ 51M have fun, Kristian On 1/24/07, Daniel Stone wrote: > Cheers, dude. > > ----- Forwarded message from David Miller ----- > > Message-ID: <45B71DD2.2060804 at bugzilla.org> > Date: Wed, 24 Jan 2007 03:50:26 -0500 > From: David Miller > To: Daniel Stone > Subject: Re: Bugzilla CVS repo copy? > > Daniel Stone wrote on 1/24/07 1:39 AM: > > Hi Dave, > > We're using Bugzilla at freedesktop.org, and often need to make our own > > local modifications and hacks. We'd like to do this in a more > > structured way (one that CVS does not allow us), so we're trying to get > > it imported into git. We have scripts that can do this just fine -- > > we've imported all of X, this isn't another Canonical. ;) > > > > However, to do this we need a complete repo copy. Is there any way of > > getting rsync access or similar to the master repo, or daily tarballs or > > something? > > Yep, it's available via public rsync from > rsync://cvs-mirror.mozilla.org/mozilla/mozilla/webtools/bugzilla > > or just rsync://cvs-mirror.mozilla.org/mozilla if you need the CVSROOT > and everything, but that'll also get you the entirety of mozilla, > firefox, thunderbird, seamonkey, camino, etc. > > -- > Dave Miller http://www.justdave.net/ > System Administrator, Mozilla Corporation http://www.mozilla.com/ > Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ > > ----- End forwarded message ----- > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.3 (GNU/Linux) > > iD8DBQFFt+nHRkzMgPKxYGwRAmB7AJ4qz6Q0QG1aA6PbGcmwWuSm5xJiYgCfTW9g > TCj75TPlEud/oY91H48P4mg= > =M37S > -----END PGP SIGNATURE----- > > > -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/