From LpSolit at gmail.com Wed Mar 1 16:15:59 2006 From: LpSolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Wed, 01 Mar 2006 17:15:59 +0100 Subject: What kind of home page for Bugzilla? Message-ID: <4405C8BF.1030405@gmail.com> Yesterday, we had our 3rd Bugzilla meeting (minutes not yet available) and one of the topics was: What do we want to see on the home page when accessing Bugzilla (homepage = index.cgi)? It appeared that the actual index.cgi page is pretty useless, i.e. contains nothing useful, at least for "advanced" users, and probably for newbies too. So we were thinking about displaying data based on a user pref (for instance, products you are interested in), such as new bugs filed in the last 24 hours for your favorite product(s),... or something else. So the question is: what would *you* like to see first (either when being logged in or not)? LpSolit From bugzilla at chimpychompy.org Wed Mar 1 16:57:04 2006 From: bugzilla at chimpychompy.org (Gavin Shelley) Date: Wed, 1 Mar 2006 16:57:04 +0000 Subject: What kind of home page for Bugzilla? In-Reply-To: <4405C8BF.1030405@gmail.com> References: <4405C8BF.1030405@gmail.com> Message-ID: I like: http://bugzilla.neooffice.org/ (With some extra stats columns for individual products) On 1 Mar 2006, at 16:15, Fr?d?ric Buclin wrote: > > > So the question is: what would *you* like to see first (either when > being logged in or not)? > From kevin.benton at amd.com Wed Mar 1 18:26:49 2006 From: kevin.benton at amd.com (Benton, Kevin) Date: Wed, 1 Mar 2006 10:26:49 -0800 Subject: What kind of home page for Bugzilla? Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4204C3201C@ssvlexmb2.amd.com> I agree - that is a very nice opening page. I think it would require us to add a new table, newsitems (or something like it) with dates to display certain items (start/stop). I also think it would be wise for us to display certain news items to users who have not been to the site before (new user info, etc), and to those that are not currently logged in (that have been to the site before). --- Kevin Benton Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator Personal Computing Systems Group Advanced Micro Devices 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 Gavin Shelley > Sent: Wednesday, March 01, 2006 9:57 AM > To: developers at bugzilla.org > Subject: Re: What kind of home page for Bugzilla? > > I like: http://bugzilla.neooffice.org/ > > (With some extra stats columns for individual products) > > > On 1 Mar 2006, at 16:15, Fr?d?ric Buclin wrote: > > > > > > > So the question is: what would *you* like to see first (either when > > being logged in or not)? > > > > - > To view or change your list settings, click here: > From kevin.benton at amd.com Wed Mar 1 18:40:51 2006 From: kevin.benton at amd.com (Benton, Kevin) Date: Wed, 1 Mar 2006 10:40:51 -0800 Subject: Technology requirements in browsers Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4204C32039@ssvlexmb2.amd.com> I'm wondering what others are feeling about this: At what point do we decide to stop supporting browsers that don't have JavaScript/CSS2 support available? I know that for some, this might sound like a radical idea. From my perspective, I've begun shifting my focus somewhat from trying to support every browser out there to recognizing that we don't necessarily have to support the oldest technology in our newest versions. While I think it's fair to say we ought to be able to support at least 98% of the users (not 98% of the browsers) out there; I think that we could do a lot better by not allowing ourselves to get tied to very old technology as we move forward. I think that at some point, it makes sense to say that we won't support "advanced" Bugzilla features in very old technology (VOT) browsers that don't support JavaScript and CSS2. That is not to say that we should allow VOT browsers to file and update bugs, but I think it's fair to say that we could do a lot more to make Bugzilla 1) look prettier, and 2) work more intuitively for users if we can say bye-bye to some of the self-imposed limitations. NeoOffice Bugzilla (http://bugzilla.neooffice.org ) is a perfect example from their main page. Some of those menu items at the top would be perfect for JavaScript drop-downs. News that automatically rotates every n seconds would also be something that would require advanced browser features. Quick stats could easily be reworked slightly to handle multiple products on mouseover, etc. I'm just thinking out loud and wondering what direction the rest of the group thinks we ought to take based on these items. --- Kevin Benton Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator Personal Computing Systems Group Advanced Micro Devices 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 tree at basistech.com Wed Mar 1 18:50:19 2006 From: tree at basistech.com (Tom Emerson) Date: Wed, 1 Mar 2006 13:50:19 -0500 Subject: What kind of home page for Bugzilla? In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4204C3201C@ssvlexmb2.amd.com> References: <6F7DA19D05F3CF40B890C7CA2DB13A4204C3201C@ssvlexmb2.amd.com> Message-ID: <17413.60651.222460.729791@tiphares.basistech.net> Benton, Kevin writes: > I agree - that is a very nice opening page. I think it would > require us to add a new table, newsitems (or something like it) with > dates to display certain items (start/stop). I also think it would > be wise for us to display certain news items to users who have not > been to the site before (new user info, etc), and to those that are > not currently logged in (that have been to the site before). A 'news' table would be a useful addition in general, I think, in addition to the other informational details that the neooffice page has. Perhaps template snippets could be written that a site admin could combine as they wish on their customized home page. -tree -- Tom Emerson Basis Technology Corp. Software Architect http://www.basistech.com "You can't fake quality any more than you can fake a good meal." (W.S.B.) From luis.villa at gmail.com Wed Mar 1 19:32:07 2006 From: luis.villa at gmail.com (Luis Villa) Date: Wed, 1 Mar 2006 14:32:07 -0500 Subject: Technology requirements in browsers In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4204C32039@ssvlexmb2.amd.com> References: <6F7DA19D05F3CF40B890C7CA2DB13A4204C32039@ssvlexmb2.amd.com> Message-ID: <2cb10c440603011132s29ae9dd5n83fd6175aea77c0a@mail.gmail.com> On 3/1/06, Benton, Kevin wrote: > > > > I'm wondering what others are feeling about this: > > > > At what point do we decide to stop supporting browsers that don't have > JavaScript/CSS2 support available? I know that for some, this might sound > like a radical idea. From my perspective, I've begun shifting my focus > somewhat from trying to support every browser out there to recognizing that > we don't necessarily have to support the oldest technology in our newest > versions. While I think it's fair to say we ought to be able to support at > least 98% of the users (not 98% of the browsers) out there; I think that we > could do a lot better by not allowing ourselves to get tied to very old > technology as we move forward. I think that at some point, it makes sense > to say that we won't support "advanced" Bugzilla features in very old > technology (VOT) browsers that don't support JavaScript and CSS2. That is > not to say that we should allow VOT browsers to file and update bugs, but I > think it's fair to say that we could do a lot more to make Bugzilla 1) look > prettier, and 2) work more intuitively for users if we can say bye-bye to > some of the self-imposed limitations. NeoOffice Bugzilla > (http://bugzilla.neooffice.org) is a perfect example from their main page. > Some of those menu items at the top would be perfect for JavaScript > drop-downs. News that automatically rotates every n seconds would also be > something that would require advanced browser features. Quick stats could > easily be reworked slightly to handle multiple products on mouseover, etc. > > > > I'm just thinking out loud and wondering what direction the rest of the > group thinks we ought to take based on these items. (1) Lots of javascript and CSS stuff is flash for flash's sake, which is never good for a serious development tool. (2) That said, you can do a *lot* of useful stuff in jscript and CSS, and I think we should. I once hacked up a dynamically sortable buglist that was quite nice, for example, and judicious use of ajax-y techniques could greatly improve the usability of the search forms. Remember that the target audience for bugzilla is primarily developers, not the general public*, and developers are usually more willing and able to move to newer browsers more quickly. We shouldn't shy away from newer tech if it'll make the tool markedly better and won't kill too many browsers. Luis * no matter how easy you make the bug submission page :) From vladd at bugzilla.org Wed Mar 1 20:05:24 2006 From: vladd at bugzilla.org (Vlad Dascalu) Date: Wed, 01 Mar 2006 22:05:24 +0200 Subject: Technology requirements in browsers In-Reply-To: <2cb10c440603011132s29ae9dd5n83fd6175aea77c0a@mail.gmail.com> References: <6F7DA19D05F3CF40B890C7CA2DB13A4204C32039@ssvlexmb2.amd.com> <2cb10c440603011132s29ae9dd5n83fd6175aea77c0a@mail.gmail.com> Message-ID: <4405FE84.5090000@bugzilla.org> Functionality (basic) should be available to Lynx users. Considering that, we can do CSS or javascript-only, or AJAX-only improvements (we already have such improvements for non-Lynx users: images, for example). Vlad Luis Villa wrote: > On 3/1/06, Benton, Kevin wrote: > >> >> I'm wondering what others are feeling about this: >> >> >> >> At what point do we decide to stop supporting browsers that don't have >> JavaScript/CSS2 support available? I know that for some, this might sound >> like a radical idea. From my perspective, I've begun shifting my focus >> somewhat from trying to support every browser out there to recognizing that >> we don't necessarily have to support the oldest technology in our newest >> versions. While I think it's fair to say we ought to be able to support at >> least 98% of the users (not 98% of the browsers) out there; I think that we >> could do a lot better by not allowing ourselves to get tied to very old >> technology as we move forward. I think that at some point, it makes sense >> to say that we won't support "advanced" Bugzilla features in very old >> technology (VOT) browsers that don't support JavaScript and CSS2. That is >> not to say that we should allow VOT browsers to file and update bugs, but I >> think it's fair to say that we could do a lot more to make Bugzilla 1) look >> prettier, and 2) work more intuitively for users if we can say bye-bye to >> some of the self-imposed limitations. NeoOffice Bugzilla >> (http://bugzilla.neooffice.org) is a perfect example from their main page. >> Some of those menu items at the top would be perfect for JavaScript >> drop-downs. News that automatically rotates every n seconds would also be >> something that would require advanced browser features. Quick stats could >> easily be reworked slightly to handle multiple products on mouseover, etc. >> >> >> >> I'm just thinking out loud and wondering what direction the rest of the >> group thinks we ought to take based on these items. >> > > (1) Lots of javascript and CSS stuff is flash for flash's sake, which > is never good for a serious development tool. > > (2) That said, you can do a *lot* of useful stuff in jscript and CSS, > and I think we should. I once hacked up a dynamically sortable buglist > that was quite nice, for example, and judicious use of ajax-y > techniques could greatly improve the usability of the search forms. > > Remember that the target audience for bugzilla is primarily > developers, not the general public*, and developers are usually more > willing and able to move to newer browsers more quickly. We shouldn't > shy away from newer tech if it'll make the tool markedly better and > won't kill too many browsers. > > Luis > * no matter how easy you make the bug submission page :) > > - > To view or change your list settings, click here: > > > > From justdave at bugzilla.org Wed Mar 1 21:06:28 2006 From: justdave at bugzilla.org (David Miller) Date: Wed, 01 Mar 2006 16:06:28 -0500 Subject: Technology requirements in browsers In-Reply-To: <4405FE84.5090000@bugzilla.org> References: <6F7DA19D05F3CF40B890C7CA2DB13A4204C32039@ssvlexmb2.amd.com> <2cb10c440603011132s29ae9dd5n83fd6175aea77c0a@mail.gmail.com> <4405FE84.5090000@bugzilla.org> Message-ID: <44060CD4.6010400@bugzilla.org> Vlad Dascalu wrote on 3/1/06 3:05 PM: > Functionality (basic) should be available to Lynx users. > > Considering that, we can do CSS or javascript-only, or AJAX-only > improvements (we already have such improvements for non-Lynx users: > images, for example). Yeah, this is my view as well. Let's make things pretty and functional with the advanced technology, but as long as the basics still work in eLinks and Lynx I'll be happy. We actually have developers at mozilla.org that use eLinks with Bugzilla because they do their development work on remote machines and for whatever reason find it easier to run a browser on the machine they're shelled into than on their local machine. eLinks actually supports Javascript, btw. It doesn't do a very good job of it yet though. -- 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 tree at basistech.com Wed Mar 1 21:36:12 2006 From: tree at basistech.com (Tom Emerson) Date: Wed, 1 Mar 2006 16:36:12 -0500 Subject: Technology requirements in browsers In-Reply-To: <44060CD4.6010400@bugzilla.org> References: <6F7DA19D05F3CF40B890C7CA2DB13A4204C32039@ssvlexmb2.amd.com> <2cb10c440603011132s29ae9dd5n83fd6175aea77c0a@mail.gmail.com> <4405FE84.5090000@bugzilla.org> <44060CD4.6010400@bugzilla.org> Message-ID: <17414.5068.688278.913116@tiphares.basistech.net> David Miller writes: > We actually have developers at mozilla.org that use eLinks with Bugzilla [...] Speaking of which: can you easily generate statistics on UA versions accessing b.m.o (minimally) or all of mozilla.org to see what percentage of use is via old browsers that can't deal with CSS or JS? -tree -- Tom Emerson Basis Technology Corp. Software Architect http://www.basistech.com "You can't fake quality any more than you can fake a good meal." (W.S.B.) From myk at mozilla.org Wed Mar 1 21:40:31 2006 From: myk at mozilla.org (Myk Melez) Date: Wed, 01 Mar 2006 13:40:31 -0800 Subject: Technology requirements in browsers In-Reply-To: <44060CD4.6010400@bugzilla.org> References: <6F7DA19D05F3CF40B890C7CA2DB13A4204C32039@ssvlexmb2.amd.com> <2cb10c440603011132s29ae9dd5n83fd6175aea77c0a@mail.gmail.com> <4405FE84.5090000@bugzilla.org> <44060CD4.6010400@bugzilla.org> Message-ID: <440614CF.9020709@mozilla.org> David Miller wrote: > Vlad Dascalu wrote on 3/1/06 3:05 PM: >> Functionality (basic) should be available to Lynx users. >> >> Considering that, we can do CSS or javascript-only, or AJAX-only >> improvements (we already have such improvements for non-Lynx users: >> images, for example). > > Yeah, this is my view as well. Let's make things pretty and > functional with the advanced technology, but as long as the basics > still work in eLinks and Lynx I'll be happy. Unfortunately the devil is in the details (what's "basic"?), and supporting even basic functionality in these browsers is a lot more work and code complexity, which represents a significant opportunity cost. The time and energy we spend supporting them we can't spend making things even better for the vast majority of our users. I suggest we drop the requirement to support these browsers but allow developers to continue to implement such support if they want it or have users who want it. This way we place the onus for supporting these browsers on the folks for whom they matter instead of making everyone pay the tax for this tiny minority of users. -myk From justdave at bugzilla.org Wed Mar 1 21:55:17 2006 From: justdave at bugzilla.org (David Miller) Date: Wed, 01 Mar 2006 16:55:17 -0500 Subject: Technology requirements in browsers In-Reply-To: <440614CF.9020709@mozilla.org> References: <6F7DA19D05F3CF40B890C7CA2DB13A4204C32039@ssvlexmb2.amd.com> <2cb10c440603011132s29ae9dd5n83fd6175aea77c0a@mail.gmail.com> <4405FE84.5090000@bugzilla.org> <44060CD4.6010400@bugzilla.org> <440614CF.9020709@mozilla.org> Message-ID: <44061845.5030607@bugzilla.org> Myk Melez wrote on 3/1/06 4:40 PM: > I suggest we drop the requirement to support these browsers but allow > developers to continue to implement such support if they want it or have > users who want it. This way we place the onus for supporting these > browsers on the folks for whom they matter instead of making everyone > pay the tax for this tiny minority of users. Works for me. We know timeless will do it anyway, he's the one who cares ;) -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From mkanat at bugzilla.org Wed Mar 1 21:59:18 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 01 Mar 2006 13:59:18 -0800 Subject: Technology requirements in browsers In-Reply-To: <440614CF.9020709@mozilla.org> References: <6F7DA19D05F3CF40B890C7CA2DB13A4204C32039@ssvlexmb2.amd.com> <2cb10c440603011132s29ae9dd5n83fd6175aea77c0a@mail.gmail.com> <4405FE84.5090000@bugzilla.org> <44060CD4.6010400@bugzilla.org> <440614CF.9020709@mozilla.org> Message-ID: <1141250359.3215.7.camel@es-lappy> On Wed, 2006-03-01 at 13:40 -0800, Myk Melez wrote: > I suggest we drop the requirement to support these browsers but allow > developers to continue to implement such support if they want it or have > users who want it. This way we place the onus for supporting these > browsers on the folks for whom they matter instead of making everyone > pay the tax for this tiny minority of users. Okay. So then would we say that the minimum browser requirements would be: * Safari 1.0 * IE 5.5 * Mozilla 1.0? Perhaps the Mozilla version could be higher, but it might be nice to still support the NS7 users for 2.24/3.0. -Max -- http://www.everythingsolved.com/ Everything Solved: Competent, Friendly Bugzilla and Linux Services From kevin.benton at amd.com Wed Mar 1 22:29:35 2006 From: kevin.benton at amd.com (Benton, Kevin) Date: Wed, 1 Mar 2006 14:29:35 -0800 Subject: Technology requirements in browsers Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4204C321B1@ssvlexmb2.amd.com> > On Wed, 2006-03-01 at 13:40 -0800, Myk Melez wrote: > > I suggest we drop the requirement to support these browsers but allow > > developers to continue to implement such support if they want it or have > > users who want it. This way we place the onus for supporting these > > browsers on the folks for whom they matter instead of making everyone > > pay the tax for this tiny minority of users. > > Okay. So then would we say that the minimum browser requirements > would > be: > > * Safari 1.0 > * IE 5.5 > * Mozilla 1.0? > > Perhaps the Mozilla version could be higher, but it might be nice to > still support the NS7 users for 2.24/3.0. I suggest we have technology requirements rather than specific browser versions. That way, we don't need to add new browsers when they begin to meet the standards. So, I would rather see things like: XHTML CSS 2 ECMAScript 1 ... --- Kevin Benton Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator Personal Computing Systems Group Advanced Micro Devices 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 engine at gmail.com Wed Mar 1 22:42:13 2006 From: engine at gmail.com (Jeff) Date: Wed, 1 Mar 2006 17:42:13 -0500 Subject: Technology requirements in browsers In-Reply-To: <44061845.5030607@bugzilla.org> References: <6F7DA19D05F3CF40B890C7CA2DB13A4204C32039@ssvlexmb2.amd.com> <2cb10c440603011132s29ae9dd5n83fd6175aea77c0a@mail.gmail.com> <4405FE84.5090000@bugzilla.org> <44060CD4.6010400@bugzilla.org> <440614CF.9020709@mozilla.org> <44061845.5030607@bugzilla.org> Message-ID: <14943db30603011442g1d3891sb4fc70a541c84041@mail.gmail.com> Hi, Not sure I'm allowed to say anything on this mailling list (feel free to put me in my place), but there's a section in the Developer's Guide that should probably be updated with whatever is decided here: _______snip________ While Bugzilla uses Javascript and cookies to make the user experience easier, no patch to Bugzilla should *require* either. The only exception is that the administrative interfaces (the edit* CGIs) may require JavaScript, as we expect the administrator to have a JavaScript-capable browser. ------------------------------------ http://www.bugzilla.org/docs/developer.html -Jeff On 3/1/06, David Miller wrote: > > Myk Melez wrote on 3/1/06 4:40 PM: > > > I suggest we drop the requirement to support these browsers but allow > > developers to continue to implement such support if they want it or have > > users who want it. This way we place the onus for supporting these > > browsers on the folks for whom they matter instead of making everyone > > pay the tax for this tiny minority of users. > > Works for me. We know timeless will do it anyway, he's the one who cares > ;) > > -- > 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: > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From LpSolit at gmail.com Wed Mar 1 22:44:53 2006 From: LpSolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Wed, 01 Mar 2006 23:44:53 +0100 Subject: Technology requirements in browsers In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4204C321B1@ssvlexmb2.amd.com> References: <6F7DA19D05F3CF40B890C7CA2DB13A4204C321B1@ssvlexmb2.amd.com> Message-ID: <440623E5.6050802@gmail.com> > XHTML > CSS 2 > ECMAScript 1 Why XHTML? I would prefer HTML 4.01 Strict. From mkanat at bugzilla.org Wed Mar 1 23:33:16 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 01 Mar 2006 15:33:16 -0800 Subject: Technology requirements in browsers In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4204C321B1@ssvlexmb2.amd.com> References: <6F7DA19D05F3CF40B890C7CA2DB13A4204C321B1@ssvlexmb2.amd.com> Message-ID: <1141255996.5874.15.camel@es-lappy> On Wed, 2006-03-01 at 14:29 -0800, Benton, Kevin wrote: > XHTML Technically that would eliminate even IE 6. But effectively it would only eliminate IE 5.0. Do you mean XHTML 1.0 Strict? That's what I'm assuming. > ECMAScript 1 Probably more important is the level of DOM support. Nearly all browsers in existence support most of ECMAScript. -Max -- http://www.everythingsolved.com/ Everything Solved: Competent, Friendly Bugzilla and Linux Services From myk at mozilla.org Wed Mar 1 23:45:10 2006 From: myk at mozilla.org (Myk Melez) Date: Wed, 01 Mar 2006 15:45:10 -0800 Subject: Technology requirements in browsers In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4204C321B1@ssvlexmb2.amd.com> References: <6F7DA19D05F3CF40B890C7CA2DB13A4204C321B1@ssvlexmb2.amd.com> Message-ID: <44063206.8040706@mozilla.org> Benton, Kevin wrote: > I suggest we have technology requirements rather than specific browser > versions. That way, we don't need to add new browsers when they begin > to meet the standards. Good idea. > So, I would rather see things like: > > XHTML > CSS 2 > ECMAScript 1 > We might outline the policy change broadly (f.e. we'll allow the use of technologies supported by popular browsers or available to most web users), but given that we're opening up new possibilities and don't yet have lots of implementation experience, I suggest we take a wait and see approach to specifying exactly which technologies we allow and give our developers some room to experiment and present us with some implmentations. -myk From mkanat at bugzilla.org Wed Mar 1 23:49:51 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 01 Mar 2006 15:49:51 -0800 Subject: We now require perl 5.8 Message-ID: <1141256991.5874.23.camel@es-lappy> Just so everybody knows, we know require perl 5.8.0 on the tip. This allows us to do various things, in particular, we can now: * "use fields" for modules, if we want (which we should, I think) * "use Switch" (instead of faking switch statements) * Use various utf8 and encoding functions that are built-in to perl, if we want. * We might want to consider using Attribute::Handlers for some reason or another in some of our objects. Perhaps we could save some of our repetitive code by using our own custom attributes. * We can now do "use if" for our optional modules. * We can use List::Util if we want. * For certain performance-critical functions, we can use the Memoize module. This should be used sparingly. * We may want to "use open ':utf8'" wherever we open files. * Storable is always included, we no longer need to check for it. * MIME::Base64 is always included, although if we need a specific version we should still check for it. * We can use Scalar::Util. A simple example is that we can use "Scalar::Util::tainted" instead of our "is_tainted." * Test::More, Test::Simple, and Test::Balanced are always available. * The release notes say "The Test module has been significantly enhanced," although I'm not sure what the enhancements are. * GetOpt::Long is always available, we should always use it instead of special ways of reading command-line arguments. -Max -- http://www.everythingsolved.com/ Everything Solved: Competent, Friendly Bugzilla and Linux Services From kevin.benton at amd.com Thu Mar 2 00:21:39 2006 From: kevin.benton at amd.com (Benton, Kevin) Date: Wed, 1 Mar 2006 16:21:39 -0800 Subject: Technology requirements in browsers Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4204C3225B@ssvlexmb2.amd.com> > Benton, Kevin wrote: > > I suggest we have technology requirements rather than specific browser > > versions. That way, we don't need to add new browsers when they begin > > to meet the standards. > Good idea. > > > So, I would rather see things like: > > > > XHTML > > CSS 2 > > ECMAScript 1 > > > We might outline the policy change broadly (f.e. we'll allow the use of > technologies supported by popular browsers or available to most web > users), but given that we're opening up new possibilities and don't yet > have lots of implementation experience, I suggest we take a wait and see > approach to specifying exactly which technologies we allow and give our > developers some room to experiment and present us with some > implmentations. I agree. Note that my reasoning behind throwing out the list above was to simply pass along an example. In no way was it intended to be a real suggestion of technology requirements. I'd need to do more research before making any kind of suggestion there. Having said that, when CSS3 becomes widely adopted, it'll make preparing text for printing far easier than it is now. I'm already using CSS2 with HTML(4) to do literary artwork, but CSS3 would be a lot better. I think CSS2 seems like a very reasonable requirement because it'll make handling dynamic fields a bunch easier. :) --- Kevin Benton Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator Personal Computing Systems Group Advanced Micro Devices 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 djm at mindrot.org Thu Mar 2 00:42:50 2006 From: djm at mindrot.org (Damien Miller) Date: Thu, 2 Mar 2006 11:42:50 +1100 (EST) Subject: Technology requirements in browsers In-Reply-To: <440614CF.9020709@mozilla.org> References: <6F7DA19D05F3CF40B890C7CA2DB13A4204C32039@ssvlexmb2.amd.com> <2cb10c440603011132s29ae9dd5n83fd6175aea77c0a@mail.gmail.com> <4405FE84.5090000@bugzilla.org> <44060CD4.6010400@bugzilla.org> <440614CF.9020709@mozilla.org> Message-ID: On Wed, 1 Mar 2006, Myk Melez wrote: > Unfortunately the devil is in the details (what's "basic"?), and > supporting even basic functionality in these browsers is a lot more > work and code complexity, which represents a significant opportunity > cost. The time and energy we spend supporting them we can't spend > making things even better for the vast majority of our users. > > I suggest we drop the requirement to support these browsers but allow > developers to continue to implement such support if they want it or > have users who want it. This way we place the onus for supporting > these browsers on the folks for whom they matter instead of making > everyone pay the tax for this tiny minority of users. I won't presume to tell developers how to spend their time, but please make it clear in the relnotes when you drop support for Lynx so I can look for another bug tracking product. The ability to search & edit bugs, download or upload files, etc. directly from a Unix system where development or testing is taking place is simply too useful to discard. -d From altlst at sonic.net Thu Mar 2 01:05:22 2006 From: altlst at sonic.net (Albert Ting) Date: Wed, 1 Mar 2006 17:05:22 -0800 Subject: What kind of home page for Bugzilla? In-Reply-To: References: <4405C8BF.1030405@gmail.com> Message-ID: <17414.17618.168298.626006@arm.com> Gavin Shelley writes: > From: Gavin Shelley > To: developers at bugzilla.org > Subject: Re: What kind of home page for Bugzilla? > Date: Wed, 1 Mar 2006 16:57:04 +0000 > > I like: http://bugzilla.neooffice.org/ > > (With some extra stats columns for individual products) This looks nice. But if a person was already logged in, it would be nice if it displayed the user's top bugzilla tickets, stats, etc. Sort of like a custom home page. From Nick.Barnes at pobox.com Thu Mar 2 09:33:21 2006 From: Nick.Barnes at pobox.com (Nick Barnes) Date: Thu, 02 Mar 2006 09:33:21 +0000 Subject: Technology requirements in browsers In-Reply-To: from Damien Miller of "Thu, 02 Mar 2006 11:42:50 +1100" Message-ID: <77527.1141292001@thrush.ravenbrook.com> At 2006-03-02 00:42:50+0000, Damien Miller writes: > I won't presume to tell developers how to spend their time, but please > make it clear in the relnotes when you drop support for Lynx so I can > look for another bug tracking product. > > The ability to search & edit bugs, download or upload files, etc. > directly from a Unix system where development or testing is taking place > is simply too useful to discard. I have considerable sympathy for this point of view, but from a different direction: in testing the P4DTI we use several of the Bugzilla interfaces from a python script. This is easy as long as it is possible to get basic Bugzilla functionality from any program which can talk HTTP. The underlying requirement here is to be able to obtain data, and perform actions, from a simple script on a remote machine. The current method we use is to craft simple HTTP requests, and to use an XML parser to suck data out of the resulting pages. Any other similarly easy method would suffice for us. CSS is probably not a problem, because (I suspect) it would only be used for rendering. In fact it might well make it easier for us, by allowing us to pick elements out based on div tags and id attributes. As for ECMAscript, that all depends. As Bugzilla moves down the road to AJAX, sooner or later third-party scripts are going to have to do XML/RPC, to "look like" an embedded ECMAscript widget. That might be OK, but we would like it flagged up well in advance. Nick B From luis.villa at gmail.com Thu Mar 2 13:31:45 2006 From: luis.villa at gmail.com (Luis Villa) Date: Thu, 2 Mar 2006 08:31:45 -0500 Subject: Technology requirements in browsers In-Reply-To: <77527.1141292001@thrush.ravenbrook.com> References: <77527.1141292001@thrush.ravenbrook.com> Message-ID: <2cb10c440603020531i6b661711p26fc0552263e8b2@mail.gmail.com> On 3/2/06, Nick Barnes wrote: > I have considerable sympathy for this point of view, but from a > different direction: in testing the P4DTI we use several of the > Bugzilla interfaces from a python script. This is easy as long as it > is possible to get basic Bugzilla functionality from any program which > can talk HTTP. Wouldn't the right thing to do here be to finish the XML-RPC APIs? Luis From kevin.benton at amd.com Thu Mar 2 15:53:33 2006 From: kevin.benton at amd.com (Benton, Kevin) Date: Thu, 2 Mar 2006 07:53:33 -0800 Subject: Technology requirements in browsers Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4204C32445@ssvlexmb2.amd.com> > > Unfortunately the devil is in the details (what's "basic"?), and > > supporting even basic functionality in these browsers is a lot more > > work and code complexity, which represents a significant opportunity > > cost. The time and energy we spend supporting them we can't spend > > making things even better for the vast majority of our users. > > > > I suggest we drop the requirement to support these browsers but allow > > developers to continue to implement such support if they want it or > > have users who want it. This way we place the onus for supporting > > these browsers on the folks for whom they matter instead of making > > everyone pay the tax for this tiny minority of users. > > I won't presume to tell developers how to spend their time, but please > make it clear in the relnotes when you drop support for Lynx so I can > look for another bug tracking product. > > The ability to search & edit bugs, download or upload files, etc. > directly from a Unix system where development or testing is taking place > is simply too useful to discard. Hi Damien. I'm certainly not suggesting that we abandon the basic support we've always had to allow users to enter new bugs and handle basic bug updates via an interface that works in basic HTML. On the other hand, I don't think it's fair to ask us to tie one hand behind our backs while writing more advanced features in Bugzilla because we're going to keep someone from being able to use them in lynx. You can still ride horses as a method to get to/from work, but that doesn't mean that it should prevent me from driving my car, does it? As a society, we made a decision that it's safer for people to stay off high-speed highways if they're on foot, bicycle, horseback, etc. because the speed differentials are incompatible for safety's sake. At some point, I think it's fair to say that this community is going to make a decision to start using some of the more advanced tools available to us for providing information back to users. Unfortunately, some of that stuff is not compatible with browsers like lynx. Creating user interfaces that provide the best experience for the greatest percentage of users we serve is (I think) our biggest concern. No matter how functional our software is, if it doesn't work in a way that the majority (of users) appreciates and understands, they won't use it. My boss's boss said something to a group of us a few days ago that made a bunch of sense. "Leading isn't leading if nobody is following you. If nobody is following you, you're just out for a walk in the park." We can't lead if nobody is following us. I think there is a very large segment of the potential user community that doesn't use Bugzilla because we aren't using more pull down menus, user-side input validation, etc. Regardless of what we do with the user interface, it'll remain very important for us to continue to provide a reliable and stable API that works with other software. It seems to me that a WAP-like interface into Bugzilla (on top of our API) makes sense at some point. I think that kind of interface might work well with lynx also. Maybe you'd like to help us develop that part of Bugzilla? --- Kevin Benton Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator Personal Computing Systems Group Advanced Micro Devices 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 dennis.melentyev at infopulse.com.ua Thu Mar 2 17:53:08 2006 From: dennis.melentyev at infopulse.com.ua (Dennis Melentyev) Date: Thu, 02 Mar 2006 19:53:08 +0200 Subject: Technology requirements in browsers In-Reply-To: <2cb10c440603020531i6b661711p26fc0552263e8b2@mail.gmail.com> References: <77527.1141292001@thrush.ravenbrook.com> <2cb10c440603020531i6b661711p26fc0552263e8b2@mail.gmail.com> Message-ID: <44073104.3030601@infopulse.com.ua> Luis Villa wrote: > On 3/2/06, Nick Barnes wrote: > >>I have considerable sympathy for this point of view, but from a >>different direction: in testing the P4DTI we use several of the >>Bugzilla interfaces from a python script. This is easy as long as it >>is possible to get basic Bugzilla functionality from any program which >>can talk HTTP. > > > Wouldn't the right thing to do here be to finish the XML-RPC APIs? 100% argee. The main thing for me is UI have to be divided from functionality. So, one who need human-less operation (cron-based lynx or HTTP modules or other not-fully-browsers-things) would be able to call some API (say, Bugzilla-client CPAN module?) to do their stuff. With HTML UI left to most of people with modern browsers. From tree at basistech.com Thu Mar 2 18:29:40 2006 From: tree at basistech.com (Tom Emerson) Date: Thu, 2 Mar 2006 13:29:40 -0500 Subject: Technology requirements in browsers In-Reply-To: <44073104.3030601@infopulse.com.ua> References: <77527.1141292001@thrush.ravenbrook.com> <2cb10c440603020531i6b661711p26fc0552263e8b2@mail.gmail.com> <44073104.3030601@infopulse.com.ua> Message-ID: <17415.14740.800009.696695@tiphares.basistech.net> Dennis Melentyev writes: [...] > other not-fully-browsers-things) would be able to call some API (say, > Bugzilla-client CPAN module?) to do their stuff. More Perl lockin? Blech. Better a SOAP or XML/RPC that can be used from multiple languages and applications... -- Tom Emerson Basis Technology Corp. Software Architect http://www.basistech.com "You can't fake quality any more than you can fake a good meal." (W.S.B.) From gerv at mozilla.org Thu Mar 2 20:22:18 2006 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 02 Mar 2006 20:22:18 +0000 Subject: What kind of home page for Bugzilla? In-Reply-To: <17413.60651.222460.729791@tiphares.basistech.net> References: <6F7DA19D05F3CF40B890C7CA2DB13A4204C3201C@ssvlexmb2.amd.com> <17413.60651.222460.729791@tiphares.basistech.net> Message-ID: <440753FA.5090103@mozilla.org> Tom Emerson wrote: > A 'news' table would be a useful addition in general, I think, in > addition to the other informational details that the neooffice page > has. Perhaps template snippets could be written that a site admin > could combine as they wish on their customized home page. I think the correct way to add news to the front page is not to implement a Bugzilla interface for adding, removing and managing news items, but to allow an RSS feed to be easily plugged into the page. Is there a TT module for doing that? Gerv From tree at basistech.com Thu Mar 2 20:32:49 2006 From: tree at basistech.com (Tom Emerson) Date: Thu, 2 Mar 2006 15:32:49 -0500 Subject: What kind of home page for Bugzilla? In-Reply-To: <440753FA.5090103@mozilla.org> References: <6F7DA19D05F3CF40B890C7CA2DB13A4204C3201C@ssvlexmb2.amd.com> <17413.60651.222460.729791@tiphares.basistech.net> <440753FA.5090103@mozilla.org> Message-ID: <17415.22129.908689.557797@tiphares.basistech.net> Gervase Markham writes: > Tom Emerson wrote: > > A 'news' table would be a useful addition in general, I think, in > > addition to the other informational details that the neooffice page > > has. Perhaps template snippets could be written that a site admin > > could combine as they wish on their customized home page. > > I think the correct way to add news to the front page is not to > implement a Bugzilla interface for adding, removing and managing news > items, but to allow an RSS feed to be easily plugged into the page. Huh? So in that design if I want to make news available just to the BZ user community in my organization I need to find other software to manage the feed? What a PITA. Sure, being able to do RSS would be useful, I suppose, but the work involved in managing news items is trivial and would be immediately useful to people. -- Tom Emerson Basis Technology Corp. Software Architect http://www.basistech.com "You can't fake quality any more than you can fake a good meal." (W.S.B.) From kevin.benton at amd.com Thu Mar 2 20:55:04 2006 From: kevin.benton at amd.com (Benton, Kevin) Date: Thu, 2 Mar 2006 12:55:04 -0800 Subject: What kind of home page for Bugzilla? Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4204C32642@ssvlexmb2.amd.com> Gervase Markham wrote: > Tom Emerson wrote: > > A 'news' table would be a useful addition in general, I think, in > > addition to the other informational details that the neooffice page > > has. Perhaps template snippets could be written that a site admin > > could combine as they wish on their customized home page. > > I think the correct way to add news to the front page is not to > implement a Bugzilla interface for adding, removing and managing news > items, but to allow an RSS feed to be easily plugged into the page. > > Is there a TT module for doing that? http://www.tt2.org/docs/plain/Modules/Template/Plugin/XML/RSS.html --- Kevin Benton Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator Personal Computing Systems Group Advanced Micro Devices The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. From gerv at mozilla.org Thu Mar 2 21:20:16 2006 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 02 Mar 2006 21:20:16 +0000 Subject: What kind of home page for Bugzilla? In-Reply-To: <17415.22129.908689.557797@tiphares.basistech.net> References: <6F7DA19D05F3CF40B890C7CA2DB13A4204C3201C@ssvlexmb2.amd.com> <17413.60651.222460.729791@tiphares.basistech.net> <440753FA.5090103@mozilla.org> <17415.22129.908689.557797@tiphares.basistech.net> Message-ID: <44076190.6040408@mozilla.org> Tom Emerson wrote: > Huh? So in that design if I want to make news available just to the BZ > user community in my organization I need to find other software to > manage the feed? What a PITA. No... if it's just for you, you can override the front page template and add the markup by hand. That would be just about as easy as typing it into a web form. There are tons of simple bits of blogging software out there which can be set up in short order and which will provide RSS feeds. We should not be reinventing that wheel. Gerv From tree at basistech.com Thu Mar 2 21:48:06 2006 From: tree at basistech.com (Tom Emerson) Date: Thu, 2 Mar 2006 16:48:06 -0500 Subject: What kind of home page for Bugzilla? In-Reply-To: <44076190.6040408@mozilla.org> References: <6F7DA19D05F3CF40B890C7CA2DB13A4204C3201C@ssvlexmb2.amd.com> <17413.60651.222460.729791@tiphares.basistech.net> <440753FA.5090103@mozilla.org> <17415.22129.908689.557797@tiphares.basistech.net> <44076190.6040408@mozilla.org> Message-ID: <17415.26646.522382.224006@tiphares.basistech.net> Gervase Markham writes: > Tom Emerson wrote: > > Huh? So in that design if I want to make news available just to the BZ > > user community in my organization I need to find other software to > > manage the feed? What a PITA. > > No... if it's just for you, you can override the front page template and > add the markup by hand. That would be just about as easy as typing it > into a web form. Great, so every time I need to provide news to my users, I have to log into the bz machine and change the index page manually, instead of using the existing BZ admin interface. Ass backwards. > There are tons of simple bits of blogging software out there which can > be set up in short order and which will provide RSS feeds. We should not > be reinventing that wheel. This isn't a wheel to reinvent. It's a trivial piece of functionality that would be useful to, I expect, a wide number of sites, and wouldn't require a lot of work. Why should I go out and install blogging software for this. Whatever. -- Tom Emerson Basis Technology Corp. Software Architect http://www.basistech.com "You can't fake quality any more than you can fake a good meal." (W.S.B.) From mkanat at bugzilla.org Thu Mar 2 22:29:52 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 02 Mar 2006 14:29:52 -0800 Subject: Technology requirements in browsers In-Reply-To: <17415.14740.800009.696695@tiphares.basistech.net> References: <77527.1141292001@thrush.ravenbrook.com> <2cb10c440603020531i6b661711p26fc0552263e8b2@mail.gmail.com> <44073104.3030601@infopulse.com.ua> <17415.14740.800009.696695@tiphares.basistech.net> Message-ID: <1141338593.3275.2.camel@localhost.localdomain> On Thu, 2006-03-02 at 13:29 -0500, Tom Emerson wrote: > Better a SOAP or XML/RPC that can be used > from multiple languages and applications... That is fully our intention: https://bugzilla.mozilla.org/show_bug.cgi?id=webservices -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From kevin.benton at amd.com Fri Mar 3 00:16:41 2006 From: kevin.benton at amd.com (Benton, Kevin) Date: Thu, 2 Mar 2006 16:16:41 -0800 Subject: What kind of home page for Bugzilla? Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4204C327B1@ssvlexmb2.amd.com> Gervase Markham wrote: > Tom Emerson wrote: > > Huh? So in that design if I want to make news available just to the BZ > > user community in my organization I need to find other software to > > manage the feed? What a PITA. > > No... if it's just for you, you can override the front page template and > add the markup by hand. That would be just about as easy as typing it > into a web form. > > There are tons of simple bits of blogging software out there which can > be set up in short order and which will provide RSS feeds. We should not > be reinventing that wheel. I don't think it's fair to put that kind of burden on our users - to expect them to understand HTML and Template Toolkit lingo enough to successfully modify their own news items. I also think that the RSS idea isn't the best for high-availability requirements systems because RSS adds another possible point of failure. I do believe, however, that a news maintenance section to Bugzilla makes a lot of sense. I see Bugzilla as a tool that encapsulates data it relies on internally (as much as possible). While I'm not saying don't do RSS, I think a newsitems table is more administrator-friendly for those who don't have the time/energy/expertise to go through setting up RSS to work with Bugzilla. --- Kevin Benton Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator Personal Computing Systems Group Advanced Micro Devices 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 Thu Mar 2 18:07:15 2006 From: kevin.benton at amd.com (Benton, Kevin) Date: Thu, 2 Mar 2006 10:07:15 -0800 Subject: Technology requirements in browsers Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4204C3251A@ssvlexmb2.amd.com> Dennis Melentyev wrote: > Luis Villa wrote: > > On 3/2/06, Nick Barnes wrote: > > > >>I have considerable sympathy for this point of view, but from a > >>different direction: in testing the P4DTI we use several of the > >>Bugzilla interfaces from a python script. This is easy as long as it > >>is possible to get basic Bugzilla functionality from any program which > >>can talk HTTP. > > > > > > Wouldn't the right thing to do here be to finish the XML-RPC APIs? > 100% argee. > The main thing for me is UI have to be divided from functionality. So, > one who need human-less operation (cron-based lynx or HTTP modules or > other not-fully-browsers-things) would be able to call some API (say, > Bugzilla-client CPAN module?) to do their stuff. With HTML UI left to > most of people with modern browsers. That sounds like a very reasonable requirement to me. Is that on the 3.0 roadmap? I've misplaced the URL and couldn't get to it from the htdig link (gives internal server error). --- Kevin Benton Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator Personal Computing Systems Group Advanced Micro Devices 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 Fri Mar 3 09:37:32 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 03 Mar 2006 01:37:32 -0800 Subject: Landfill Tinderbox Clients Message-ID: <1141378653.8781.2.camel@localhost.localdomain> I wrote a new perl module, Tinderbox::Client, and I'm testing it out by switching over all the Bugzilla tinderboxes to use it. I seem to have them all working properly now, but let me know if you see any problems. Also, it's super-simple for me to set up new tinderboxes that run any sort of command now, so let me know if you'd like one for some reason. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From dennis.melentyev at infopulse.com.ua Fri Mar 3 11:14:11 2006 From: dennis.melentyev at infopulse.com.ua (Dennis Melentyev) Date: Fri, 03 Mar 2006 13:14:11 +0200 Subject: Technology requirements in browsers In-Reply-To: <17415.14740.800009.696695@tiphares.basistech.net> References: <77527.1141292001@thrush.ravenbrook.com> <2cb10c440603020531i6b661711p26fc0552263e8b2@mail.gmail.com> <44073104.3030601@infopulse.com.ua> <17415.14740.800009.696695@tiphares.basistech.net> Message-ID: <44082503.80207@infopulse.com.ua> Tom Emerson wrote: > Dennis Melentyev writes: > [...] > >>other not-fully-browsers-things) would be able to call some API (say, >>Bugzilla-client CPAN module?) to do their stuff. > > > More Perl lockin? Blech. Better a SOAP or XML/RPC that can be used > from multiple languages and applications... > I did not say that it should not be SOAP or XML/RPC based. I just need a command-line interface to remote bugzilla instances. Since most scripts are in Perl, it's easier to have just another CPAN module. I don't care would it contact server via XML/RPC or plain Ethernet packets. Just think of it as of Perl binding for Bugzilla API. So, it looks like we agree on this :) From Guillaume.Rousse at inria.fr Fri Mar 3 14:07:21 2006 From: Guillaume.Rousse at inria.fr (Guillaume Rousse) Date: Fri, 03 Mar 2006 15:07:21 +0100 Subject: We now require perl 5.8 In-Reply-To: <1141256991.5874.23.camel@es-lappy> References: <1141256991.5874.23.camel@es-lappy> Message-ID: <44084D99.3090705@inria.fr> Max Kanat-Alexander wrote: > * "use Switch" (instead of faking switch statements) According to switch module maintainer himself, that is really not a good idea :) From mkanat at bugzilla.org Fri Mar 3 21:15:03 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 03 Mar 2006 13:15:03 -0800 Subject: We now require perl 5.8 In-Reply-To: <44084D99.3090705@inria.fr> References: <1141256991.5874.23.camel@es-lappy> <44084D99.3090705@inria.fr> Message-ID: <1141420503.3259.4.camel@localhost.localdomain> On Fri, 2006-03-03 at 15:07 +0100, Guillaume Rousse wrote: > Max Kanat-Alexander wrote: > > * "use Switch" (instead of faking switch statements) > > According to switch module maintainer himself, that is really not a good > idea :) Really? Why? Could you point me to where he says that? -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From LpSolit at gmail.com Sun Mar 5 15:14:09 2006 From: LpSolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Sun, 05 Mar 2006 16:14:09 +0100 Subject: Minutes of the 3rd Bugzilla meeting Message-ID: <440B0041.7000302@gmail.com> We met last Tuesday, Feb 28, for our 3rd Bugzilla meeting on IRC: http://bugzilla.glob.com.au/irc/?c=bugzilla-meeting&a=date&s=28+Feb+2006&e=28+Feb+2006&h= Briefly: - One week after the 2.16.11, 2.18.5, 2.20.1 and 2.22rc1 releases, only one regression has been reported, affecting 2.20.1 and 2.22rc1: "unable to log in the very first time on a new installation when using the login form on the homepage". This bug, which was due to a regression from one of our security bugs, has been fixed. This makes us think that we don't need a second release candidate for 2.22, and so we expect to release 2.22 final in two weeks (around March 15, 2006). - Due to the lack of download stats, we don't know if nobody reported another regressions because there are none or because very few people downloaded our latest releases. Let's hope that's because there are none. :) - 2.16.11 was probably our last release on the 2.16 branch, as we will stop support for this branch together with the release of 2.22 in two weeks. - mkanat is working on killing both data/versioncache and globals.pl, out first two tasks of our roadmap. Some work has been done already, but he is now blocked by the way Auth.pm works. He is working on it. Maybe you noticed that globals.pl is already 300 lines shorter? :) He thinks versioncache should be completely dead during the second half of April. - No progress has been done about removing deprecated DB routines though. - The actual home page (index.cgi) seems to be pretty useless for everyone, especially for advanced users, i.e. it contains no useful information. gandalf will work on it. - We keep crashing when creating a product/component which existed in the past and which has been deleted meanwhile, because Series.pm tries to insert duplicated entries into the DB. We suggested to offer an option to either remove series data from the DB when the product/component is removed, or store it in another table, for instance as a CSV file. This way, you can decide whether you want to keep product history or not. karl will work on it. - We will meet again on Tuesday, March 14, 2006, at 19:00 GMT (11:00 PST). LpSolit From bugreport at peshkin.net Sun Mar 5 16:25:56 2006 From: bugreport at peshkin.net (Joel Peshkin) Date: Sun, 05 Mar 2006 08:25:56 -0800 Subject: Minutes of the 3rd Bugzilla meeting In-Reply-To: <440B0041.7000302@gmail.com> References: <440B0041.7000302@gmail.com> Message-ID: <440B1114.9060609@peshkin.net> > > > - Due to the lack of download stats, we don't know if nobody reported > another regressions because there are none or because very few people > downloaded our latest releases. Let's hope that's because there are > none. :) > You can get a "hint" about the take-rate for live sites using.... http://www.google.com/search?hl=en&lr=&safe=off&q=%22Bugzilla+Version+2.20%22+%2B%22Main+Page%22&btnG=Search If you change that to 2.18, you get 500 hits instead of 16. From mkanat at bugzilla.org Mon Mar 6 08:52:35 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 06 Mar 2006 00:52:35 -0800 Subject: A New Bugzilla::Auth Message-ID: <1141635155.19684.4.camel@localhost.localdomain> In order to pave the way for mod_perl support, one of the largest tasks I had was to re-write Bugzilla::Auth to not require a BEGIN block. Since I had to restructure it anyway, I did a lot of re-architecture. In effect, we have an entirely new Bugzilla::Auth system, that should be more flexible and easier to write new plugins for. To maintain stability, I kept nearly all the old Bugzilla::Auth code, I just moved it around a lot. It was a huge task (probably about 20-30 hours of actual coding), but I have now finished a working patch. As it's such a large re-write, I'd really like many eyes to look over it. It's at: https://bugzilla.mozilla.org/show_bug.cgi?id=300410 I've written a long, detailed guide to the patch in a comment on the bug, including a "How to Review This Patch" section. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From gerv at mozilla.org Mon Mar 6 09:45:34 2006 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 06 Mar 2006 09:45:34 +0000 Subject: What kind of home page for Bugzilla? In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4204C327B1@ssvlexmb2.amd.com> References: <6F7DA19D05F3CF40B890C7CA2DB13A4204C327B1@ssvlexmb2.amd.com> Message-ID: <440C04BE.9090704@mozilla.org> Benton, Kevin wrote: > I don't think it's fair to put that kind of burden on our users - to > expect them to understand HTML and Template Toolkit lingo enough to > successfully modify their own news items. They wouldn't need to understand TT. - Open file - Insert news item above other news items, inside

tags - Save file > I also think that the RSS > idea isn't the best for high-availability requirements systems because > RSS adds another possible point of failure. It would be an unusual high-availability Bugzilla which also needed high-availability for the news items on the front page. > I do believe, however, that > a news maintenance section to Bugzilla makes a lot of sense. I see > Bugzilla as a tool that encapsulates data it relies on internally (as > much as possible). Absolutely; and it does not rely on the content of news postings about itself. > While I'm not saying don't do RSS, I think a > newsitems table is more administrator-friendly for those who don't have > the time/energy/expertise to go through setting up RSS to work with > Bugzilla. But it's not just that, is it? It's like any additional feature - not only does it have to be maintained, but people keep requesting enhancements to it. "Let's have a rich text editor, a better posting interface, automatic dating, categories, tagging..." and you end up reinventing existing software, where you get all this included. RSS is designed specifically for the purpose of allowing sites to display news items etc. from other sites. It seems to me that leveraging this already-existing infrastructure, software and design expertise is a no-brainer. Particularly as TT has an RSS tool. But then, I'm not the person who has a veto here, Dave is. I've made my point. :-) Gerv From simon.steele at softel.co.uk Mon Mar 6 10:39:13 2006 From: simon.steele at softel.co.uk (Simon Steele) Date: Mon, 6 Mar 2006 10:39:13 -0000 Subject: What kind of home page for Bugzilla? Message-ID: > RSS is designed specifically for the purpose of allowing sites to > display news items etc. from other sites. It seems to me that leveraging > this already-existing infrastructure, software and design expertise is a > no-brainer. Particularly as TT has an RSS tool. These seemingly opposing goals do not need to be separate: use RSS data as the source for the news display mechanism, and if necessary provide a configuration page that adds news to an RSS formatted document. This way the display code is developed once supporting all forms of RSS feed and the authoring (if added) works with a standard storage format. The potential benefits of supporting RSS here are big, allowing information from numerous useful sources (like CI systems for example) to be drawn into the page. You could also automatically include bugzilla search results on the front page if they can be suitably formatted as RSS - thus removing the need for any custom work to support front-page lists. Simon. ________________________________________________________________________ This e-mail has been scanned for viruses by MessageLabs. From tree at basistech.com Mon Mar 6 16:50:20 2006 From: tree at basistech.com (Tom Emerson) Date: Mon, 6 Mar 2006 11:50:20 -0500 Subject: What kind of home page for Bugzilla? In-Reply-To: References: Message-ID: <17420.26700.426700.903696@tiphares.basistech.net> I see Gerv's point, and given that TT can handle RSS, it is easy to provide that functionality (from what little I read about it.) But for sites that want something simple, there is no compelling reason not to make this database backed in a simple way: that will address 80-90% of cases in a simple way. If you want more than that, you go all the way with RSS. So my view is that this isn't a case of one or the other: both could coexist. It comes down, of course, to someone putting a patch together and making it available for integration. Time to put some money where my mouth is, I think... -- Tom Emerson Basis Technology Corp. Software Architect http://www.basistech.com "You can't fake quality any more than you can fake a good meal." (W.S.B.) From luis.villa at gmail.com Tue Mar 7 03:56:18 2006 From: luis.villa at gmail.com (Luis Villa) Date: Mon, 6 Mar 2006 22:56:18 -0500 Subject: Minutes of the 3rd Bugzilla meeting In-Reply-To: <440B0041.7000302@gmail.com> References: <440B0041.7000302@gmail.com> Message-ID: <2cb10c440603061956u71a8f1bfm6aea2b349a4fc234@mail.gmail.com> [these meeting summaries are really useful, please continue them!] On 3/5/06, Fr?d?ric Buclin wrote: > - The actual home page (index.cgi) seems to be pretty useless for > everyone, especially for advanced users, i.e. it contains no useful > information. gandalf will work on it. I might suggest looking at: http://bugzilla.gnome.org/describeuser.cgi?user=luis.villa at gmail.com For logged in users, some variant of this would be an excellent way to start. Might also look at: http://bugzilla.gnome.org/browse.cgi?product=bugzilla.gnome.org for product summaries. These really rock, and should go upstream. Luis From Guillaume.Rousse at inria.fr Fri Mar 10 09:52:29 2006 From: Guillaume.Rousse at inria.fr (Guillaume Rousse) Date: Fri, 10 Mar 2006 10:52:29 +0100 Subject: We now require perl 5.8 In-Reply-To: <1141420503.3259.4.camel@localhost.localdomain> References: <1141256991.5874.23.camel@es-lappy> <44084D99.3090705@inria.fr> <1141420503.3259.4.camel@localhost.localdomain> Message-ID: <44114C5D.7070203@inria.fr> Max Kanat-Alexander wrote: > On Fri, 2006-03-03 at 15:07 +0100, Guillaume Rousse wrote: >> Max Kanat-Alexander wrote: >>> * "use Switch" (instead of faking switch statements) >> According to switch module maintainer himself, that is really not a good >> idea :) > > Really? Why? Could you point me to where he says that? On IRC :) Basically, it's a source filter, too much sensitive to source code presentation. A native implementation as a perl keyword is scheduled in 5.10 however? From gerv at mozilla.org Fri Mar 10 10:03:11 2006 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 10 Mar 2006 10:03:11 +0000 Subject: We now require perl 5.8 In-Reply-To: <44114C5D.7070203@inria.fr> References: <1141256991.5874.23.camel@es-lappy> <44084D99.3090705@inria.fr> <1141420503.3259.4.camel@localhost.localdomain> <44114C5D.7070203@inria.fr> Message-ID: <44114EDF.5090206@mozilla.org> Guillaume Rousse wrote: > Basically, it's a source filter, too much sensitive to source code > presentation. A native implementation as a perl keyword is scheduled in > 5.10 however? Well, we have full control over the style of our source, so if it works with Bugzilla house style, that doesn't seem like a major problem. Gerv From kevin.benton at amd.com Fri Mar 10 17:19:03 2006 From: kevin.benton at amd.com (Benton, Kevin) Date: Fri, 10 Mar 2006 09:19:03 -0800 Subject: FW: "Auto Detect" for attachment content type. Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4204EF6650@ssvlexmb2.amd.com> Cheap trick in browsers... If you want to specify a file type via the URL of a CGI, use this http://path/to/my.cgi/filename.ext?thisvar=that... Apache knows enough to stop at the my.cgi. The browser doesn't, however, and will take the extension specified. --- Kevin Benton Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator Digital Media Pervasive Computing Solutions Group Advanced Micro Devices 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: support-bugzilla-bounces at lists.mozilla.org [mailto:support-bugzilla-bounces at lists.mozilla.org] On Behalf Of Max Kanat-Alexander Sent: Friday, March 10, 2006 6:40 AM To: support-bugzilla at lists.mozilla.org Subject: RE: "Auto Detect" for attachment content type. On Fri, 2006-03-10 at 07:01 -0600, Jim Spurr wrote: > 1) I have tried many permutations of application/*excel, but have not > yet succeeded. Can someone confirm the proper string? I looked it up, it's: application/vnd.ms-excel > 2) My browser is IE 6 on XP ... I cannot find any place that manages > the file detection. Can you provide any clues on where to look? You can't control it. It's built-in to the browser. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. _______________________________________________ support-bugzilla mailing list support-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/support-bugzilla From eseyman at linagora.com Tue Mar 14 10:32:22 2006 From: eseyman at linagora.com (Emmanuel Seyman) Date: Tue, 14 Mar 2006 11:32:22 +0100 (CET) Subject: What kind of home page for Bugzilla? In-Reply-To: <4405C8BF.1030405@gmail.com> References: <4405C8BF.1030405@gmail.com> Message-ID: <50816.192.168.1.254.1142332342.squirrel@tomate.linagora.lan> Fr?d?ric Buclin wrote: > > What do we want to see on the home page when accessing Bugzilla > (homepage = index.cgi)? I'ld really like to have the ability to post announcements like : Version X of product Y has been released. Click here for the buglist of all bugs that this version fixes. Emmanuel From LpSolit at gmail.com Tue Mar 14 17:38:36 2006 From: LpSolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Tue, 14 Mar 2006 18:38:36 +0100 Subject: IRC meeting today, at 19:00 GMT (11:00 PST) Message-ID: <4416FF9C.50700@gmail.com> Just to remind you: 4th IRC meeting: *today* Tuesday, Mar 14 at 19:00 GMT (11:00 PST) on irc://irc.mozilla.org/bugzilla-meeting LpSolit From mkanat at bugzilla.org Tue Mar 14 21:06:37 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 14 Mar 2006 13:06:37 -0800 Subject: Bugzilla Meeting Minutes: 2006-03-14 Message-ID: <1142370397.3468.24.camel@localhost.localdomain> We had a nice meeting today, it was under two hours. If you were unable to attend, please read the log! :-) The log is at: * We cleared all the current blockers, they weren't considered severe enough to actually stop the release of 2.22. QA has started on 2.22, if you'd like to help, join #qa-bugzilla on irc.mozilla.org. We expect QA to be done in a week. We hope to release Bugzilla 2.22 (and 2.20.2) by March 26, meaning that the release process will start some time around March 23. This means that checkins are completely frozen on 2.22 and 2.20, except for critical regressions. * It would be useful to have a way to indicate what the team's priority is on a bug, as separate from what the developer's priority is for their personal buglist. However, that would have to wait for Custom Fields. That would allow us to prioritize certain bugs inside of a Target Milestone. * versioncache removal is currently slowed-down by some re-architecture that has to be done. We should keep working on removing other parts of globals.pl, though. And we should remove any parts of versioncache that we can remove now. * We considered a mechanism for automatically notifying admins that a new Bugzilla release was available, inside of Bugzilla itself. We filed a bug: https://bugzilla.mozilla.org/show_bug.cgi?id=330487 * Bugzilla Test Runner is becoming a mozilla.org project. It is now owned by Gregary Hendricks of Novell. Gregary and his team have been working extensively on Test Runner for some time now, and have been improving it in addition to bringing it up-to-date to work with 2.22. It will be changing names, and there's a contest going on for naming it. If you are interested in Test Runner, join #testrunner on irc.mozilla.org, and see: https://sourceforge.net/projects/testrunner * Some people are for eating breakfast, other people are against it. Apparently breakfast is a highly controversial subject. :-D Our next meeting will be Tuesday, March 28 at 19:00 GMT (11:00 PST). Hope to see you there! -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From ralf.beckers at chipvision.com Wed Mar 15 14:42:55 2006 From: ralf.beckers at chipvision.com (Ralf Beckers) Date: Wed, 15 Mar 2006 15:42:55 +0100 Subject: Problems with while.pl of BZ 2.20.1 after update Message-ID: <441827EF.70509@chipvision.com> Hi, after updating, I get an error message from th while.pl cron job. It complains about an sql statement. The table values for that while_schedule: id eventid run_day run_time run_next mailto mailto_type 3 5 MF 7 2006-03-15 00:08:00 6 0 The sql statement generated by while.pl: UPDATE whine_schedules SET run_next = CURRENT_DATE + INTERVAL 1 DAY + INTERVAL 8 HOUR WHERE id = 3 The full error message: DBD::mysql::st execute failed: You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near '(run_next = (CURRENT_DATE + INTERVAL '1' DAY + INTERVAL '7' HOU [for Statement "UPDATE whine_schedules SET (run_next = (CURRENT_DATE + INTERVAL ? DAY + INTERVAL ? HOUR)) WHERE id = ?"] at ./whine.pl line 612 main::reset_timer(3) called at ./whine.pl line 296 main::get_next_event() called at ./whine.pl line 324 DBI::db=HASH(0x89cae88)->disconnect invalidates 1 active statement handle (either destroy statement handles or call finish on them before disconnecting) at Bugzilla.pm line 182. CURRENT_DATE + INTERVAL 1 DAY works when using it manually in phpmyadmin, but not with an appended + INTERVAL 1 DAY. I'm using mysql version 4.0.21. Thanks for any hints, Ralf -- Ralf Beckers Lead Development Engineer ChipVision Design Systems AG Fritz-Bock-Strasse 5 - 26121 Oldenburg - Germany phone +49-441-35042-360 fax +49-441-35042-350 email ralf.beckers at chipvision.com www.chipvision.com From ralf.beckers at chipvision.com Wed Mar 15 15:36:53 2006 From: ralf.beckers at chipvision.com (Ralf Beckers) Date: Wed, 15 Mar 2006 16:36:53 +0100 Subject: Problems with while.pl of BZ 2.20.1 after update In-Reply-To: <441827EF.70509@chipvision.com> References: <441827EF.70509@chipvision.com> Message-ID: <44183495.2080905@chipvision.com> Ahoi, Ralf Beckers schrieb: > after updating, I get an error message from th while.pl cron job. It > complains about an sql statement. I used the bugfixes from version 1.23 of while.pl, which seem to help me. Thanks for that great tool :) Ralf -- Ralf Beckers Lead Development Engineer ChipVision Design Systems AG Fritz-Bock-Strasse 5 - 26121 Oldenburg - Germany phone +49-441-35042-360 fax +49-441-35042-350 email ralf.beckers at chipvision.com www.chipvision.com From vladd at bugzilla.org Wed Mar 15 15:47:00 2006 From: vladd at bugzilla.org (Vlad Dascalu) Date: Wed, 15 Mar 2006 17:47:00 +0200 Subject: Problems with while.pl of BZ 2.20.1 after update In-Reply-To: <441827EF.70509@chipvision.com> References: <441827EF.70509@chipvision.com> Message-ID: <441836F4.4060703@bugzilla.org> This was probably fixed in https://bugzilla.mozilla.org/show_bug.cgi?id=327348 , there is a patch there available that you can apply manually. Otherwise we're planning a new release within one week from now (we're currently doing QA on it). Ralf Beckers wrote: > Hi, > > after updating, I get an error message from th while.pl cron job. It > complains about an sql statement. > > The table values for that while_schedule: > > id eventid run_day run_time run_next mailto mailto_type > 3 5 MF 7 2006-03-15 00:08:00 6 0 > > The sql statement generated by while.pl: > UPDATE whine_schedules SET run_next = CURRENT_DATE + INTERVAL 1 DAY + > INTERVAL 8 HOUR WHERE id = 3 > > The full error message: > DBD::mysql::st execute failed: You have an error in your SQL syntax. > Check the manual that corresponds to your MySQL server version for the > right syntax to use near '(run_next = (CURRENT_DATE + INTERVAL '1' DAY > + INTERVAL '7' HOU [for Statement "UPDATE whine_schedules SET > (run_next = (CURRENT_DATE + INTERVAL ? DAY + INTERVAL ? HOUR)) WHERE > id = ?"] at ./whine.pl line 612 > main::reset_timer(3) called at ./whine.pl line 296 > main::get_next_event() called at ./whine.pl line 324 > DBI::db=HASH(0x89cae88)->disconnect invalidates 1 active statement > handle (either destroy statement handles or call finish on them before > disconnecting) at Bugzilla.pm line 182. > > CURRENT_DATE + INTERVAL 1 DAY works when using it manually in > phpmyadmin, but not with an appended + INTERVAL 1 DAY. > > I'm using mysql version 4.0.21. > > Thanks for any hints, > Ralf From ghendricks at novell.com Wed Mar 15 16:05:02 2006 From: ghendricks at novell.com (Greg Hendricks) Date: Wed, 15 Mar 2006 09:05:02 -0700 Subject: prioritizing custom fields development In-Reply-To: <4404B978.7060906@mozilla.org> References: <43FCF29C.9080005@mozilla.org> <4404B978.7060906@mozilla.org> Message-ID: <200603150905.02115.ghendricks@novell.com> On Tuesday 28 February 2006 13:58, Myk Melez wrote: > Thanks all for your feedback. Based on what you've told me and my own > sense of the project, I've roughly prioritized tasks into the following > list, where the tasks appearing earlier are higher priority: > > 1. custom fields appearance on search, bug list, change multiple > bugs, long list, and printable pages; > 2. ability to list and delete custom fields via the command-line; > 3. boolean fields; > 4. web interface for managing custom fields; > 5. ability to position fields at arbitrary places on the edit > bug page; > 6. type-constrained plain-text fields; > 7. single-select fields; > 8. user fields; > 9. bug fields; > 10. multi-select fields; > 11. date fields; > 12. ability to restrict fields to specific product/component > combinations; > 13. ability to restrict fields to specific user groups; > 14. multi-user fields; > 15. multi-bug fields. > I am curious about something. At bugzilla.novell.com we implemented a custom field patch some time ago. We got the code from one of the custom patch bugs, made it into a module, and have been using it since day one. Of the 15 things listed here it does almost everything but the command line interface (it has a GUI interface for managing). We offered it back and were told that was not the direction Bugzilla was going. This was back in the days we had the raging debate over custom field implementation. So my question is, has there been a change of direction? Because this seems to be exactly what we have already. -- Greg Hendricks Novell IS&T Engineer GHendricks at novell.com Office: (801) 861-3481 www.novell.com From ghendricks at novell.com Wed Mar 15 16:11:50 2006 From: ghendricks at novell.com (Gregary Hendricks) Date: Wed, 15 Mar 2006 09:11:50 -0700 Subject: On Tuesday 28 February 2006 13:58, Myk Melez wrote: Message-ID: <4417DA55.3532.00D2.0@novell.com> On Tuesday 28 February 2006 13:58, Myk Melez wrote: > Thanks all for your feedback. Based on what you've told me and my own > sense of the project, I've roughly prioritized tasks into the following > list, where the tasks appearing earlier are higher priority: > > 1. custom fields appearance on search, bug list, change multiple > bugs, long list, and printable pages; > 2. ability to list and delete custom fields via the command-line; > 3. boolean fields; > 4. web interface for managing custom fields; > 5. ability to position fields at arbitrary places on the edit > bug page; > 6. type-constrained plain-text fields; > 7. single-select fields; > 8. user fields; > 9. bug fields; > 10. multi-select fields; > 11. date fields; > 12. ability to restrict fields to specific product/component > combinations; > 13. ability to restrict fields to specific user groups; > 14. multi-user fields; > 15. multi-bug fields. > I am curious about something. At bugzilla.novell.com we implemented a custom field patch some time ago. We got the code from one of the custom patch bugs, made it into a module, and have been using it since day one. Of the 15 things listed here it does almost everything but the command line interface (at least for bugs). It has a GUI interface for managing the fields, which show up in all the places listed. And though we don't have support for user fields (not sure what is meant by that), it would probably not be too hard to extend. We offered it back but were told that was not the direction Bugzilla was going. This was back in the days we had the raging debate over custom field implementation. So my question is, has there been a change of direction? Because this seems to be exactly what we have already. Greg Hendricks From vladd at bugzilla.org Wed Mar 15 17:10:40 2006 From: vladd at bugzilla.org (Vlad Dascalu) Date: Wed, 15 Mar 2006 19:10:40 +0200 Subject: On Tuesday 28 February 2006 13:58, Myk Melez wrote: In-Reply-To: <4417DA55.3532.00D2.0@novell.com> References: <4417DA55.3532.00D2.0@novell.com> Message-ID: <44184A90.9060503@bugzilla.org> The biggest problem is reviewing, integrating and QA-ing such a large chunk of code. Doing it one-step-at-a-time speeds up the process, at least that was the direction in which we were going with this, last time I checked. Vlad Gregary Hendricks wrote: > On Tuesday 28 February 2006 13:58, Myk Melez wrote: > >> Thanks all for your feedback. Based on what you've told me and my >> > own > >> sense of the project, I've roughly prioritized tasks into the >> > following > >> list, where the tasks appearing earlier are higher priority: >> >> 1. custom fields appearance on search, bug list, change multiple >> bugs, long list, and printable pages; >> 2. ability to list and delete custom fields via the >> > command-line; > >> 3. boolean fields; >> 4. web interface for managing custom fields; >> 5. ability to position fields at arbitrary places on the edit >> bug page; >> 6. type-constrained plain-text fields; >> 7. single-select fields; >> 8. user fields; >> 9. bug fields; >> 10. multi-select fields; >> 11. date fields; >> 12. ability to restrict fields to specific product/component >> combinations; >> 13. ability to restrict fields to specific user groups; >> 14. multi-user fields; >> 15. multi-bug fields. >> >> > > I am curious about something. At bugzilla.novell.com we implemented a > custom > field patch some time ago. We got the code from one of the custom patch > bugs, > made it into a module, and have been using it since day one. Of the 15 > things > listed here it does almost everything but the command line interface > (at least > for bugs). It has a GUI interface for managing the fields, which show > up in all > the places listed. And though we don't have support for user fields > (not sure > what is meant by that), it would probably not be too hard to extend. > We offered it back but were told that was not the direction Bugzilla > was going. > This was back in the days we had the raging debate over custom field > implementation. > So my question is, has there been a change of direction? > Because this seems to be exactly what we have already. > > Greg Hendricks > - > To view or change your list settings, click here: > > > > From luis.villa at gmail.com Wed Mar 15 17:52:59 2006 From: luis.villa at gmail.com (Luis Villa) Date: Wed, 15 Mar 2006 12:52:59 -0500 Subject: On Tuesday 28 February 2006 13:58, Myk Melez wrote: In-Reply-To: <4417DA55.3532.00D2.0@novell.com> References: <4417DA55.3532.00D2.0@novell.com> Message-ID: <2cb10c440603150952x637b0255hafe518efc201828f@mail.gmail.com> On 3/15/06, Gregary Hendricks wrote: > On Tuesday 28 February 2006 13:58, Myk Melez wrote: > > Thanks all for your feedback. Based on what you've told me and my > own > > sense of the project, I've roughly prioritized tasks into the > following > > list, where the tasks appearing earlier are higher priority: > > > > 1. custom fields appearance on search, bug list, change multiple > > bugs, long list, and printable pages; > > 2. ability to list and delete custom fields via the > command-line; > > 3. boolean fields; > > 4. web interface for managing custom fields; > > 5. ability to position fields at arbitrary places on the edit > > bug page; > > 6. type-constrained plain-text fields; > > 7. single-select fields; > > 8. user fields; > > 9. bug fields; > > 10. multi-select fields; > > 11. date fields; > > 12. ability to restrict fields to specific product/component > > combinations; > > 13. ability to restrict fields to specific user groups; > > 14. multi-user fields; > > 15. multi-bug fields. > > > > I am curious about something. At bugzilla.novell.com we implemented a > custom > field patch some time ago. We got the code from one of the custom patch > bugs, > made it into a module, and have been using it since day one. Of the 15 > things > listed here it does almost everything but the command line interface > (at least > for bugs). It has a GUI interface for managing the fields, which show > up in all > the places listed. And though we don't have support for user fields > (not sure > what is meant by that), it would probably not be too hard to extend. > We offered it back but were told that was not the direction Bugzilla > was going. If I recall correctly, Greg, the problem was not whether or not to do custom fields; I believe the issue was how custom fields were implemented in the particular patch that bugzilla.novell.com's work is derived from, and that is why the patch was rejected, not disagreement with the notion of custom fields. Luis From kevin.benton at amd.com Wed Mar 15 18:20:34 2006 From: kevin.benton at amd.com (Benton, Kevin) Date: Wed, 15 Mar 2006 10:20:34 -0800 Subject: Custom Fields Development (was Re: On Tuesday 28 February 2006 13:58, Myk Melez wrote:) Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4205072E32@ssvlexmb2.amd.com> IIRC, the discussion (albeit heated at times) wasn't whether or not to implement custom fields, but rather how to implement them. As I recall, I saw parties going back and fourth about fields as data versus other methods. I felt that as long as it was manageable, and didn't significantly degrade performance of Bugzilla, I didn't really care what method was used. --- Kevin Benton Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator Digital Media Pervasive Computing Solutions Group Advanced Micro Devices 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 Luis Villa > Sent: Wednesday, March 15, 2006 10:53 AM > To: developers at bugzilla.org > Subject: Re: On Tuesday 28 February 2006 13:58, Myk Melez wrote: > > On 3/15/06, Gregary Hendricks wrote: > > On Tuesday 28 February 2006 13:58, Myk Melez wrote: > > > Thanks all for your feedback. Based on what you've told me and my > > own > > > sense of the project, I've roughly prioritized tasks into the > > following > > > list, where the tasks appearing earlier are higher priority: > > > > > > 1. custom fields appearance on search, bug list, change multiple > > > bugs, long list, and printable pages; > > > 2. ability to list and delete custom fields via the > > command-line; > > > 3. boolean fields; > > > 4. web interface for managing custom fields; > > > 5. ability to position fields at arbitrary places on the edit > > > bug page; > > > 6. type-constrained plain-text fields; > > > 7. single-select fields; > > > 8. user fields; > > > 9. bug fields; > > > 10. multi-select fields; > > > 11. date fields; > > > 12. ability to restrict fields to specific product/component > > > combinations; > > > 13. ability to restrict fields to specific user groups; > > > 14. multi-user fields; > > > 15. multi-bug fields. > > > > > > > I am curious about something. At bugzilla.novell.com we implemented a > > custom > > field patch some time ago. We got the code from one of the custom patch > > bugs, > > made it into a module, and have been using it since day one. Of the 15 > > things > > listed here it does almost everything but the command line interface > > (at least > > for bugs). It has a GUI interface for managing the fields, which show > > up in all > > the places listed. And though we don't have support for user fields > > (not sure > > what is meant by that), it would probably not be too hard to extend. > > We offered it back but were told that was not the direction Bugzilla > > was going. > > If I recall correctly, Greg, the problem was not whether or not to do > custom fields; I believe the issue was how custom fields were > implemented in the particular patch that bugzilla.novell.com's work is > derived from, and that is why the patch was rejected, not disagreement > with the notion of custom fields. > > Luis > > - > To view or change your list settings, click here: > From mkanat at bugzilla.org Wed Mar 15 18:24:46 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 15 Mar 2006 10:24:46 -0800 Subject: prioritizing custom fields development In-Reply-To: <200603150905.02115.ghendricks@novell.com> References: <43FCF29C.9080005@mozilla.org> <4404B978.7060906@mozilla.org> <200603150905.02115.ghendricks@novell.com> Message-ID: <1142447086.3481.7.camel@localhost.localdomain> On Wed, 2006-03-15 at 09:05 -0700, Greg Hendricks wrote: > We offered it back and were told that was not > the direction Bugzilla was going. This was back in the days we had the raging > debate over custom field implementation. So my question is, has there been a > change of direction? Because this seems to be exactly what we have already. That patch's problem isn't the feature set offered, it's the implementation, and the size of the patch. Nobody could have ever humanly reviewed a patch of that size (note that a patch of that size has never been accepted into Bugzilla, as far as I know), and the *way* it was coded wasn't the direction Bugzilla was going. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From dberlin at dberlin.org Wed Mar 15 18:25:26 2006 From: dberlin at dberlin.org (Daniel Berlin) Date: Wed, 15 Mar 2006 13:25:26 -0500 Subject: Custom Fields Development (was Re: On Tuesday 28 February 2006 In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4205072E32@ssvlexmb2.amd.com> References: <6F7DA19D05F3CF40B890C7CA2DB13A4205072E32@ssvlexmb2.amd.com> Message-ID: <1142447126.32206.37.camel@dyn9002219123.watson.ibm.com> On Wed, 2006-03-15 at 10:20 -0800, Benton, Kevin wrote: > IIRC, the discussion (albeit heated at times) wasn't whether or not to > implement custom fields, but rather how to implement them. As I recall, > I saw parties going back and fourth about fields as data versus other > methods. I felt that as long as it was manageable, and didn't > significantly degrade performance of Bugzilla, I didn't really care what > method was used. > Right. And honestly, the whole discussion was somewhat surreal. It's going to take 1.0 seconds to select the millions of pieces of data from the db instead of .5 if we do it that way! Meanwhile, it takes 30 seconds to render the page either way, ...... From mkanat at bugzilla.org Wed Mar 15 18:26:29 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 15 Mar 2006 10:26:29 -0800 Subject: Custom Fields Development (was Re: On Tuesday 28 February 2006 In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4205072E32@ssvlexmb2.amd.com> References: <6F7DA19D05F3CF40B890C7CA2DB13A4205072E32@ssvlexmb2.amd.com> Message-ID: <1142447189.3481.10.camel@localhost.localdomain> On Wed, 2006-03-15 at 10:20 -0800, Benton, Kevin wrote: > As I recall, > I saw parties going back and fourth about fields as data versus other > methods. That actually wasn't so much related to the patch on that bug as it was related to our actual planned upstream implementation. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From myk at mozilla.org Wed Mar 15 22:05:55 2006 From: myk at mozilla.org (Myk Melez) Date: Wed, 15 Mar 2006 14:05:55 -0800 Subject: Custom Fields Development (was Re: On Tuesday 28 February 2006 In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4205072E32@ssvlexmb2.amd.com> References: <6F7DA19D05F3CF40B890C7CA2DB13A4205072E32@ssvlexmb2.amd.com> Message-ID: <44188FC3.6040608@mozilla.org> Benton, Kevin wrote: > IIRC, the discussion (albeit heated at times) wasn't whether or not to > implement custom fields, but rather how to implement them. Right. Both sides in the debate (fields-as-columns, a.k.a. FAC, and fields-as-data, a.k.a. FAD) agreed on the outcome (that Bugzilla should have custom fields with a certain feature set); we just disagreed on the approach. Areas of contention included performance (with both sides claiming significantly better performance for their approach), how best to integrate with the Bugzilla code infrastructure, and what the database schema should look like. In the end, Dave didn't choose sides, and development stalled, although patches were available for both approaches (my basic implementation for FAC and a complete but large and infrastructure-modifying implementation for FAD). Then Max revived development with a proposal to incrementally develop the feature, and he filed bugs on each discrete implementation task. Meanwhile, I believe FAD's primary developer lost his Bugzilla development job (I'm not positive about this, as my mail server won't let me get to my personal list archive, and getting the list archive from majordomo is hard) and was no longer available to work on the FAD approach. I then modified my basic FAC implementation to implement the first few of Max's bugs and took it through the review process. Recently it got checked in when the trunk reopened for 2.24 development, and here we are. -myk From mkanat at bugzilla.org Thu Mar 16 17:32:46 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 16 Mar 2006 09:32:46 -0800 Subject: Bugzilla Roadmap as a Dependency Tree Message-ID: <1142530366.3402.5.camel@localhost.localdomain> For any who are interested, I've filed a meta-bug to keep track of things on our Bugzilla 3.0 Roadmap: https://bugzilla.mozilla.org/show_bug.cgi?id=330700 Also, for any interested contributors, looking at the dependency tree on that bug is a good way to see the list of bugs that we really would like to see fixed. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From mkgnu at mkgnu.net Fri Mar 17 17:50:55 2006 From: mkgnu at mkgnu.net (Kristis Makris) Date: Fri, 17 Mar 2006 10:50:55 -0700 Subject: Bugzilla Roadmap as a Dependency Tree In-Reply-To: <1142530366.3402.5.camel@localhost.localdomain> References: <1142530366.3402.5.camel@localhost.localdomain> Message-ID: <1142617855.5183.118.camel@syd.mkgnu.net> On Thu, 2006-03-16 at 09:32 -0800, Max Kanat-Alexander wrote: > For any who are interested, I've filed a meta-bug to keep track of > things on our Bugzilla 3.0 Roadmap: > > https://bugzilla.mozilla.org/show_bug.cgi?id=330700 Just a nitpick suggestion. Is it possible that you somehow use a wiki link that will be more permanent than: http://wiki.mozilla.org/Bugzilla:Roadmap e.g. http://wiki.mozilla.org/Bugzilla:Roadmap:2.22 or http://wiki.mozilla.org/Bugzilla:Roadmap_to_3.0 Asking only because your wiki's page may be updated when you move to 2.24, or 2.26 or what have you, before we get to support the Bugzilla changes (e.g. 2.22) in Scmbug. Thanks!! From julien.beti at free.fr Thu Mar 23 16:51:48 2006 From: julien.beti at free.fr (Julien BETI) Date: Thu, 23 Mar 2006 17:51:48 +0100 Subject: Bugzilla related little project and e-mail notification In-Reply-To: <43C56BA5.4080501@bugzilla.org> References: <43C43CCC.8000707@free.fr> <43C56BA5.4080501@bugzilla.org> Message-ID: <4422D224.1080502@free.fr> Well, I'd like to keep my application "full java", and use the Bugzilla rescan mail functionality as a kind of web service. I finally found the time to learn a bit of Perl and to propose a patch (for Bugzilla 2.20), available here: http://bugzilla.jujunie.com/cgi-bin/bugzilla/attachment.cgi?id=7 It simply introduce in new request parameter "forceDelayTo" which if set forces the delay to the specified value. In my application (http://freshmeat.net/projects/jujunie-integration/), I'm using it set to 0 Please let me know if this patch is acceptable, as I'm a real beginner in Perl, and as I perhaps did not realize the full impacts of this change. Is there a chance to see it included in one of upcoming Bugzilla release? David Miller wrote: >Julien BETI wrote on 1/10/06 6:01 PM: > > > >>I have a little question to improve my project. After updating the >>Bugzilla database with new deadlines, I'm calling the sanitycheck, >>section rescan unsend mail, in order to make Bugzilla sends the e-mails >>notifying the changes. But in your script, there is a delay in order to >>not send e-mails if the change is more recent than 30 minutes ago. Since >>I'd like to propose a patch to add a parameter to define this delay (and >>set it to 0 in my case :p), and in order to avoid regressions, I'd like >>to know why this delay has been introduced? Your answer will be also >>useful for the CruiseControl BugzillaPublisher plugin (developed by >>Nanthrax: http://buildprocess.sourceforge.net/bugzillapublisher.html) >>where I'd like to porpose a patch to add the "e-mail notification" also. >> >> > >There's a "sendbugmail.pl" script which probably is a better match for >what you're looking for. It takes the bug number on the command line, >and sends any unsent mail for that specific bug. Assuming you know >which bugs you're changing that would probably be a safer route to go. > >Also, there is a "sendunsentbugmail.pl" script (in contrib I think) >which does exactly what the sanitycheck process does, but doesn't have >the overhead of running everything else in sanitycheck as well (and also >does it from the command line). That script should be pretty easy to >modify to remove the 30 minute exception if you really need to run it >across the board instead of on specific bugs. > > > -- Motofix La route est longue, mais la voie est libre... http://www.jujunie.com From kevin.benton at amd.com Thu Mar 23 23:54:38 2006 From: kevin.benton at amd.com (Benton, Kevin) Date: Thu, 23 Mar 2006 15:54:38 -0800 Subject: Bugzilla related little project and e-mail notification Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A42052F9649@ssvlexmb2.amd.com> > Well, I'd like to keep my application "full java", and use the Bugzilla > rescan mail functionality as a kind of web service. I finally found the > time to learn a bit of Perl and to propose a patch (for Bugzilla 2.20), > available here: > http://bugzilla.jujunie.com/cgi-bin/bugzilla/attachment.cgi?id=7 > > It simply introduce in new request parameter "forceDelayTo" which if set > forces the delay to the specified value. In my application > (http://freshmeat.net/projects/jujunie-integration/), I'm using it set to > 0 > > Please let me know if this patch is acceptable, as I'm a real beginner > in Perl, and as I perhaps did not realize the full impacts of this > change. Is there a chance to see it included in one of upcoming Bugzilla > release? Hello Julien. Without having looked at it, I can tell you it'll be difficult to find someone to review it since Bugzilla 2.22rc1 is current. I had to learn the hard way that I need to submit patches against the CVS tip rather than a specific version. This does two things. 1) It helps developers compare code against current code. 2) It makes life a lot easier for those who have the job of putting your patch into production. If you'd like to see new features implemented, your best bet is to work against the latest code rather than a released stable version (in general). Thanks for contributing! :) --- Kevin Benton Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator Digital Media Pervasive Computing Solutions Group Advanced Micro Devices 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 Tue Mar 28 21:26:36 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 28 Mar 2006 13:26:36 -0800 Subject: Bugzilla Meeting Minutes: 2006-03-28 Message-ID: <1143581196.3380.10.camel@localhost.localdomain> We had a very short meeting today. If you were unable to attend, you can read the log here: http://bugzilla.glob.com.au/irc/?c=bugzilla-meeting&s=2006-03-28&e=2006-03-28 * QA is underway for the 2.22 and 2.20.2 releases. The QA team can always use more help. If you'd like to help, come to #qa-bugzilla on irc.mozilla.org and talk to LpSolit. * We hope to release 2.22 and 2.20.2 by April 10. * We could use more active reviewers. Becoming a reviewer basically involves contributing enough patches and doing some informal reviews. Once you really understand Bugzilla code and our style guide, then you get to be a reviewer. I'm going to eventually write up a guide on how to become one. But the way to start is to contribute. * Bugzilla Testrunner is now known as Testopia. The IRC channel is #testopia on irc.mozilla.org. Gregary Hendricks and others are working toward 1.0. Testopia always welcomes more contributors! If you'd like to contribute, come into the IRC channel and talk to ghendricks. Our next meeting is on Tuesday, April 11, 2006, at 18:00 GMT (11:00 PDT). Yes, the GMT meeting time has changed, because of Daylight Savings Time in the USA. If you want to discuss something at our next meeting, put it on the agenda: http://wiki.mozilla.org/Bugzilla:Meetings We look forward to seeing you there! -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From john at redux.org.uk Wed Mar 29 11:47:44 2006 From: john at redux.org.uk (John Beranek) Date: Wed, 29 Mar 2006 12:47:44 +0100 Subject: Bugzilla Meeting Minutes: 2006-03-28 In-Reply-To: <1143581196.3380.10.camel@localhost.localdomain> References: <1143581196.3380.10.camel@localhost.localdomain> Message-ID: <442A73E0.1040101@redux.org.uk> Max Kanat-Alexander wrote: > Our next meeting is on Tuesday, April 11, 2006, at 18:00 GMT (11:00 > PDT). Yes, the GMT meeting time has changed, because of Daylight Savings > Time in the USA. Maybe best to call it 19:00 BST, 18:00 UTC... :) John. -- John Beranek To generalise is to be an idiot. http://redux.org.uk/ -- William Blake From paulo.casanova at link.pt Fri Mar 31 12:24:47 2006 From: paulo.casanova at link.pt (Paulo Casanova) Date: Fri, 31 Mar 2006 13:24:47 +0100 Subject: Customizing bugzilla workflow (bug #101179) Message-ID: <00b301c654be$197beff0$0813a8c0@aitec.pt> Hi! I would like to see bugzilla's customizable workflow done and I would like to contribute a patch. However, there are some architectural issues I would like to discuss first. I think the whole workflow should be controlled by an independent module so I could be replaced by something else in specific instalations. If this is allowed we could have BZ easily integrated into more complex enterprise architectures which use other technologies (such as Oracle BPEL). My main concern about bug #101179 is that I see a "custom workflow" implementation and I see no need for it as most of the work is already done. I don't know much about CPAN's workflow module (Workflow) but I don't have much confidence since its a new module and never heard of anyone using it. BZ could ship with an implementation of the "abstract" Bugzilla::Workflow module using a solution based on what has been discussed on the bug. In what features are concerted, I think we should support: a) Internally, each bug should have a process number (this allows mapping into other workflow systems); b) The workflow module should be able to define a number of fields that characterize each state (currently, status + resolution); c) User actions (accept, reassign, resolve) for each bug are determined by the workflow module; d) All changes that occur after a user action are determined by the workflow module (default will just change state, invoke some mail sending and register the bug activity); A few things I would like to discuss is: e) How do we start processes? The products page could be replaced by a "workflows" page (the default module can have a different workflow per product) but more complex systems could have several workflows per product; f) Should we control which fields can be edited in which workflow state? Any ideas? Paulo -------------- next part -------------- An HTML attachment was scrubbed... URL: From kristis.makris at asu.edu Fri Mar 31 21:51:14 2006 From: kristis.makris at asu.edu (Kristis Makris) Date: Fri, 31 Mar 2006 14:51:14 -0700 Subject: Minimum required DBI version Message-ID: <1143841874.26691.3.camel@syd.mkgnu.net> Hello, The Bugzilla installation section claims that DBI 1.38 is the minimum required version to get Bugzilla working. http://www.bugzilla.org/docs/2.22/html/installation.html#install-perlmodules We discovered that under Windows if one uses a DBI that is < 1.50 to talk to Bugzilla 2.20 (previous releases work fine), and one happens to fork multiple processes that use the DBI, the DBI exits unexpectedly. This is documented in: http://bugzilla.mkgnu.net/show_bug.cgi?id=646 http://bugs.activestate.com/show_bug.cgi?id=45411 In any case, I wanted to give you a heads up. This might come up if one builds additional tools in Windows that use Bugzilla. Perhaps the minimum required DBI version should be 1.50, and not 1.38.