From lpsolit at gmail.com Mon Jul 3 09:43:49 2006 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Mon, 03 Jul 2006 11:43:49 +0200 Subject: Bugzilla meeting postponed Message-ID: <44A8E6D5.2070803@gmail.com> Due to the Independence Day, which is a federal holiday in the US, we will postpone our Bugzilla meeting for a week, i.e. we will meet on Tuesday, July 11 at 18:00 GMT (11:00 PDT) instead of tomorrow. LpSolit From mkanat at bugzilla.org Tue Jul 4 01:16:13 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 03 Jul 2006 18:16:13 -0700 Subject: Preference Bloat Message-ID: <1151975773.4290.19.camel@localhost.localdomain> I notice that we have a lot of preferences, now (User Settings). Some of them will never be used by 90% of users. Some of them will be used more frequently. I don't want the Preferences page to start looking like our old Parameters page did. Just be careful about adding new Preferences. Just because we can, doesn't mean we should. Also, perhaps some of them should ship as disabled by default, to clean up the default UI. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From dixson_zhou at suminet-sh.com Tue Jul 4 04:31:29 2006 From: dixson_zhou at suminet-sh.com (Dixson Zhou) Date: Tue, 04 Jul 2006 12:31:29 +0800 Subject: =?GB2312?B?o6jO3tb3zOKjqQ==?= Message-ID: <44A9EF21.7010602@suminet-sh.com> unregister-pattern-allmatching ALL -- Best Regards! Dixson Zhou From skandagatla at URBANSCIENCE.com Thu Jul 6 18:33:20 2006 From: skandagatla at URBANSCIENCE.com (Kandagatla, Satya) Date: Thu, 6 Jul 2006 14:33:20 -0400 Subject: Question!!!!!!!!!! In-Reply-To: <200607061829.k66ITYKG019894@sheridan.syndicomm.com> Message-ID: <6D5132237BA50F45A268A3694E22A0AA0544BE8E@deturbansci08.urbanscience.net> Hello, I am not sure whether I am posting the question at the right place or not but I thought it would be worth trying: We have the following development environment at our work place: Microsoft .Net Framework Winforms/Webforms (Visual Studio.Net) Webservers have Microsoft Windows 2003 as Server OS Database is SQL Server. So my question is, can we install BugZilla successfully and use it as our defect tracking system? Thanks in advance. Satya -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkanat at bugzilla.org Thu Jul 6 19:35:01 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 06 Jul 2006 12:35:01 -0700 Subject: Question!!!!!!!!!! In-Reply-To: <6D5132237BA50F45A268A3694E22A0AA0544BE8E@deturbansci08.urbanscience.net> References: <6D5132237BA50F45A268A3694E22A0AA0544BE8E@deturbansci08.urbanscience.net> Message-ID: <1152214502.2440.11.camel@localhost.localdomain> On Thu, 2006-07-06 at 14:33 -0400, Kandagatla, Satya wrote: > I am not sure whether I am posting the question at the right place or > not but I thought it would be worth trying: [snip] Hi Satya. The correct place is the bugzilla-support list. You can see details here: http://www.bugzilla.org/support/ -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From mkanat at bugzilla.org Thu Jul 6 19:54:37 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 06 Jul 2006 12:54:37 -0700 Subject: LDAP bug cleanup Message-ID: <1152215678.2440.14.camel@localhost.localdomain> Hey hey. I cleaned up all of the various LDAP bugs today. Now all LDAP bugs start with [LDAP] in the summary, and all of the ones that are still open are actually valid bugs or enhancements. If you file a new LDAP bug, just put [LDAP] on the front of its summary. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From vladd at bugzilla.org Thu Jul 6 20:06:53 2006 From: vladd at bugzilla.org (Vlad Dascalu) Date: Thu, 6 Jul 2006 13:06:53 -0700 (PDT) Subject: Question!!!!!!!!!! In-Reply-To: <6D5132237BA50F45A268A3694E22A0AA0544BE8E@deturbansci08.urbanscience.net> References: <200607061829.k66ITYKG019894@sheridan.syndicomm.com> <6D5132237BA50F45A268A3694E22A0AA0544BE8E@deturbansci08.urbanscience.net> Message-ID: <1147.81.12.219.19.1152216413.squirrel@www.syndicomm.com> Hi, We don't support SQL Server, so you'll need to install MySQL or Pgsql in addition to what you have. Otherwise there's no problem. Vlad > Hello, > > I am not sure whether I am posting the question at the right place or > not but I thought it would be worth trying: > > We have the following development environment at our work place: > > Microsoft .Net Framework > > Winforms/Webforms (Visual Studio.Net) > > Webservers have Microsoft Windows 2003 as Server OS > > Database is SQL Server. > > So my question is, can we install BugZilla successfully and use it as > our defect tracking system? > > Thanks in advance. > > Satya From gerv at mozilla.org Thu Jul 6 20:25:41 2006 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 06 Jul 2006 21:25:41 +0100 Subject: LDAP bug cleanup In-Reply-To: <1152215678.2440.14.camel@localhost.localdomain> References: <1152215678.2440.14.camel@localhost.localdomain> Message-ID: <44AD71C5.7070500@mozilla.org> Max Kanat-Alexander wrote: > Hey hey. I cleaned up all of the various LDAP bugs today. Now all LDAP > bugs start with [LDAP] in the summary, and all of the ones that are > still open are actually valid bugs or enhancements. > > If you file a new LDAP bug, just put [LDAP] on the front of its > summary. Isn't this sort of thing why we have components? :-) Gerv From getpat at gmail.com Thu Jul 6 18:50:52 2006 From: getpat at gmail.com (Patrick Bishop) Date: Thu, 6 Jul 2006 13:50:52 -0500 Subject: Question!!!!!!!!!! In-Reply-To: <6D5132237BA50F45A268A3694E22A0AA0544BE8E@deturbansci08.urbanscience.net> References: <200607061829.k66ITYKG019894@sheridan.syndicomm.com> <6D5132237BA50F45A268A3694E22A0AA0544BE8E@deturbansci08.urbanscience.net> Message-ID: <23abb3e0607061150l43fb937ga55fe7427be364a6@mail.gmail.com> Satya: No, however we can host your bugzilla on our servers and provide all necessary services to support your company. Bugzilla does not run under a Microsoft framework it was developed use with mySQL however they are doing a rewrite as we speak and it may be more compatible in the future. If you are interested let me know how many users and projects you are working with. Thanks, Pat On 7/6/06, Kandagatla, Satya wrote: > > Hello, > > I am not sure whether I am posting the question at the right place or not > but I thought it would be worth trying: > > We have the following development environment at our work place: > > Microsoft .Net Framework > > Winforms/Webforms (Visual Studio.Net) > > Webservers have Microsoft Windows 2003 as Server OS > > Database is SQL Server. > > *So my question is, can we install BugZilla successfully and use it as our > defect tracking system? * > > Thanks in advance. > > Satya > -------------- next part -------------- An HTML attachment was scrubbed... URL: From asharma at newgen.co.in Fri Jul 7 08:00:48 2006 From: asharma at newgen.co.in (Amit Sharma) Date: Fri, 7 Jul 2006 13:30:48 +0530 Subject: Question!!!!!!!!!! References: <200607061829.k66ITYKG019894@sheridan.syndicomm.com> <6D5132237BA50F45A268A3694E22A0AA0544BE8E@deturbansci08.urbanscience.net> <23abb3e0607061150l43fb937ga55fe7427be364a6@mail.gmail.com> Message-ID: <004001c6a19b$75ee4470$e705a8c0@amit> Dear All, Graphical reports are not coming in the bugzilla. It is not showing any error while click the graphical reports menu. But, when I run the test server it is saying that the png image generated is not matching with the png image generated by the testserver. please help. I think it is the final stage of implementation.. therefore please help. regards amit ----- Original Message ----- From: Patrick Bishop To: developers at bugzilla.org Sent: Friday, July 07, 2006 12:20 AM Subject: Re: Question!!!!!!!!!! Satya: No, however we can host your bugzilla on our servers and provide all necessary services to support your company. Bugzilla does not run under a Microsoft framework it was developed use with mySQL however they are doing a rewrite as we speak and it may be more compatible in the future. If you are interested let me know how many users and projects you are working with. Thanks, Pat On 7/6/06, Kandagatla, Satya < skandagatla at urbanscience.com> wrote: Hello, I am not sure whether I am posting the question at the right place or not but I thought it would be worth trying: We have the following development environment at our work place: Microsoft .Net Framework Winforms/Webforms (Visual Studio.Net) Webservers have Microsoft Windows 2003 as Server OS Database is SQL Server. So my question is, can we install BugZilla successfully and use it as our defect tracking system? Thanks in advance. Satya -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.benton at amd.com Fri Jul 7 17:44:07 2006 From: kevin.benton at amd.com (Benton, Kevin) Date: Fri, 7 Jul 2006 10:44:07 -0700 Subject: Question!!!!!!!!!! Message-ID: Amit - please use the Support mailing list for this type of question (as Dave documented a few emails ago). --- Kevin Benton Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator AMD - ECSD Software Validation and Tools The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. ________________________________ From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] On Behalf Of Amit Sharma Sent: Friday, July 07, 2006 2:01 AM To: developers at bugzilla.org Subject: Re: Question!!!!!!!!!! Dear All, Graphical reports are not coming in the bugzilla. It is not showing any error while click the graphical reports menu. But, when I run the test server it is saying that the png image generated is not matching with the png image generated by the testserver. please help. I think it is the final stage of implementation.. therefore please help. regards amit ----- Original Message ----- From: Patrick Bishop To: developers at bugzilla.org Sent: Friday, July 07, 2006 12:20 AM Subject: Re: Question!!!!!!!!!! Satya: No, however we can host your bugzilla on our servers and provide all necessary services to support your company. Bugzilla does not run under a Microsoft framework it was developed use with mySQL however they are doing a rewrite as we speak and it may be more compatible in the future. If you are interested let me know how many users and projects you are working with. Thanks, Pat On 7/6/06, Kandagatla, Satya < skandagatla at urbanscience.com> wrote: Hello, I am not sure whether I am posting the question at the right place or not but I thought it would be worth trying: We have the following development environment at our work place: Microsoft .Net Framework Winforms/Webforms (Visual Studio.Net) Webservers have Microsoft Windows 2003 as Server OS Database is SQL Server. So my question is, can we install BugZilla successfully and use it as our defect tracking system? Thanks in advance. Satya Disclaimer :- This e-mail message including any attachment may contain confidential, proprietary or legally privileged information. It should not be used by who is not the original intended recipient. If you have erroneously received this message, you are notified that you are strictly prohibited from using, copying, altering or disclosing the content of this message. Please delete it immediately and notify the sender. Newgen Software Technologies Ltd and / or its subsidiary Companies accept no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus and further acknowledges that any views expressed in this message are those of the individual sender and no binding nature of the message shall be implied or assumed unless the sender does so expressly with due authority of Newgen Software Technologies Ltd and / or its subsidiary Companies, as applicable. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.benton at amd.com Fri Jul 7 17:45:20 2006 From: kevin.benton at amd.com (Benton, Kevin) Date: Fri, 7 Jul 2006 10:45:20 -0700 Subject: Question!!!!!!!!!! Message-ID: OOPS - as Max documented a few emails ago... :-) --- Kevin Benton Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator AMD - ECSD Software Validation and Tools The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. ________________________________ From: Benton, Kevin Sent: Friday, July 07, 2006 11:44 AM To: 'developers at bugzilla.org' Subject: RE: Question!!!!!!!!!! Amit - please use the Support mailing list for this type of question (as Dave documented a few emails ago). --- Kevin Benton Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator AMD - ECSD Software Validation and Tools The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. ________________________________ From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] On Behalf Of Amit Sharma Sent: Friday, July 07, 2006 2:01 AM To: developers at bugzilla.org Subject: Re: Question!!!!!!!!!! Dear All, Graphical reports are not coming in the bugzilla. It is not showing any error while click the graphical reports menu. But, when I run the test server it is saying that the png image generated is not matching with the png image generated by the testserver. please help. I think it is the final stage of implementation.. therefore please help. regards amit ----- Original Message ----- From: Patrick Bishop To: developers at bugzilla.org Sent: Friday, July 07, 2006 12:20 AM Subject: Re: Question!!!!!!!!!! Satya: No, however we can host your bugzilla on our servers and provide all necessary services to support your company. Bugzilla does not run under a Microsoft framework it was developed use with mySQL however they are doing a rewrite as we speak and it may be more compatible in the future. If you are interested let me know how many users and projects you are working with. Thanks, Pat On 7/6/06, Kandagatla, Satya < skandagatla at urbanscience.com> wrote: Hello, I am not sure whether I am posting the question at the right place or not but I thought it would be worth trying: We have the following development environment at our work place: Microsoft .Net Framework Winforms/Webforms (Visual Studio.Net) Webservers have Microsoft Windows 2003 as Server OS Database is SQL Server. So my question is, can we install BugZilla successfully and use it as our defect tracking system? Thanks in advance. Satya Disclaimer :- This e-mail message including any attachment may contain confidential, proprietary or legally privileged information. It should not be used by who is not the original intended recipient. If you have erroneously received this message, you are notified that you are strictly prohibited from using, copying, altering or disclosing the content of this message. Please delete it immediately and notify the sender. Newgen Software Technologies Ltd and / or its subsidiary Companies accept no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus and further acknowledges that any views expressed in this message are those of the individual sender and no binding nature of the message shall be implied or assumed unless the sender does so expressly with due authority of Newgen Software Technologies Ltd and / or its subsidiary Companies, as applicable. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerv at mozilla.org Mon Jul 10 09:59:12 2006 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 10 Jul 2006 10:59:12 +0100 Subject: UI module owner In-Reply-To: <44A2FE99.2010603@bugzilla.org> References: <449F9D99.8020501@mozilla.org> <1151316452.90475.142.camel@D-MELENTYEV.HOME> <449FB685.5070305@mozilla.org> <1a75cc570606260413y5bd6d64bj96111e673dc80e37@mail.gmail.com> <449FC8B7.5030200@mozilla.org> <1a75cc570606260754u53ceff80md9c8ee3fce754e39@mail.gmail.com> <44A0149D.9050706@mozilla.org> <1a75cc570606270316q7803f58l90e087247e6edd00@mail.gmail.com> <44A2D3C9.2010604@mozilla.org> <1a75cc570606281249x18176051hbdc6558f854e03b6@mail.gmail.com> <44A2E224.5030405@mozilla.org> <44A2FE99.2010603@bugzilla.org> Message-ID: <44B224F0.40004@mozilla.org> David Miller wrote: > And we have two major types of organizations that we target, which have > distinct usage patterns. (corporate environment vs public projects) This is an important point. How do we deal with this? a) have a persona which is a developer for a corporation who also works on free software in his spare time; b) argue that the requirements are pretty similar in one or all areas, and so we don't need separate personas c) have parallel sets of personas for closed vs open development ? I think there are some differences. For example, the manager-type persona isn't a big feature of open projects and, when he is, the requirements are generally the same as for closed projects. So perhaps it's just for developers that there's a difference, and the difference is that developers of open projects tend to use multiple Bugzilla installations, whereas developers of closed projects will usually just use one, or multiple extremely similar ones. Gerv From gerv at mozilla.org Mon Jul 10 10:00:58 2006 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 10 Jul 2006 11:00:58 +0100 Subject: Bugzilla Extensions/Hooks Mechanism (was Re: UI module owner) In-Reply-To: <956ECBA5-0FB5-4675-AC8D-11B491D3407A@zachlipton.com> References: <449C2A87.9090509@mozilla.org> <449C3B46.7080504@bugzilla.org> <449C40D7.8010207@mozilla.org> <1151231997.90475.69.camel@D-MELENTYEV.HOME> <449F9D99.8020501@mozilla.org> <1151316452.90475.142.camel@D-MELENTYEV.HOME> <449FB685.5070305@mozilla.org> <1a75cc570606260413y5bd6d64bj96111e673dc80e37@mail.gmail.com> <449FC8B7.5030200@mozilla.org> <1a75cc570606260754u53ceff80md9c8ee3fce754e39@mail.gmail.com> <44A006AC.4050304@dberlin.org> <44A0585A.8040802@mozilla.org> <44A12E66.8070302@dberlin.org> <44A2D2C8.10907@mozilla.org> <956ECBA5-0FB5-4675-AC8D-11B491D3407A@zachlipton.com> Message-ID: <44B2255A.8050309@mozilla.org> Zach Lipton wrote: > The system is documented at > http://www.bugzilla.org/docs/tip/html/cust-hooks.html. Information about > template hooks in general is available at > http://www.bugzilla.org/docs/tip/html/cust-templates.html. > > Right now, there aren't very many code hooks in the code at all, but > extension developers can easily request them and they will be added to > the source. Perhaps it would be worth setting a good example by saying that all future customisations we make to b.m.o. will be packaged as extensions? If the patch also has to contain a few one-line changes adding the required hooks because they are not yet present, that's still much easier to re-merge than the current method. And it'll give us some data about where hooks might be needed by other people. Gerv From gerv at mozilla.org Mon Jul 10 10:12:09 2006 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 10 Jul 2006 11:12:09 +0100 Subject: UI module owner In-Reply-To: <44A2E292.3000904@bugzilla.org> References: <449C2A87.9090509@mozilla.org> <449C3B46.7080504@bugzilla.org> <449C40D7.8010207@mozilla.org> <1151231997.90475.69.camel@D-MELENTYEV.HOME> <449F9D99.8020501@mozilla.org> <1151316452.90475.142.camel@D-MELENTYEV.HOME> <449FB685.5070305@mozilla.org> <1a75cc570606260413y5bd6d64bj96111e673dc80e37@mail.gmail.com> <449FC8B7.5030200@mozilla.org> <44A0AC8E.9000700@bugzilla.org> <44A2D36E.6040208@mozilla.org> <44A2E292.3000904@bugzilla.org> Message-ID: <44B227F9.30309@mozilla.org> David Miller wrote: >> 10-createaccount-privacy-notice.diff >> should have used a hook. > > Is there one for that page? If not, maybe we want one. Even if not, the patch we wrote should have added one and used it. > We should > probably provide a link to a privacy policy on the createaccount page by > default (and probably in small type in the footer somewhere). We can > put a page.cgi page in with some default template for people that don't > already have one. Sounds like a good idea. https://bugzilla.mozilla.org/show_bug.cgi?id=344091 filed. >> 03-mozilla-subsite-skin.diff >> shouldn't this be a separate skin in skins/custom? > > Yep, except that the version of Bugzilla we're running didn't support > that completely enough to implement that at the time. Ah. :-) Gerv From justdave at bugzilla.org Mon Jul 10 19:46:16 2006 From: justdave at bugzilla.org (David Miller) Date: Mon, 10 Jul 2006 15:46:16 -0400 Subject: OSCON 2006 Message-ID: <44B2AE88.2060000@bugzilla.org> Any bugzilla folks out there planning to attend OSCON in Portland? I'll be there Tuesday afternoon through Friday. If there'll be enough Bugzilla folks there maybe we could do something. -- 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 myk at mozilla.org Mon Jul 10 19:50:55 2006 From: myk at mozilla.org (Myk Melez) Date: Mon, 10 Jul 2006 12:50:55 -0700 Subject: OSCON 2006 In-Reply-To: <44B2AE88.2060000@bugzilla.org> References: <44B2AE88.2060000@bugzilla.org> Message-ID: <44B2AF9F.1020100@mozilla.org> David Miller wrote: > Any bugzilla folks out there planning to attend OSCON in Portland? > I'll be there Tuesday afternoon through Friday. If there'll be enough > Bugzilla folks there maybe we could do something. I'll be there the whole week. -myk From jdevalk at opendarwin.org Mon Jul 10 19:50:59 2006 From: jdevalk at opendarwin.org (Joost 'AlthA' de Valk) Date: Mon, 10 Jul 2006 21:50:59 +0200 Subject: OSCON 2006 In-Reply-To: <44B2AE88.2060000@bugzilla.org> References: <44B2AE88.2060000@bugzilla.org> Message-ID: Are you paying the ticket? If so, perhaps :P On Jul 10, 2006, at 9:46 PM, David Miller wrote: > Any bugzilla folks out there planning to attend OSCON in Portland? > I'll be there Tuesday afternoon through Friday. If there'll be > enough Bugzilla folks there maybe we could do something. > > -- > 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: > From LpSolit at gmail.com Mon Jul 10 23:00:04 2006 From: LpSolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Tue, 11 Jul 2006 01:00:04 +0200 Subject: Bugzilla meeting on IRC on Tuesday, July 11 at 18:00 GMT (11:00 PDT) Message-ID: <44B2DBF4.6010104@gmail.com> Reminder: We have a Bugzilla meeting tomorrow! 12th IRC meeting: Tuesday, July 11th at 18:00 GMT (11:00 PDT) IRC channel: irc://irc.mozilla.org/bugzilla-meeting The meeting is public. See you tomorrow, LpSolit From asharma at newgen.co.in Tue Jul 11 07:56:02 2006 From: asharma at newgen.co.in (Amit Sharma) Date: Tue, 11 Jul 2006 13:26:02 +0530 Subject: Please Help References: <200607061829.k66ITYKG019894@sheridan.syndicomm.com> <6D5132237BA50F45A268A3694E22A0AA0544BE8E@deturbansci08.urbanscience.net> <23abb3e0607061150l43fb937ga55fe7427be364a6@mail.gmail.com> Message-ID: <012f01c6a4bf$7530d080$e705a8c0@amit> Dear All, Graphs are not generated in the bugzilla. Please help. [root at bugzilla bugzilla]# perl checksetup.pl Checking perl modules ... Checking for AppConfig (v1.52) ok: found v1.56 Checking for CGI (v2.93) ok: found v3.05 Checking for Data::Dumper (any) ok: found v2.121 Checking for Date::Format (v2.21) ok: found v2.22 Checking for DBI (v1.38) ok: found v1.40 Checking for File::Spec (v0.84) ok: found v0.87 Checking for File::Temp (any) ok: found v0.14 Checking for Template (v2.08) ok: found v2.15 Checking for Text::Wrap (v2001.0131) ok: found v2001.09292 Checking for Mail::Mailer (v1.65) ok: found v1.74 Checking for Storable (any) ok: found v2.13 The following Perl modules are optional: Checking for GD (v1.20) ok: found v2.34 Checking for Chart::Base (v1.0) ok: found v2.3 Checking for XML::Parser (any) ok: found v2.34 Checking for GD::Graph (any) ok: found v1.4308 Checking for GD::Text::Align (any) ok: found v1.18 Checking for PatchReader (v0.9.4) ok: found v0.9.5 Checking user setup ... Removing existing compiled templates ... Precompiling templates ... Checking for DBD::mysql (v2.9003) ok: found v3.0006 Checking for MySQL (v3.23.41) ok: found v4.1.7 Populating duplicates table... [root at bugzilla bugzilla]# perl testserver.pl http://192.168.4.59/bugzilla TEST-OK Webserver is running under group id in $webservergroup. TEST-OK Got ant picture. TEST-OK Webserver is executing CGIs. TEST-OK Webserver is preventing fetch of http://192.168.4.59/bugzilla/localconfig. TEST-OK GD version 2.34, libgd version 2.0.33; Major versions match. TEST-WARNING GD library generated a PNG that didn't match the expected image. It has been saved as ./data/testgd-local.png and should be compared with t/testgd.png TEST-OK Chart library generated a good PNG image Thanks and Regards Amit -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkanat at bugzilla.org Tue Jul 11 08:06:16 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 11 Jul 2006 01:06:16 -0700 Subject: Please Help In-Reply-To: <012f01c6a4bf$7530d080$e705a8c0@amit> References: <200607061829.k66ITYKG019894@sheridan.syndicomm.com> <6D5132237BA50F45A268A3694E22A0AA0544BE8E@deturbansci08.urbanscience.net> <23abb3e0607061150l43fb937ga55fe7427be364a6@mail.gmail.com> <012f01c6a4bf$7530d080$e705a8c0@amit> Message-ID: <1152605177.5890.2.camel@localhost.localdomain> On Tue, 2006-07-11 at 13:26 +0530, Amit Sharma wrote: > Graphs are not generated in the bugzilla. Please help. Amit: Support questions go to the support list, NOT to this list. Don't post a support question here again. You can read about the support list here: http://www.bugzilla.org/support/ -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From lpsolit at gmail.com Wed Jul 12 00:01:28 2006 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Wed, 12 Jul 2006 02:01:28 +0200 Subject: Minutes of the Bugzilla meeting Message-ID: <44B43BD8.7010700@gmail.com> We had a Bugzilla meeting today. You can read the log at http://bugzilla.glob.com.au/irc/?c=bugzilla-meeting&a=date&s=11+Jul+2006&e=11+Jul+2006 * Related to the recurrent lack of reviewers, getting reviews can be somewhat slow, even for trivial patches. It appears that most of the time, patches need on average 3-5 revisions, sometimes more (especially for new contributors), but also sometimes less (for some reviewers, most likely). * The questions are then: would it help more than it hurts to let some reviewers go and commit patches without requiring review first? Would this speed up development? Would this affect code quality and stability? * The Bugzilla product needs to run its own code (dogfood), i.e. we should have a separate bugzilla.bugzilla.org installation running the tip code. * We are going to have module owners. They will be allowed to commit to their own area without review (on the trunk only, and outside freezing periods. Patches for branches still require review + approval). This discussion will be internal to reviewers (the discussion won't be public). Actions to be taken are: 1. get a list of components that need owners on the wiki (LpSolit) 2. nominate people for ownership of said modules (reviewers + justdave for the final decision) 3. update dependencies for bug 127876 - dogfood (justdave) 4. write the new review policy (justdave) 5. developer documentation is going to have to be updated to reflect all of this (mkanat) * Around September 1, we will decide if we postpone things which aren't ready for 3.0 or if we delay the freeze date to get them in. * Support for Oracle has been removed from the roadmap as the guy working on it has left the Oracle Corp. LpSolit From lpsolit at gmail.com Thu Jul 13 10:12:40 2006 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Thu, 13 Jul 2006 12:12:40 +0200 Subject: Bugzilla 2.23.2 broken Message-ID: <44B61C98.8070702@gmail.com> Just so that you know: 1) You cannot create any new bug using Bugzilla 2.23.2. We just discovered a bug in post_bug.cgi (regression) due to the removal of globals.pl, see bug 344497. The fix is a one-liner: add "use Bugzilla::Component;" at line 39 in post_bug.cgi. The patch has been reviewed and is waiting for approval (or a second review, invoking the emergency checkin procedure). 2) You cannot install or upgrade to Bugzilla 2.23.2 using Perl 5.8.0. The problem has been fixed meanwhile and will be in 2.23.3 (in a few weeks/months). Regressions were to be expected when you know that 95% of the CGI scripts have been altered with the removal of globals.pl, making testing everything pretty hard. LpSolit From gerv at mozilla.org Thu Jul 13 10:24:16 2006 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 13 Jul 2006 11:24:16 +0100 Subject: Bugzilla 2.23.2 broken In-Reply-To: <44B61C98.8070702@gmail.com> References: <44B61C98.8070702@gmail.com> Message-ID: <44B61F50.9060709@mozilla.org> Fr?d?ric Buclin wrote: > Regressions were to be expected when you know that 95% of the CGI > scripts have been altered with the removal of globals.pl, making testing > everything pretty hard. Sure - but is creating new bugs not part of any test suite or plan? I'm not being accusatory - it's not as if I did lots of work to test the release! I'm just curious that our current QA system didn't pick up a failure as seemingly basic as creating a bug. Gerv From lpsolit at gmail.com Thu Jul 13 10:48:23 2006 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Thu, 13 Jul 2006 12:48:23 +0200 Subject: Bugzilla 2.23.2 broken In-Reply-To: <44B61F50.9060709@mozilla.org> References: <44B61C98.8070702@gmail.com> <44B61F50.9060709@mozilla.org> Message-ID: <44B624F7.2090709@gmail.com> > I'm not being accusatory - it's not as if I did lots of work to test the > release! I'm just curious that our current QA system didn't pick up a > failure as seemingly basic as creating a bug. We don't test development releases. I would have to update the QA tests we use for 2.22 and I didn't take the time yet. As I'm now on vacation, I will try to do it in the next 3 weeks. LpSolit From mkanat at bugzilla.org Thu Jul 13 22:42:21 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 13 Jul 2006 15:42:21 -0700 Subject: mod_perl is testable Message-ID: <1152830541.2539.21.camel@localhost.localdomain> Hello, hello! So, mod_perl support is in a testable state, now, on the tip. There are a few known bugs, you can see them here: https://bugzilla.mozilla.org/showdependencytree.cgi?id=87406&hide_resolved=1 You can patch checksetup to show you the requirements (although this will be in CVS soon): https://bugzilla.mozilla.org/show_bug.cgi?id=342736 Instructions for a basic mod_perl setup are here: https://bugzilla.mozilla.org/show_bug.cgi?id=343336#c1 If you find any bugs, file them as a blocker of "mod_perl" (that's the alias of the mod_perl bug) and CC me on them. If you have any questions about mod_perl or about setting up Bugzilla to run with mod_perl, come into IRC and ask me (mkanat). -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From gerv at mozilla.org Fri Jul 14 08:27:05 2006 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 14 Jul 2006 09:27:05 +0100 Subject: OSCON 2006 In-Reply-To: <44B2AE88.2060000@bugzilla.org> References: <44B2AE88.2060000@bugzilla.org> Message-ID: <44B75559.7040907@mozilla.org> David Miller wrote: > Any bugzilla folks out there planning to attend OSCON in Portland? I'll > be there Tuesday afternoon through Friday. If there'll be enough > Bugzilla folks there maybe we could do something. I'll be there from Tuesday until Friday lunchtime. Gerv From gerv at mozilla.org Fri Jul 14 16:06:25 2006 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 14 Jul 2006 17:06:25 +0100 Subject: Personas Message-ID: <44B7C101.3080709@mozilla.org> I've come back to working on the personas. Thanks to you who started a conversation, even if it was a bit one-sided while I went away to be ill :-) I think I've continued each one; please do go back and respond to what I said. Particularly: http://wiki.mozilla.org/Bugzilla_Talk:Personas:Mitch http://wiki.mozilla.org/Bugzilla_Talk:Personas One thing that has emerged is that we need two sorts of "coder" persona - one for closed and one for open source, because they use Bugzilla in different ways. I'd like to try and nail down those differences on the mailing list before going back to make that split. Here's what I have so far: Open: * Triages own bugs, and decides own priorities * Interacts directly with customers and users * May well use multiple Bugzillas Closed: * Most bug triage and prioritisation is done by managers * No direct customer interaction * Uses just a single install, or a couple of very similar ones. Any more ideas? Are these enough differences to require a split? Lastly, Gandalf has created two more outline personas, listed here: http://wiki.mozilla.org/Bugzilla:Personas I'd be interested to know whether people feel these are new, hitherto undiscovered user types, or whether they are merely combinations or variants of the existing ones. Gerv From kevin.benton at amd.com Tue Jul 18 22:37:59 2006 From: kevin.benton at amd.com (Benton, Kevin) Date: Tue, 18 Jul 2006 15:37:59 -0700 Subject: DB Server Versions Documentation Message-ID: Does anyone besides me think we should consider putting together a matrix of database versions we support with MySQL versus our Bugzilla versions so we can point Bugzilla Administrators to it? I'm thinking that table might look *something* like this (from ... to ...): ... Supported Bugzilla Database Engine Versions +----------------------------+--------+--------+--------+ | Bugzilla Version | 2.18.x | 2.20.x | 2.22.x | +----------------------------+--------+--------+--------+ | MySQL 3.23.x | Yes | No* | No* | +----------------------------+--------+--------+--------+ | MySQL 4.0.13 and earlier | Yes | No* | No* | +----------------------------+--------+--------+--------+ | MySQL 4.0.x (14+) | Yes | Yes | Yes | +----------------------------+--------+--------+--------+ | MySQL 4.1.x | Yes | Yes | Yes | +----------------------------+--------+--------+--------+ | MySQL 5.0.x | No | Yes | Yes | +----------------------------+--------+--------+--------+ | PostgreSQL 8.0.x | No | Yes | Yes | +----------------------------+--------+--------+--------+ * = Bugzilla support for this DB version has ended. Database engines not listed in the table above have either not been tested or do not work with Bugzilla. The recommended production database engine for Bugzilla 2.22.x is the latest stable release of: MySQL 4.1.x ... I suggest we limit to this kind of reporting (major & minor versions known to work) rather than some form of "x.y.z and greater". I make the suggestion because we haven't seen the feature set for version x+1 or y+1 yet and therefore, we have no way to know if a database code change will impact Bugzilla. --- Kevin Benton Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator AMD - ECSD Software Validation and Tools ? The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management.? This communication may contain sensitive and/or confidential and/or proprietary information.? Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices.? This communication is for the intended recipient(s) only.? If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. From justdave at bugzilla.org Tue Jul 18 22:50:34 2006 From: justdave at bugzilla.org (David Miller) Date: Tue, 18 Jul 2006 15:50:34 -0700 Subject: DB Server Versions Documentation In-Reply-To: References: Message-ID: <44BD65BA.5070602@bugzilla.org> Benton, Kevin wrote on 7/18/06 3:37 PM: > Does anyone besides me think we should consider putting together a matrix of database versions we support with MySQL versus our Bugzilla versions so we can point Bugzilla Administrators to it? I'm thinking that table might look *something* like this (from ... to ...): I think that's a great idea. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From lpsolit at gmail.com Tue Jul 18 23:04:33 2006 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Wed, 19 Jul 2006 01:04:33 +0200 Subject: DB Server Versions Documentation In-Reply-To: References: Message-ID: <44BD6901.6080906@gmail.com> Benton, Kevin a ?crit : > Does anyone besides me think we should consider putting together a matrix of database versions we support with MySQL versus our Bugzilla versions so we can point Bugzilla Administrators to it? I'm thinking that table might look *something* like this (from ... to ...): Good idea! You should also mention PostreSQL 7.4+ which is supported on 2.22 (but will not be on 3.0). LpSolit From mkanat at bugzilla.org Wed Jul 19 00:55:53 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 18 Jul 2006 17:55:53 -0700 Subject: DB Server Versions Documentation In-Reply-To: <44BD6901.6080906@gmail.com> References: <44BD6901.6080906@gmail.com> Message-ID: <1153270553.5631.15.camel@localhost.localdomain> On Wed, 2006-07-19 at 01:04 +0200, Fr?d?ric Buclin wrote: > Benton, Kevin a ?crit : > > Does anyone besides me think we should consider putting together a matrix of database versions we support with MySQL versus our Bugzilla versions so we can point Bugzilla Administrators to it? I'm thinking that table might look *something* like this (from ... to ...): > > Good idea! You should also mention PostreSQL 7.4+ which is supported on > 2.22 (but will not be on 3.0). I'm pretty sure we support even as far back as 7.3.0 on 2.22. 3.0 will require 8.0.0 at least. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From mkanat at bugzilla.org Wed Jul 19 00:57:48 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 18 Jul 2006 17:57:48 -0700 Subject: DB Server Versions Documentation In-Reply-To: References: Message-ID: <1153270668.5631.18.camel@localhost.localdomain> On Tue, 2006-07-18 at 15:37 -0700, Benton, Kevin wrote: > +----------------------------+--------+--------+--------+ > | MySQL 5.0.x | No | Yes | Yes | You might want to also include MySQL 5.1--I'm pretty sure none of our versions support that yet, although maybe CVS does. > +----------------------------+--------+--------+--------+ > | PostgreSQL 8.0.x | No | Yes | Yes | I'm not certain that 2.20 fully supports 8.0. You might also want to mention that 2.22 is the first version to *fully* support PostgreSQL, and that 2.20 has many known bugs. This seems like a good thing for the Wiki, yeah? We could perhaps point to the Wiki from the docs, also. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From lists at nabble.com Wed Jul 19 15:26:55 2006 From: lists at nabble.com (Karen (sent by Nabble.com)) Date: Wed, 19 Jul 2006 08:26:55 -0700 (PDT) Subject: BugZ with XAMPP Message-ID: <5398430.post@talk.nabble.com> Hi, I'm new in this and need your help. I'm trying to install BugZ on my PC which has XAMPP on it. The purpose of that is to modify some of the BugZ template. Can anyone please refer/explain how to install BugZ on this type of machine? I was looking on line for this combination and couldn't find any step by step instructions. Thanks, Karen -- View this message in context: http://www.nabble.com/BugZ-with-XAMPP-tf1967045.html#a5398430 Sent from the Bugzilla - Dev forum at Nabble.com. From mkanat at bugzilla.org Wed Jul 19 18:57:18 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 19 Jul 2006 11:57:18 -0700 Subject: BugZ with XAMPP In-Reply-To: <5398430.post@talk.nabble.com> References: <5398430.post@talk.nabble.com> Message-ID: <1153335438.2441.0.camel@localhost.localdomain> On Wed, 2006-07-19 at 08:26 -0700, Karen (sent by Nabble.com) wrote: > I'm new in this and need your help. > I'm trying to install BugZ on my PC which has XAMPP on it. Hi Karen. This is not a support list. This question would be more appropriate for the bugzilla-support list. See this link for details: http://www.bugzilla.org/support/ -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From lists at nabble.com Wed Jul 19 22:50:07 2006 From: lists at nabble.com (Karen (sent by Nabble.com)) Date: Wed, 19 Jul 2006 15:50:07 -0700 (PDT) Subject: BugZ with XAMPP In-Reply-To: <1153335438.2441.0.camel@localhost.localdomain> References: <5398430.post@talk.nabble.com> <1153335438.2441.0.camel@localhost.localdomain> Message-ID: <5406072.post@talk.nabble.com> Sorry about that :) -- View this message in context: http://www.nabble.com/BugZ-with-XAMPP-tf1967045.html#a5406072 Sent from the Bugzilla - Dev forum at Nabble.com. From justdave at bugzilla.org Thu Jul 20 08:46:50 2006 From: justdave at bugzilla.org (David Miller) Date: Thu, 20 Jul 2006 04:46:50 -0400 Subject: [Fwd: bugzilla.org cvs update] Message-ID: <44BF42FA.1060503@bugzilla.org> The docs build on the website is broken. The web server does not have a copy of Bugzilla/Install/Requirements.pm, nor is it practical to give it one. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ -------------- next part -------------- An embedded message was scrubbed... From: root Subject: bugzilla.org cvs update Date: Wed, 19 Jul 2006 14:45:20 -0700 Size: 4439 URL: From lpsolit at gmail.com Fri Jul 21 18:53:46 2006 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Fri, 21 Jul 2006 20:53:46 +0200 Subject: Bugzilla meeting on Monday, July 24 at 18:00 GMT (11:00 PDT, 20:00 CET) Message-ID: <44C122BA.6010407@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Reminder: We meet again on Monday, July 24 at 18:00 GMT (11:00 PDT, 20:00 CET) in the #bugzilla-meeting channel on irc.mozilla.org. Note that I said Monday, not Tuesday. ;) The meeting looks very interesting, see the agenda yourself: http://wiki.mozilla.org/Bugzilla:Meetings See you on Monday, LpSolit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEwSK6uG3TRgecPlsRAiruAKCtlVfbWynTjjyydSC/2vD1hKAUdwCeIxYT veMu3qnREQ+pTn4QQjpD50o= =reNf -----END PGP SIGNATURE----- From bugzilla at colinogilvie.co.uk Fri Jul 21 22:07:13 2006 From: bugzilla at colinogilvie.co.uk (Colin Ogilvie) Date: Fri, 21 Jul 2006 23:07:13 +0100 Subject: [Fwd: bugzilla.org cvs update] In-Reply-To: <44BF42FA.1060503@bugzilla.org> References: <44BF42FA.1060503@bugzilla.org> Message-ID: <44C15011.4000007@colinogilvie.co.uk> David Miller wrote: > The docs build on the website is broken. The web server does not have a > copy of Bugzilla/Install/Requirements.pm, nor is it practical to give it > one. > Can I ask why it's not practical to give it one? It is (in my opinion anyway) beneficial to have the docs information coming from the same source as checksetup.pl - especially when people seem to forget the documentation... Other than reverting the patch, and going back to the old way of doing things, the only other option I can see is to have landfill check in the documentation to the website CVS Repository from the tinderbox when the documentation changes... Colin From bugzilla at colinogilvie.co.uk Fri Jul 21 22:07:59 2006 From: bugzilla at colinogilvie.co.uk (Colin Ogilvie) Date: Fri, 21 Jul 2006 23:07:59 +0100 Subject: Bugzilla meeting on Monday, July 24 at 18:00 GMT (11:00 PDT, In-Reply-To: <44C122BA.6010407@gmail.com> References: <44C122BA.6010407@gmail.com> Message-ID: <44C1503F.8000509@colinogilvie.co.uk> Fr?d?ric Buclin wrote: > We meet again on Monday, July 24 at 18:00 GMT (11:00 PDT, 20:00 CET) in > the #bugzilla-meeting channel on irc.mozilla.org. > > Note that I said Monday, not Tuesday. ;) I can't help but thinking it would be more useful to stop changing the days/dates etc. of the meetings... Colin From mkanat at bugzilla.org Fri Jul 21 22:20:00 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 21 Jul 2006 15:20:00 -0700 Subject: Bugzilla meeting on Monday, July 24 at 18:00 GMT (11:00 PDT, In-Reply-To: <44C1503F.8000509@colinogilvie.co.uk> References: <44C122BA.6010407@gmail.com> <44C1503F.8000509@colinogilvie.co.uk> Message-ID: <1153520400.3285.5.camel@localhost.localdomain> On Fri, 2006-07-21 at 23:07 +0100, Colin Ogilvie wrote: > I can't help but thinking it would be more useful to stop changing the > days/dates etc. of the meetings... They're standardly on Tuesday. They only change when we have some special requirement. For example, this week justdave would be unable to attend on Tuesday, because of OSCON. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From lpsolit at gmail.com Fri Jul 21 22:32:01 2006 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Sat, 22 Jul 2006 00:32:01 +0200 Subject: Bugzilla meeting on Monday, July 24 at 18:00 GMT (11:00 PDT, In-Reply-To: <44C1503F.8000509@colinogilvie.co.uk> References: <44C122BA.6010407@gmail.com> <44C1503F.8000509@colinogilvie.co.uk> Message-ID: <44C155E1.7040200@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I can't help but thinking it would be more useful to stop changing the > days/dates etc. of the meetings... Well, if core developers cannot attend, it doesn't make sense to have a meeting. That's the reason the meeting is one day earlier. LpSolit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEwVXguG3TRgecPlsRAj1TAJ413dHpx63d1l3XDiE1rKaoSZqg6wCeOuW3 PTuHDamZ69kZzzZ5ibTmij0= =PnPw -----END PGP SIGNATURE----- From justdave at bugzilla.org Fri Jul 21 23:26:07 2006 From: justdave at bugzilla.org (David Miller) Date: Fri, 21 Jul 2006 19:26:07 -0400 Subject: [Fwd: bugzilla.org cvs update] In-Reply-To: <44C15011.4000007@colinogilvie.co.uk> References: <44BF42FA.1060503@bugzilla.org> <44C15011.4000007@colinogilvie.co.uk> Message-ID: <44C1628F.8080509@bugzilla.org> Colin Ogilvie wrote on 7/21/06 6:07 PM: > David Miller wrote: >> The docs build on the website is broken. The web server does not have a >> copy of Bugzilla/Install/Requirements.pm, nor is it practical to give it >> one. >> > > Can I ask why it's not practical to give it one? Because the docs directory from source is checked out directly into its location in the webtree within the document root of the main website. I think we can make this whole problem go away if we fix the build system to work like mozilla.com does (where there's a src directory with our templates in it, and they get compiled into the destination directory by the build script, where the destination directory is a symlink to the real docroot. I think this is https://bugzilla.mozilla.org/show_bug.cgi?id=324893 Should we change the CVS repository location? Right now we're using a directory that's supposed to be http://www.mozilla.org/projects/bugzilla/ and shoehorning it into a separate website. Perhaps it's time to move to a top-level bugzilla-org CVSROOT. -- 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 bugzilla at colinogilvie.co.uk Sun Jul 23 18:48:13 2006 From: bugzilla at colinogilvie.co.uk (Colin Ogilvie) Date: Sun, 23 Jul 2006 19:48:13 +0100 Subject: [Fwd: bugzilla.org cvs update] In-Reply-To: <44C1628F.8080509@bugzilla.org> References: <44BF42FA.1060503@bugzilla.org> <44C15011.4000007@colinogilvie.co.uk> <44C1628F.8080509@bugzilla.org> Message-ID: <20060723184813.GA17539@theta> On Fri, Jul 21, 2006 at 07:26:07PM -0400, David Miller wrote: > I think we can make this whole problem go away if we fix the build > system to work like mozilla.com does (where there's a src directory with > our templates in it, and they get compiled into the destination > directory by the build script, where the destination directory is a > symlink to the real docroot. > > I think this is https://bugzilla.mozilla.org/show_bug.cgi?id=324893 What is required to have that bug fixed? As far as I can see, _RSZ_ has already done most of the work (as he says bugzilla.jp is using it). I assume it is just waiting on someone to review it and the changes to be made to the server? > Should we change the CVS repository location? Right now we're using a > directory that's supposed to be > http://www.mozilla.org/projects/bugzilla/ and shoehorning it into a > separate website. Perhaps it's time to move to a top-level bugzilla-org > CVSROOT. That probably makes some sense, particularly if the servers are going to end up set up the same way as mozilla.(org|com) builds... Colin From myk at mozilla.org Mon Jul 24 08:43:47 2006 From: myk at mozilla.org (Myk Melez) Date: Mon, 24 Jul 2006 01:43:47 -0700 Subject: Bugzilla meeting on Monday, July 24 at 18:00 GMT (11:00 PDT, In-Reply-To: <44C122BA.6010407@gmail.com> References: <44C122BA.6010407@gmail.com> Message-ID: <44C48843.40006@mozilla.org> Fr?d?ric Buclin wrote: > We meet again on Monday, July 24 at 18:00 GMT (11:00 PDT, 20:00 CET) in > the #bugzilla-meeting channel on irc.mozilla.org. > It's unclear that I'll be able to attend this meeting in any significant way. I'm at a conference this week and will be attending a tutorial all morning. But my next two priorities for custom fields in 2.24 are: 1. enhancing the command-line tool so that it can list and delete custom fields; 2. adding support for boolean custom fields. -myk -------------- next part -------------- An HTML attachment was scrubbed... URL: From lpsolit at gmail.com Mon Jul 24 09:03:57 2006 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Mon, 24 Jul 2006 11:03:57 +0200 Subject: Bugzilla meeting on Monday, July 24 at 18:00 GMT (11:00 PDT, In-Reply-To: <44C48843.40006@mozilla.org> References: <44C122BA.6010407@gmail.com> <44C48843.40006@mozilla.org> Message-ID: <44C48CFD.2090400@gmail.com> > 1. enhancing the command-line tool so that it can list and delete > custom fields; I was thinking about doing that as part of bug 344875. Tell me if you want to do it separately and I will do the UI thing only without changing the code within customfields.pl. LpSolit From myk at mozilla.org Mon Jul 24 09:08:24 2006 From: myk at mozilla.org (Myk Melez) Date: Mon, 24 Jul 2006 02:08:24 -0700 Subject: Bugzilla meeting on Monday, July 24 at 18:00 GMT (11:00 PDT, In-Reply-To: <44C48CFD.2090400@gmail.com> References: <44C122BA.6010407@gmail.com> <44C48843.40006@mozilla.org> <44C48CFD.2090400@gmail.com> Message-ID: <44C48E08.9090504@mozilla.org> Fr?d?ric Buclin wrote: >> 1. enhancing the command-line tool so that it can list and delete >> custom fields; >> > > I was thinking about doing that as part of bug 344875. Tell me if you > want to do it separately and I will do the UI thing only without > changing the code within customfields.pl. > You are welcome to do that as part of a patch for bug 344875, although it may make the most sense as a discrete patch which the patch for bug 344875 depends upon. -myk -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.benton at amd.com Mon Jul 24 17:13:24 2006 From: kevin.benton at amd.com (Benton, Kevin) Date: Mon, 24 Jul 2006 10:13:24 -0700 Subject: Bugzilla meeting on Monday, July 24 at 18:00 GMT (11:00 Message-ID: I would like to add (since I'll be in a company meeting), that it seems to me that we ought to support custom fields that require valid values for other fields (custom or otherwise). In other words, a rudimentary way to add business logic to custom fields (like the fixed_in_rev and fixed_in_stage, field may be changed only when the bug_status is being changed to or is now RESOLVED, or cleared when the status goes from REOPENED, or when the status is set to PENDING, that the pending_status field is set). --- Kevin Benton Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator AMD - ECSD Software Validation and Tools The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. ________________________________ From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] On Behalf Of Myk Melez Sent: Monday, July 24, 2006 2:44 AM To: developers at bugzilla.org Subject: Re: Bugzilla meeting on Monday, July 24 at 18:00 GMT (11:00 PDT, Fr?d?ric Buclin wrote: We meet again on Monday, July 24 at 18:00 GMT (11:00 PDT, 20:00 CET) in the #bugzilla-meeting channel on irc.mozilla.org. It's unclear that I'll be able to attend this meeting in any significant way. I'm at a conference this week and will be attending a tutorial all morning. But my next two priorities for custom fields in 2.24 are: 1. enhancing the command-line tool so that it can list and delete custom fields; 2. adding support for boolean custom fields. -myk -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkanat at bugzilla.org Mon Jul 24 20:37:46 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 24 Jul 2006 13:37:46 -0700 Subject: Bugzilla meeting on Monday, July 24 at 18:00 GMT (11:00 In-Reply-To: References: Message-ID: <1153773466.2516.33.camel@localhost.localdomain> On Mon, 2006-07-24 at 10:13 -0700, Benton, Kevin wrote: > I would like to add (since I?ll be in a company meeting), that it > seems to me that we ought to support custom fields that require valid > values for other fields (custom or otherwise). In other words, a > rudimentary way to add business logic to custom fields (like the > fixed_in_rev and fixed_in_stage, field may be changed only when the > bug_status is being changed to or is now RESOLVED, or cleared when the > status goes from REOPENED, or when the status is set to PENDING, that > the pending_status field is set). Yep, there's a bug for that: https://bugzilla.mozilla.org/show_bug.cgi?id=291433 -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From myk at mozilla.org Wed Jul 26 07:08:25 2006 From: myk at mozilla.org (Myk Melez) Date: Wed, 26 Jul 2006 00:08:25 -0700 Subject: Poul-Henning's "a bike shed (any colour will do)" Message-ID: <44C714E9.4040502@mozilla.org> I happened upon a message today about OSS project dynamics that seems like it would be insightful and useful reading for the Bugzilla development community. http://www.freebsd.org/cgi/getmsg.cgi?fetch=506636+517178+/usr/local/www/db/text/1999/freebsd-hackers/19991003.freebsd-hackers -myk From dberlin at dberlin.org Wed Jul 26 13:34:37 2006 From: dberlin at dberlin.org (Daniel Berlin) Date: Wed, 26 Jul 2006 09:34:37 -0400 Subject: Poul-Henning's "a bike shed (any colour will do)" In-Reply-To: <44C714E9.4040502@mozilla.org> References: <44C714E9.4040502@mozilla.org> Message-ID: <44C76F6D.9010302@dberlin.org> Myk Melez wrote: > I happened upon a message today about OSS project dynamics that seems > like it would be insightful and useful reading for the Bugzilla > development community. > > http://www.freebsd.org/cgi/getmsg.cgi?fetch=506636+517178+/usr/local/www/db/text/1999/freebsd-hackers/19991003.freebsd-hackers > > -myk > http://taupe.bikeshed.com Run by a friend of mine (any html color will work as a subdomain :P) From kevin.benton at amd.com Wed Jul 26 15:26:17 2006 From: kevin.benton at amd.com (Benton, Kevin) Date: Wed, 26 Jul 2006 08:26:17 -0700 Subject: Poul-Henning's "a bike shed (any colour will do)" Message-ID: > I happened upon a message today about OSS project dynamics that seems > like it would be insightful and useful reading for the Bugzilla > development community. > > http://www.freebsd.org/cgi/getmsg.cgi?fetch=506636+517178+/usr/local/www /db/text/1999/freebsd-hackers/19991003.freebsd-hackers This thread reminds me of our custom fields "discussion." :) Let's focus on what's most important and leave the minutia to the developers / reviewers / approvers. Thanks for the repost, Myk :) --- Kevin Benton Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator AMD - ECSD Software Validation and Tools The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. From kevin.benton at amd.com Wed Jul 26 15:46:44 2006 From: kevin.benton at amd.com (Benton, Kevin) Date: Wed, 26 Jul 2006 08:46:44 -0700 Subject: Bugzilla FAQ Message-ID: Has anyone put together a FAQ for Bugzilla yet? If not, I think we should begin compiling one and put the results on the Support page. I'm willing to do it if nobody else is up to it. We're answering a lot of questions multiple times in the support list. It'd be a lot easier to point users to the FAQ than to keep answering the same question over and over again. :-) --- Kevin Benton Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator AMD - ECSD Software Validation and Tools The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lpsolit at gmail.com Wed Jul 26 16:23:25 2006 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Wed, 26 Jul 2006 18:23:25 +0200 Subject: Bugzilla FAQ In-Reply-To: References: Message-ID: <44C796FD.5040506@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Has anyone put together a FAQ for Bugzilla yet? http://wiki.mozilla.org/Bugzilla:FAQ http://www.bugzilla.org/docs/tip/html/faq.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEx5b9uG3TRgecPlsRAuZMAKCNXPDkxFcx0ANpFCK4L1uBlcue5QCeOLq3 WMFl/NPRxxRZYnfcXoA+x4c= =K1Pd -----END PGP SIGNATURE----- From kevin.benton at amd.com Wed Jul 26 16:54:53 2006 From: kevin.benton at amd.com (Benton, Kevin) Date: Wed, 26 Jul 2006 09:54:53 -0700 Subject: Bugzilla FAQ Message-ID: Hey Dave - do you think it'd be a good idea to put a link to http://www.bugzilla.org/docs/tip/html/faq.html on the support page? :) --- Kevin Benton Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator AMD - ECSD Software Validation and Tools The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. > -----Original Message----- > From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] > On Behalf Of Fr?d?ric Buclin > Sent: Wednesday, July 26, 2006 10:23 AM > To: developers at bugzilla.org > Subject: Re: Bugzilla FAQ > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Has anyone put together a FAQ for Bugzilla yet? > > http://wiki.mozilla.org/Bugzilla:FAQ > http://www.bugzilla.org/docs/tip/html/faq.html > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2.2 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFEx5b9uG3TRgecPlsRAuZMAKCNXPDkxFcx0ANpFCK4L1uBlcue5QCeOLq3 > WMFl/NPRxxRZYnfcXoA+x4c= > =K1Pd > -----END PGP SIGNATURE----- > - > To view or change your list settings, click here: > > From myk at mozilla.org Wed Jul 26 17:22:03 2006 From: myk at mozilla.org (Myk Melez) Date: Wed, 26 Jul 2006 10:22:03 -0700 Subject: Poul-Henning's "a bike shed (any colour will do)" In-Reply-To: References: Message-ID: <44C7A4BB.4020307@mozilla.org> Benton, Kevin wrote: > This thread reminds me of our custom fields "discussion." FWIW, as I mentioned in the thread back then, I thought custom fields was one of the exceptions to Poul-Henning's general principle. But maybe not. Reasonable people can disagree about such things. :-) -myk From gerv at mozilla.org Wed Jul 26 18:48:31 2006 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 26 Jul 2006 11:48:31 -0700 Subject: Poul-Henning's "a bike shed (any colour will do)" In-Reply-To: <44C7A4BB.4020307@mozilla.org> References: <44C7A4BB.4020307@mozilla.org> Message-ID: <44C7B8FF.1060209@mozilla.org> Myk Melez wrote: > FWIW, as I mentioned in the thread back then, I thought custom fields > was one of the exceptions to Poul-Henning's general principle. But > maybe not. Reasonable people can disagree about such things. :-) Well, custom fields is a nuclear power plant, not a bike shed. So in fact, the scrutiny it's been getting, and the excellent, data-supported discussion about the relative merits of FAD and FAC seems to me like things working right, not wrong. Gerv From justdave at bugzilla.org Wed Jul 26 19:13:28 2006 From: justdave at bugzilla.org (David Miller) Date: Wed, 26 Jul 2006 12:13:28 -0700 Subject: Bugzilla FAQ In-Reply-To: References: Message-ID: <44C7BED8.2010606@bugzilla.org> Benton, Kevin wrote on 7/26/06 9:54 AM: > Hey Dave - do you think it'd be a good idea to put a link to http://www.bugzilla.org/docs/tip/html/faq.html on the support page? :) Yes. I think pointing at the wiki version might be better. We should pull it back to the docs from there (so it's in the stuff included in the tarball) before each release. -- 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 kevin.benton at amd.com Wed Jul 26 21:12:05 2006 From: kevin.benton at amd.com (Benton, Kevin) Date: Wed, 26 Jul 2006 14:12:05 -0700 Subject: Bugzilla FAQ Message-ID: > Benton, Kevin wrote on 7/26/06 9:54 AM: > > Hey Dave - do you think it'd be a good idea to put a link to > http://www.bugzilla.org/docs/tip/html/faq.html on the support page? :) > > Yes. I think pointing at the wiki version might be better. We should > pull it back to the docs from there (so it's in the stuff included in > the tarball) before each release. Hi Dave, Would you like me to file a bug and/or patch for this or did you just want to do it? --- Kevin Benton Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator AMD - ECSD Software Validation and Tools The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. From mkanat at bugzilla.org Wed Jul 26 21:38:56 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 26 Jul 2006 14:38:56 -0700 Subject: Poul-Henning's "a bike shed (any colour will do)" In-Reply-To: <44C7B8FF.1060209@mozilla.org> References: <44C7A4BB.4020307@mozilla.org> <44C7B8FF.1060209@mozilla.org> Message-ID: <1153949936.2595.21.camel@localhost.localdomain> On Wed, 2006-07-26 at 11:48 -0700, Gervase Markham wrote: > Myk Melez wrote: > > FWIW, as I mentioned in the thread back then, I thought custom fields > > was one of the exceptions to Poul-Henning's general principle. But > > maybe not. Reasonable people can disagree about such things. :-) > > Well, custom fields is a nuclear power plant, not a bike shed. So in > fact, the scrutiny it's been getting, and the excellent, data-supported > discussion about the relative merits of FAD and FAC seems to me like > things working right, not wrong. Yeah, I would agree in this case. Some things do deserve some discussion. Custom Fields, Skins, things like that. I did really enjoy reading Poul-Henning's post. I think the Bugzilla Project is normally pretty good about not discussing small changes to death. :-) I'm sure we've done it a few times, though, and this post should be a great reminder for us in the future if and when we get into that situation. :-) -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From mkanat at bugzilla.org Wed Jul 26 21:40:53 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 26 Jul 2006 14:40:53 -0700 Subject: Bugzilla FAQ In-Reply-To: <44C7BED8.2010606@bugzilla.org> References: <44C7BED8.2010606@bugzilla.org> Message-ID: <1153950053.2595.24.camel@localhost.localdomain> On Wed, 2006-07-26 at 12:13 -0700, David Miller wrote: > Benton, Kevin wrote on 7/26/06 9:54 AM: > > Hey Dave - do you think it'd be a good idea to put a link to http://www.bugzilla.org/docs/tip/html/faq.html on the support page? :) > > Yes. I think pointing at the wiki version might be better. We should > pull it back to the docs from there (so it's in the stuff included in > the tarball) before each release. We had a bit of a discussion about this: https://bugzilla.mozilla.org/show_bug.cgi?id=338439#c1 See also: https://bugzilla.mozilla.org/show_bug.cgi?id=340821 https://bugzilla.mozilla.org/show_bug.cgi?id=272886 -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From mkanat at bugzilla.org Thu Jul 27 00:54:49 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 26 Jul 2006 17:54:49 -0700 Subject: Branch Intelligence in Bugzilla Message-ID: <1153961690.7166.10.camel@localhost.localdomain> Some of us have been reading dbaron's message about bugzilla.mozilla.org management, here: http://groups.google.com/group/mozilla.dev.planning/browse_frm/thread/fb9c78418938bdc6/2227ccd96a042c69 When reading this and discussing it with Myk and LpSolit, I finally came to the idea that Bugzilla should understand the idea of a "branch." Now, this idea has been proposed in the past, and I rejected it, saying that it would make Bugzilla too complex. However, reading dbaron's message, and thinking about my own bug list, I think it would be useful in a lot of ways. Here's what I'm thinking: 1) Make the Version field a multi-select. 2) Associate each Version with a "Branch". For example, 1.8.1, 1.8.2, and 1.8.3 would all be associated with the "1.8 Branch." 3) For each affected branch, there would be two fields that would appear on a bug: * Desire: ---, Unwanted, Would Take, Wanted, Required Where "Required" would replace our current blocking flags. * Fix In: (Put all branch versions here) "Fix In" would represent both the version we plan to fix it in, and the version it was actually fixed in. We could mark certain versions as "unreleased," so that they would show up in the "Fix In" list, but not in the "Version" list. More than one branch could be associated with a version, so "alpha" and "beta" could both be considered "branches" under this system. I think that would handle our current problems, and would make bug list triage much more meaningful in a world with many branches. I think this would be worthwhile as a core Bugzilla feature because nearly every open-source and corporate user of Bugzilla has some need for Bugzilla to understand the idea of a "branch." (If you reply to this message from mozilla-dev-planning, make sure to CC me directly since I'm not on the list.) -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From mkanat at bugzilla.org Thu Jul 27 01:04:27 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 26 Jul 2006 18:04:27 -0700 Subject: Branch Intelligence in Bugzilla In-Reply-To: <1153961690.7166.10.camel@localhost.localdomain> References: <1153961690.7166.10.camel@localhost.localdomain> Message-ID: <1153962268.7166.15.camel@localhost.localdomain> Also: For searches, we could have a list of branches both on query.cgi and colchange.cgi. On colchange.cgi, you could set which branches you'd like to see the branch fields for. On query.cgi you could also set these, and they'd override what you selected as defaults on colchange.cgi. (Just wanted to get that down while it was in my mind.) -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From jochen.wiedmann at gmail.com Thu Jul 27 06:37:07 2006 From: jochen.wiedmann at gmail.com (Jochen Wiedmann) Date: Thu, 27 Jul 2006 08:37:07 +0200 Subject: Branch Intelligence in Bugzilla In-Reply-To: <1153961690.7166.10.camel@localhost.localdomain> References: <1153961690.7166.10.camel@localhost.localdomain> Message-ID: On 7/27/06, Max Kanat-Alexander wrote: > 1) Make the Version field a multi-select. > 2) Associate each Version with a "Branch". For example, 1.8.1, > 1.8.2, and 1.8.3 would all be associated with the "1.8 > Branch." > 3) For each affected branch, there would be two fields that > would appear on a bug: > > * Desire: ---, Unwanted, Would Take, Wanted, Required > Where "Required" would replace our current blocking > flags. > > * Fix In: (Put all branch versions here) > > "Fix In" would represent both the version we plan to fix it in, and the To me that sounds very much like your original "make Bugzilla too complex". And, although I am using branches in any of my open source and business projects very heavily, I do not even stand the rationale. In other words: If you do decide to put that in, please make it at least a configurable option and, by default, omit it from the GUI. If that should appear in any Bugzilla I am working with then the only thing I would expect would be weeks of discussion whether/how/when/why this should be used or whatever else. Jochen -- Whenever you find yourself on the side of the majority, it is time to pause and reflect. (Mark Twain) From mkanat at bugzilla.org Thu Jul 27 06:50:13 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 26 Jul 2006 23:50:13 -0700 Subject: Branch Intelligence in Bugzilla In-Reply-To: References: <1153961690.7166.10.camel@localhost.localdomain> Message-ID: <1153983013.2617.5.camel@localhost.localdomain> On Thu, 2006-07-27 at 08:37 +0200, Jochen Wiedmann wrote: > In other words: If you do decide to put that in, please make it at > least a configurable option and, by default, omit it from the GUI. Yes, I absolutely agree with you. It would not appear in the GUI unless enabled. It would only appear in products for which you specified more than one branch in editversions.cgi. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From justdave at bugzilla.org Thu Jul 27 07:04:27 2006 From: justdave at bugzilla.org (David Miller) Date: Thu, 27 Jul 2006 00:04:27 -0700 Subject: Bugzilla FAQ In-Reply-To: References: Message-ID: <44C8657B.60803@bugzilla.org> Benton, Kevin wrote on 7/26/06 2:12 PM: >> Benton, Kevin wrote on 7/26/06 9:54 AM: >>> Hey Dave - do you think it'd be a good idea to put a link to >> http://www.bugzilla.org/docs/tip/html/faq.html on the support page? :) >> >> Yes. I think pointing at the wiki version might be better. We should >> pull it back to the docs from there (so it's in the stuff included in >> the tarball) before each release. > > Would you like me to file a bug and/or patch for this or did you just > want to do it? Looks like we already have a bug on it: https://bugzilla.mozilla.org/show_bug.cgi?id=272886 If someone wants to do it, go for it, otherwise I'll try to remember it again sometime when I'm actually awake. -- 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 kairo at kairo.at Thu Jul 27 10:15:28 2006 From: kairo at kairo.at (Robert Kaiser) Date: Thu, 27 Jul 2006 12:15:28 +0200 Subject: Branch Intelligence in Bugzilla In-Reply-To: References: Message-ID: <44C89240.8080002@kairo.at> Max Kanat-Alexander schrieb: > * Fix In: (Put all branch versions here) > > "Fix In" would represent both the version we plan to fix it in, and the > version it was actually fixed in. How do we make sure then that bugs that had been targeted (planned) to be fixed in that release and actually didn't make it are not mistakenly marked as fixed when the release is actually out? The overall idea sounds good, but mixing the target and "fixed in" sounds a bit dangerous to me. Though I think replacing our "fixed*" keywords (possibly even "verified*"?) with such a branch-aware field would be really nice... Robert Kaiser From dwilliss at microimages.com Thu Jul 27 17:40:14 2006 From: dwilliss at microimages.com (Dave Williss) Date: Thu, 27 Jul 2006 12:40:14 -0500 Subject: Branch Intelligence in Bugzilla References: <44C89240.8080002@kairo.at> Message-ID: <17ff01c6b1a3$b7a09d60$4b00000a@opus2> I know at our site, we actually use the "Target Milestone" to indicate the version a bug was fixed in, and we don't usually even set it until it's fixed. Occasionally we will set it if a bug is marked as a blocker to indicate which version it's blocking. But we find a better way to mark bugs as blocking a release is to issue a bug with the summary something like "Get version X.Y out the door" and make it any bugs that would prevent the release a blocker of that bug. So for us, "Target Milestone" is used more for historical reference than planning. We would much rather have a "Fixed In" ----- Original Message ----- From: "Robert Kaiser" Newsgroups: mozilla.dev.planning To: "Max Kanat-Alexander" Cc: ; Sent: Thursday, July 27, 2006 5:15 AM Subject: Re: Branch Intelligence in Bugzilla > Max Kanat-Alexander schrieb: >> * Fix In: (Put all branch versions here) >> >> "Fix In" would represent both the version we plan to fix it in, and the >> version it was actually fixed in. > > How do we make sure then that bugs that had been targeted (planned) to > be fixed in that release and actually didn't make it are not mistakenly > marked as fixed when the release is actually out? > > The overall idea sounds good, but mixing the target and "fixed in" > sounds a bit dangerous to me. Though I think replacing our "fixed*" > keywords (possibly even "verified*"?) with such a branch-aware field > would be really nice... > > Robert Kaiser > - > To view or change your list settings, click here: > From kevin.benton at amd.com Thu Jul 27 20:52:13 2006 From: kevin.benton at amd.com (Benton, Kevin) Date: Thu, 27 Jul 2006 13:52:13 -0700 Subject: 2.23.2+ page top UI Message-ID: > The release notes for 2.23.2 indicates: > > - The UI at the top of each page has been generally improved. > > We did something very similar to our Bugzilla installation (2.20) and > the users thought it was great. I tried logging in to landfill to see > what it looks like, but the CVS tip is current borked for creating new > users. One thing we found to be pretty useful was to have a link to > the page "footer" in the page header since we didn't replicate all the > functionality present in the footer into the header (it just got too > long). Apologies if this isn't relevant, like I said, I couldn't log > in to check. In any event, I very much like the new style. That's a good one to send to the developers mailing list or to post in our IRC channel - irc.mozilla.org:6667#mozwebtools > My only regret is that I couldn't figure out a way to get the header > or footer to always stay on the page (prevent it from scrolling). > Frames are undesirable, and I'm not enough of a CSS wiz to figure out > how to deal with expanding (variable sized) headers. If "static > headers" could be solved, it would sure be nice to also have the > search headers and the top couple of lines for each Bug held "static" > also. Hello Aaron, It seems to me that you could potentially use CSS to do that by making a floating box that self-aligns to the top or bottom of the browser window. This would never work for text-only browsers, but providing a link to the page footer should suffice. :) --- Kevin Benton Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator AMD - ECSD Software Validation and Tools The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. From lpsolit at gmail.com Thu Jul 27 21:24:23 2006 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Thu, 27 Jul 2006 23:24:23 +0200 Subject: 2.23.2+ page top UI In-Reply-To: References: Message-ID: <44C92F07.8000505@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > It seems to me that you could potentially use CSS to do that by making a > floating box that self-aligns to the top or bottom of the browser > window. This would never work for text-only browsers, but providing a > link to the page footer should suffice. :) Mozilla-like browsers understand 'position: fixed' in CSS, but IE doesn't. And using JavaScript to refresh the position of the box is ugly. That's definitely a bad user experience. LpSolit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEyS7luG3TRgecPlsRAqOcAKCTh+Fu58+UE7wJqHI2sa/b/77JygCeJfpy mcOWLLlT2cBDhTvdSqC1QPo= =wx8z -----END PGP SIGNATURE----- From mkanat at bugzilla.org Thu Jul 27 21:42:04 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 27 Jul 2006 14:42:04 -0700 Subject: Branch Intelligence in Bugzilla In-Reply-To: <44C89240.8080002@kairo.at> References: <44C89240.8080002@kairo.at> Message-ID: <1154036525.5723.2.camel@localhost.localdomain> On Thu, 2006-07-27 at 12:15 +0200, Robert Kaiser wrote: > How do we make sure then that bugs that had been targeted (planned) to > be fixed in that release and actually didn't make it are not mistakenly > marked as fixed when the release is actually out? Because bugs get marked as FIXED when they're checked into CVS (or whatever SCM you're using), not when a release comes out. So at the time that somebody marks the bug as FIXED...oh, I see what you mean--do you mean that some organizations fix the branches at a different time than they fix the trunk? In that case you're probably right that it would be advantageous to note that something has actually *been* fixed on a branch. Does that actually happen that frequently, though, that something is fixed on the trunk but not on a branch? Usually in that case I just leave a bug open, and leave a comment on it... Anybody have a better idea that wouldn't involve making the proposed "branch" fields more complicated? -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From mkanat at bugzilla.org Thu Jul 27 21:51:07 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 27 Jul 2006 14:51:07 -0700 Subject: Branch Intelligence in Bugzilla In-Reply-To: <20060727182802.GA5452@ridley.dbaron.org> References: <1153962006.7166.12.camel@localhost.localdomain> <20060727182802.GA5452@ridley.dbaron.org> Message-ID: <1154037067.5723.9.camel@localhost.localdomain> On Thu, 2006-07-27 at 11:28 -0700, L. David Baron wrote: > For example, we're starting triage > for the 1.9 cycle around now, but it's not going to branch for more than > 6 months from now. Hrm. So perhaps a way to note that a certain branch always appear on all versions would be useful? And then later you can move the fields to showing up only on bugs filed against 1.9. But if you'd set any values in the fields on old bugs, the fields would still show up there. I'm just trying to come up with some *ideal* way to handle the situation that you're in, because it's actually an extremely common situation, and I'd like to be able to deploy it generically to all users of Bugzilla as a part of the upstream code. > If we had the > ability to have branch statuses for bugs we'd essentially want to copy > trunk status to branch status at the branch point. Okay, easy enough. So it might be good for Bugzilla to understand the idea that branches are related to other branches. That is, most branches come from the trunk, and thus anything on the trunk before "date X" is also on the branch. > If a bug is filed against the trunk, it might be a > regression since an already-existing branch branched, or it might be an > old bug that is also present on the branch. There could be significant > confusion if the bug system automatically assumed either default, so I > suspect an unknown status might be needed. Well, if you just selected that it affected the trunk, by my proposal the system wouldn't say *anything* about the branch until you also said that it affected the branch. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From mkanat at bugzilla.org Thu Jul 27 22:15:04 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 27 Jul 2006 15:15:04 -0700 Subject: Branch Intelligence in Bugzilla In-Reply-To: <44C9375C.7090606@mit.edu> References: <44C89240.8080002@kairo.at> <44C9375C.7090606@mit.edu> Message-ID: <1154038504.5723.31.camel@localhost.localdomain> On Thu, 2006-07-27 at 16:59 -0500, Boris Zbarsky wrote: > Max Kanat-Alexander wrote: > > Does that actually happen that frequently, though, that something is fixed on the > > trunk but not on a branch? > > 100% of the time, for Mozilla. Branch fixes require additional approvals, after > the the trunk fix has been verified. Okay, good point. So it sounds like branches also need their own Resolution field, which can be blank. I'm not sure they also need their own Status, though--seems like just Resolution would be enough. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From mkanat at bugzilla.org Thu Jul 27 22:21:28 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 27 Jul 2006 15:21:28 -0700 Subject: 2.23.2+ page top UI In-Reply-To: References: Message-ID: <1154038888.5723.33.camel@localhost.localdomain> > > but the CVS tip is current borked for creating new users. Just to let you know, it works fine for me. I just made a new user successfully on bugzilla-tip. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From bbaetz at acm.org Fri Jul 28 00:46:08 2006 From: bbaetz at acm.org (Bradley Baetz) Date: Fri, 28 Jul 2006 10:46:08 +1000 Subject: Branch Intelligence in Bugzilla In-Reply-To: <1154036525.5723.2.camel@localhost.localdomain> References: <44C89240.8080002@kairo.at> <1154036525.5723.2.camel@localhost.localdomain> Message-ID: <99435f5b0607271746i69d35e08x53bb5b70252853f2@mail.gmail.com> On 28/07/06, Max Kanat-Alexander wrote: > Because bugs get marked as FIXED when they're checked into CVS (or > whatever SCM you're using), not when a release comes out. So at the time > that somebody marks the bug as FIXED...oh, I see what you mean--do you > mean that some organizations fix the branches at a different time than > they fix the trunk? Yes - branches may need approval to check in to (or, in a more traditional model, 'released' to a particular environment). What would be nice is if a bug could be marked as fixed-in-cvs when the fix was in CVS, but not fixed on the branch. Developers could then look at what bugs were open, and project managers/etc could look at what bugs were fixed but not fixed on their env. > Anybody have a better idea that wouldn't involve making the proposed > "branch" fields more complicated? Oh. Umm.... :) Bradley From jochen.wiedmann at gmail.com Fri Jul 28 06:17:37 2006 From: jochen.wiedmann at gmail.com (Jochen Wiedmann) Date: Fri, 28 Jul 2006 08:17:37 +0200 Subject: Branch Intelligence in Bugzilla In-Reply-To: <1154036525.5723.2.camel@localhost.localdomain> References: <44C89240.8080002@kairo.at> <1154036525.5723.2.camel@localhost.localdomain> Message-ID: On 7/27/06, Max Kanat-Alexander wrote: > that somebody marks the bug as FIXED...oh, I see what you mean--do you > mean that some organizations fix the branches at a different time than > they fix the trunk? Yes, of course. It's quite usual to develop a "fix" (which may of course as well be a new feature, in other words something larger) in the trunk and backport it later. Jochen -- Whenever you find yourself on the side of the majority, it is time to pause and reflect. (Mark Twain) From dbaron at dbaron.org Thu Jul 27 18:28:02 2006 From: dbaron at dbaron.org (L. David Baron) Date: Thu, 27 Jul 2006 11:28:02 -0700 Subject: Branch Intelligence in Bugzilla In-Reply-To: <1153962006.7166.12.camel@localhost.localdomain> References: <1153962006.7166.12.camel@localhost.localdomain> Message-ID: <20060727182802.GA5452@ridley.dbaron.org> On Wednesday 2006-07-26 18:00 -0700, Max Kanat-Alexander wrote: > 1) Make the Version field a multi-select. > 2) Associate each Version with a "Branch". For example, 1.8.1, > 1.8.2, and 1.8.3 would all be associated with the "1.8 > Branch." > 3) For each affected branch, there would be two fields that > would appear on a bug: > > * Desire: ---, Unwanted, Would Take, Wanted, Required > Where "Required" would replace our current blocking > flags. > > * Fix In: (Put all branch versions here) There are things where having Bugzilla be able to branch the status of bugs would be useful. However, I don't think this solves the triage problem, because we want to start triage for a release long before there's a branch associated with it. For example, we're starting triage for the 1.9 cycle around now, but it's not going to branch for more than 6 months from now. So we want a triage concept for it now, but we don't want to make all developers have to mark everything as fixed-on-trunk *and* fixed-for-1.9 for the next six months. I think these are two separate problems. Branching bug status simultaneously with cvs status could be useful, although I'm not sure the complexity is worth it. The biggest thing it could help with is that doing bugzilla queries to determine which bugs are fixed on a branch with our current keyword system can be very difficult because the 'fixed1.8' keyword only appears on bugs fixed on the branch *after* the branch separated from the trunk. If we had the ability to have branch statuses for bugs we'd essentially want to copy trunk status to branch status at the branch point. However, the complexity comes from the requirement for unknown status on other branches. If a bug is filed against the trunk, it might be a regression since an already-existing branch branched, or it might be an old bug that is also present on the branch. There could be significant confusion if the bug system automatically assumed either default, so I suspect an unknown status might be needed. -David -- L. David Baron Technical Lead, Layout & CSS, Mozilla Corporation -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bzbarsky at mit.edu Thu Jul 27 21:59:56 2006 From: bzbarsky at mit.edu (Boris Zbarsky) Date: Thu, 27 Jul 2006 16:59:56 -0500 Subject: Branch Intelligence in Bugzilla In-Reply-To: References: <44C89240.8080002@kairo.at> Message-ID: <44C9375C.7090606@mit.edu> Max Kanat-Alexander wrote: > Does that actually happen that frequently, though, that something is fixed on the > trunk but not on a branch? 100% of the time, for Mozilla. Branch fixes require additional approvals, after the the trunk fix has been verified. > Usually in that case I just leave a bug open, and leave a comment on it... That gives really bad tracking of what's fixed on trunk. -Boris From Aaron at larsonsonline.net Fri Jul 28 00:23:41 2006 From: Aaron at larsonsonline.net (Aaron Larson) Date: Thu, 27 Jul 2006 19:23:41 -0500 Subject: 2.23.2+ page top UI In-Reply-To: <1154038888.5723.33.camel@localhost.localdomain> (Max Kanat-Alexander's message of "Thu, 27 Jul 2006 15:21:28 -0700") References: <1154038888.5723.33.camel@localhost.localdomain> Message-ID: <87mzaua86q.fsf@aaron2.LarsonsOnline.net> >>>>> "MK" == Max Kanat-Alexander writes: >> > but the CVS tip is current borked for creating new users. MK> Just to let you know, it works fine for me. I just made a new user MK> successfully on bugzilla-tip. Sorry, should have been more precise. I created the user o.k., but when responding to the "Your Bugzilla password." email and attempting to log in for the first time I get: Software error: DBI::st=HASH(0xabe31e0)->_prepare(...): attribute parameter 'aaron at larsonsonline.net' is not a hash ref at /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi/DBD/Pg.pm line 188. For help, please send mail to the webmaster (webmaster at bugzilla.org), giving this error message and the time and date of the error. From jochen.wiedmann at gmail.com Fri Jul 28 07:56:10 2006 From: jochen.wiedmann at gmail.com (Jochen Wiedmann) Date: Fri, 28 Jul 2006 09:56:10 +0200 Subject: Branch Intelligence in Bugzilla In-Reply-To: <44C9375C.7090606@mit.edu> References: <44C89240.8080002@kairo.at> <44C9375C.7090606@mit.edu> Message-ID: On 7/27/06, Boris Zbarsky wrote: > 100% of the time, for Mozilla. Branch fixes require additional approvals, after > the the trunk fix has been verified. Which makes me wonder whether this branch thingys model is any good. In my mind I do see this as a meta bug with several dependent bugs (one per branch). In other words, it might possibly be sufficient to support creating the meta bug and the dependent bugs at one go. Jochen -- My wife Mary and I have been married for forty-seven years and not once have we had an argument serious enough to consider divorce; murder, yes, but divorce, never. (Jack Benny) From dbaron at dbaron.org Fri Jul 28 08:34:49 2006 From: dbaron at dbaron.org (L. David Baron) Date: Fri, 28 Jul 2006 01:34:49 -0700 Subject: Branch Intelligence in Bugzilla In-Reply-To: <1154037067.5723.9.camel@localhost.localdomain> References: <1153962006.7166.12.camel@localhost.localdomain> <20060727182802.GA5452@ridley.dbaron.org> <1154037067.5723.9.camel@localhost.localdomain> Message-ID: <20060728083449.GA12936@ridley.dbaron.org> On Thursday 2006-07-27 14:51 -0700, Max Kanat-Alexander wrote: > On Thu, 2006-07-27 at 11:28 -0700, L. David Baron wrote: > > For example, we're starting triage > > for the 1.9 cycle around now, but it's not going to branch for more than > > 6 months from now. > > Hrm. So perhaps a way to note that a certain branch always appear on > all versions would be useful? And then later you can move the fields to > showing up only on bugs filed against 1.9. But if you'd set any values > in the fields on old bugs, the fields would still show up there. I'm really not sure what it is that you're suggesting, or how it would help. Frankly, I've never found the version field very useful -- it's simply a snapshot of one version on which the bug is present. I think if bugzilla understood branches, the original reporter could choose a version, and that version would be translated to status information on the relevant branch, plus text in the initial comment of the bug, and then disappear. > > If a bug is filed against the trunk, it might be a > > regression since an already-existing branch branched, or it might be an > > old bug that is also present on the branch. There could be significant > > confusion if the bug system automatically assumed either default, so I > > suspect an unknown status might be needed. > > Well, if you just selected that it affected the trunk, by my proposal > the system wouldn't say *anything* about the branch until you also said > that it affected the branch. But there would also probably need to be a way of saying that a bug does *not* affect the branch. -David -- L. David Baron Technical Lead, Layout & CSS, Mozilla Corporation -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Aaron at larsonsonline.net Fri Jul 28 14:48:42 2006 From: Aaron at larsonsonline.net (Aaron Larson) Date: Fri, 28 Jul 2006 09:48:42 -0500 Subject: 2.23.2+ page top UI In-Reply-To: (Kevin Benton's message of "Thu, 27 Jul 2006 13:52:13 -0700") References: Message-ID: <87irlhaiph.fsf@aaron2.LarsonsOnline.net> >>>>> "KB" == Benton, Kevin writes: AL> My only regret is that I couldn't figure out a way to get the AL> header or footer to always stay on the page (prevent it from AL> scrolling). Frames are undesirable, and I'm not enough of a CSS AL> wiz to figure out how to deal with expanding (variable sized) AL> headers. If "static headers" could be solved, it would sure be AL> nice to also have the search headers and the top couple of lines AL> for each Bug held "static" also. KB> ... It seems to me that you could potentially use CSS to do that KB> by making a floating box that self-aligns to the top or bottom of KB> the browser window.... I tried that, but I could never come up with CSS that reasonably handled resizing windows (which might change the number of lines in the header) or changing the font size. What I really wanted to say in CSS was "whatever the size of this box needs to be, just put it at the top of the window". I eventually came to the conclusion that CSS was not powerful enough to do it, but it could just be that my skills were inadequate for the job (or both). From john.fisher at znyx.com Fri Jul 28 16:26:16 2006 From: john.fisher at znyx.com (John P. Fisher) Date: Fri, 28 Jul 2006 09:26:16 -0700 Subject: Branch Intelligence in Bugzilla In-Reply-To: <44C9375C.7090606@mit.edu> References: <44C89240.8080002@kairo.at> <44C9375C.7090606@mit.edu> Message-ID: <44CA3AA8.8090300@znyx.com> I hope you don't mind a lurker poking in 2cents worth... I modified a Bugzilla 2.17 vintage to include found-in and fixed-in fields, a branch field for differing CVS branches, and cloned bugs to keep track of single problems that occur in multiple code trees. ( i.e. the algorithm is roughly the same, but the code is separate ) It should be noted that we have several different hardware platforms, that have somewhat different APIs and capability/capacity. anyway. Its turns out that Test are the most fanatical about the clones/branches and fixed-in requirement. They need to keep track of which fix they tested on which hardware- just because it works on the A model doesn't mean it works on the T model. you get the idea... So to answer Max's question, its true all the time for us too, but tracking testing is equally important. We don't have enough engineers to fix everything everywhere right away. Who does? John Boris Zbarsky wrote: > Max Kanat-Alexander wrote: >> Does that actually happen that frequently, though, that something is >> fixed on the >> trunk but not on a branch? > > 100% of the time, for Mozilla. Branch fixes require additional > approvals, after the the trunk fix has been verified. > >> Usually in that case I just leave a bug open, and leave a comment on >> it... > > That gives really bad tracking of what's fixed on trunk. > > -Boris > - > To view or change your list settings, click here: > > From mkanat at bugzilla.org Fri Jul 28 20:02:25 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 28 Jul 2006 13:02:25 -0700 Subject: Bugzilla Meeting Minutes: 2006-07-24 Message-ID: <1154116945.2652.14.camel@es-lappy> We had our meeting on Monday this week, because justdave was at OSCON starting Tuesday. If you were unable to attend, you can see the log here: http://bugzilla.glob.com.au/irc/?c=bugzilla-meeting&s=24+Jul+2006&e=24+Jul+2006 * Only one major regression in 2.23.2, you can't enter a bug. It's already been fixed: https://bugzilla.mozilla.org/show_bug.cgi?id=344497 * We are going to release a new dev. snapshot soon. There will also be a 2.18.6, 2.20.3, and 2.22.1. I could use help with the releases from anybody who'd like to volunteer. * Since we've released 2.23.2, we have: custom resolutions, shared Saved Searches, working mod_perl, fully-functional plain-text custom fields, and improved performance for installations with many products. * We're behind with the Bug.pm work for Bugzilla 3.0. (bug 211922 and dependencies). * justdave finalized the Module Owners: http://wiki.mozilla.org/Bugzilla:Owners This is a significant change to the development process of Bugzilla, so you'll probably want to read it. * The basic framework for Bugzilla's XML-RPC interface is very close to being checked in. After that we want to figure out a stable API for it, and then implement it. The API should be stable across versions of Bugzilla. * There's a consensus to remove the REMIND and LATER resolutions from the default list. People can add them back if they want, now that we have custom resolutions. Existing installations probably won't be modified, though. * We eventually want to have a UI that allows Bugzilla administrators to specify field-level group controls, like "group A is allowed to change field X". * Testopia 1.0 RC1 is ready. -Max -- http://www.everythingsolved.com/ Everything Solved: Competent, Friendly Bugzilla and Linux Services From gerv at mozilla.org Fri Jul 28 22:55:03 2006 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 28 Jul 2006 23:55:03 +0100 Subject: Branch Intelligence in Bugzilla In-Reply-To: References: <1153961690.7166.10.camel@localhost.localdomain> Message-ID: <44CA95C7.2000301@mozilla.org> Jochen Wiedmann wrote: > To me that sounds very much like your original "make Bugzilla too > complex". It sounds a bit like it to me, too :-| Note that Google, in their very-recently-announced hosting project, is moving in the opposite direction - less structured fields, more tags, and better search. While we don't have their search fu, we might want to pause before making the Bugzilla UI even more complex, given that this is one of the things it's often criticised for. Gerv From mkanat at bugzilla.org Sat Jul 29 00:42:15 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 28 Jul 2006 17:42:15 -0700 Subject: checksetup on the run! Message-ID: <1154133736.2652.23.camel@es-lappy> I'm doing some major, major hacking to checksetup.pl, as a part of this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=bz-checksetup Basically, almost all of checksetup is going to end up in modules under the Bugzilla::Install namespace. It's moving extremely fast right now, so if you touch a part of checksetup in any current patch it's extremely likely to rot, and I do apologize. Once things are in the modules they're relatively more stable. If you have a patch that touches checksetup and it's super-close to approval, and you don't want to have to fix the bitrot, mention it to me and I'll try not to touch that part of checksetup until you've checked-in your patch. Finally, I'm doing extremely extensive testing, and we do have test-checksetup.pl to catch me if something goes horribly wrong, but there's still always a chance of something breaking, particularly when editing code as strange as checksetup. So be careful when upgrading your installation to the tip, for the next few weeks. Keep backups of your data/ directory, your localconfig file, and your database. There are some cool results already, though. Try doing "perldoc checksetup.pl" on the tip, and you can see its perldoc. :-) Eventually, one day, I hope that a lot of the checksetup code can run from a CGI, granting the wish of many, many users. -Max -- http://www.everythingsolved.com/ Everything Solved: Competent, Friendly Bugzilla and Linux Services From mkanat at bugzilla.org Sun Jul 30 07:58:18 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sun, 30 Jul 2006 00:58:18 -0700 Subject: Windows Testing Machine Message-ID: <1154246298.4789.3.camel@localhost.localdomain> If anybody has a Windows machine that I could connect to remotely to test my checksetup patches, I'd really appreciate it. Right now I'm editing a lot of code, and although I'm not really *changing* a lot of it, I'd still like to make sure that all my changes still work on Windows. Also, I was considering enhancing checksetup.pl to work even better on Windows (perhaps actually make it able to set file permissions). Anyhow, for all this I'd need access to some Windows machine that has MySQL, perl, and Apache installed on it. (And preferably also IIS, if possible.) If anybody out there could give me remote (rdesktop or VNC) access to such a machine, send me an email directly and let me know. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From jpyeron at pdinc.us Sun Jul 30 15:00:40 2006 From: jpyeron at pdinc.us (Jason Pyeron) Date: Sun, 30 Jul 2006 11:00:40 -0400 Subject: Windows Testing Machine In-Reply-To: <1154246298.4789.3.camel@localhost.localdomain> Message-ID: <200607301500.k6UF0j904122@ns.pyerotechnics.com> How about a vmware instance of w2k? You should be able to set it real easy. -----Original Message----- From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] On Behalf Of Max Kanat-Alexander Sent: Sunday, July 30, 2006 3:58 To: developers at bugzilla.org Subject: Windows Testing Machine If anybody has a Windows machine that I could connect to remotely to test my checksetup patches, I'd really appreciate it. Right now I'm editing a lot of code, and although I'm not really *changing* a lot of it, I'd still like to make sure that all my changes still work on Windows. Also, I was considering enhancing checksetup.pl to work even better on Windows (perhaps actually make it able to set file permissions). Anyhow, for all this I'd need access to some Windows machine that has MySQL, perl, and Apache installed on it. (And preferably also IIS, if possible.) If anybody out there could give me remote (rdesktop or VNC) access to such a machine, send me an email directly and let me know. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. - To view or change your list settings, click here: From mkanat at bugzilla.org Sun Jul 30 15:50:04 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sun, 30 Jul 2006 08:50:04 -0700 Subject: Windows Testing Machine In-Reply-To: <200607301500.k6UF0j904122@ns.pyerotechnics.com> References: <200607301500.k6UF0j904122@ns.pyerotechnics.com> Message-ID: <1154274604.2459.6.camel@localhost.localdomain> On Sun, 2006-07-30 at 11:00 -0400, Jason Pyeron wrote: > How about a vmware instance of w2k? Yeah, that would be perfect, I just don't own a copy of Windows 2000. It's the actual Windows license that I lack, in this particular situation, which is why I need access to somebody else's machine. :-) -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From jpyeron at pdinc.us Sun Jul 30 15:57:43 2006 From: jpyeron at pdinc.us (Jason Pyeron) Date: Sun, 30 Jul 2006 11:57:43 -0400 Subject: Windows Testing Machine In-Reply-To: <1154274604.2459.6.camel@localhost.localdomain> Message-ID: <200607301557.k6UFvm904979@ns.pyerotechnics.com> Would you be willing to ssh -> ssh -> vnc to one? I can see what we can do if that is ok. -----Original Message----- From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] On Behalf Of Max Kanat-Alexander Sent: Sunday, July 30, 2006 11:50 To: developers at bugzilla.org Subject: Re: Windows Testing Machine On Sun, 2006-07-30 at 11:00 -0400, Jason Pyeron wrote: > How about a vmware instance of w2k? Yeah, that would be perfect, I just don't own a copy of Windows 2000. It's the actual Windows license that I lack, in this particular situation, which is why I need access to somebody else's machine. :-) -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. - To view or change your list settings, click here: From kevin.benton at amd.com Mon Jul 31 15:54:11 2006 From: kevin.benton at amd.com (Benton, Kevin) Date: Mon, 31 Jul 2006 08:54:11 -0700 Subject: Branch Intelligence in Bugzilla Message-ID: > On Thu, 2006-07-27 at 12:15 +0200, Robert Kaiser wrote: > > How do we make sure then that bugs that had been targeted (planned) to > > be fixed in that release and actually didn't make it are not mistakenly > > marked as fixed when the release is actually out? > > Because bugs get marked as FIXED when they're checked into CVS (or > whatever SCM you're using), not when a release comes out. So at the time > that somebody marks the bug as FIXED...oh, I see what you mean--do you > mean that some organizations fix the branches at a different time than > they fix the trunk? > > In that case you're probably right that it would be advantageous to > note that something has actually *been* fixed on a branch. Does that > actually happen that frequently, though, that something is fixed on the > trunk but not on a branch? Usually in that case I just leave a bug open, > and leave a comment on it... > > Anybody have a better idea that wouldn't involve making the proposed > "branch" fields more complicated? Target Milestone is used here to reflect the version we *want* an issue fixed in, and commitment (new field) is used to reflect when an issue must be fixed. RESOLVED is when an issue passes development's testing. VERIFIED is when Validation (Q/A) has completed testing to the point where they are confident that the patch can be applied to the trunk without negative impact. CLOSED is when the fix is released to our customers. We also have a requirement that each effected branch has a bug filed because each will require its own testing, so we don't have a problem with version cross-over. When a bug hits a CLOSED state here, it has a traceable history with our customized fixed_in_rev and found_in_rev fields telling us where it was fixed and found (found meaning the earliest revision the issue was seen in). When it turns out that we're just entering Errata, we also have an errata_to_rev field. All three of these fields key off a single version table for the product. For a bug to be filed, a found_in_rev is required. For a bug to enter the RESOLVED state, either fixed_in_rev or errata_to_rev must be valid. By default, these fields are 0 which is auto-replaced with "N/A". If a bug goes to the REOPENED state, the fixed_in_rev and/or errata_to_rev fields are automatically cleared. --- Kevin Benton Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator AMD - ECSD Software Validation and Tools The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication.