From bugzilla at glob.com.au Fri Oct 1 01:15:15 2004 From: bugzilla at glob.com.au (bugzilla at glob.com.au) Date: Fri, 1 Oct 2004 09:15:15 +0800 (WST) Subject: enforcing access is via urlbase Message-ID: <20041001011515.8AD884BCA03@stutter.bur.st> > > Other than that, I think it's probably a fine idea. Of course, it > > really belongs in the .htaccess file as a RewriteRule, or something like > > that. It's a doc note, I think, as part of the installation guide, more > > than an option in Bugzilla. RewriteRule is ok, as long as you remember to exclude files such as robots.txt. > Another point is that if the end-user is using HTTP/1.0 to access > Bugzilla, then there is no way for Bugzilla to know which hostname they > used. (although we can certainly tell if they're using SSL or not) ah. i'd forgotten about that. that would be a show stopper. /me shelfs idea begin-base64 644 signature.gif R0lGODlhbQAHAIAAAABPo////ywAAAAAbQAHAAACfAxuGAnch+Bibkn7FL1p XgVl4Ig1jjlZRoqybgun2Cur5uOunq7u/Ipq7WIyIc7XG9JquEgumPzdlhTf h0O83kDJaXEm8mRHwXKJy5sac7qYOpT+gtv0n+0ujQOfdqh16caWt0foBViH N1PRMXimiLUGt3ElVimlgbllWAAAOw== ==== From kiko at async.com.br Fri Oct 1 07:02:49 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Fri, 1 Oct 2004 04:02:49 -0300 Subject: enforcing access is via urlbase In-Reply-To: <20041001011515.8AD884BCA03@stutter.bur.st> References: <20041001011515.8AD884BCA03@stutter.bur.st> Message-ID: <20041001070249.GA20727@www.async.com.br> On Fri, Oct 01, 2004 at 09:15:15AM +0800, bugzilla at glob.com.au wrote: > > Another point is that if the end-user is using HTTP/1.0 to access > > Bugzilla, then there is no way for Bugzilla to know which hostname they > > used. (although we can certainly tell if they're using SSL or not) > > ah. i'd forgotten about that. that would be a show stopper. Odd. Doesn't the 1.0 spec define a Host: header that is mandatory? AFAIK only 0.9 allowed Host:less connects. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 From justdave at bugzilla.org Fri Oct 1 07:08:09 2004 From: justdave at bugzilla.org (David Miller) Date: Fri, 01 Oct 2004 03:08:09 -0400 Subject: enforcing access is via urlbase In-Reply-To: <20041001070249.GA20727@www.async.com.br> References: <20041001011515.8AD884BCA03@stutter.bur.st> <20041001070249.GA20727@www.async.com.br> Message-ID: <415D0259.5080305@bugzilla.org> Christian Robottom Reis wrote: > On Fri, Oct 01, 2004 at 09:15:15AM +0800, bugzilla at glob.com.au wrote: > >>>Another point is that if the end-user is using HTTP/1.0 to access >>>Bugzilla, then there is no way for Bugzilla to know which hostname they >>>used. (although we can certainly tell if they're using SSL or not) >> >>ah. i'd forgotten about that. that would be a show stopper. > > Odd. Doesn't the 1.0 spec define a Host: header that is mandatory? AFAIK > only 0.9 allowed Host:less connects. Nope. That's why name-based virtual hosts don't work in HTTP/1.0 -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From mkanat at kerio.com Fri Oct 1 17:36:28 2004 From: mkanat at kerio.com (Max Kanat-Alexander) Date: Fri, 01 Oct 2004 10:36:28 -0700 Subject: enforcing access is via urlbase In-Reply-To: <415D0259.5080305@bugzilla.org> References: <20041001011515.8AD884BCA03@stutter.bur.st> <20041001070249.GA20727@www.async.com.br> <415D0259.5080305@bugzilla.org> Message-ID: <1096652187.2924.0.camel@localhost.localdomain> On Fri, 2004-10-01 at 00:08, David Miller wrote: > Nope. That's why name-based virtual hosts don't work in HTTP/1.0 You know, to be fair, with our CSS redesign plans, we're going to be dropping support for most clients that would be using HTTP/1.0 anyhow. -Max From jpyeron at pdinc.us Fri Oct 1 17:48:18 2004 From: jpyeron at pdinc.us (Jason Pyeron) Date: Fri, 1 Oct 2004 13:48:18 -0400 (EDT) Subject: enforcing access is via urlbase In-Reply-To: <1096652187.2924.0.camel@localhost.localdomain> Message-ID: to be double fair, when it is not a big burden we do 'support' the others; whether non-css, http/1.0, IE, etc. -jason On Fri, 1 Oct 2004, Max Kanat-Alexander wrote: > On Fri, 2004-10-01 at 00:08, David Miller wrote: > > Nope. That's why name-based virtual hosts don't work in HTTP/1.0 > > You know, to be fair, with our CSS redesign plans, we're going to be > dropping support for most clients that would be using HTTP/1.0 anyhow. > > -Max > > > - > To view or change your list settings, click here: > > -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Partner & Sr. Manager #1 2739 Saint Paul Street - - +1 (410) 808-6646 (c) Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, purge the message from your system and notify the sender immediately. Any other use of the email by you is prohibited. From jay at veggiespam.com Fri Oct 1 17:59:40 2004 From: jay at veggiespam.com (jay ball) Date: Fri, 01 Oct 2004 13:59:40 -0400 Subject: enforcing access is via urlbase In-Reply-To: <20041001011515.8AD884BCA03@stutter.bur.st> References: <20041001011515.8AD884BCA03@stutter.bur.st> Message-ID: <415D9B0C.3040507@veggiespam.com> bugzilla at glob.com.au wrote: >>Another point is that if the end-user is using HTTP/1.0 to access >>Bugzilla, then there is no way for Bugzilla to know which hostname they >>used. (although we can certainly tell if they're using SSL or not) > > > ah. i'd forgotten about that. that would be a show stopper. > what about RewriteCond %{THE_REQUEST} !.*HTTP/...$ [OR] RewriteCond %{HTTP:Server} !.* [OR] RewriteCond %{THE_REQUEST} .*HTTP/1.0$ RewriteRule ^/.* /http-1.1-required.html The first line might handle HTTP 0.9 or requests without the HTTP doodad on the request line, the second looks for a server header, and the final does HTTP 1.0. Someone with less nachos in the stomach might be able to perfect it the suggestion; i have not tested it. Max write: > You know, to be fair, with our CSS redesign plans, we're going to be > dropping support for most clients that would be using HTTP/1.0 anyhow. So, if this is true, then just ban HTTP/1.0. Q: how many v1.0 or v0.9 requests do many of you get any longer? Random thought. -j From jpyeron at pdinc.us Fri Oct 1 19:13:05 2004 From: jpyeron at pdinc.us (Jason Pyeron) Date: Fri, 1 Oct 2004 15:13:05 -0400 (EDT) Subject: mid-air collisions on bmo In-Reply-To: Message-ID: is https://bugzilla.mozilla.org/show_bug.cgi?id=53452 applied? if so, then something is up. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Partner & Sr. Manager #1 2739 Saint Paul Street - - +1 (410) 808-6646 (c) Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, purge the message from your system and notify the sender immediately. Any other use of the email by you is prohibited. From jpyeron at pdinc.us Fri Oct 1 19:37:15 2004 From: jpyeron at pdinc.us (Jason Pyeron) Date: Fri, 1 Oct 2004 15:37:15 -0400 (EDT) Subject: google ads on [our] bz... In-Reply-To: Message-ID: We tried to see how well Google ads could help us. We rationalized that some vendors might have solutions to our bus, so we allowed Google to pay us for target ads. They crawl our bugzilla install, and target ads towards out content. It has not been without its flaws, but nice all the same. I particularly like the ad on http://projects.pyerotechnics.com/show_bug.cgi?id=119 -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Partner & Sr. Manager #1 2739 Saint Paul Street - - +1 (410) 808-6646 (c) Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, purge the message from your system and notify the sender immediately. Any other use of the email by you is prohibited. From myk at mozilla.org Fri Oct 1 20:03:46 2004 From: myk at mozilla.org (Myk Melez) Date: Fri, 01 Oct 2004 13:03:46 -0700 Subject: enforcing access is via urlbase In-Reply-To: <1096652187.2924.0.camel@localhost.localdomain> References: <20041001011515.8AD884BCA03@stutter.bur.st> <20041001070249.GA20727@www.async.com.br> <415D0259.5080305@bugzilla.org> <1096652187.2924.0.camel@localhost.localdomain> Message-ID: <415DB822.1000903@mozilla.org> Max Kanat-Alexander wrote: > You know, to be fair, with our CSS redesign plans, we're going to be >dropping support for most clients that would be using HTTP/1.0 anyhow. > > The CSS language was designed to degrade gracefully on CSS-unaware clients, and it's how we're designing the Bugzilla CSS as well, so once Bugzilla is completely CSSified we'll still continue to support clients that don't grok CSS. -myk From justdave at bugzilla.org Fri Oct 1 20:44:55 2004 From: justdave at bugzilla.org (David Miller) Date: Fri, 01 Oct 2004 16:44:55 -0400 Subject: mid-air collisions on bmo In-Reply-To: References: Message-ID: <415DC1C7.1070604@bugzilla.org> Jason Pyeron wrote: > is https://bugzilla.mozilla.org/show_bug.cgi?id=53452 > applied? > > if so, then something is up. No, it's not. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From andyster at gmail.com Sat Oct 2 23:21:40 2004 From: andyster at gmail.com (Andy Smith) Date: Sat, 2 Oct 2004 16:21:40 -0700 Subject: Sxip: a new authentication and user-base for Bugzilla Message-ID: <54190141041002162156b1571d@mail.gmail.com> Hey folks, For the impatient who already know about Sxip, a demo is at http://an9.org/bugs (you will have to register with demohomesite.com, first, otherwise you probably won't know what is going on) and click log in. If all goes well once you sxip in you will have a new account on the site ready to post bugs with. I just wrote a chunk of code to integrate Sxip authentication with Bugzilla. Sxip, since many of you probably haven't heard of it yet (it is quite new, but growing fast), is an open, distributed, platform for personal digital identity management (kind of like Passport but cooler and not evil). More info at https://sxip.org. Basically, where it fits in with Bugzilla, it is single sign-on for the web with verifiable (cert signed xml) user data transmission. This lets a user arrive at a site for the first time and give verifiable evidence that he is who he says he his (at this point this is limited to an email address, but it scales to much more) so that he does not have to register a new account on that site. So, in Bugzilla, this means when a new users come to submit a bug they can simply log in without having to first register their email address (email + confirmation that we all hate). I have set up a demo of the code at http://an9.org/bugs, but you will need to register an account at https://demohomesite.com first to test it out. Once you've done that, click Log In on the demo and then Sxip In. The code itself is available at http://an9.org/data/sxip-bugzilla.tgz along with some more in-depth documentation and diagrams. The current implementation is mostly a proof of concept, as my knowledge of the Bugzilla code is mostly limited to the few hours I spent on this project, but if I get some positive feedback from this it could develop into a very useful thing. Imagine a world where you no longer have to go through a new registration process for every project you want to submit a bug for, or remember which email address you used as your login. Sounds pretty nice to me. (P.S. Mailman is next on my list.) Anyway, there's everything for your talented persual. Any comments, questions, or assistance are welcome, more contact info on me is available on my wiki at http://an9.org/w/AndySmith. Thanks. - Andy From justdave at bugzilla.org Sun Oct 3 00:07:27 2004 From: justdave at bugzilla.org (David Miller) Date: Sat, 02 Oct 2004 20:07:27 -0400 Subject: Sxip: a new authentication and user-base for Bugzilla In-Reply-To: <54190141041002162156b1571d@mail.gmail.com> References: <54190141041002162156b1571d@mail.gmail.com> Message-ID: <415F42BF.2090705@bugzilla.org> Andy Smith wrote: > I just wrote a chunk of code to integrate Sxip authentication with > Bugzilla. Just grabbed the tarball and had a peek, and I like the idea first off. However, I don't like the idea of modifying Bugzilla.pm to make it work. If you need changes there, you should let us know what changes you need and see if we can provide a hook somehow so you don't have to actually change anything in Bugzilla itself. In Bugzilla 2.19.1 (due to be released in the next day or so), the authentication modules have been split up so there is a complete distinction between "modules that interact with the user to gather authentication information" and "modules that interact with an authentication source to determine if the user's credentials are valid". As such, Auth::CGI can now be replaced just as easily as Auth::DB can be, and only requires changes to the parameters to pick the one you want to use. For example, we now provide one that lets you use an environment variable for authentication (in case of using HTTP authentication or some other web-server integrated signon which provides the authenticated user's information in an environment variable). If you can't already make it work within that infrastructure, I'd be very interested in getting Bugzilla itself to the point where you can install your integration just by dropping those files into the Auth directories. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From bugreport at peshkin.net Sun Oct 3 00:31:46 2004 From: bugreport at peshkin.net (Joel Peshkin) Date: Sat, 02 Oct 2004 17:31:46 -0700 Subject: Sxip: a new authentication and user-base for Bugzilla In-Reply-To: <54190141041002162156b1571d@mail.gmail.com> References: <54190141041002162156b1571d@mail.gmail.com> Message-ID: <415F4872.6030701@peshkin.net> Actually, from a first glance, what you are trying to do should be a very good fit with the new authentication in Bugzilla. In particular, the new system should permit you to keep your changes to a very few files. I suggest you look at the support in 2.19 for authentication by environment variable. It has the capability to identify a user by using a persistant identifier (like your GUPI) and then associating it with the login_name (a.k.a. email address). A key difference is what happens the first time a user who exists in Bugzilla but has no GUPI visits and is authenticated by SXIP. In the case analagous to the environment authentication, Bugzilla will learn that, since there was no user with that GUPI and the user with the same email address had no GUPI, this email address now does go with that GUPI. -Joel From andyster at gmail.com Sun Oct 3 04:43:42 2004 From: andyster at gmail.com (Andy Smith) Date: Sat, 2 Oct 2004 21:43:42 -0700 Subject: Sxip: a new authentication and user-base for Bugzilla In-Reply-To: <415F42BF.2090705@bugzilla.org> References: <54190141041002162156b1571d@mail.gmail.com> <415F42BF.2090705@bugzilla.org> Message-ID: <54190141041002214346014da1@mail.gmail.com> > Just grabbed the tarball and had a peek, and I like the idea first off. > However, I don't like the idea of modifying Bugzilla.pm to make it > work. If you need changes there, you should let us know what changes > you need and see if we can provide a hook somehow so you don't have to > actually change anything in Bugzilla itself. This is actually almost exactly why I was submitting this. I noticed in the comments that there was planned support for more authentication systems, so I had high hopes of some support from you guys as to where to proceed further. I'll check out 2.19 and see what the outlook is from there. Thanks for the tip. From gerv at mozilla.org Tue Oct 5 07:36:59 2004 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 05 Oct 2004 08:36:59 +0100 Subject: mid-air collisions on bmo In-Reply-To: References: Message-ID: <41624F1B.7060308@mozilla.org> Jason Pyeron wrote: > is https://bugzilla.mozilla.org/show_bug.cgi?id=53452 > applied? > > if so, then something is up. No - we haven't updated between the end of July (when the bug was fixed) and now. Gerv From chicks at chicks.net Wed Oct 6 14:40:00 2004 From: chicks at chicks.net (Christopher Hicks) Date: Wed, 6 Oct 2004 10:40:00 -0400 (EDT) Subject: What are bugs? Are bugs really work items? In-Reply-To: <827BF123F7B64D48A7F305D6688840750B872F@ex2k.bitheadsinc.local> References: <827BF123F7B64D48A7F305D6688840750B872F@ex2k.bitheadsinc.local> Message-ID: On Wed, 6 Oct 2004, Jay Glanville wrote: > The argument to not use the severity field to indicate feature work is > because you might want to use the severity field for features. For > example, a feature could have a 'critical' severity to indicate the > amount of work required, or a severity of 'trivial' to indicate it's > just a small feature. > > Basically, the correct answer to this problem is to have a "type" field, > and to stop calling the items 'bugs'. For example, all items are 'work > items', and the type field had possibilities of: bug, suggestion or > feature. This would basically capture the situation in a nutshell. > Hold on, if we changed 'bugs' to 'work items', does that mean we'd have > to change the name from Bugzilla to WorkItemZilla? ;-) This comes from a recent discussion on the webtools list. Since this is a question about the direction/future of bugzilla which I've had on my mind and in my inbox quite often recently so I decided to bring this to the developers list. Would the core devs be willing to share their thoughts and feelings on this seemingly sensible question? If I had more sleep I'd slip in something witty about the continually blurring semantics of bugs, but I'm not that coherent yet this morning. :) -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare From kiko at async.com.br Wed Oct 6 14:55:21 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Wed, 6 Oct 2004 11:55:21 -0300 Subject: What are bugs? Are bugs really work items? In-Reply-To: References: <827BF123F7B64D48A7F305D6688840750B872F@ex2k.bitheadsinc.local> Message-ID: <20041006145521.GF1356@async.com.br> On Wed, Oct 06, 2004 at 10:40:00AM -0400, Christopher Hicks wrote: > >Hold on, if we changed 'bugs' to 'work items', does that mean we'd have > >to change the name from Bugzilla to WorkItemZilla? ;-) Note that that is currently trivial to do, requiring two one-line changes to global/variables.none.tmpl. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 From lisa.anderson at imcentric.com Wed Oct 6 15:16:27 2004 From: lisa.anderson at imcentric.com (Lisa Anderson) Date: Wed, 6 Oct 2004 09:16:27 -0600 Subject: What are bugs? Are bugs really work items? Message-ID: <7EEAE93B09529A40972F5EFC7093ED6307F35D@imc-exchange.IMCentricAD> I'm relatively new to Bugzilla; we've set it up here at work and have been using it for the last 3 weeks and have been pleased overall. The severity field has been a problem for us, however, and it looks like others are struggling with it as well. In other situations I have used the severity field as follows: Severity * Likelihood = Priority. We even got fancier and rated each component or feature as to the development risk, i.e., how hard is it to fix, how much code is involved, etc. The formula becomes this: Severity * Likelihood * Dev Risk = Priority. I like this method because using scales like the following takes the subjectivity out of prioritizing bugs. Severity: Blue Screen/Hang Loss w/o workaround Loss w/ workaround Inconvenient Enhancement Likelihood (how often will the user - not the developer) run into this problem: Always Usually Sometimes Rarely Never Bottom line this means that it doesn't matter what you call the records in Bugzilla - bugs, work items, feature enhancements, whatever. The records now all become issues that need to be addressed some how, some way before the product can be shipped. And, with the method above, the records are properly identified as to their importance to the project. LisaAn -----Original Message----- From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] On Behalf Of Christopher Hicks Sent: Wednesday, October 06, 2004 8:40 AM To: Bugzilla Developers Mailing List Cc: Jay Glanville Subject: What are bugs? Are bugs really work items? On Wed, 6 Oct 2004, Jay Glanville wrote: > The argument to not use the severity field to indicate feature work is > because you might want to use the severity field for features. For > example, a feature could have a 'critical' severity to indicate the > amount of work required, or a severity of 'trivial' to indicate it's > just a small feature. > > Basically, the correct answer to this problem is to have a "type" field, > and to stop calling the items 'bugs'. For example, all items are 'work > items', and the type field had possibilities of: bug, suggestion or > feature. This would basically capture the situation in a nutshell. > Hold on, if we changed 'bugs' to 'work items', does that mean we'd have > to change the name from Bugzilla to WorkItemZilla? ;-) This comes from a recent discussion on the webtools list. Since this is a question about the direction/future of bugzilla which I've had on my mind and in my inbox quite often recently so I decided to bring this to the developers list. Would the core devs be willing to share their thoughts and feelings on this seemingly sensible question? If I had more sleep I'd slip in something witty about the continually blurring semantics of bugs, but I'm not that coherent yet this morning. :) -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare - To view or change your list settings, click here: From john.fisher at znyx.com Wed Oct 6 15:19:27 2004 From: john.fisher at znyx.com (John Fisher) Date: Wed, 06 Oct 2004 08:19:27 -0700 Subject: What are bugs? Are bugs really work items? In-Reply-To: References: <827BF123F7B64D48A7F305D6688840750B872F@ex2k.bitheadsinc.local> Message-ID: <41640CFF.30001@znyx.com> In my experience 'enhancements' or more commonly 'features' don't have a priority ( except for the sales group ) they have a scheduled release. Changing to 'work items' is a mental jump onto the slippery slope to a task-management system. Bugzilla already has feature bloat, don't make it worse. If OTOH its just a semantic argument, then put in a proper variable and let everybody change it in the params. Christopher Hicks wrote: > On Wed, 6 Oct 2004, Jay Glanville wrote: > >> The argument to not use the severity field to indicate feature work is >> because you might want to use the severity field for features. For >> example, a feature could have a 'critical' severity to indicate the >> amount of work required, or a severity of 'trivial' to indicate it's >> just a small feature. -- John P. Fisher at ZNYX Networks 805 683 1488 x 3245 john.fisher at znyx.com From mkanat at kerio.com Wed Oct 6 19:27:59 2004 From: mkanat at kerio.com (Max Kanat-Alexander) Date: Wed, 06 Oct 2004 12:27:59 -0700 Subject: What are bugs? Are bugs really work items? In-Reply-To: References: <827BF123F7B64D48A7F305D6688840750B872F@ex2k.bitheadsinc.local> Message-ID: <1097090878.2927.3.camel@localhost.localdomain> My apologies for not quoting, but I think the Subject handles the question to be answered quite well-enough. To be fair, I use our Bugzilla here at Kerio to keep track of my personal tasks, and certain tasks for the IT department. I think it's the best way to choose who I want to keep informed, hold a running record of everything I've done for myself to look back on, and provide that same record to anybody else who may need to see the archive in the future. I don't really find, though, that at this time Bugzilla needs any additional features to make this more useful to me. Just the most basic features of Bugzilla give me everything I really need for it. :-) -Max From micklweiss at gmx.net Thu Oct 7 16:07:16 2004 From: micklweiss at gmx.net (Mick Weiss) Date: Thu, 07 Oct 2004 12:07:16 -0400 Subject: What are bugs? Are bugs really work items? In-Reply-To: <7EEAE93B09529A40972F5EFC7093ED6307F35D@imc-exchange.IMCentricAD> References: <7EEAE93B09529A40972F5EFC7093ED6307F35D@imc-exchange.IMCentricAD> Message-ID: <416569B4.5060707@gmx.net> I'm not sure if anyone else has used "Eventum" - from the folks who wrote MySQL. This has one cool feature - the ability to create custom fields in the priority drop down. the only problem is that you *need to* define them yourself and there are no defaults. Then again this is also possible with Bugzilla - but it just takes a little more work. The other thing is that Eventum is more for "Issue tracking" and not really for software development bug tracking. I actually use both Eventum and Bugzilla to keep those two things separate. I guess the idea is to use the right tool for each job. Best Regards, - Mick (o> Web / software developer ( ) UNIX Systems Admin --- ~ www.mickweiss.com ~ Lisa Anderson wrote: > I'm relatively new to Bugzilla; we've set it up here at work and have > been using it for the last 3 weeks and have been pleased overall. > > The severity field has been a problem for us, however, and it looks like > others are struggling with it as well. In other situations I have used > the severity field as follows: > > Severity * Likelihood = Priority. > > We even got fancier and rated each component or feature as to the > development risk, i.e., how hard is it to fix, how much code is > involved, etc. The formula becomes this: > > > Severity * Likelihood * Dev Risk = Priority. > > I like this method because using scales like the following takes the > subjectivity out of prioritizing bugs. > > Severity: > Blue Screen/Hang > Loss w/o workaround > Loss w/ workaround > Inconvenient > Enhancement > > Likelihood (how often will the user - not the developer) run into this > problem: > Always > Usually > Sometimes > Rarely > Never > > Bottom line this means that it doesn't matter what you call the records > in Bugzilla - bugs, work items, feature enhancements, whatever. The > records now all become issues that need to be addressed some how, some > way before the product can be shipped. And, with the method above, the > records are properly identified as to their importance to the project. > > LisaAn > > > -----Original Message----- > From: developers-owner at bugzilla.org > [mailto:developers-owner at bugzilla.org] On Behalf Of Christopher Hicks > Sent: Wednesday, October 06, 2004 8:40 AM > To: Bugzilla Developers Mailing List > Cc: Jay Glanville > Subject: What are bugs? Are bugs really work items? > > On Wed, 6 Oct 2004, Jay Glanville wrote: > >>The argument to not use the severity field to indicate feature work is >>because you might want to use the severity field for features. For >>example, a feature could have a 'critical' severity to indicate the >>amount of work required, or a severity of 'trivial' to indicate it's >>just a small feature. >> >>Basically, the correct answer to this problem is to have a "type" > > field, > >>and to stop calling the items 'bugs'. For example, all items are > > 'work > >>items', and the type field had possibilities of: bug, suggestion or >>feature. This would basically capture the situation in a nutshell. >>Hold on, if we changed 'bugs' to 'work items', does that mean we'd > > have > >>to change the name from Bugzilla to WorkItemZilla? ;-) > > > This comes from a recent discussion on the webtools list. Since this is > a > question about the direction/future of bugzilla which I've had on my > mind > and in my inbox quite often recently so I decided to bring this to the > developers list. Would the core devs be willing to share their thoughts > > and feelings on this seemingly sensible question? > > If I had more sleep I'd slip in something witty about the continually > blurring semantics of bugs, but I'm not that coherent yet this morning. > :) > From kiko at async.com.br Thu Oct 7 16:16:43 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Thu, 7 Oct 2004 13:16:43 -0300 Subject: What are bugs? Are bugs really work items? In-Reply-To: <416569B4.5060707@gmx.net> References: <7EEAE93B09529A40972F5EFC7093ED6307F35D@imc-exchange.IMCentricAD> <416569B4.5060707@gmx.net> Message-ID: <20041007161643.GA2267@async.com.br> On Thu, Oct 07, 2004 at 12:07:16PM -0400, Mick Weiss wrote: > I'm not sure if anyone else has used "Eventum" - from the folks who > wrote MySQL. This has one cool feature - the ability to create custom > fields in the priority drop down. the only problem is that you *need to* > define them yourself and there are no defaults. You can do this as well in Bugzilla by changing localconfig -- and by making it just a "little more work" we avoid the proliferation of user-defined priorities ("forget sleeping!", etc). We could have a Web interface for localconfig changes, of course. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 From chicks at chicks.net Thu Oct 7 16:46:31 2004 From: chicks at chicks.net (Christopher Hicks) Date: Thu, 7 Oct 2004 12:46:31 -0400 (EDT) Subject: What are bugs? Are bugs really work items? In-Reply-To: <416569B4.5060707@gmx.net> References: <7EEAE93B09529A40972F5EFC7093ED6307F35D@imc-exchange.IMCentricAD> <416569B4.5060707@gmx.net> Message-ID: On Thu, 7 Oct 2004, Mick Weiss wrote: > I guess the idea is to use the right tool for each job. But wouldn't an even better idea be to use one integrated tool that accomplishes both jobs well? I'm all for the UNIX toolkit philosophy to API's of various kinds whether they be web services, libraries, or the command line. But the Perl philosophy of throw all the good stuff in one pot and let it simmer is much more appropriate at the level of application design. The simmering part of the process may be painful at times, but the results can be quite nice. (Think Linux and Firefox.) -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare From mkanat at kerio.com Thu Oct 7 21:58:16 2004 From: mkanat at kerio.com (Max Kanat-Alexander) Date: Thu, 07 Oct 2004 14:58:16 -0700 Subject: What are bugs? Are bugs really work items? In-Reply-To: References: <7EEAE93B09529A40972F5EFC7093ED6307F35D@imc-exchange.IMCentricAD> <416569B4.5060707@gmx.net> Message-ID: <1097186296.5708.4.camel@localhost.localdomain> On Thu, 2004-10-07 at 09:46, Christopher Hicks wrote: > The simmering part of the process may be painful at times, but > the results can be quite nice. (Think Linux and Firefox.) Actually, interesting that you chose those two examples -- Firefox is a reversal of that theory, a moving away from the Mozilla Suite and separating the browser. Linux follows the Unix Philosophy most definitely, where all the different parts of the kernel can be modularized and are written mostly separately. (Though it is a monolithic kernel, so it does give some credit to your theory.) -Max -- Maxwell Kanat-Alexander 2nd Level Tech Support Engineer, USA Kerio Technologies, Inc. 2041 Mission College Blvd. Suite 100 Santa Clara, CA 95054 Phone: (408) 496-4500 Fax: (408) 496-6902 Web: http://www.kerio.com/support.html From chicks at chicks.net Fri Oct 8 23:43:27 2004 From: chicks at chicks.net (Christopher Hicks) Date: Fri, 8 Oct 2004 19:43:27 -0400 (EDT) Subject: What are bugs? Are bugs really work items? In-Reply-To: <41640CFF.30001@znyx.com> References: <827BF123F7B64D48A7F305D6688840750B872F@ex2k.bitheadsinc.local> <41640CFF.30001@znyx.com> Message-ID: On Wed, 6 Oct 2004, John Fisher wrote: > In my experience 'enhancements' or more commonly 'features' don't have a > priority ( except for the sales group ) they have a scheduled release. I can see that. But we have several clients that have features and we use bugzilla to prioritize them. > Changing to 'work items' is a mental jump onto the slippery slope to a > task-management system. I'm running down that slide as fast as I can. > Bugzilla already has feature bloat, don't make it worse. I'm not trying to. I'm trying to make other things fit cleanly with bugzilla so that people that want more than bug tracking can have it without massive change to bugzilla or the other pieces being melded. > If OTOH its just a semantic argument, then put in a proper variable > and let everybody change it in the params. My original question was certainly a purely semantic one. I don't have any problem with having a few equivalent terms that people can use as they like and letting people choose, but that's just the pragmatic part. The semantic question is intersting because if we accept that bugs can be bugs, features, work items, and maybe a few other terms, then maybe some folks might consider expanding the appropraite directions for feature creep. Maybe everybody gets this and I'm asking a stupid question. The answers I've gotten haven't really seemed to get the question. Maybe this meandering restatement will be less confusing than my terse prose. -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare From travis at SEDSystems.ca Sat Oct 9 00:08:29 2004 From: travis at SEDSystems.ca (Shane H. W. Travis) Date: Fri, 8 Oct 2004 18:08:29 -0600 (CST) Subject: What are bugs? Are bugs really work items? In-Reply-To: References: <827BF123F7B64D48A7F305D6688840750B872F@ex2k.bitheadsinc.local> <41640CFF.30001@znyx.com> Message-ID: I know I'm new around here, but I thought I'd throw in my two cents worth about how WE use it at this company. One of the first customizations that was made around he was to add a 'Category' function to our bugs. (One of the second customizations was to substitute 'Log Item' for 'Bug' everywhere it appeared.) This category field contains the following: Requirement Change - Customer Originated Requirement Change - Internally Originated Defect - System Performance Defect - Internal HW Unit Defect - Purchased HW Unit Defect - Performance/Crash/Memory Defect - Physical (Mechanical/Electrical) Defect - User Interface Implementation Defect - Algorithm/Code Design Defect - Algorithm/Code Implementation Defect - External Interface SW Defect - External System Defect - Internal Equipment Driver SW Defect - Database Structure/Content/Design Defect - Missing Functionality User Interface - Defect/Problem User Interface - Enhancement User Interface - Cosmetic SW Config Control Documentation Todo/Reminder Yeah, they aren't laid out as well as they could be, and some of the categories overlap (some overlap a LOT), but it gives a pretty good overview of the sorts of things that we use Bugzilla for. Basically, if it's something that needs doing on a project -- whether it's a huge, showstopping bug, or just a typo on the UI -- it gets logged by someone, and assigned to someone (else), and tracked so we know how things are coming along. Took a while to get into the habit, but now it's pretty much ingrained in folks... and it sure saves a lot of paper. Speeds up communication internally too, in a lot of cases. We also added some time-management functionality, which I'm eagerly looking forward to replacing with that of 2.18. (Ours is just a simple 'Labour Impact' with a few discrete drop-downs, and it isn't tracked by person at all, nor can it be updated without replacement.) Finally, our installation is modified to use Design Authority (usually the Project Manager) instead of the QAContact field; every time a log item changes state, ownership automatically reverts to the Design Authority so he/she can decide what happens next -- reassign to someone else for verification, reopen, close, etc. We've done a lot of customization to get ours how we like it, and we use it for waaaaay more than 'just' bugs. Does that answer your question at all? Shane Travis | Physics is like sex. Sure, it may give some travis at sedsystems.ca | practical results, but that's not why we Saskatoon, Saskatchewan | do it. -- Richard Feynman From gerv at mozilla.org Sat Oct 9 17:14:42 2004 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 09 Oct 2004 18:14:42 +0100 Subject: What are bugs? Are bugs really work items? In-Reply-To: References: <827BF123F7B64D48A7F305D6688840750B872F@ex2k.bitheadsinc.local> <41640CFF.30001@znyx.com> Message-ID: <41681C82.3080901@mozilla.org> Christopher Hicks wrote: >> Changing to 'work items' is a mental jump onto the slippery slope to a >> task-management system. > > I'm running down that slide as fast as I can. Yeah, Chris, we know you are :-) The problem is, last time we talked about it, the current project direction was to avoid going that way. I guess if Dave wants to change that (or if I've completely misunderstood him ;-), he'll re-open the discussion, but until then if you try to get more task management features into Bugzilla, all that'll happen is that you'll increasingly come into conflict with the other developers. (This is a general comment, and doesn't reflect a particular opinion on the question under discussion.) Gerv From chicks at chicks.net Sat Oct 9 18:12:08 2004 From: chicks at chicks.net (Christopher Hicks) Date: Sat, 9 Oct 2004 14:12:08 -0400 (EDT) Subject: What are bugs? Are bugs really work items? In-Reply-To: <41681C82.3080901@mozilla.org> References: <827BF123F7B64D48A7F305D6688840750B872F@ex2k.bitheadsinc.local> <41640CFF.30001@znyx.com> <41681C82.3080901@mozilla.org> Message-ID: On Sat, 9 Oct 2004, Gervase Markham wrote: > Christopher Hicks wrote: >>> Changing to 'work items' is a mental jump onto the slippery slope to a >>> task-management system. >> >> I'm running down that slide as fast as I can. > > Yeah, Chris, we know you are :-) My failings don't include an inability to be vocal. :) > The problem is, last time we talked about it, the current project > direction was to avoid going that way. I understand that. I respect the motivations than went into that choice. But when other projects are being written that do bug, task, wiki and version tracking in a seemlessly integrated way bugzilla runs the risk of being relegated to the also-rans. I personally think that would be tragic and I'd rather get teeth extracted than run PHP or Python for my daily work. Given the recent directions of opening up better cleaner interfaces for interacting with bugzilla I'm hopeful that a variety of existing technologies (wiki, svn, cvsmonitor, viewcvs, my existing billing code, etc.) can be integrated into a bugzilla superset which will make my life easier and not incur the steep uphill climb that having these things added to bugzilla would obviously entail. > I guess if Dave wants to change that (or if I've completely > misunderstood him ;-), he'll re-open the discussion, but until then if > you try to get more task management features into Bugzilla, all that'll > happen is that you'll increasingly come into conflict with the other > developers. I don't think that would be healthy for me or bugzilla. I'd really like to convince people that a single-value primary key on longdescs would be good though. (Bug 225221 if you're interested.) Given that I haven't managed to do that yet, I'm in no way deluded enough to try to make a significant contribution directly to bugzilla. I'm trying to answer moz-webtools list questions that I have some ability to help with or that Dave doesn't get to first and work on bringing together a small team to work on this bugzilla superset idea that I mentioned a few weeks ago, so I haven't given up on bugzilla or helping the bugzilla community, but indirect contributions seem much more effective at this stage. > (This is a general comment, and doesn't reflect a particular opinion on > the question under discussion.) I guess its a dead horse. Sorry for beating this drum again. I truly thought that some core bugzilla dev might be willing to engage in the semantic conversation and that it might lead to some enlightening conclusions. C'est la vie. I'll go crawl back in my hole until we've got something to show that people might be interested in playing with. Actually we should have a mailing list going this week to start discussing goals and design ideas. I'll post when it's working. Thanks for all the folks who have sent me private notes of support in this process. And particular thanks and apologies to the bugzilla developers I've annoyed in trying to get task management implemented in bugzilla. -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare From micklweiss at gmx.net Sat Oct 9 21:41:48 2004 From: micklweiss at gmx.net (Mick Weiss) Date: Sat, 09 Oct 2004 17:41:48 -0400 Subject: What are bugs? Are bugs really work items? In-Reply-To: References: <827BF123F7B64D48A7F305D6688840750B872F@ex2k.bitheadsinc.local> <41640CFF.30001@znyx.com> <41681C82.3080901@mozilla.org> Message-ID: <41685B1C.2090905@gmx.net> Christopher Hicks wrote: > On Sat, 9 Oct 2004, Gervase Markham wrote: > >> Christopher Hicks wrote: >> >>>> Changing to 'work items' is a mental jump onto the slippery slope to >>>> a task-management system. >>> >>> >>> I'm running down that slide as fast as I can. >> >> >> Yeah, Chris, we know you are :-) > > > My failings don't include an inability to be vocal. :) > >> The problem is, last time we talked about it, the current project >> direction was to avoid going that way. > > > I understand that. I respect the motivations than went into that > choice. But when other projects are being written that do bug, task, > wiki and version tracking in a seemlessly integrated way bugzilla runs > the risk of being relegated to the also-rans. I personally think that > would be tragic and I'd rather get teeth extracted than run PHP or > Python for my daily work. I resent that. I'm a PHP programmer :-P > > Given the recent directions of opening up better cleaner interfaces for > interacting with bugzilla I'm hopeful that a variety of existing > technologies (wiki, svn, cvsmonitor, viewcvs, my existing billing code, > etc.) can be integrated into a bugzilla superset which will make my life > easier and not incur the steep uphill climb that having these things > added to bugzilla would obviously entail. > >> I guess if Dave wants to change that (or if I've completely >> misunderstood him ;-), he'll re-open the discussion, but until then if >> you try to get more task management features into Bugzilla, all >> that'll happen is that you'll increasingly come into conflict with the >> other developers. > > > I don't think that would be healthy for me or bugzilla. I'd really like > to convince people that a single-value primary key on longdescs would be > good though. (Bug 225221 if you're interested.) Given that I haven't > managed to do that yet, I'm in no way deluded enough to try to make a > significant contribution directly to bugzilla. I'm trying to answer > moz-webtools list questions that I have some ability to help with or > that Dave doesn't get to first and work on bringing together a small > team to work on this bugzilla superset idea that I mentioned a few weeks > ago, so I haven't given up on bugzilla or helping the bugzilla > community, but indirect contributions seem much more effective at this > stage. > >> (This is a general comment, and doesn't reflect a particular opinion >> on the question under discussion.) > > > I guess its a dead horse. Sorry for beating this drum again. I truly > thought that some core bugzilla dev might be willing to engage in the > semantic conversation and that it might lead to some enlightening > conclusions. C'est la vie. I'll go crawl back in my hole until we've > got something to show that people might be interested in playing with. > Actually we should have a mailing list going this week to start > discussing goals and design ideas. I'll post when it's working. Chris, if you feel so inclined - fork this project (or create "module" addons - that could just be diffs). The whole thing could be a perl wrapper around "patch". And I think that you could feel free to post those to this list. > > Thanks for all the folks who have sent me private notes of support in > this process. And particular thanks and apologies to the bugzilla > developers I've annoyed in trying to get task management implemented in > bugzilla. > I haven't been annoyed myself (I found it rather intriguing even though I wouldn't use it). Why not open a project on sf.net bugzilla-task-management or something. I'm sure you could find people interested in this. Hell, I'd even volunteer to set this up and help develop something like this (even though I probably wouldn't use it). Send me a message about who is interested. I'm sure Dave would be willing to even link to the project from www.bugzilla.org if it actually becomes usable. Hell, it could even be something more general like: bugzilla-addons with un-approved addons for bugzilla (addons that don't follow the design goals of bugzilla). Just my 2 cents. - Mick (o> Web / software developer ( ) UNIX Systems Admin --- ~ www.mickweiss.com ~ From bugreport at peshkin.net Sat Oct 9 21:56:24 2004 From: bugreport at peshkin.net (Joel Peshkin) Date: Sat, 09 Oct 2004 14:56:24 -0700 Subject: What are bugs? Are bugs really work items? In-Reply-To: References: <827BF123F7B64D48A7F305D6688840750B872F@ex2k.bitheadsinc.local> <41640CFF.30001@znyx.com> <41681C82.3080901@mozilla.org> Message-ID: <41685E88.5090008@peshkin.net> Christopher Hicks wrote: > I guess its a dead horse. Sorry for beating this drum again. I truly > thought that some core bugzilla dev might be willing to engage in the > semantic conversation and that it might lead to some enlightening > conclusions. C'est la vie. I'll go crawl back in my hole until we've > got something to show that people might be interested in playing with. > Actually we should have a mailing list going this week to start > discussing goals and design ideas. I'll post when it's working. > > Thanks for all the folks who have sent me private notes of support in > this process. And particular thanks and apologies to the bugzilla > developers I've annoyed in trying to get task management implemented > in bugzilla. > Actually, it would be best to start by identifying the places where adding new hooks to Bugzilla makes it easier to tie in functionality that the standard Bugzilla does not want. The addition of templates, modular authentication, template hooks, template plugins, etc... all move the underlying Bugzilla project in a direction that makes it easier to do this sort of thing. Aside from a few custom fields and some template changes, I suspect that one of the major things needed for work items is to have a stronger sense of workflow. This is something that is useful to the core Bugzilla project as well. Let's look for the common parts before focussing in the parts that diverge. -Joel From gerv at mozilla.org Sat Oct 9 22:27:28 2004 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 09 Oct 2004 23:27:28 +0100 Subject: What are bugs? Are bugs really work items? In-Reply-To: <41685E88.5090008@peshkin.net> References: <827BF123F7B64D48A7F305D6688840750B872F@ex2k.bitheadsinc.local> <41640CFF.30001@znyx.com> <41681C82.3080901@mozilla.org> <41685E88.5090008@peshkin.net> Message-ID: <416865D0.20909@mozilla.org> > Christopher Hicks wrote: >> Thanks for all the folks who have sent me private notes of support in >> this process. And particular thanks and apologies to the bugzilla >> developers I've annoyed in trying to get task management implemented >> in bugzilla. I seem to have missed the original of this... but I don't think anyone's annoyed. I just wanted to point out the difference in goals to make sure that no-one was misled. We have enough trouble keeping up with the bug fixes and feature requests to make Bugzilla a world-class bug-tracking (or defect-tracking - call them what you like) system. This is demonstrated by the fairly slow pace of development and the difficulty in getting reviews. Trying to be different pieces of software as well would just lead to developers being spread even more thinly than they currently are. Joel Peshkin wrote: > Actually, it would be best to start by identifying the places where > adding new hooks to Bugzilla makes it easier to tie in functionality > that the standard Bugzilla does not want. The addition of templates, > modular authentication, template hooks, template plugins, etc... all > move the underlying Bugzilla project in a direction that makes it easier > to do this sort of thing. Absolutely. No argument from me on this front. > Aside from a few custom fields and some template changes, I suspect that > one of the major things needed for work items is to have a stronger > sense of workflow. This is something that is useful to the core > Bugzilla project as well. More agreement :-) I'm all for cust res. and cust. statuses. Gerv From chicks at chicks.net Sat Oct 9 22:44:12 2004 From: chicks at chicks.net (Christopher Hicks) Date: Sat, 9 Oct 2004 18:44:12 -0400 (EDT) Subject: What are bugs? Are bugs really work items? In-Reply-To: <41685B1C.2090905@gmx.net> References: <827BF123F7B64D48A7F305D6688840750B872F@ex2k.bitheadsinc.local> <41640CFF.30001@znyx.com> <41681C82.3080901@mozilla.org> <41685B1C.2090905@gmx.net> Message-ID: On Sat, 9 Oct 2004, Mick Weiss wrote: > Christopher Hicks wrote: >> I understand that. I respect the motivations than went into that choice. >> But when other projects are being written that do bug, task, wiki and >> version tracking in a seemlessly integrated way bugzilla runs the risk of >> being relegated to the also-rans. I personally think that would be tragic >> and I'd rather get teeth extracted than run PHP or Python for my daily >> work. > > I resent that. I'm a PHP programmer :-P Feel free to program in PHP if you like. I think you're making a mistake for various OT reasons, but I've posted about this enough to thoroughly tork Rasmus on a few occassions so it shouldn't too hard to find. If you want to discuss this with me off list, send me a direct note. Try Apache::ASP though. It's my nicorette for PHP addicts. > Chris, if you feel so inclined - fork this project (or create "module" > addons - that could just be diffs). The whole thing could be a perl > wrapper around "patch". And I think that you could feel free to post > those to this list. I'm trying very hard to avoid forking anything. I'd like to include some patches (like custom fields) that haven't gotten much exposure and that have had people begging for it for years, but I'm prepared to deal with whatever the migration issues are when the bugzilla core folks sanctify a custom fields patch of their own. > I haven't been annoyed myself (I found it rather intriguing even though > I wouldn't use it). Given that the target audience for this thread has been utterly silent on the prime topic of the thread I'm guessing I've annoyed some folks beyond caring about what I'm saying. > Why not open a project on sf.net bugzilla-task-management or something. I've played with running a sourceforge project and it was severely lacking. For one thing, I want to use svn instead of cvs. But when you get right down to it a lot of what I'm looking at doing is creating something that's going to compete with sourceforge. And I fully intend to eat my own dogfood throughout this process. I have servers. I have bandwidth. I just want some better tools to deal with an increasingly workload. Bugzilla runs my life in some senses and I'd like to spend less time on overhead and more time on doing what people are asking for. > I'm sure you could find people interested in this. There are a couple so far. Previous times this topic has come up there was no interest whatsoever, so two folks is sounding much better than squeezing out all the time myself. > Hell, I'd even volunteer to set this up and help develop something like > this (even though I probably wouldn't use it). Send me a message about > who is interested. We're setting up a mailing list next, and then a wiki, and soon after a dedicated server for folks that want to work on the project. I haven't asked anyone who's privately emailed me if sharing their names is OK, so I'm going to leave that to them in their own good time. > I'm sure Dave would be willing to even link to the project from > www.bugzilla.org if it actually becomes usable. I'd love to get it to the point that it would be a relevant question. > Hell, it could even be something more general like: bugzilla-addons with > un-approved addons for bugzilla (addons that don't follow the design > goals of bugzilla). That's the gist of the idea. > Just my 2 cents. Thanks for responding. -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare From chicks at chicks.net Sat Oct 9 22:50:59 2004 From: chicks at chicks.net (Christopher Hicks) Date: Sat, 9 Oct 2004 18:50:59 -0400 (EDT) Subject: What are bugs? Are bugs really work items? In-Reply-To: <41685E88.5090008@peshkin.net> References: <827BF123F7B64D48A7F305D6688840750B872F@ex2k.bitheadsinc.local> <41640CFF.30001@znyx.com> <41681C82.3080901@mozilla.org> <41685E88.5090008@peshkin.net> Message-ID: On Sat, 9 Oct 2004, Joel Peshkin wrote: > Actually, it would be best to start by identifying the places where > adding new hooks to Bugzilla makes it easier to tie in functionality > that the standard Bugzilla does not want. A clean interface for creating/updating bugs including comments and time would be the main thing. I know work has been done on improving the bugzilla API's from the mailing list murmerings, but I haven't played with it myself so I'm not sure what it's got and doesn't until somebody digs into it. > The addition of templates, modular authentication, template hooks, > template plugins, etc... all move the underlying Bugzilla project in a > direction that makes it easier to do this sort of thing. I'm not particularly worried about authentication. There are plenty of generic frameworks for that. Using PAM provides fully modular authentication. I don't currently see that any templates would need to be added to BZ, but I would like to extend the easy-CSSification work once that's ready to fly (is that in yet?) to all of the different intergrated components to minimize the number of places that things need to change for localizing the look and feel. > Aside from a few custom fields and some template changes, I suspect that > one of the major things needed for work items is to have a stronger > sense of workflow. This is something that is useful to the core > Bugzilla project as well. This is something that we've batted around a little bit, but it's not a goal for the first release. I agree that something like this would be good for bugzilla and this other bugzilla-based thing. I desperately need a name for this other thing, but my cold has strangled my creative neurons this week so nothing good has popped out yet. I'm tired of talking about it in non-named terms though. Blerg. > Let's look for the common parts before focussing in the parts that diverge. Absolutely. -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare From chicks at chicks.net Sat Oct 9 22:56:15 2004 From: chicks at chicks.net (Christopher Hicks) Date: Sat, 9 Oct 2004 18:56:15 -0400 (EDT) Subject: What are bugs? Are bugs really work items? In-Reply-To: <416865D0.20909@mozilla.org> References: <827BF123F7B64D48A7F305D6688840750B872F@ex2k.bitheadsinc.local> <41640CFF.30001@znyx.com> <41681C82.3080901@mozilla.org> <41685E88.5090008@peshkin.net> <416865D0.20909@mozilla.org> Message-ID: On Sat, 9 Oct 2004, Gervase Markham wrote: > I seem to have missed the original of this... http://bugzilla.org/cgi-bin/mj_wwwusr?user=&passw=&list=developers&brief=on&func=archive-get-part&extra=200410/15 > but I don't think anyone's annoyed. When I only hear crickets I get worried. > I just wanted to point out the difference in goals to make sure that > no-one was misled. Cool. Did you feel I was being misleading somehow or just inadequately clear? > We have enough trouble keeping up with the bug fixes and feature > requests to make Bugzilla a world-class bug-tracking (or defect-tracking > - call them what you like) system. This is demonstrated by the fairly > slow pace of development and the difficulty in getting reviews. Trying > to be different pieces of software as well would just lead to developers > being spread even more thinly than they currently are. I'm not trying to change this mindset. I understand it. I respect it. It doesn't make me jump for joy, but I'm not going to fight it. -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare From micklweiss at gmx.net Sun Oct 10 01:26:15 2004 From: micklweiss at gmx.net (Mick Weiss) Date: Sat, 09 Oct 2004 21:26:15 -0400 Subject: What are bugs? Are bugs really work items? In-Reply-To: References: <827BF123F7B64D48A7F305D6688840750B872F@ex2k.bitheadsinc.local> <41640CFF.30001@znyx.com> <41681C82.3080901@mozilla.org> <41685B1C.2090905@gmx.net> Message-ID: <41688FB7.9030208@gmx.net> Christopher Hicks wrote: > On Sat, 9 Oct 2004, Mick Weiss wrote: > >> Christopher Hicks wrote: >> >>> I understand that. I respect the motivations than went into that >>> choice. But when other projects are being written that do bug, task, >>> wiki and version tracking in a seemlessly integrated way bugzilla >>> runs the risk of being relegated to the also-rans. I personally >>> think that would be tragic and I'd rather get teeth extracted than >>> run PHP or Python for my daily work. >> >> >> I resent that. I'm a PHP programmer :-P > > > Feel free to program in PHP if you like. I think you're making a > mistake for various OT reasons, but I've posted about this enough to > thoroughly tork Rasmus on a few occassions so it shouldn't too hard to > find. If you want to discuss this with me off list, send me a direct > note. Try Apache::ASP though. It's my nicorette for PHP addicts. > It was a joke, leave it alone. >> Chris, if you feel so inclined - fork this project (or create "module" >> addons - that could just be diffs). The whole thing could be a perl >> wrapper around "patch". And I think that you could feel free to post >> those to this list. > > > I'm trying very hard to avoid forking anything. I'd like to include > some patches (like custom fields) that haven't gotten much exposure and > that have had people begging for it for years, but I'm prepared to deal > with whatever the migration issues are when the bugzilla core folks > sanctify a custom fields patch of their own. Good enough > >> I haven't been annoyed myself (I found it rather intriguing even >> though I wouldn't use it). > > > Given that the target audience for this thread has been utterly silent > on the prime topic of the thread I'm guessing I've annoyed some folks > beyond caring about what I'm saying. > >> Why not open a project on sf.net bugzilla-task-management or something. > > If you want to use svn just try using BerliOS (http://www.berlios.de/). What your looking to do has already been done and it is quite popular. > I've played with running a sourceforge project and it was severely > lacking. For one thing, I want to use svn instead of cvs. But when you > get right down to it a lot of what I'm looking at doing is creating > something that's going to compete with sourceforge. And I fully intend > to eat my own dogfood throughout this process. I have servers. I have > bandwidth. I just want some better tools to deal with an increasingly > workload. Bugzilla runs my life in some senses and I'd like to spend > less time on overhead and more time on doing what people are asking for. > >> I'm sure you could find people interested in this. > > > There are a couple so far. Previous times this topic has come up there > was no interest whatsoever, so two folks is sounding much better than > squeezing out all the time myself. Fair enough. > >> Hell, I'd even volunteer to set this up and help develop something >> like this (even though I probably wouldn't use it). Send me a message >> about who is interested. > > > We're setting up a mailing list next, and then a wiki, and soon after a > dedicated server for folks that want to work on the project. I haven't > asked anyone who's privately emailed me if sharing their names is OK, so > I'm going to leave that to them in their own good time. > >> I'm sure Dave would be willing to even link to the project from >> www.bugzilla.org if it actually becomes usable. > > > I'd love to get it to the point that it would be a relevant question. > >> Hell, it could even be something more general like: bugzilla-addons >> with un-approved addons for bugzilla (addons that don't follow the >> design goals of bugzilla). > > > That's the gist of the idea. Sounds good. Go for it. Best Regards, - Mick (o> Web / software developer ( ) UNIX Systems Admin --- ~ www.mickweiss.com ~ > >> Just my 2 cents. > > > Thanks for responding. > -- From chicks at chicks.net Sun Oct 10 16:45:50 2004 From: chicks at chicks.net (Christopher Hicks) Date: Sun, 10 Oct 2004 12:45:50 -0400 (EDT) Subject: What are bugs? Are bugs really work items? In-Reply-To: <1097186296.5708.4.camel@localhost.localdomain> References: <7EEAE93B09529A40972F5EFC7093ED6307F35D@imc-exchange.IMCentricAD> <416569B4.5060707@gmx.net> <1097186296.5708.4.camel@localhost.localdomain> Message-ID: On Thu, 7 Oct 2004, Max Kanat-Alexander wrote: > Actually, interesting that you chose those two examples -- Firefox > is a reversal of that theory, a moving away from the Mozilla Suite and > separating the browser. But would we have had firefox if people hadn't piled features onto mozilla to the point that it needed to split up? I think Mozilla is one of the better examples of shoving tons of different pieces into the pot, not particularly fearing feature creep, and letting folks take as big (or small) a bowl of soup as you want. > Linux follows the Unix Philosophy most definitely, where all the > different parts of the kernel can be modularized and are written mostly > separately. (Though it is a monolithic kernel, so it does give some > credit to your theory.) When I said Linux I was referring to the kernel. -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare From gerv at mozilla.org Sun Oct 10 22:23:12 2004 From: gerv at mozilla.org (Gervase Markham) Date: Sun, 10 Oct 2004 23:23:12 +0100 Subject: What are bugs? Are bugs really work items? In-Reply-To: References: <7EEAE93B09529A40972F5EFC7093ED6307F35D@imc-exchange.IMCentricAD> <416569B4.5060707@gmx.net> <1097186296.5708.4.camel@localhost.localdomain> Message-ID: <4169B650.5070501@mozilla.org> Christopher Hicks wrote: > But would we have had firefox if people hadn't piled features onto > mozilla to the point that it needed to split up? In this analogy, Bugzilla is Mozilla. I think most of the developers would prefer not to see Bugzilla get into such a bloated state that people wanted to do a slimmer rewrite... Turn it around. If people hadn't piled features into Mozilla in that way, we wouldn't necessarily have needed Firefox. > I think Mozilla is one > of the better examples of shoving tons of different pieces into the pot, > not particularly fearing feature creep, and letting folks take as big > (or small) a bowl of soup as you want. I cannot believe you are using the way Mozilla developed as an example to follow! :-) And the browser in the Mozilla Suite is a single-size bowl of soup anyway. >> Linux follows the Unix Philosophy most definitely, where all the >> different parts of the kernel can be modularized and are written >> mostly separately. (Though it is a monolithic kernel, so it does give >> some credit to your theory.) > > When I said Linux I was referring to the kernel. The fact that it's a monolithic kernel isn't really relevant. The kernel is still very carefully modularised. The fact that the modules are linked into one big binary and communicate via shared memory rather than being a lot of services communicating via message passing is orthogonal to the level of code modularity. Gerv From chicks at chicks.net Mon Oct 11 00:19:38 2004 From: chicks at chicks.net (Christopher Hicks) Date: Sun, 10 Oct 2004 20:19:38 -0400 (EDT) Subject: What are bugs? Are bugs really work items? In-Reply-To: <4169B650.5070501@mozilla.org> References: <7EEAE93B09529A40972F5EFC7093ED6307F35D@imc-exchange.IMCentricAD> <416569B4.5060707@gmx.net> <1097186296.5708.4.camel@localhost.localdomain> <4169B650.5070501@mozilla.org> Message-ID: On Sun, 10 Oct 2004, Gervase Markham wrote: > Christopher Hicks wrote: >> But would we have had firefox if people hadn't piled features onto mozilla >> to the point that it needed to split up? > > In this analogy, Bugzilla is Mozilla. I think most of the developers would > prefer not to see Bugzilla get into such a bloated state that people wanted > to do a slimmer rewrite... I don't view Firefox as just a "slimmer rewrite", but I can understand why you and others do. Firefox, Thunderbird, Calendar, etc. were all part of the "suite" and the suite was always somewhat bloated. Users viewed the various chunks of Communicator as seperate apps, but until recently it wasn't implemented that way. The fact that it took a while for that to become obvious to the developers is totally understandable, but viewing that process as tragic or avoidable is making a value judgement with which I don't concur. The refactoring was going to happen eventually. > Turn it around. If people hadn't piled features into Mozilla in that > way, we wouldn't necessarily have needed Firefox. Firefox was always needed. Occassional refactoring is just a fact of life in good software. >> I think Mozilla is one of the better examples of shoving tons of different >> pieces into the pot, not particularly fearing feature creep, and letting >> folks take as big (or small) a bowl of soup as you want. > > I cannot believe you are using the way Mozilla developed as an example to > follow! I'm not trying to follow the Mozilla example religiously, but I do feel it exemplifies the life cycle of good software. Folks fighting feature creep are only slowing the inevitable growth and refactoring cycle of software. The process doesn't have to be pretty or always right for the result to be what the result needs to be. I'm totally open for taking the methodology experience gained in mozilla development to heart and I think there's at least as many things "done right" as "done wrong". Repeating the successess and avoiding repeating the mistakes seems like a great philosophy until you get to getting people to agree on what's a mistake and what's a success, but I haven't ever heard of any better philosophy. (I read a quote today from quotationspage.com that "the only thing we learn from history is that we don't learn from history." I'm not that cynical yet, but I see his point.) > :-) And the browser in the Mozilla Suite is a single-size bowl of soup > anyway. Precisely. It was always a single bowl of soup. Discouraging folks from "bloating" mozilla would only have delayed this realization >>> Linux follows the Unix Philosophy most definitely, where all the >>> different parts of the kernel can be modularized and are written mostly >>> separately. (Though it is a monolithic kernel, so it does give some >>> credit to your theory.) >> >> When I said Linux I was referring to the kernel. > > The fact that it's a monolithic kernel isn't really relevant. Admittedly. > The kernel is still very carefully modularised. Which bugzilla is doing better at through time. > The fact that the modules are linked into one big binary and communicate > via shared memory rather than being a lot of services communicating via > message passing is orthogonal to the level of code modularity. That's all fine. Linux still exemplifies the "throw it all in and deal with the consequences" philosophy. There have been numerous refactorings through time. If folks started saying Linux is only a kernel for single machines or kernel features were thrown out because people were fearing feature creep it would only slow down the process. I'm sure people can find plenty of examples where folks in the mozilla or lkm communities stomped on something for feature creep reasons, but I don't think that exemplifies the overall attitude in effect. YMMV. :) Also - I'm not saying that totally opening things up and not thinking at all about the direction or value of things is the way to go. But the bugzilla attitude has gone so far in the other direction that it has stifled healthy progress. -- Westheimer's Discovery: "A coupla months in the laboratory can save a coupla hours in the library." From lee at netzentry.com Mon Oct 11 17:25:20 2004 From: lee at netzentry.com (Lee Ivy) Date: Mon, 11 Oct 2004 10:25:20 -0700 Subject: Looking for sample scripts Message-ID: <416AC200.3020004@netzentry.com> Hello, I am a new member of this list. Sorry if this is a dumb question but I did not see it in the FAQ. I am taking over an existing Bugzilla DB and I am looking for a fast way to perform cleanup operations such as: 1. Get a list of all the defects in Resolved/Fixed state 2. For each of these defects, if it has seen no updates in the last X months, change its state to Closed When I worked with ddts I built up a set of similar scripts & it was very handy, once I had a few working it was not hard to customize them for whatever I needed. If anyone can point me to any share-able scripts that do anything similar, and point out any caveats or land-mines to be aware of, I would appreciate it. Lee Ivy QA Architect netZentry, inc. www.netzentry.com lee at netzentry.com From justdave at bugzilla.org Mon Oct 11 17:41:25 2004 From: justdave at bugzilla.org (David Miller) Date: Mon, 11 Oct 2004 13:41:25 -0400 Subject: Looking for sample scripts In-Reply-To: <416AC200.3020004@netzentry.com> References: <416AC200.3020004@netzentry.com> Message-ID: <416AC5C5.5040309@bugzilla.org> Lee Ivy wrote: > Hello, > I am a new member of this list. Sorry if this is a dumb question but I > did not see it in the FAQ. > > I am taking over an existing Bugzilla DB and I am looking for a fast way > to perform cleanup operations such as: > > 1. Get a list of all the defects in Resolved/Fixed state > 2. For each of these defects, if it has seen no updates in the last X > months, change its state to Closed > > When I worked with ddts I built up a set of similar scripts & it was > very handy, once I had a few working it was not hard to customize them > for whatever I needed. > > If anyone can point me to any share-able scripts that do anything > similar, and point out any caveats or land-mines to be aware of, I would > appreciate it. There are some similar goodies on http://www.bugzilla.org/docs/queries.html I don't think it has everything you're looking for, but it's a start. You can do the above from the web UI though. Go to the advanced search page, select the resolutions you want to match, put "1/1/1970" to "4m" in the date range section of the Bug Changes section, and run the search. Once you have the results, click the "change several bugs at once" link at the bottom, then click "Check All", pick the option to close the bugs, and submit. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From gerv at mozilla.org Mon Oct 11 18:28:13 2004 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 11 Oct 2004 19:28:13 +0100 Subject: What are bugs? Are bugs really work items? In-Reply-To: References: <7EEAE93B09529A40972F5EFC7093ED6307F35D@imc-exchange.IMCentricAD> <416569B4.5060707@gmx.net> <1097186296.5708.4.camel@localhost.localdomain> <4169B650.5070501@mozilla.org> Message-ID: <416AD0BD.8030707@mozilla.org> Christopher Hicks wrote: > That's all fine. Linux still exemplifies the "throw it all in and deal > with the consequences" philosophy. Oh, it _so_ doesn't. Did you read the post from that guy who replied to that Sun blogger who complained about Linux not having stuff in Solaris? His main point was that getting stuff past Linus is _hard_. The kernel is one of the most tightly controlled projects out there. http://www.kroah.com/log/2004/09/23/#2004_09_23_sun_rebuttal > Also - I'm not saying that totally opening things up and not thinking at > all about the direction or value of things is the way to go. But the > bugzilla attitude has gone so far in the other direction that it has > stifled healthy progress. I still don't see "healthy progress" as "throw everything in, cook it down, and see what emerges", primarily because anyone using the software during the cooking process will not have a pleasant experience. Progress has been slow of late, but that's an issue to do with time from the devs, not to do with choice of direction. Gerv From kiko at async.com.br Mon Oct 11 21:26:40 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Mon, 11 Oct 2004 18:26:40 -0300 Subject: What are bugs? Are bugs really work items? In-Reply-To: <416AD0BD.8030707@mozilla.org> References: <7EEAE93B09529A40972F5EFC7093ED6307F35D@imc-exchange.IMCentricAD> <416569B4.5060707@gmx.net> <1097186296.5708.4.camel@localhost.localdomain> <4169B650.5070501@mozilla.org> <416AD0BD.8030707@mozilla.org> Message-ID: <20041011212640.GB2899@async.com.br> On Mon, Oct 11, 2004 at 07:28:13PM +0100, Gervase Markham wrote: > I still don't see "healthy progress" as "throw everything in, cook it > down, and see what emerges", primarily because anyone using the software > during the cooking process will not have a pleasant experience. That's what releases are for. I don't think end-users should be using development versions, and the really conservative approach to CVS HEAD tends to hurt us long-run. I get the feeling there are lots of volunteers willing to help Bugzilla, but very few willing to endure the very slow rate of review and feedback they get after submitting their first change. Maybe that's a feature of the process, but maybe it isn't. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 From bugreport at peshkin.net Mon Oct 11 22:03:51 2004 From: bugreport at peshkin.net (Joel Peshkin) Date: Mon, 11 Oct 2004 15:03:51 -0700 Subject: What are bugs? Are bugs really work items? In-Reply-To: <20041011212640.GB2899@async.com.br> References: <7EEAE93B09529A40972F5EFC7093ED6307F35D@imc-exchange.IMCentricAD> <416569B4.5060707@gmx.net> <1097186296.5708.4.camel@localhost.localdomain> <4169B650.5070501@mozilla.org> <416AD0BD.8030707@mozilla.org> <20041011212640.GB2899@async.com.br> Message-ID: <416B0347.4090609@peshkin.net> Christian Robottom Reis wrote: >That's what releases are for. I don't think end-users should be using >development versions, and the really conservative approach to CVS HEAD >tends to hurt us long-run. > >I get the feeling there are lots of volunteers willing to help Bugzilla, >but very few willing to endure the very slow rate of review and feedback >they get after submitting their first change. Maybe that's a feature of >the process, but maybe it isn't. > > It took a lot of work to stabilize 2.18 after the huge pile of stuff that went in on HEAD between 2.16 and 2.18. There were a lot of changes that went in on HEAD that had to be fixed by a very small cadre of people (yes - I know you were one of them). I think that our position towards feature bloat caused by people who stick around to maintain the feature should be very different from our position towards features from people who just want to contribute a feature to HEAD and walk away. For now, we should encourage the work-item folks to work with us to make maintainable interfaces where their customizations can interface. Then, if we find that the actual customizations reach a criticial mass of users and maintainers, they can land. -Joel From chicks at chicks.net Tue Oct 12 02:28:51 2004 From: chicks at chicks.net (Christopher Hicks) Date: Mon, 11 Oct 2004 22:28:51 -0400 (EDT) Subject: What are bugs? Are bugs really work items? In-Reply-To: <416B0347.4090609@peshkin.net> References: <7EEAE93B09529A40972F5EFC7093ED6307F35D@imc-exchange.IMCentricAD> <416569B4.5060707@gmx.net> <1097186296.5708.4.camel@localhost.localdomain> <4169B650.5070501@mozilla.org> <416AD0BD.8030707@mozilla.org> <20041011212640.GB2899@async.com.br> <416B0347.4090609@peshkin.net> Message-ID: On Mon, 11 Oct 2004, Joel Peshkin wrote: > I think that our position towards feature bloat caused by people who stick > around to maintain the feature should be very different from our position > towards features from people who just want to contribute a feature to HEAD > and walk away. I've been here for years and I can't even get a PK on one table. I suppose when I'm an 80 year old rotting corpse begging for following simple concepts of relational database design I'll have met your criteria? Bug 225221 was going to be my "get familiar with the process" warmup since Dave said going for task management would be OK with him: > Let me know when the new bug is up with > the summary of the old one in place on it and I'll take care of duping > the original (so it has a mark of authority on it :) ( http://bugzilla.org/cgi-bin/mj_wwwusr?user=&passw=&list=developers&brief=on&func=archive-get-part&extra=200307/80 ) Back to Joel: > For now, we should encourage the work-item folks to work with us to make > maintainable interfaces where their customizations can interface. Agreed. > Then, if we find that the actual customizations reach a criticial mass > of users and maintainers, they can land. It's a long shot, but I'll give it a good try. -- Westheimer's Discovery: "A coupla months in the laboratory can save a coupla hours in the library." From gerv at mozilla.org Tue Oct 12 17:56:23 2004 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 12 Oct 2004 18:56:23 +0100 Subject: What are bugs? Are bugs really work items? In-Reply-To: <20041011212640.GB2899@async.com.br> References: <7EEAE93B09529A40972F5EFC7093ED6307F35D@imc-exchange.IMCentricAD> <416569B4.5060707@gmx.net> <1097186296.5708.4.camel@localhost.localdomain> <4169B650.5070501@mozilla.org> <416AD0BD.8030707@mozilla.org> <20041011212640.GB2899@async.com.br> Message-ID: <416C1AC7.5080303@mozilla.org> Christian Robottom Reis wrote: > On Mon, Oct 11, 2004 at 07:28:13PM +0100, Gervase Markham wrote: > >>I still don't see "healthy progress" as "throw everything in, cook it >>down, and see what emerges", primarily because anyone using the software >>during the cooking process will not have a pleasant experience. > > That's what releases are for. I don't think end-users should be using > development versions, and the really conservative approach to CVS HEAD > tends to hurt us long-run. I think we're talking at slightly cross purposes. I agree that, in an idal world, we'd release more often. We all know the reason 2.18 took so long is because we took too long to freeze and so had too much change - a vicious cycle. But that's not the same thing as saying that we should take every feature someone comes up with a patch for, see which ones users like, and remove the rest (which is chicks' cooking proposal, as I understand it. > I get the feeling there are lots of volunteers willing to help Bugzilla, > but very few willing to endure the very slow rate of review and feedback > they get after submitting their first change. Maybe that's a feature of > the process, but maybe it isn't. Magic clocks which give everyone more time would be fab, I agree :-) I'd like to put much more time into Bugzilla, but I'm stuck doing mozilla.org stuff at the moment. Gerv From chicks at chicks.net Tue Oct 12 21:15:04 2004 From: chicks at chicks.net (Christopher Hicks) Date: Tue, 12 Oct 2004 17:15:04 -0400 (EDT) Subject: how do i find bugs where QA Contact is not set? In-Reply-To: <20041012195917.GJ6095@cryptio.net> References: <20041012195917.GJ6095@cryptio.net> Message-ID: On Tue, 12 Oct 2004, Tyler wrote on webtools: > Boolean queries for "contains ---", "contains [nothing -- that is, > nothing typed in the text box]", "doesn't match regex [a-z]", etc. don't > find these bugs. Ideas? I tried this and couldn't find a solution, but even more interesting: I tried the same "doesn't match regexp" string of "chicks" for bug owner and qa contact and it worked with bug owner, but qa contact. I looked through the open and resolved bugzilla bugs and didn't see anything that seemed to address this. Is it a known issue? I'd like to give this guy some answer -- even if it points to a new bug yet to be created. -- Westheimer's Discovery: "A coupla months in the laboratory can save a coupla hours in the library." From chicks at chicks.net Tue Oct 12 21:35:06 2004 From: chicks at chicks.net (Christopher Hicks) Date: Tue, 12 Oct 2004 17:35:06 -0400 (EDT) Subject: how do i find bugs where QA Contact is not set? In-Reply-To: References: <20041012195917.GJ6095@cryptio.net> Message-ID: On Tue, 12 Oct 2004, Christopher Hicks wrote: > Is it a known issue? Joel answered this directly already. -- Westheimer's Discovery: "A coupla months in the laboratory can save a coupla hours in the library." From chicks at chicks.net Tue Oct 12 22:14:34 2004 From: chicks at chicks.net (Christopher Hicks) Date: Tue, 12 Oct 2004 18:14:34 -0400 (EDT) Subject: What are bugs? Are bugs really work items? In-Reply-To: <416C1AC7.5080303@mozilla.org> References: <7EEAE93B09529A40972F5EFC7093ED6307F35D@imc-exchange.IMCentricAD> <416569B4.5060707@gmx.net> <1097186296.5708.4.camel@localhost.localdomain> <4169B650.5070501@mozilla.org> <416AD0BD.8030707@mozilla.org> <20041011212640.GB2899@async.com.br> <416C1AC7.5080303@mozilla.org> Message-ID: On Tue, 12 Oct 2004, Gervase Markham wrote: >> I get the feeling there are lots of volunteers willing to help Bugzilla, >> but very few willing to endure the very slow rate of review and feedback >> they get after submitting their first change. Maybe that's a feature of >> the process, but maybe it isn't. > > Magic clocks which give everyone more time would be fab, I agree :-) I'd like > to put much more time into Bugzilla, but I'm stuck doing mozilla.org stuff at > the moment. The magic clock is that if new contributors are treated better you'll have more time. -- Westheimer's Discovery: "A coupla months in the laboratory can save a coupla hours in the library." From justdave at bugzilla.org Tue Oct 12 23:03:37 2004 From: justdave at bugzilla.org (David Miller) Date: Tue, 12 Oct 2004 19:03:37 -0400 Subject: how do i find bugs where QA Contact is not set? In-Reply-To: References: <20041012195917.GJ6095@cryptio.net> Message-ID: <416C62C9.10507@bugzilla.org> Christopher Hicks wrote: > On Tue, 12 Oct 2004, Tyler wrote on webtools: > >> Boolean queries for "contains ---", "contains [nothing -- that is, >> nothing typed in the text box]", "doesn't match regex [a-z]", etc. >> don't find these bugs. Ideas? > > I tried this and couldn't find a solution, but even more interesting: I > tried the same "doesn't match regexp" string of "chicks" for bug owner > and qa contact and it worked with bug owner, but qa contact. I looked > through the open and resolved bugzilla bugs and didn't see anything that > seemed to address this. Is it a known issue? I'd like to give this guy > some answer -- even if it points to a new bug yet to be created. Needs Bugzilla 2.19.1 or later to be able to do that from the UI (or a recent version from CVS, since 2.19.1 isn't out yet). The problem is that the QA Contact field is null when it's empty, and there's no provision in the UI to match a null (which is a distinct entity from an empty string). 2.19cvs adds a "not" operator (as a checkbox) in front of each row of the boolean chart. You can then search for NOT ('QA Contact' 'matches regexp' '.') and successfully match it. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From tyler at cryptio.net Tue Oct 12 23:15:43 2004 From: tyler at cryptio.net (Tyler) Date: Tue, 12 Oct 2004 16:15:43 -0700 Subject: how do i find bugs where QA Contact is not set? In-Reply-To: <416C62C9.10507@bugzilla.org> References: <20041012195917.GJ6095@cryptio.net> <416C62C9.10507@bugzilla.org> Message-ID: <20041012231543.GN6095@cryptio.net> On Tue, Oct 12, 2004 at 07:03:37PM -0400, David Miller wrote: > Christopher Hicks wrote: > >On Tue, 12 Oct 2004, Tyler wrote on webtools: > > > >>Boolean queries for "contains ---", "contains [nothing -- that is, > >>nothing typed in the text box]", "doesn't match regex [a-z]", etc. > >>don't find these bugs. Ideas? > > > >I tried this and couldn't find a solution, but even more interesting: I > >tried the same "doesn't match regexp" string of "chicks" for bug owner > >and qa contact and it worked with bug owner, but qa contact. I looked > >through the open and resolved bugzilla bugs and didn't see anything that > >seemed to address this. Is it a known issue? I'd like to give this guy > >some answer -- even if it points to a new bug yet to be created. I was terribly confused as to why i'd been demoted to third-person status until i noticed that this bounced over to developers@ (i proc all my bugzilla mail to a single folder). > Needs Bugzilla 2.19.1 or later to be able to do that from the UI (or a > recent version from CVS, since 2.19.1 isn't out yet). Joel pointed me to https://bugzilla.mozilla.org/show_bug.cgi?id=204903. I'm waiting on an alluded-to-but-not-in-the-bug final patch for this. > The problem is that the QA Contact field is null when it's empty, and > there's no provision in the UI to match a null (which is a distinct > entity from an empty string). > > 2.19cvs adds a "not" operator (as a checkbox) in front of each row of > the boolean chart. You can then search for > > NOT ('QA Contact' 'matches regexp' '.') > > and successfully match it. How would the NOT operator be different from "doesn't match regexp"? Also, everything =~ /./ (except, evidently, the null that QA Contact has by default), so why would !~ /./ be helpful? tyler From justdave at bugzilla.org Tue Oct 12 23:19:34 2004 From: justdave at bugzilla.org (David Miller) Date: Tue, 12 Oct 2004 19:19:34 -0400 Subject: how do i find bugs where QA Contact is not set? In-Reply-To: <416C62C9.10507@bugzilla.org> References: <20041012195917.GJ6095@cryptio.net> <416C62C9.10507@bugzilla.org> Message-ID: <416C6686.2050304@bugzilla.org> David Miller wrote: > 2.19cvs adds a "not" operator (as a checkbox) in front of each row of > the boolean chart. You can then search for And actually, the patch Joel pointed out already on mozilla-webtools makes "doesn't match regexp" work to match nulls :) -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From gerv at mozilla.org Wed Oct 13 09:01:15 2004 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 13 Oct 2004 10:01:15 +0100 Subject: What are bugs? Are bugs really work items? In-Reply-To: References: <7EEAE93B09529A40972F5EFC7093ED6307F35D@imc-exchange.IMCentricAD> <416569B4.5060707@gmx.net> <1097186296.5708.4.camel@localhost.localdomain> <4169B650.5070501@mozilla.org> <416AD0BD.8030707@mozilla.org> <20041011212640.GB2899@async.com.br> <416C1AC7.5080303@mozilla.org> Message-ID: <416CEEDB.50609@mozilla.org> Christopher Hicks wrote: > The magic clock is that if new contributors are treated better you'll > have more time. Maybe I'm missing something here (and JP will probably jump in to reassure me that I am) but I don't see how new contributors are being treated badly. No-one's being rude to them, or telling them their contributions are worthless. Contributions may not have been looked at very quickly, but that's the time problem - fixing that requires having more time, it doesn't generate more time. There have been disagreements on the right thing to do, sure - but that's what happens with more than one person working on a project. I'm sure you're not advocating that we agree with everything new contributors say in order to make them feel accepted. Gerv From justdave at bugzilla.org Wed Oct 13 09:20:23 2004 From: justdave at bugzilla.org (David Miller) Date: Wed, 13 Oct 2004 05:20:23 -0400 Subject: What are bugs? Are bugs really work items? In-Reply-To: References: <827BF123F7B64D48A7F305D6688840750B872F@ex2k.bitheadsinc.local> <41640CFF.30001@znyx.com> <41681C82.3080901@mozilla.org> <41685E88.5090008@peshkin.net> <416865D0.20909@mozilla.org> Message-ID: <416CF357.4030708@bugzilla.org> Christopher Hicks wrote: > On Sat, 9 Oct 2004, Gervase Markham wrote: > >> but I don't think anyone's annoyed. > > When I only hear crickets I get worried. Can't vouch for anyone else, but I just started reading this thread tonight. The subject line didn't quite expose that the content of the thread was urgent, and I was putting it off until I had more time to sit down and read for a while because of the number of posts in the thread already. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From paulo.casanova at link.pt Wed Oct 13 09:40:34 2004 From: paulo.casanova at link.pt (Paulo Casanova) Date: Wed, 13 Oct 2004 10:40:34 +0100 Subject: Some contributions Message-ID: Hi all, In my company we're using bugzilla and we need some extra features some of which are bugs already reported in bugzilla.mozilla.org. We have some effort to spend on fixing some things so I would like to discuss whether it makes sense commiting those changes to the main BZ dev trunk. 1. One simple feature we have already implemented (and I think it made some sense commiting) is disable account creation. BZ now allows disabling anonymous users so disabling account creation is a logical step IMHO. Does it make sense? Should I post a bug with it and attach a patch? 2. Custom fields (bug #91047). Although some people disagree with the need of custom fields, in IT we must do what we're paid for (I won't argue about this). We're ready to start working on this one but I would like some guidance. I am thinking following the plan in comment #239: (1) The basic functionality of custom fields is: enter_bug.cgi: The ability to enter data into a custom text field show_bug.cgi: The ability to see the data from entered custom text fields. (2) An shell-based admin tool to manage custom fields. (3) In order for this to become useful for most users: query.cgi: The ability to search custom fields (4) Ability to track custom fields in the bug activity. (5) Custom fields of different types, such as Select or Radio. (6) Control of Custom fields through templates. (7) Ability to do mass-changes of custom fields. So, as a first step I would work on step 1 & 2. Any feedback is appreciated. Thanks, Paulo From chicks at chicks.net Wed Oct 13 13:08:34 2004 From: chicks at chicks.net (Christopher Hicks) Date: Wed, 13 Oct 2004 09:08:34 -0400 (EDT) Subject: What are bugs? Are bugs really work items? In-Reply-To: <416CF357.4030708@bugzilla.org> References: <827BF123F7B64D48A7F305D6688840750B872F@ex2k.bitheadsinc.local> <41640CFF.30001@znyx.com> <41681C82.3080901@mozilla.org> <41685E88.5090008@peshkin.net> <416865D0.20909@mozilla.org> <416CF357.4030708@bugzilla.org> Message-ID: On Wed, 13 Oct 2004, David Miller wrote: > Christopher Hicks wrote: >> On Sat, 9 Oct 2004, Gervase Markham wrote: >>> but I don't think anyone's annoyed. >> When I only hear crickets I get worried. > > Can't vouch for anyone else, but I just started reading this thread > tonight. The subject line didn't quite expose that the content of the > thread was urgent, and I was putting it off until I had more time to sit > down and read for a while because of the number of posts in the thread > already. I can certainly understand that silence may mean a variety of things. Thanks for letting me know it wasn't for the reasons I feared at least in your case. -- Westheimer's Discovery: "A coupla months in the laboratory can save a coupla hours in the library." From chicks at chicks.net Wed Oct 13 13:31:34 2004 From: chicks at chicks.net (Christopher Hicks) Date: Wed, 13 Oct 2004 09:31:34 -0400 (EDT) Subject: Some contributions In-Reply-To: References: Message-ID: On Wed, 13 Oct 2004, Paulo Casanova wrote: > 1. One simple feature we have already implemented (and I think it made some > sense commiting) is disable account creation. BZ now allows disabling > anonymous users so disabling account creation is a logical step IMHO. Does it > make sense? Should I post a bug with it and attach a patch? You get my vote. By using usebuggroups and usebuggroupsentry I've gotten past my fear of random folks creating accounts and being able to see bugs. ( Incidentally, this reminds me of an "atypical" bugzilla usage that some of you might find amusing. My whole family uses bugzilla. My wife uses it for business and family stuff (as do I). So, for instance there's a bug for "paint the bathroom". But we've gotten our son to start using it to report his desktop Windows problems through bugzilla and we're assigning him various nontrivial tasks and he's using it to track his progress. ) So you can see why I want to avoid random folks even having an account. :) -- Westheimer's Discovery: "A coupla months in the laboratory can save a coupla hours in the library." From bugreport at peshkin.net Wed Oct 13 14:00:53 2004 From: bugreport at peshkin.net (Joel Peshkin) Date: Wed, 13 Oct 2004 07:00:53 -0700 Subject: Some contributions In-Reply-To: References: Message-ID: <416D3515.2000808@peshkin.net> Paulo Casanova wrote: > > Hi all, > > In my company we're using bugzilla and we need some extra features > some of which are bugs already reported in bugzilla.mozilla.org. We > have some effort to spend on fixing some things so I would like to > discuss whether it makes sense commiting those changes to the main BZ > dev trunk. > > 1. One simple feature we have already implemented (and I think it made > some sense commiting) is disable account creation. BZ now allows > disabling anonymous users so disabling account creation is a logical > step IMHO. Does it make sense? Should I post a bug with it and attach > a patch? > If you use a blank createemailregexp, then nobody (except an administrator) can create an account. Does that do what you need? > 2. Custom fields (bug #91047). Although some people disagree with the > need of custom fields, in IT we must do what we're paid for (I won't > argue about this). We're ready to start working on this one but I > would like some guidance. > s/91047/91037/ > I am thinking following the plan in comment #239: > > > So, as a first step I would work on step 1 & 2. Any feedback is > appreciated. Thanks, > > Paulo > I think that both a valuable thing and a reasonable plan. Actually getting Bugzilla contributions landed (merged) tends to be very difficult for new contributors and this feature is both very complex and has a history of being controversial so it is likely to take 3x-4x as much effort to get it landed as it would to make a patch for your own use against a specific version. I suggest you work out a plan that permits sections of this to land even prior to exposing the feature to most sites and work with justdave to make sure that the plan has whatever type of pre-approval is appropriate so that you know from the outset that you are on the right track. You can usually find several of the right people (and a number of the wrong people) on irc://irc.mozilla.org/mozwebtools With the plan in bug 91037, comment 239.... I would describe it as follows.... 1) Get consensus on the way this interacts with the Bugzilla schema, Search, and Fielddefs. When you do get to looking at fielddefs, I suspect you will find that you will want to propose some enhancements to Fielddefs first. It would be a big help if fielddefs knew about more characteristics of a field than it currently does. It is probably the most effective way for all of the rest of the code to become aware of any new fields and how they should be handled. 2) Implement the fielddefs changes. [probably land this change with no new feature] 3) Implement the code that handles administration of new fields. 4) Implement the code that works with the new fields in Bug.pm, Search.pm, and any cgis where the list of fields is currently hardcoded. At this point, once someone who is willing to do their own template changes can use customfields, then land this. 5) Then, get fancy with templates that don't require hacking (but still permit it) -Joel From kiko at async.com.br Wed Oct 13 14:09:20 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Wed, 13 Oct 2004 11:09:20 -0300 Subject: Some contributions In-Reply-To: <416D3515.2000808@peshkin.net> References: <416D3515.2000808@peshkin.net> Message-ID: <20041013140920.GA521@async.com.br> On Wed, Oct 13, 2004 at 07:00:53AM -0700, Joel Peshkin wrote: > 1) Get consensus on the way this interacts with the Bugzilla schema, > Search, and Fielddefs. When you do get to looking at fielddefs, I > suspect you will find that you will want to propose some enhancements to > Fielddefs first. It would be a big help if fielddefs knew about more > characteristics of a field than it currently does. It is probably the > most effective way for all of the rest of the code to become aware of > any new fields and how they should be handled. > > 2) Implement the fielddefs changes. [probably land this change with no > new feature] Yes! Having an enhanced fielddefs (having *methods* per fielddefs, even) would make cleaning up the code in parts a *lot* easier. I'd say it's an excellent first step. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 From kiko at async.com.br Wed Oct 13 14:16:37 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Wed, 13 Oct 2004 11:16:37 -0300 Subject: What are bugs? Are bugs really work items? In-Reply-To: <416CEEDB.50609@mozilla.org> References: <1097186296.5708.4.camel@localhost.localdomain> <4169B650.5070501@mozilla.org> <416AD0BD.8030707@mozilla.org> <20041011212640.GB2899@async.com.br> <416C1AC7.5080303@mozilla.org> <416CEEDB.50609@mozilla.org> Message-ID: <20041013141637.GC521@async.com.br> On Wed, Oct 13, 2004 at 10:01:15AM +0100, Gervase Markham wrote: > Christopher Hicks wrote: > >The magic clock is that if new contributors are treated better you'll > >have more time. > > Maybe I'm missing something here (and JP will probably jump in to > reassure me that I am) but I don't see how new contributors are being > treated badly. No-one's being rude to them, or telling them their > contributions are worthless. Contributions may not have been looked at > very quickly, but that's the time problem - fixing that requires having > more time, it doesn't generate more time. I agree up-front that maintainers are not usually objetively rude. I'd say it's more that contributing to Bugzilla isn't *exciting*. When people hook up with an OSS project, they like to feel like they make a difference; with us I fear people just don't feel valued enough. It may just have to do with maintainers not having time to review and nudge them ahead, but I think there's also a lack of a "warm fuzzy feeling" towards contributors. I'd like to see more "Wow, this feature is awesome!" or "It's great to have you on board" but most of the time I see us replying back with sterile r-minuses and complicated cross-examining. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 From jpyeron at pdinc.us Wed Oct 13 16:18:15 2004 From: jpyeron at pdinc.us (Jason Pyeron) Date: Wed, 13 Oct 2004 12:18:15 -0400 (EDT) Subject: What are bugs? Are bugs really work items? In-Reply-To: <20041013141637.GC521@async.com.br> Message-ID: On Wed, 13 Oct 2004, Christian Robottom Reis wrote: > I'd say it's more that contributing to Bugzilla isn't *exciting*. When > people hook up with an OSS project, they like to feel like they make a > difference; with us I fear people just don't feel valued enough. It may > just have to do with maintainers not having time to review and nudge > them ahead, but I think there's also a lack of a "warm fuzzy feeling" > towards contributors. I'd like to see more "Wow, this feature is > awesome!" or "It's great to have you on board" but most of the time I > see us replying back with sterile r-minuses and complicated > cross-examining. I think we fight to many battles for the sake of perfection (this causes bit rot). Or even more trivial are the situations where a patch is given as step 1 of 2, and step 1 is never committed since step 2 was not done too. If there cannot be an agreement or an absolute "RIGHT" decided for step 2 then don't r- if step one is good on its own merit. Sometimes changing a 'function name' or other detail for 'cosmetics' is just not worth it. just my 2 cents, sorry if it is a rant, I'm just over worked. https://bugzilla.mozilla.org/show_bug.cgi?id=261289#c14 Dave Miller 2004-10-08 23:42 PDT wrote: > I like this, it helps move things away from depending on CGI, so it can > be done more easily from some other UI (and even makes it much easier > for an Auth method to create users on the fly if they authenticate from > an external source, in fact) > > However, I'm a little bit concerned about the naming of the function and > the related constants. For some reason it just sticks out as too wordy, > and I'm wondering if we can come up with a simpler name to use. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Partner & Sr. Manager #1 2739 Saint Paul Street - - +1 (410) 808-6646 (c) Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, purge the message from your system and notify the sender immediately. Any other use of the email by you is prohibited. From gerv at mozilla.org Tue Oct 12 17:40:27 2004 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 12 Oct 2004 18:40:27 +0100 Subject: What are bugs? Are bugs really work items? In-Reply-To: References: <7EEAE93B09529A40972F5EFC7093ED6307F35D@imc-exchange.IMCentricAD> <416569B4.5060707@gmx.net> <1097186296.5708.4.camel@localhost.localdomain> <4169B650.5070501@mozilla.org> <416AD0BD.8030707@mozilla.org> <20041011212640.GB2899@async.com.br> <416B0347.4090609@peshkin.net> Message-ID: <416C170B.6080204@mozilla.org> Christopher Hicks wrote: > Bug 225221 was going to be my "get familiar with the process" warmup > since Dave said going for task management would be OK with him: Rereading the thread, the bug in question was "Separate enhancements from severity field / Bug classification field", which is hardly "going for task management". Unless I've misunderstood what you are after when you say you want task management. (Again, all this is subject to Dave diving in and saying "Actually, task management is where we are going. Ride on, cowboy!") Gerv From micklweiss at gmx.net Wed Oct 13 20:54:55 2004 From: micklweiss at gmx.net (Mick Weiss) Date: Wed, 13 Oct 2004 16:54:55 -0400 Subject: What are bugs? Are bugs really work items? In-Reply-To: References: <827BF123F7B64D48A7F305D6688840750B872F@ex2k.bitheadsinc.local> <41640CFF.30001@znyx.com> <41681C82.3080901@mozilla.org> <41685E88.5090008@peshkin.net> <416865D0.20909@mozilla.org> <416CF357.4030708@bugzilla.org> Message-ID: <416D961F.8010601@gmx.net> Christopher Hicks wrote: > On Wed, 13 Oct 2004, David Miller wrote: > >> Christopher Hicks wrote: >> >>> On Sat, 9 Oct 2004, Gervase Markham wrote: >>> >>>> but I don't think anyone's annoyed. >>> >>> When I only hear crickets I get worried. >> >> >> Can't vouch for anyone else, but I just started reading this thread >> tonight. The subject line didn't quite expose that the content of the >> thread was urgent, and I was putting it off until I had more time to >> sit down and read for a while because of the number of posts in the >> thread already. > > > I can certainly understand that silence may mean a variety of things. > Thanks for letting me know it wasn't for the reasons I feared at least > in your case. > When will this thread die? - Mick (o> Web / software developer ( ) UNIX Systems Admin --- ~ www.mickweiss.com ~ From bugreport at peshkin.net Tue Oct 12 03:58:47 2004 From: bugreport at peshkin.net (Joel Peshkin) Date: Mon, 11 Oct 2004 20:58:47 -0700 Subject: What are bugs? Are bugs really work items? In-Reply-To: References: <7EEAE93B09529A40972F5EFC7093ED6307F35D@imc-exchange.IMCentricAD> <416569B4.5060707@gmx.net> <1097186296.5708.4.camel@localhost.localdomain> <4169B650.5070501@mozilla.org> <416AD0BD.8030707@mozilla.org> <20041011212640.GB2899@async.com.br> <416B0347.4090609@peshkin.net> Message-ID: <416B5677.2050207@peshkin.net> Christopher Hicks wrote: > On Mon, 11 Oct 2004, Joel Peshkin wrote: > >> I think that our position towards feature bloat caused by people who >> stick around to maintain the feature should be very different from >> our position towards features from people who just want to contribute >> a feature to HEAD and walk away. > > > I've been here for years and I can't even get a PK on one table. I > suppose when I'm an 80 year old rotting corpse begging for following > simple concepts of relational database design I'll have met your > criteria? > > Bug 225221 was going to be my "get familiar with the process" warmup > since Dave said going for task management would be OK with him: > Don't gripe me about that bug. I commented on that very bug pointing out that the PK is needed. Also, nobody is obstructing that bug, but nobody seems to have taken on the task of making the conversion code work properly. For existing databases, it is probably necessary to first assign integers to the new field in the correct order, then identify the new field as a primary key. From german at spritesoftware.com Thu Oct 14 00:21:26 2004 From: german at spritesoftware.com (German) Date: Thu, 14 Oct 2004 13:21:26 +1300 Subject: What are bugs? Are bugs really work items? In-Reply-To: Message-ID: <000701c4b183$be9ae1b0$1300a8c0@CARLITOS> Does anybody knows an easy way to change bug statuses? If you want to change the statuses now you have to change the code and many different places, any ideas on how to simplify this task? Greeting from New Zealand German Moreno Sprite Software -----Original Message----- From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] On Behalf Of Christopher Hicks Sent: Thursday, 14 October 2004 2:09 AM To: developers at bugzilla.org Subject: Re: What are bugs? Are bugs really work items? On Wed, 13 Oct 2004, David Miller wrote: > Christopher Hicks wrote: >> On Sat, 9 Oct 2004, Gervase Markham wrote: >>> but I don't think anyone's annoyed. >> When I only hear crickets I get worried. > > Can't vouch for anyone else, but I just started reading this thread > tonight. The subject line didn't quite expose that the content of the > thread was urgent, and I was putting it off until I had more time to sit > down and read for a while because of the number of posts in the thread > already. I can certainly understand that silence may mean a variety of things. Thanks for letting me know it wasn't for the reasons I feared at least in your case. -- Westheimer's Discovery: "A coupla months in the laboratory can save a coupla hours in the library." - To view or change your list settings, click here: From justdave at bugzilla.org Wed Oct 13 23:30:10 2004 From: justdave at bugzilla.org (David Miller) Date: Wed, 13 Oct 2004 19:30:10 -0400 Subject: What are bugs? Are bugs really work items? In-Reply-To: <416C170B.6080204@mozilla.org> References: <7EEAE93B09529A40972F5EFC7093ED6307F35D@imc-exchange.IMCentricAD> <416569B4.5060707@gmx.net> <1097186296.5708.4.camel@localhost.localdomain> <4169B650.5070501@mozilla.org> <416AD0BD.8030707@mozilla.org> <20041011212640.GB2899@async.com.br> <416B0347.4090609@peshkin.net> <416C170B.6080204@mozilla.org> Message-ID: <416DBA82.90403@bugzilla.org> Gervase Markham wrote: > Rereading the thread, the bug in question was "Separate enhancements > from severity field / Bug classification field", which is hardly "going > for task management". Unless I've misunderstood what you are after when > you say you want task management. > > (Again, all this is subject to Dave diving in and saying "Actually, task > management is where we are going. Ride on, cowboy!") Bugzilla already has a lot of task management features, but the ones it's got are meant to provide minimum functionality for people who don't need the big guns on it. I'm fairly hesitant to add any more to it directly... that said, we have a lot of good infrastructure in place now to be able to have 3rd party plugins/add-on packs that do such things, and I would absolutely not hesitate in the least to expand the APIs as needed to make something like that work as a plugin. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From kiko at async.com.br Thu Oct 14 01:27:03 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Wed, 13 Oct 2004 22:27:03 -0300 Subject: What are bugs? Are bugs really work items? In-Reply-To: <416DBA82.90403@bugzilla.org> References: <1097186296.5708.4.camel@localhost.localdomain> <4169B650.5070501@mozilla.org> <416AD0BD.8030707@mozilla.org> <20041011212640.GB2899@async.com.br> <416B0347.4090609@peshkin.net> <416C170B.6080204@mozilla.org> <416DBA82.90403@bugzilla.org> Message-ID: <20041014012703.GK846@async.com.br> On Wed, Oct 13, 2004 at 07:30:10PM -0400, David Miller wrote: > Gervase Markham wrote: > > >Rereading the thread, the bug in question was "Separate enhancements > >from severity field / Bug classification field", which is hardly "going > >for task management". Unless I've misunderstood what you are after when > >you say you want task management. > > > >(Again, all this is subject to Dave diving in and saying "Actually, task > >management is where we are going. Ride on, cowboy!") > > Bugzilla already has a lot of task management features, but the ones > it's got are meant to provide minimum functionality for people who don't > need the big guns on it. I guess the right attitude is, instead of using big labels to describe this big fuzzy thing called task management, using good judgement to determine whether individual changes make sense for Bugzilla or not. [For one, I find timetracking to be a major selling point for Bugzilla when presenting it as a solution to a customer -- and that's not strictly `bug tracking', though who cares about labels when the intent is to make kick-ass software.] Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 From gerv at mozilla.org Thu Oct 14 08:45:42 2004 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 14 Oct 2004 09:45:42 +0100 Subject: What are bugs? Are bugs really work items? In-Reply-To: References: Message-ID: <416E3CB6.9090004@mozilla.org> Jason Pyeron wrote: > I think we fight to many battles for the sake of perfection (this causes > bit rot). Or even more trivial are the situations where a patch is given > as step 1 of 2, and step 1 is never committed since step 2 was not done > too. If there cannot be an agreement or an absolute "RIGHT" decided for > step 2 then don't r- if step one is good on its own merit. If step 1 is good on its own merit, then don't present it as "step 1 of 2" :-) > Sometimes changing a 'function name' or other detail for 'cosmetics' is > just not worth it. I'd disagree. Coding standards are important for current and new developers to know what's going on. Changing a function name is usually so easily that it's hardly ever not worth it. Gerv From chicks at chicks.net Thu Oct 14 14:30:39 2004 From: chicks at chicks.net (Christopher Hicks) Date: Thu, 14 Oct 2004 10:30:39 -0400 (EDT) Subject: Bug 225221 - a primary key for longdescs In-Reply-To: <416B5677.2050207@peshkin.net> References: <7EEAE93B09529A40972F5EFC7093ED6307F35D@imc-exchange.IMCentricAD> <416569B4.5060707@gmx.net> <1097186296.5708.4.camel@localhost.localdomain> <4169B650.5070501@mozilla.org> <416AD0BD.8030707@mozilla.org> <20041011212640.GB2899@async.com.br> <416B0347.4090609@peshkin.net> <416B5677.2050207@peshkin.net> Message-ID: On Mon, 11 Oct 2004, Joel Peshkin wrote: > Don't gripe me about that bug. Why? > I commented on that very bug pointing out that the PK is needed. That's nice, but it hardly makes a good reason for not griping. Particularly considering: > Also, nobody is obstructing that bug, but nobody seems to have taken on > the task of making the conversion code work properly. For existing > databases, it is probably necessary to first assign integers to the new > field in the correct order, then identify the new field as a primary > key. That won't work! How can you assign integers to something you can't uniquely refer to? The simplest and most painless way to get past the chicken and egg problem is by having MySQL do it (as my patches have done) you end up with a primary key already filled out for you. It seems so simple yet its taken so long and folks still don't get it. So I gripe. -- "Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing." -- Dick Brandon From msew at pobox.com Thu Oct 14 18:31:04 2004 From: msew at pobox.com (msew at pobox.com) Date: Thu, 14 Oct 2004 11:31:04 -0700 Subject: which version for a new non uber critical production installation Message-ID: <6.1.2.0.2.20041014110857.0b24f740@mail.ev1.net> From the mailing list and the 2.18 blocking statue page, it seems that 2.18 rc3 and 2.19.1 and 2.16 release are all ?imminent? :-) So for someone who is doing their first installation and first usage of bugzilla which should I use? I have been eagerly awaiting 2.18rc3 as it seemed to be the version of choice. But from some posts on the mailing list it seems that 2.19.1 is going to have a bunch of changes to make bugzilla more extensible. Any idea when 2.18rc3 and 2.19.1 are going to be released? And which one should I go for? thanks! From msew at ev1.net Thu Oct 14 18:08:42 2004 From: msew at ev1.net (msew at ev1.net) Date: Thu, 14 Oct 2004 11:08:42 -0700 Subject: What are bugs? Are bugs really work items? In-Reply-To: <416DBA82.90403@bugzilla.org> References: <7EEAE93B09529A40972F5EFC7093ED6307F35D@imc-exchange.IMCentricAD> <416569B4.5060707@gmx.net> <1097186296.5708.4.camel@localhost.localdomain> <4169B650.5070501@mozilla.org> <416AD0BD.8030707@mozilla.org> <20041011212640.GB2899@async.com.br> <416B0347.4090609@peshkin.net> <416C170B.6080204@mozilla.org> <416DBA82.90403@bugzilla.org> Message-ID: <6.1.2.0.2.20041014110833.2d1fce50@mail.ev1.net> At 16:30 2004-10-13, David Miller wrote: >Gervase Markham wrote: > >>Rereading the thread, the bug in question was "Separate enhancements from >>severity field / Bug classification field", which is hardly "going for >>task management". Unless I've misunderstood what you are after when you >>say you want task management. >>(Again, all this is subject to Dave diving in and saying "Actually, task >>management is where we are going. Ride on, cowboy!") > >Bugzilla already has a lot of task management features, but the ones it's >got are meant to provide minimum functionality for people who don't need >the big guns on it. > >I'm fairly hesitant to add any more to it directly... that said, we have >a lot of good infrastructure in place now to be able to have 3rd party >plugins/add-on packs that do such things, and I would absolutely not >hesitate in the least to expand the APIs as needed to make something like >that work as a plugin. From the recent posts, within the last month or two, I don't think I have yet seen a list of what specific functionality bugzilla is missing for task management. Or even what is really different from a bug or task or job or work item or enhancement or feature request. Semantic discussions are great when they result in a list of differences and a plan on how to resolve those differences. Be it API additions, core changes, UI changes, a new page that does some spiffy query to show something that is not shown currently, etc. So can someone either point me to a bug that lists out what is missing / needing to be added to bugzilla? And if that doesn't exist, can someone throw down the gauntlet and specify what their vision of bug or task or job or work item or enhancement or feature request are and how they are different. :-) From justdave at bugzilla.org Thu Oct 14 18:41:25 2004 From: justdave at bugzilla.org (David Miller) Date: Thu, 14 Oct 2004 14:41:25 -0400 Subject: which version for a new non uber critical production installation In-Reply-To: <6.1.2.0.2.20041014110857.0b24f740@mail.ev1.net> References: <6.1.2.0.2.20041014110857.0b24f740@mail.ev1.net> Message-ID: <416EC855.9000900@bugzilla.org> msew at pobox.com wrote: > From the mailing list and the 2.18 blocking statue page, it seems that > 2.18 rc3 and 2.19.1 and 2.16 release are all ?imminent? :-) > > So for someone who is doing their first installation and first usage of > bugzilla which should I use? I have been eagerly awaiting 2.18rc3 as > it seemed to be the version of choice. But from some posts on the > mailing list it seems that 2.19.1 is going to have a bunch of changes to > make bugzilla more extensible. > > Any idea when 2.18rc3 and 2.19.1 are going to be released? And which > one should I go for? Yeah, I've been saying "any hour now" for the last 2 days. There's about 3 hours worth of stuff left to do (which is basically roll the tarballs and fix up the web pages). Just a matter of finding time to do it. Hopefully sometime today. 2.19.x is actually pretty darn "stable" right now as far as lack of problems. If we weren't so far behind on the 2.18 release, I would actually be calling it 2.20rc1 instead of 2.19.1, but that just feels wrong when 2.18 isn't even released yet. :) -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From msew at pobox.com Thu Oct 14 18:48:51 2004 From: msew at pobox.com (msew at pobox.com) Date: Thu, 14 Oct 2004 11:48:51 -0700 Subject: which version for a new non uber critical production In-Reply-To: <416EC855.9000900@bugzilla.org> References: <6.1.2.0.2.20041014110857.0b24f740@mail.ev1.net> <416EC855.9000900@bugzilla.org> Message-ID: <6.1.2.0.2.20041014114543.2d27c6f0@mail.ev1.net> At 11:41 2004-10-14, David Miller wrote: >2.19.x is actually pretty darn "stable" right now as far as lack of >problems. If we weren't so far behind on the 2.18 release, I would >actually be calling it 2.20rc1 instead of 2.19.1, but that just feels >wrong when 2.18 isn't even released yet. :) will there be a list of differences between 2.18 and 2.19.1 ? :-) The only thing that is semi holding me back from wanting to go with 2.19.1 (2.20rc1) is the lack of support from p4dti http://www.ravenbrook.com/project/p4dti/plan/#section-2.15 (not a bugzilla issue per say). But I use perforce and having my tracking software interfacing with my revision control software is sort of needed :-) From justdave at bugzilla.org Thu Oct 14 19:34:38 2004 From: justdave at bugzilla.org (David Miller) Date: Thu, 14 Oct 2004 15:34:38 -0400 Subject: which version for a new non uber critical production In-Reply-To: <6.1.2.0.2.20041014114543.2d27c6f0@mail.ev1.net> References: <6.1.2.0.2.20041014110857.0b24f740@mail.ev1.net> <416EC855.9000900@bugzilla.org> <6.1.2.0.2.20041014114543.2d27c6f0@mail.ev1.net> Message-ID: <416ED4CE.9080303@bugzilla.org> msew at pobox.com wrote: > At 11:41 2004-10-14, David Miller wrote: > >> 2.19.x is actually pretty darn "stable" right now as far as lack of >> problems. If we weren't so far behind on the 2.18 release, I would >> actually be calling it 2.20rc1 instead of 2.19.1, but that just feels >> wrong when 2.18 isn't even released yet. :) > > will there be a list of differences between 2.18 and 2.19.1 ? :-) Yes, that's among the mentioned web pages that need to be done as part of the release. :) -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From bugreport at peshkin.net Thu Oct 14 21:13:36 2004 From: bugreport at peshkin.net (Joel Peshkin) Date: Thu, 14 Oct 2004 14:13:36 -0700 Subject: Bug 225221 - a primary key for longdescs In-Reply-To: References: <7EEAE93B09529A40972F5EFC7093ED6307F35D@imc-exchange.IMCentricAD> <416569B4.5060707@gmx.net> <1097186296.5708.4.camel@localhost.localdomain> <4169B650.5070501@mozilla.org> <416AD0BD.8030707@mozilla.org> <20041011212640.GB2899@async.com.br> <416B0347.4090609@peshkin.net> <416B5677.2050207@peshkin.net> Message-ID: <416EEC00.8020402@peshkin.net> Christopher Hicks wrote: > > That won't work! How can you assign integers to something you can't > uniquely refer to? The simplest and most painless way to get past the > chicken and egg problem is by having MySQL do it (as my patches have > done) you end up with a primary key already filled out for you. It > seems so simple yet its taken so long and folks still don't get it. > So I gripe. > You go through the existing rows in checksetup and identify them and assign them integers. if you really find 2 identical rows, the LIMIT 1 in the update statement will take care of it. Pseudocode for checksetup.... alter table longdescs add column newkey int; select bug_id, bug_when, bug_who from longdescs order by bug_id, bug_when; while (row) do update longdescs set newkey = $nextnumber where bug_id = $id AND bug_when = $when AND bug_who = $who LIMIT 1 until no_rows_updated alter table longdescs alter column newkey auto_increment primary key From justdave at bugzilla.org Thu Oct 14 22:37:10 2004 From: justdave at bugzilla.org (David Miller) Date: Thu, 14 Oct 2004 18:37:10 -0400 Subject: Bug 225221 - a primary key for longdescs In-Reply-To: References: <7EEAE93B09529A40972F5EFC7093ED6307F35D@imc-exchange.IMCentricAD> <416569B4.5060707@gmx.net> <1097186296.5708.4.camel@localhost.localdomain> <4169B650.5070501@mozilla.org> <416AD0BD.8030707@mozilla.org> <20041011212640.GB2899@async.com.br> <416B0347.4090609@peshkin.net> <416B5677.2050207@peshkin.net> Message-ID: <416EFF96.2060408@bugzilla.org> Christopher Hicks wrote: > On Mon, 11 Oct 2004, Joel Peshkin wrote: > >> Also, nobody is obstructing that bug, but nobody seems to have taken >> on the task of making the conversion code work properly. For existing >> databases, it is probably necessary to first assign integers to the >> new field in the correct order, then identify the new field as a >> primary key. > > That won't work! How can you assign integers to something you can't > uniquely refer to? The simplest and most painless way to get past the > chicken and egg problem is by having MySQL do it (as my patches have > done) you end up with a primary key already filled out for you. It > seems so simple yet its taken so long and folks still don't get it. So > I gripe. You missed the "in the correct order" part. MySQL will happily assign them for you, but there's no guarantee they'll wind up in the order you expect them. On the other hand, if there is such a guarantee, point it out to me in the MySQL docs and I'll change my mind. :) -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From zak at sxip.com Fri Oct 15 17:07:21 2004 From: zak at sxip.com (Zak Greant) Date: Fri, 15 Oct 2004 10:07:21 -0700 Subject: Bug 225221 - a primary key for longdescs In-Reply-To: <416EFF96.2060408@bugzilla.org> References: <7EEAE93B09529A40972F5EFC7093ED6307F35D@imc-exchange.IMCentricAD> <416569B4.5060707@gmx.net> <1097186296.5708.4.camel@localhost.localdomain> <4169B650.5070501@mozilla.org> <416AD0BD.8030707@mozilla.org> <20041011212640.GB2899@async.com.br> <416B0347.4090609@peshkin.net> <416B5677.2050207@peshkin.net> <416EFF96.2060408@bugzilla.org> Message-ID: Greetings All, I have been lurking, watching to see what happens with the Sxip stuff. However, since I used to work for MySQL, I could not resist this question. On Oct 14, 2004, at 15:37, David Miller wrote: > Christopher Hicks wrote: >> On Mon, 11 Oct 2004, Joel Peshkin wrote: >>> Also, nobody is obstructing that bug, but nobody seems to have taken >>> on the task of making the conversion code work properly. For >>> existing databases, it is probably necessary to first assign >>> integers to the new field in the correct order, then identify the >>> new field as a primary key. >> That won't work! How can you assign integers to something you can't >> uniquely refer to? The simplest and most painless way to get past >> the chicken and egg problem is by having MySQL do it (as my patches >> have done) you end up with a primary key already filled out for you. >> It seems so simple yet its taken so long and folks still don't get >> it. So I gripe. > > You missed the "in the correct order" part. MySQL will happily assign > them for you, but there's no guarantee they'll wind up in the order > you expect them. On the other hand, if there is such a guarantee, > point it out to me in the MySQL docs and I'll change my mind. :) MySQL, in most common use cases, will generate a sequential set of integers. As rows are deleted, the corresponding integers will not be re-used. The exceptions to this are multi-column primary keys with auto_increment fields and some versions of MySQL > 3 years old. Still, why rely on a feature that is only supported by one database? It seems better to be more independent. Cheers! --zak From justdave at bugzilla.org Fri Oct 15 17:27:10 2004 From: justdave at bugzilla.org (David Miller) Date: Fri, 15 Oct 2004 13:27:10 -0400 Subject: Bug 225221 - a primary key for longdescs In-Reply-To: References: <7EEAE93B09529A40972F5EFC7093ED6307F35D@imc-exchange.IMCentricAD> <416569B4.5060707@gmx.net> <1097186296.5708.4.camel@localhost.localdomain> <4169B650.5070501@mozilla.org> <416AD0BD.8030707@mozilla.org> <20041011212640.GB2899@async.com.br> <416B0347.4090609@peshkin.net> <416B5677.2050207@peshkin.net> <416EFF96.2060408@bugzilla.org> Message-ID: <4170086E.30206@bugzilla.org> Zak Greant wrote: > MySQL, in most common use cases, will generate a sequential set of > integers. As rows are deleted, the corresponding integers will not be > re-used. The exceptions to this are multi-column primary keys with > auto_increment fields and some versions of MySQL > 3 years old. > > Still, why rely on a feature that is only supported by one database? It > seems better to be more independent. This would only be in the upgrade code, and there are no non-MySQL databases that we care about upgrading at the moment (because we don't actually support any others yet). Assuming this code lands before the database independence stuff does, it won't need to work on anything other than MySQL. The table in question has potentionally a hundred thousand or more rows in it already, with no existing primary key. There's a bug ID and a datestamp, which are sorted on when it's loaded currently. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From zak at sxip.com Fri Oct 15 17:47:15 2004 From: zak at sxip.com (Zak Greant) Date: Fri, 15 Oct 2004 10:47:15 -0700 Subject: Bug 225221 - a primary key for longdescs In-Reply-To: <4170086E.30206@bugzilla.org> References: <7EEAE93B09529A40972F5EFC7093ED6307F35D@imc-exchange.IMCentricAD> <416569B4.5060707@gmx.net> <1097186296.5708.4.camel@localhost.localdomain> <4169B650.5070501@mozilla.org> <416AD0BD.8030707@mozilla.org> <20041011212640.GB2899@async.com.br> <416B0347.4090609@peshkin.net> <416B5677.2050207@peshkin.net> <416EFF96.2060408@bugzilla.org> <4170086E.30206@bugzilla.org> Message-ID: <406B94B6-1ED2-11D9-B3D0-000D93B39814@sxip.com> Greetings! On Oct 15, 2004, at 10:27, David Miller wrote: > Zak Greant wrote: > >> MySQL, in most common use cases, will generate a sequential set of >> integers. As rows are deleted, the corresponding integers will not be >> re-used. The exceptions to this are multi-column primary keys with >> auto_increment fields and some versions of MySQL > 3 years old. >> Still, why rely on a feature that is only supported by one database? >> It seems better to be more independent. > > This would only be in the upgrade code, and there are no non-MySQL > databases that we care about upgrading at the moment (because we don't > actually support any others yet). Assuming this code lands before the > database independence stuff does, it won't need to work on anything > other than MySQL. Heh. At least that simplifies things for the now. :) > The table in question has potentionally a hundred thousand or more > rows in it already, with no existing primary key. There's a bug ID > and a datestamp, which are sorted on when it's loaded currently. Something simple like: ALTER TABLE longdescs ORDER BY bug_when, bug_id; ALTER TABLE longdescs ADD COLUMN pk INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY; ... seems like it should do the trick. Cheers! --zak From gerv at mozilla.org Fri Oct 15 19:10:58 2004 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 15 Oct 2004 20:10:58 +0100 Subject: What are bugs? Are bugs really work items? In-Reply-To: <20041013141637.GC521@async.com.br> References: <1097186296.5708.4.camel@localhost.localdomain> <4169B650.5070501@mozilla.org> <416AD0BD.8030707@mozilla.org> <20041011212640.GB2899@async.com.br> <416C1AC7.5080303@mozilla.org> <416CEEDB.50609@mozilla.org> <20041013141637.GC521@async.com.br> Message-ID: <417020C2.1020208@mozilla.org> Christian Robottom Reis wrote: > I'd say it's more that contributing to Bugzilla isn't *exciting*. When > people hook up with an OSS project, they like to feel like they make a > difference; with us I fear people just don't feel valued enough. It may > just have to do with maintainers not having time to review and nudge > them ahead, but I think there's also a lack of a "warm fuzzy feeling" > towards contributors. I'd like to see more "Wow, this feature is > awesome!" or "It's great to have you on board" but most of the time I > see us replying back with sterile r-minuses and complicated > cross-examining. That's a good point, and a fair cop. More warm fuzzies. Gerv From justdave at bugzilla.org Fri Oct 15 18:27:56 2004 From: justdave at bugzilla.org (David Miller) Date: Fri, 15 Oct 2004 14:27:56 -0400 Subject: Bug 225221 - a primary key for longdescs In-Reply-To: <406B94B6-1ED2-11D9-B3D0-000D93B39814@sxip.com> References: <7EEAE93B09529A40972F5EFC7093ED6307F35D@imc-exchange.IMCentricAD> <416569B4.5060707@gmx.net> <1097186296.5708.4.camel@localhost.localdomain> <4169B650.5070501@mozilla.org> <416AD0BD.8030707@mozilla.org> <20041011212640.GB2899@async.com.br> <416B0347.4090609@peshkin.net> <416B5677.2050207@peshkin.net> <416EFF96.2060408@bugzilla.org> <4170086E.30206@bugzilla.org> <406B94B6-1ED2-11D9-B3D0-000D93B39814@sxip.com> Message-ID: <417016AC.2040407@bugzilla.org> Zak Greant wrote: > ALTER TABLE longdescs ORDER BY bug_when, bug_id; I didn't know you could do that... :) Sure enough: http://dev.mysql.com/doc/mysql/en/ALTER_TABLE.html That's pretty cool. Thanks -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From travis at SEDSystems.ca Fri Oct 15 23:26:17 2004 From: travis at SEDSystems.ca (Shane H. W. Travis) Date: Fri, 15 Oct 2004 17:26:17 -0600 (CST) Subject: bug tracking, or task management? Message-ID: I've just made some localized mods that fall smack on the side of Task Management, and I'm wondering if something like this would be at all interesting to Bugzilla. BACKGROUND: Many of the contracts signed by SED Systems are for individually tailored software packages that will be used by one specific customer. Since a lot of the underlying functionality (reduncancy switching between servers, message communication, alarms, operator interface) is the same from project to project, we have a large reusable code base called The Framework. PROBLEM: When a new project finds a bug in the Framework, they have to hand it off to Framework coders to fix it. It is something that is blocking their progress, however, so they also want it tracked locally. ISSUE #1: The needs of the Framework group (discussing how to best fix the bug, and its ramifications on other parts of the framweork) are irrelevant to the end project, and the comments of the end project (e.g. knowing that the fix has been installed on the local testbed, but not yet at site) are irrelevant to the core framework coders. ISSUE #2: Since both sides of the issue want to track progress of the log item, re-assigning a single log item to different projects at various stages is not acceptable, as the scope is then lost to whoever doesn't 'own' it right now. SOLUTION: Creation of a simple way to duplicate an existing log item. Added the ability to say, "Make this bug look like ____" to on enter_bug.cgi (and its templates), which pulls all relevant information and the first comment out of the database, then inserts them into the local fields. On commit, the copy and original are automatically given a dependson/blocks relationship. I can think of a number of situations where something like this would come in really handy... but they seem to me to fall under 'task management' and not 'bug tracking'. Silly example: you own five rental properties, and want to get new locks on each one. The meta-task is "Install new locks in each of my properties"; each of your properties (products) has its own copy of this item, blocked by the original. As the hardware arrives, you install it in each house as you make visits there, and close the appropriate bug. (This contrived situation is actually analogous to some hardware projects we have in the building.) Unlike some of my local modifications -- which I confess are 'do whatever works' -- I was inspired by recent participation in this list to try and do this *right*. As such, I think I could make a decent patch for this. It would still be some work, though, especially since I'd have to test it against a 2.19 installation (right?) and we're only running 2.16.6 locally. I don't see any open (or closed) bugs or enhancement requests asking for a feature like this, though, and it may well be that nobody out there but us NEEDS to be able to duplicate a bug (or in our case, a Log Item). So, I'm looking for some feedback, I guess. Does this fall into Bugzilla's 'scope' as a bug-tracking tool, or is it too task-managementish? Or does it matter, because nobody but us would ever need such an enhancement anyway so there's no use submitting it? (If I'm discussing this in completely the wrong way/place, someone please clue me in gently via private e-mail. I'm new to the process, so I may be mistaken... but I'm teachable. :) Shane Travis | A fanatic is someone who can't change his mind, travis at sedsystems.ca | and won't change the subject. Saskatoon, Saskatchewan | -- Winston Churchill From bugreport at peshkin.net Sat Oct 16 04:38:53 2004 From: bugreport at peshkin.net (Joel Peshkin) Date: Fri, 15 Oct 2004 21:38:53 -0700 Subject: bug tracking, or task management? In-Reply-To: References: Message-ID: <4170A5DD.1090507@peshkin.net> Shane H. W. Travis wrote: >I've just made some localized mods that fall smack on the side of Task >Management, and I'm wondering if something like this would be at all >interesting to Bugzilla. > > >BACKGROUND: Many of the contracts signed by SED Systems are for individually >tailored software packages that will be used by one specific customer. Since >a lot of the underlying functionality (reduncancy switching between servers, >message communication, alarms, operator interface) is the same from project >to project, we have a large reusable code base called The Framework. > >PROBLEM: When a new project finds a bug in the Framework, they have to hand >it off to Framework coders to fix it. It is something that is blocking their >progress, however, so they also want it tracked locally. > >ISSUE #1: The needs of the Framework group (discussing how to best fix the >bug, and its ramifications on other parts of the framweork) are irrelevant >to the end project, and the comments of the end project (e.g. knowing that >the fix has been installed on the local testbed, but not yet at site) are >irrelevant to the core framework coders. > >ISSUE #2: Since both sides of the issue want to track progress of the log >item, re-assigning a single log item to different projects at various stages >is not acceptable, as the scope is then lost to whoever doesn't 'own' it >right now. > >SOLUTION: Creation of a simple way to duplicate an existing log item. Added >the ability to say, "Make this bug look like ____" to on enter_bug.cgi (and >its templates), which pulls all relevant information and the first comment >out of the database, then inserts them into the local fields. On commit, the >copy and original are automatically given a dependson/blocks relationship. > > >I can think of a number of situations where something like this would come >in really handy... but they seem to me to fall under 'task management' and >not 'bug tracking'. Silly example: you own five rental properties, and want >to get new locks on each one. The meta-task is "Install new locks in each of >my properties"; each of your properties (products) has its own copy of this >item, blocked by the original. As the hardware arrives, you install it in >each house as you make visits there, and close the appropriate bug. (This >contrived situation is actually analogous to some hardware projects we have >in the building.) > > >Unlike some of my local modifications -- which I confess are 'do whatever >works' -- I was inspired by recent participation in this list to try and do >this *right*. As such, I think I could make a decent patch for this. It >would still be some work, though, especially since I'd have to test it >against a 2.19 installation (right?) and we're only running 2.16.6 locally. >I don't see any open (or closed) bugs or enhancement requests asking for a >feature like this, though, and it may well be that nobody out there but us >NEEDS to be able to duplicate a bug (or in our case, a Log Item). > >So, I'm looking for some feedback, I guess. Does this fall into Bugzilla's >'scope' as a bug-tracking tool, or is it too task-managementish? Or does it >matter, because nobody but us would ever need such an enhancement anyway so >there's no use submitting it? > > > > Heck yes. In fact, I use a bookmarklet to do just that. See bug 241443 for that. If you have a cleaner way to handle it, I'd sure use it. From gerv at mozilla.org Sat Oct 16 12:38:48 2004 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 16 Oct 2004 13:38:48 +0100 Subject: bug tracking, or task management? In-Reply-To: References: Message-ID: <41711658.6090203@mozilla.org> Shane H. W. Travis wrote: > I can think of a number of situations where something like this would come > in really handy... but they seem to me to fall under 'task management' and > not 'bug tracking'. Silly example: you own five rental properties, and want > to get new locks on each one. The meta-task is "Install new locks in each of > my properties"; each of your properties (products) has its own copy of this > item, blocked by the original. As the hardware arrives, you install it in > each house as you make visits there, and close the appropriate bug. (This > contrived situation is actually analogous to some hardware projects we have > in the building.) Usually, one would use dependencies for this, and "bookmarkable template" support on the bug entry page to create the five bugs, one for each lock changing operation. > Unlike some of my local modifications -- which I confess are 'do whatever > works' -- I was inspired by recent participation in this list to try and do > this *right*. As such, I think I could make a decent patch for this. It > would still be some work, though, especially since I'd have to test it > against a 2.19 installation (right?) and we're only running 2.16.6 locally. > I don't see any open (or closed) bugs or enhancement requests asking for a > feature like this, though, and it may well be that nobody out there but us > NEEDS to be able to duplicate a bug (or in our case, a Log Item). There's definitely a bug on this. Search for "clone bug". > So, I'm looking for some feedback, I guess. Does this fall into Bugzilla's > 'scope' as a bug-tracking tool, or is it too task-managementish? Or does it > matter, because nobody but us would ever need such an enhancement anyway so > there's no use submitting it? I think there is a need for it, and I don't think it's a particularly "task management" feature, but no-one's actually done it yet. Gerv From gerv at mozilla.org Sat Oct 16 15:38:18 2004 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 16 Oct 2004 16:38:18 +0100 Subject: Counting comments Message-ID: <4171406A.7070607@mozilla.org> Is it possible, either via the GUI or directly in SQL, to say: "Give me a list of all bugs meeting certain criteria, which in addition have (exactly 1|more than 1) comment"? I can do: SELECT bug_id, count(bug_when) AS bug_count FROM longdescs GROUP BY bug_id; but then I can't say "AND bug_count > 1" - it doesn't like that. At a pinch, I could cope with a solution just for one of the two cases, as I could do the root query and subtract. Gerv From chicks at chicks.net Sat Oct 16 15:45:39 2004 From: chicks at chicks.net (Christopher Hicks) Date: Sat, 16 Oct 2004 11:45:39 -0400 (EDT) Subject: Counting comments In-Reply-To: <4171406A.7070607@mozilla.org> References: <4171406A.7070607@mozilla.org> Message-ID: On Sat, 16 Oct 2004, Gervase Markham wrote: > Is it possible, either via the GUI or directly in SQL, to say: > > "Give me a list of all bugs meeting certain criteria, which in addition > have (exactly 1|more than 1) comment"? > > I can do: > > SELECT bug_id, count(bug_when) AS bug_count FROM longdescs GROUP BY bug_id; > > but then I can't say "AND bug_count > 1" - it doesn't like that. > > At a pinch, I could cope with a solution just for one of the two cases, > as I could do the root query and subtract. Isn't that what HAVING is for? -- "Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing." -- Dick Brandon From justdave at bugzilla.org Sat Oct 16 16:00:49 2004 From: justdave at bugzilla.org (David Miller) Date: Sat, 16 Oct 2004 12:00:49 -0400 Subject: Counting comments In-Reply-To: References: <4171406A.7070607@mozilla.org> Message-ID: <417145B1.8030505@bugzilla.org> Christopher Hicks wrote: > On Sat, 16 Oct 2004, Gervase Markham wrote: > >> Is it possible, either via the GUI or directly in SQL, to say: >> >> "Give me a list of all bugs meeting certain criteria, which in addition >> have (exactly 1|more than 1) comment"? >> >> I can do: >> >> SELECT bug_id, count(bug_when) AS bug_count FROM longdescs GROUP BY >> bug_id; >> >> but then I can't say "AND bug_count > 1" - it doesn't like that. >> >> At a pinch, I could cope with a solution just for one of the two cases, >> as I could do the root query and subtract. > > Isn't that what HAVING is for? Yep, Chris is correct, this works: mysql> SELECT bug_id, count(bug_when) AS comments FROM longdescs GROUP BY bug_id HAVING comments > 400 ORDER BY comments DESC; +--------+----------+ | bug_id | comments | +--------+----------+ | 27803 | 700 | | 18574 | 540 | | 25537 | 503 | | 171441 | 430 | | 82534 | 410 | +--------+----------+ 5 rows in set (9.29 sec) -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From prasad_kadbane at yahoo.co.in Sat Oct 16 11:30:04 2004 From: prasad_kadbane at yahoo.co.in (prasad kadbane) Date: Sat, 16 Oct 2004 12:30:04 +0100 (BST) Subject: what should be bug to testcase relation Message-ID: <20041016113004.69736.qmail@web8509.mail.in.yahoo.com> Hello, I am a perl developer and I working on project which support testcase management system and bug tracking system. I also know the bugzilla well. I am confused about what should be the test case to bug relation Is it one-to-one or one-to-many or many-to-many. Some experts says that it should be one to many ie one test case can have one or many bugs. Please help about relation and tell me what is standerd. ________________________________________________________________________ Yahoo! India Matrimony: Find your life partner online Go to: http://yahoo.shaadi.com/india-matrimony From bbaetz at acm.org Sun Oct 17 00:19:56 2004 From: bbaetz at acm.org (Bradley Baetz) Date: Sun, 17 Oct 2004 10:19:56 +1000 Subject: Counting comments In-Reply-To: <4171406A.7070607@mozilla.org> References: <4171406A.7070607@mozilla.org> Message-ID: <20041017001956.GA3558@mango.home> On Sat, Oct 16, 2004 at 04:38:18PM +0100, Gervase Markham wrote: > Is it possible, either via the GUI or directly in SQL, to say: > > "Give me a list of all bugs meeting certain criteria, which in addition > have (exactly 1|more than 1) comment"? They're almost all going to have the initial comment, so you probably want > 1. select bug_id from longdescs where bug_id in (SELECT id from bugs where ....) GROUP BY bug_id HAVING count(*) > 1 In mysql you'll have to do it as a temp table + join. > I can do: > > SELECT bug_id, count(bug_when) AS bug_count FROM longdescs GROUP BY bug_id; > > but then I can't say "AND bug_count > 1" - it doesn't like that. You have to do HAVING count(bug_when) > 1 - HAVING runs after GROUP BY. Depending on your myqsl version, you may or may not have to have the expression in the having as part of the columns you select. Bradley From gerv at mozilla.org Sun Oct 17 12:55:22 2004 From: gerv at mozilla.org (Gervase Markham) Date: Sun, 17 Oct 2004 13:55:22 +0100 Subject: what should be bug to testcase relation In-Reply-To: <20041016113004.69736.qmail@web8509.mail.in.yahoo.com> References: <20041016113004.69736.qmail@web8509.mail.in.yahoo.com> Message-ID: <41726BBA.4030904@mozilla.org> prasad kadbane wrote: > I am a perl developer and I working on project > which support testcase management system and bug > tracking system. I also know the bugzilla well. I am > confused about what should be the test case to bug > relation Is it one-to-one or one-to-many or > many-to-many. Some experts says that it should be one > to many ie one test case can have one or many bugs. > Please help about relation and tell me what is standerd. I would suggest that one bug can certainly have multiple testcases, and one testcase can sometimes refer to multiple bugs. So it's many-to-many. Gerv From zak at sxip.com Mon Oct 18 01:11:19 2004 From: zak at sxip.com (Zak Greant) Date: Sun, 17 Oct 2004 18:11:19 -0700 Subject: Counting comments In-Reply-To: <20041017001956.GA3558@mango.home> References: <4171406A.7070607@mozilla.org> <20041017001956.GA3558@mango.home> Message-ID: <9E434746-20A2-11D9-88D5-000D93B39814@sxip.com> Greetings! On Oct 16, 2004, at 17:19, Bradley Baetz wrote: ... > select bug_id from longdescs where bug_id in (SELECT id from > bugs where ....) GROUP BY bug_id HAVING count(*) > 1 > > In mysql you'll have to do it as a temp table + join. In MySQL version 4.0 or less, you will have to do it as a temp table and join. MySQL 4.1+ should support this syntax. Cheers! --zak From lee at netzentry.com Mon Oct 18 04:45:18 2004 From: lee at netzentry.com (Lee Ivy) Date: Sun, 17 Oct 2004 21:45:18 -0700 Subject: what should be bug to testcase relation References: <20041016113004.69736.qmail@web8509.mail.in.yahoo.com> <41726BBA.4030904@mozilla.org> Message-ID: <001801c4b4cd$4d4f6240$0300a8c0@IvyFamily> I agree with Gervase that there are cases where you see either several bugs from 1 test case, or several test cases for 1 bug. However, if a many-to-many relationship will create a lot of extra complexity, my advice to Prasad would be to ask your users what query operations are most important to them. In my experience running QA groups, it's very important to answer the question, "What is the status of the bug(s) for this test case?" (usually this is implemented as a query to the test case database) -- but it is less common for someone to ask, "What are all the test cases associated with this bug?". So if you are under pressure to deliver a solution quickly, you may want to try simplifying your problem a bit -- perhaps you could get away with supporting a single test case per bug, but be sure to allow multiple bugs per test case. If my experience is not typical, I'm sure the kind people in the group will not be shy about providing a different view. Lee ----- Original Message ----- From: "Gervase Markham" To: Cc: Sent: Sunday, October 17, 2004 5:55 AM Subject: Re: what should be bug to testcase relation > prasad kadbane wrote: > > I am a perl developer and I working on project > > which support testcase management system and bug > > tracking system. I also know the bugzilla well. I am > > confused about what should be the test case to bug > > relation Is it one-to-one or one-to-many or > > many-to-many. Some experts says that it should be one > > to many ie one test case can have one or many bugs. > > Please help about relation and tell me what is standerd. > > I would suggest that one bug can certainly have multiple testcases, and > one testcase can sometimes refer to multiple bugs. So it's many-to-many. > > Gerv > - > To view or change your list settings, click here: > > From virajdhumal at yahoo.co.in Mon Oct 18 06:02:08 2004 From: virajdhumal at yahoo.co.in (viraj dhumal) Date: Mon, 18 Oct 2004 07:02:08 +0100 (BST) Subject: Testcase-to-Bug Relationship Message-ID: <20041018060208.1849.qmail@web8503.mail.in.yahoo.com> I am a software developer from india. we have developed a TESTCASE MANAGEMENT SYSTEM which works as an ADD-ON OVER BUGZILLA. In our system the Testcase-to-Bug relationship is one-to-one. But the QA persons in our company have suggested that the a testcase should be associated with multiple bugs. we are confused that if the relationship can be one-to-many(testcase-bug) then why not many-to-many. But many-to-many relationship will be too complex. Also developers from the mailing list suggested to keep the relationship as one-to-many. Now in our TCM we are creating a Testcase as a sequence of STEPS. each step of a testcase has 1.action 2.expected result 3.actual result 4.status(pass, fail) The testcase status is the AND-ING of steps status. now consider the case of one-to-many relation(testcase-bug). my query is whether to explicitly relate a bug to a step of the testcase.In that case the no. of bugs associated with a testcase will be limited to the no of steps in that testcase. or whether to keep no explicit relation between bug and test step, but only a one-to-many relation betn testcase and bug. Please Reply............... Regards, viraj. ________________________________________________________________________ Yahoo! India Matrimony: Find your life partner online Go to: http://yahoo.shaadi.com/india-matrimony From john.fisher at znyx.com Mon Oct 18 15:40:25 2004 From: john.fisher at znyx.com (John Fisher) Date: Mon, 18 Oct 2004 08:40:25 -0700 Subject: bug tracking, or task management? In-Reply-To: References: Message-ID: <4173E3E9.7070009@znyx.com> FWIW dept: I have done something with a similar intent in a different way: we too have multiple branches of the same code base. I have added a branch field and a clone field. Branches are not product-dependent in our world, but versions do have a unique relationship with a branch. Bugs may be cloned at any time in their lifecycle, en mass at the creation of a branch, or singly. I have also added a diff clones by branch feature which allows a user to find out whether and which bugs have been cloned from one branch to another. Unfortunately I can't supply a patch, as I have headed off so far into the wilderness, that I basically have a forked code base. I'd be happy to supply snippets or advice or whatever, if this is widely useful. John Shane H. W. Travis wrote: > I've just made some localized mods that fall smack on the side of Task > Management, and I'm wondering if something like this would be at all > interesting to Bugzilla. > > -- John P. Fisher at ZNYX Networks 805 683 1488 x 3245 john.fisher at znyx.com From zak at sxip.com Sat Oct 16 16:37:54 2004 From: zak at sxip.com (Zak Greant) Date: Sat, 16 Oct 2004 09:37:54 -0700 Subject: Bug 225221 - a primary key for longdescs In-Reply-To: <417016AC.2040407@bugzilla.org> References: <7EEAE93B09529A40972F5EFC7093ED6307F35D@imc-exchange.IMCentricAD> <416569B4.5060707@gmx.net> <1097186296.5708.4.camel@localhost.localdomain> <4169B650.5070501@mozilla.org> <416AD0BD.8030707@mozilla.org> <20041011212640.GB2899@async.com.br> <416B0347.4090609@peshkin.net> <416B5677.2050207@peshkin.net> <416EFF96.2060408@bugzilla.org> <4170086E.30206@bugzilla.org> <406B94B6-1ED2-11D9-B3D0-000D93B39814@sxip.com> <417016AC.2040407@bugzilla.org> Message-ID: On Oct 15, 2004, at 11:27, David Miller wrote: > Zak Greant wrote: >> ALTER TABLE longdescs ORDER BY bug_when, bug_id; > > I didn't know you could do that... :) > > Sure enough: http://dev.mysql.com/doc/mysql/en/ALTER_TABLE.html > > That's pretty cool. Thanks My pleasure - thanks for the work on Bugzilla! :) Cheers! --zak From lee at netzentry.com Tue Oct 19 00:55:05 2004 From: lee at netzentry.com (Lee Ivy) Date: Mon, 18 Oct 2004 17:55:05 -0700 Subject: Testcase-to-Bug Relationship In-Reply-To: <20041018060208.1849.qmail@web8503.mail.in.yahoo.com> References: <20041018060208.1849.qmail@web8503.mail.in.yahoo.com> Message-ID: <417465E9.9020703@netzentry.com> Viraj, As I stated in my previous posting, I think one-testcase-to-many-bugs is a reasonable compromise. On your question about whether to relate bugs to testcases or to steps of testcases -- I don't see the value of the extra complexity created by the step-to-bug requirement, and I think most QA people would be annoyed if you asked them to follow such a model. And the mapping still may not be one-to-one: what if 2 bad things happened at once? Better to keep it simple and make sure there is at least 1 bug logged for every failed test case. Remember, too, that it's reasonable for some bugs to be logged that are not associated with any test case. At one place I worked, we called them "falling off a log" bugs -- an example would be an exception or crash that just happened when you were navigating around the system getting ready to start a test. The name meant that you weren't even trying to break the system yet, you just ran into the bug and could not avoid it. Lee viraj dhumal wrote: > I am a software developer from india. we have >developed a TESTCASE MANAGEMENT SYSTEM which works as >an ADD-ON OVER BUGZILLA. In our system the >Testcase-to-Bug relationship is one-to-one. But the QA >persons in our company have suggested that the a >testcase should be associated with multiple bugs. we >are confused that if the relationship can be >one-to-many(testcase-bug) then why not many-to-many. > But many-to-many relationship will be too >complex. Also developers from the mailing list >suggested to keep the relationship as one-to-many. > Now in our TCM we are creating a Testcase as >a sequence of STEPS. each step of a testcase has >1.action >2.expected result >3.actual result >4.status(pass, fail) > >The testcase status is the AND-ING of steps status. > >now consider the case of one-to-many >relation(testcase-bug). >my query is whether to explicitly relate a bug to a >step of the testcase.In that case the no. of bugs >associated with a testcase will be limited to the no >of steps in that testcase. > >or > >whether to keep no explicit relation between bug and >test step, but only a one-to-many relation betn >testcase and bug. > > Please Reply............... > >Regards, >viraj. > >________________________________________________________________________ >Yahoo! India Matrimony: Find your life partner online >Go to: http://yahoo.shaadi.com/india-matrimony >- >To view or change your list settings, click here: > > > From kiko at async.com.br Tue Oct 19 11:26:51 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Tue, 19 Oct 2004 08:26:51 -0300 Subject: What are bugs? Are bugs really work items? In-Reply-To: <416E3CB6.9090004@mozilla.org> References: <416E3CB6.9090004@mozilla.org> Message-ID: <20041019112651.GE521@async.com.br> On Thu, Oct 14, 2004 at 09:45:42AM +0100, Gervase Markham wrote: > Jason Pyeron wrote: > >I think we fight to many battles for the sake of perfection (this causes > >bit rot). Or even more trivial are the situations where a patch is given > >as step 1 of 2, and step 1 is never committed since step 2 was not done > >too. If there cannot be an agreement or an absolute "RIGHT" decided for > >step 2 then don't r- if step one is good on its own merit. > > If step 1 is good on its own merit, then don't present it as "step 1 of > 2" :-) Well, Jason may have a point. The point is that too often we are reluctant to allow people to file follow-up bugs, which is something that would relieve them significantly of a lengthy, disencouraging review cycle. The problem that derives from that is having people file follow-up bugs and disappear. But I don't think we can go on living with that mentality, because IMO it tends to intensify the issue which brings people to disappear in the first place. > >Sometimes changing a 'function name' or other detail for 'cosmetics' is > >just not worth it. > > I'd disagree. Coding standards are important for current and new > developers to know what's going on. Changing a function name is usually > so easily that it's hardly ever not worth it. Sure, unless you take two months to review and then say "ah, can we please rename X to Y and Z to W and split A into B and C?". These are all valid requests in themselves, but after a lengthy review cycle you may have to leave them to follow-up bugs, or give them up if you want to keep the contributor, or take it up yourself and fix it. Not doing any of those means we just bitrot everything people do and then we're sitting here in a circle wondering why nobody stays around. Being allowed to mark something as FIXED is a major incentive to participating for me -- I would actually be a lot more productive if I was allowed to mark things that are `almost perfect' FIXED and move on to fallout or follow-up there towards `perfection'. I think we err on the side of caution too often and this brings us to stalemates all around. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 From chicks at chicks.net Tue Oct 19 15:58:25 2004 From: chicks at chicks.net (Christopher Hicks) Date: Tue, 19 Oct 2004 11:58:25 -0400 (EDT) Subject: What are bugs? Are bugs really work items? In-Reply-To: <20041019112651.GE521@async.com.br> References: <416E3CB6.9090004@mozilla.org> <20041019112651.GE521@async.com.br> Message-ID: On Tue, 19 Oct 2004, Christian Robottom Reis wrote: > I think we err on the side of caution too often and this brings us to > stalemates all around. Amen. -- "Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing." -- Dick Brandon From kiko at async.com.br Tue Oct 19 18:24:37 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Tue, 19 Oct 2004 15:24:37 -0300 Subject: Doomed Reports? Message-ID: <20041019182437.GA3109@async.com.br> In the version of Bugzilla I currently run at Async (2.17.early) we can get bug counts per engineer. I don't see a way to do that in modern Bugzilla, though I may just be a victim of the UI. I see that it was removed a while back: 2002-10-16 20:09 gerv%gerv.net * reports.cgi, CGI.pl, template/en/default/global/user-error.html.tmpl, template/en/default/global/code-error.html.tmpl: Bug 172959 - Remove old reporting (most doomed etc.). Patch by gerv; r=bbaetz. But I'm having a hard time understanding why if this functionality is no longer available. Or if it is, can someone hold my hand and explain it to me? Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 From kiko at async.com.br Tue Oct 19 11:29:01 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Tue, 19 Oct 2004 08:29:01 -0300 Subject: What are bugs? Are bugs really work items? In-Reply-To: <6.1.2.0.2.20041014110833.2d1fce50@mail.ev1.net> References: <4169B650.5070501@mozilla.org> <416AD0BD.8030707@mozilla.org> <20041011212640.GB2899@async.com.br> <416B0347.4090609@peshkin.net> <416C170B.6080204@mozilla.org> <416DBA82.90403@bugzilla.org> <6.1.2.0.2.20041014110833.2d1fce50@mail.ev1.net> Message-ID: <20041019112901.GF521@async.com.br> On Thu, Oct 14, 2004 at 11:08:42AM -0700, msew at ev1.net wrote: > >Bugzilla already has a lot of task management features, but the ones it's > >got are meant to provide minimum functionality for people who don't need > >the big guns on it. > > So can someone either point me to a bug that lists out what is missing / > needing to be added to bugzilla? And if that doesn't exist, can someone > throw down the gauntlet and specify what their vision of bug or task or job > or work item or enhancement or feature request are and how they are > different. :-) As you can see, either we lack no features or nobody's interested in actually saying what they are ;-) In my book, bits and pieces I miss are: - Bug type: An enum of localconfig-defined values that can be used to define what that bug represents -- a code error, a user request, an enhancement request, an operational mistake, and anything else which may or may not indicate a need to change code. - A deadline field (patch in hand and approved, awaiting checkin) - The ability to easily create dependent or blocking bugs from one bug -- this would make it a one-click deal to generate a child bug to which we'd only need to enter a summary and description. - A way to view a time-cut summary of comments posted to a `bug subtree' so you can get an overview of all the activity done on that bug - I have entertained before an idea of a "parent bug" field that would *not* be the same as blocks. I am still thinking this one over. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 From mkanat at kerio.com Tue Oct 19 23:21:16 2004 From: mkanat at kerio.com (Max Kanat-Alexander) Date: Tue, 19 Oct 2004 16:21:16 -0700 Subject: What are bugs? Are bugs really work items? In-Reply-To: <20041019112901.GF521@async.com.br> References: <4169B650.5070501@mozilla.org> <416AD0BD.8030707@mozilla.org> <20041011212640.GB2899@async.com.br> <416B0347.4090609@peshkin.net> <416C170B.6080204@mozilla.org> <416DBA82.90403@bugzilla.org> <6.1.2.0.2.20041014110833.2d1fce50@mail.ev1.net> <20041019112901.GF521@async.com.br> Message-ID: <1098228075.26669.23.camel@localhost.localdomain> On Tue, 2004-10-19 at 04:29, Christian Robottom Reis wrote: > - Bug type: An enum of localconfig-defined values that can be used > to define what that bug represents [snip] I've certainly also considered adding this to my local Bugzilla, but I've wondered what real process advantage it gets me. Is it somehow better than just having separate components for those types of things, per-product? I mean, the reason that I'd want to have "bug categories" is because I'd want to treat those differently. But I'm not sure how just adding a field would really allow me to do that. > - A deadline field (patch in hand and approved, awaiting checkin) Agreed, definitely. Or a way to associate dates with Target Milestones -- that would be the best. > - The ability to easily create dependent or blocking bugs from one > bug -- this would make it a one-click deal to generate a child bug > to which we'd only need to enter a summary and description. I agree. > - A way to view a time-cut summary of comments posted to a `bug > subtree' so you can get an overview of all the activity done on > that bug By "bug subtree" I assume that you mean "this bug and all its dependencies?" This would probably be less useful than all the above features, but would still be neat and helpful. > - I have entertained before an idea of a "parent bug" field that > would *not* be the same as blocks. I am still thinking this one > over. What would it indicate? Are there RFEs on b.m.o for any of these things? -Max -- Maxwell Kanat-Alexander 2nd Level Tech Support Engineer, USA Kerio Technologies, Inc. 2041 Mission College Blvd. Suite 100 Santa Clara, CA 95054 Phone: (408) 496-4500 Fax: (408) 496-6902 Web: http://www.kerio.com/support.html From stu at asyn.com Wed Oct 20 16:32:10 2004 From: stu at asyn.com (Stuart Donaldson) Date: Wed, 20 Oct 2004 09:32:10 -0700 Subject: Changing flags on multiple bugs at once. Message-ID: <4176930A.8020902@asyn.com> I am trying to upgrade to Bugzilla 1.18 right now, and looking at how best to utilize the flags capabilities. I want to be able to see the flags on a report, and to change multiple flags at once. I have come up with a patch that lets me see flags in the reports, adding columns for Flags+, Flags-, and Flags? and displaying in those columns all flags in the respective categories. However the problem of changing multiple flags at a time is more elusive. Furthermore, i would like to be able to query on flags. I am lead to wonder if I am approaching this in the wrong way. I had been using keywords, however the main problem with keywords is that someone has to type them in, and there isn't a convenient selection/picker for it. Neither is there a way to put any restriction on some keywords apply to some products and not others. Any ideas here? -Stuart- From myk at mozilla.org Wed Oct 20 23:12:51 2004 From: myk at mozilla.org (Myk Melez) Date: Thu, 21 Oct 2004 01:12:51 +0200 Subject: Changing flags on multiple bugs at once. In-Reply-To: <4176930A.8020902@asyn.com> References: <4176930A.8020902@asyn.com> Message-ID: <4176F0F3.9070001@mozilla.org> Stuart Donaldson wrote: > I have come up with a patch that lets me see flags in the reports, > adding columns for Flags+, Flags-, and Flags? and displaying in those > columns all flags in the respective categories. That sounds useful. Could you file a bug report about it and attach your patch? > However the problem of changing multiple flags at a time is more elusive. This is certainly doable, although getting the UI right may be hard. You would need to hack the "change several bugs at once" form to include flags. Perhaps for each flag you could add an additional control for specifying whether to add or delete the flag (just as keywords has a menu for specifying whether to add the listed keywords, delete them, or make them match the entered string exactly). > Furthermore, i would like to be able to query on flags. This is currently possible via the boolean chart. > I am lead to wonder if I am approaching this in the wrong way. I had > been using keywords, however the main problem with keywords is that > someone has to type them in, and there isn't a convenient > selection/picker for it. Neither is there a way to put any > restriction on some keywords apply to some products and not others. Keyword pickers are available (I wrote one early in my Bugzilla hacking days), although AFAIK none has ever gone through review and been checked in. Nonetheless, you're right that keywords can't be product-specific, and flags were partly designed to provide a better solution for some problems previously solved by keywords, so they may be what you want. Note however that you could add product-specificity to keywords. I have a patch currently awaiting review that makes the product/component inclusions/exclusions ("clusions") code be independent of the flag type code so that it can be used in other parts of Bugzilla for product/component specificity. Using that patch, you could add such specificity to kewords. https://bugzilla.mozilla.org/show_bug.cgi?id=261181 -myk From gerv at mozilla.org Wed Oct 20 23:17:32 2004 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 21 Oct 2004 00:17:32 +0100 Subject: Doomed Reports? In-Reply-To: <20041019182437.GA3109@async.com.br> References: <20041019182437.GA3109@async.com.br> Message-ID: <4176F20C.9000007@mozilla.org> Christian Robottom Reis wrote: > In the version of Bugzilla I currently run at Async (2.17.early) we can > get bug counts per engineer. I don't see a way to do that in modern > Bugzilla, though I may just be a victim of the UI. > > I see that it was removed a while back: > > 2002-10-16 20:09 gerv%gerv.net > > * reports.cgi, CGI.pl, > template/en/default/global/user-error.html.tmpl, > template/en/default/global/code-error.html.tmpl: Bug 172959 - > Remove old reporting (most doomed etc.). Patch by gerv; r=bbaetz. > > But I'm having a hard time understanding why if this functionality is no > longer available. Or if it is, can someone hold my hand and explain it > to me? You can plot people against statuses on the reporting page, which is pretty close to the old function. Basically, it went away because it was horrible, old, crufty, non-localisable, unmaintainable code, and there was a near-equivalent replacement in the much more functional new reporting system. You are the first person to notice it's disappearance after two years, so I doubt it's much missed :-) Gerv From stu at asyn.com Thu Oct 21 01:12:30 2004 From: stu at asyn.com (Stuart Donaldson) Date: Wed, 20 Oct 2004 18:12:30 -0700 Subject: Changing flags on multiple bugs at once. In-Reply-To: <4176F0F3.9070001@mozilla.org> References: <4176930A.8020902@asyn.com> <4176F0F3.9070001@mozilla.org> Message-ID: <41770CFE.3090905@asyn.com> Myk Melez wrote: > Stuart Donaldson wrote: > >> I have come up with a patch that lets me see flags in the reports, >> adding columns for Flags+, Flags-, and Flags? and displaying in >> those columns all flags in the respective categories. > > > That sounds useful. Could you file a bug report about it and attach > your patch? > Ok, see: https://bugzilla.mozilla.org/show_bug.cgi?id=265354 ... >> I am lead to wonder if I am approaching this in the wrong way. I had >> been using keywords, however the main problem with keywords is that >> someone has to type them in, and there isn't a convenient >> selection/picker for it. Neither is there a way to put any >> restriction on some keywords apply to some products and not others. > > > Keyword pickers are available (I wrote one early in my Bugzilla > hacking days), although AFAIK none has ever gone through review and > been checked in. Nonetheless, you're right that keywords can't be > product-specific, and flags were partly designed to provide a better > solution for some problems previously solved by keywords, so they may > be what you want. > Where can I find a keyword picker? That might help a lot. My requirements for product specific keywords are not as important, and keywords are easier to search on, without having to resort to the booleans. -Stuart- From kiko at async.com.br Thu Oct 21 13:15:42 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Thu, 21 Oct 2004 10:15:42 -0300 Subject: Doomed Reports? In-Reply-To: <4176F20C.9000007@mozilla.org> References: <20041019182437.GA3109@async.com.br> <4176F20C.9000007@mozilla.org> Message-ID: <20041021131542.GA2949@async.com.br> On Thu, Oct 21, 2004 at 12:17:32AM +0100, Gervase Markham wrote: > >In the version of Bugzilla I currently run at Async (2.17.early) we can > >get bug counts per engineer. I don't see a way to do that in modern > >Bugzilla, though I may just be a victim of the UI. > > You can plot people against statuses on the reporting page, which is > pretty close to the old function. Oh! I picked Assignee versus Status and indeed, this is precisely what I wanted. It would be cool to be able to nickname reports as we do searches (saved reports?), but I assume there's a bug open on that. Think it's worth putting some effort into? > Basically, it went away because it was horrible, old, crufty, > non-localisable, unmaintainable code, and there was a near-equivalent > replacement in the much more functional new reporting system. Wow, this is *really* nice work -- if only the UI made it clearer this is how I should go about getting this sort of information. I'll be thinking about this in the future, but thanks a lot for now. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 From gerv at mozilla.org Thu Oct 21 21:00:46 2004 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 21 Oct 2004 22:00:46 +0100 Subject: Doomed Reports? In-Reply-To: <20041021131542.GA2949@async.com.br> References: <20041019182437.GA3109@async.com.br> <4176F20C.9000007@mozilla.org> <20041021131542.GA2949@async.com.br> Message-ID: <4178237E.5020807@mozilla.org> Christian Robottom Reis wrote: > Oh! I picked Assignee versus Status and indeed, this is precisely what I > wanted. It would be cool to be able to nickname reports as we do > searches (saved reports?), but I assume there's a bug open on that. > > Think it's worth putting some effort into? Use bookmarks :-) If you find the bug, you'll find me saying it's a bad idea because we end up with the Saved Searches problem - everyone wants more and more features until we reinvent an entire bookmarks system. And if you want them on more than one PC, give Mozilla's roaming profile support a kick. ;-) Gerv From chicks at chicks.net Thu Oct 21 21:21:33 2004 From: chicks at chicks.net (Christopher Hicks) Date: Thu, 21 Oct 2004 17:21:33 -0400 (EDT) Subject: Doomed Reports? In-Reply-To: <4178237E.5020807@mozilla.org> References: <20041019182437.GA3109@async.com.br> <4176F20C.9000007@mozilla.org> <20041021131542.GA2949@async.com.br> <4178237E.5020807@mozilla.org> Message-ID: On Thu, 21 Oct 2004, Gervase Markham wrote: > And if you want them on more than one PC, give Mozilla's roaming profile > support a kick. ;-) There will be rejoicing in the hills when this hits. -- "Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing." -- Dick Brandon From myk at mozilla.org Thu Oct 21 22:23:32 2004 From: myk at mozilla.org (Myk Melez) Date: Fri, 22 Oct 2004 00:23:32 +0200 Subject: CSS plan stage one complete: rearchitecture and custom stylesheet support Message-ID: <417836E4.1030409@mozilla.org> Developers and reviewers, With Gerv's reviews and Dave's approvals (thanks Gerv and Dave!), I checked in three patches today to 2.20 that together finish implementing the first stage of the Bugzilla CSS plan. The patches move Bugzilla CSS files from css/ to skins/standard/, make checksetup.pl create skins/custom/, and include skins/custom/ stylesheets in Bugzilla pages. These mainly architectural fixes implement support for custom (installation-specific) stylesheets and pave the way for future support for third-party skins. If you are a Bugzilla developer who does CSS hacking, look in skins/standard/ for the files to hack. If you are a Bugzilla reviewer reviewing a patch from before the change, the patch should apply cleanly to the equivalent files in skins/standard/. Just replace the css/ directory in your Bugzilla home directory with a symlink to skins/standard/ before applying the patch: cd ; mv css css.old; ln -s skins/standard css -myk From kiko at async.com.br Fri Oct 22 02:55:28 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Thu, 21 Oct 2004 23:55:28 -0300 Subject: Doomed Reports? In-Reply-To: <4178237E.5020807@mozilla.org> References: <20041019182437.GA3109@async.com.br> <4176F20C.9000007@mozilla.org> <20041021131542.GA2949@async.com.br> <4178237E.5020807@mozilla.org> Message-ID: <20041022025528.GB30368@www.async.com.br> On Thu, Oct 21, 2004 at 10:00:46PM +0100, Gervase Markham wrote: > Christian Robottom Reis wrote: > >Oh! I picked Assignee versus Status and indeed, this is precisely what I > >wanted. It would be cool to be able to nickname reports as we do > >searches (saved reports?), but I assume there's a bug open on that. > > > >Think it's worth putting some effort into? > > Use bookmarks :-) If you find the bug, you'll find me saying it's a bad > idea because we end up with the Saved Searches problem - everyone wants > more and more features until we reinvent an entire bookmarks system. Fair enough. But this means you *do* agree we need a number of pre-set searches put together in the Reports page to allow people to actually discover this kind of feature exists, right? Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 From chicks at chicks.net Sun Oct 24 22:02:56 2004 From: chicks at chicks.net (Christopher Hicks) Date: Sun, 24 Oct 2004 18:02:56 -0400 (EDT) Subject: Firefox not bring up bugzilla.org pages Message-ID: I've had trouble looking at pages on www.bugzilla.org with Firefox PR1. I'm able to bring up the same pages through google cache without difficulty so I suspect its a problem with moz' apache. Can anyone cross check me? -- Physics is like sex. Sure, it may give some practical results, but that's not why we do it. -- Richard Feynman From justdave at bugzilla.org Sun Oct 24 22:23:11 2004 From: justdave at bugzilla.org (David Miller) Date: Sun, 24 Oct 2004 18:23:11 -0400 Subject: Firefox not bring up bugzilla.org pages In-Reply-To: References: Message-ID: <417C2B4F.1050604@bugzilla.org> Christopher Hicks wrote: > I've had trouble looking at pages on www.bugzilla.org with Firefox PR1. > I'm able to bring up the same pages through google cache without > difficulty so I suspect its a problem with moz' apache. Can anyone > cross check me? Nope, it's a problem with OpenBSD's pf implementation in OpenBSD 3.1. bugzilla.org's web host is using OpenBSD 3.1 (plus security patches) as their firewall, and the bug in their window scaling implementation was fixed in OpenBSD 3.3. Unfortunately, they didn't see fit to include it in the security updates, so you actually have to upgrade the system to pick it up. It'll get upgraded eventually, but because it's a whole OS upgrade it'll probably be a month or two. It only affects machines running Linux 2.6.8+ kernels on the client end (which is why people are just now suddenly running into it). In the meantime, you can work around it by doing this as root: sysctl -w net.ipv4.tcp_default_win_scale=0 To make it permanent, you can add the following to your /etc/sysctl.conf file: net.ipv4.tcp_default_win_scale=0 The best writeup of the situation I've seen so far is at http://lwn.net/Articles/92727/ if you're curious about the details. :) -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From myk at mozilla.org Sun Oct 24 22:30:12 2004 From: myk at mozilla.org (Myk Melez) Date: Mon, 25 Oct 2004 00:30:12 +0200 Subject: Firefox not bring up bugzilla.org pages In-Reply-To: References: Message-ID: <417C2CF4.3000007@mozilla.org> Christopher Hicks wrote: > I've had trouble looking at pages on www.bugzilla.org with Firefox > PR1. I'm able to bring up the same pages through google cache without > difficulty so I suspect its a problem with moz' apache. Can anyone > cross check me? Are you on a Linux box perchance? There's a known bug affecting Linux clients connecting to web servers behind certain BSD kernel-based firewalls, like the one protecting bugzilla.org. There's a workaround which you can apply to your Linux machine's configuration, but I can't remember what it is right now. Dave'll know, though. -myk From chicks at chicks.net Sun Oct 24 22:40:35 2004 From: chicks at chicks.net (Christopher Hicks) Date: Sun, 24 Oct 2004 18:40:35 -0400 (EDT) Subject: Firefox not bring up bugzilla.org pages In-Reply-To: <417C2B4F.1050604@bugzilla.org> References: <417C2B4F.1050604@bugzilla.org> Message-ID: On Sun, 24 Oct 2004, David Miller wrote: > Nope, it's a problem with OpenBSD's pf implementation in OpenBSD 3.1. > bugzilla.org's web host is using OpenBSD 3.1 (plus security patches) as their > firewall, and the bug in their window scaling implementation was fixed in > OpenBSD 3.3. Unfortunately, they didn't see fit to include it in the > security updates, so you actually have to upgrade the system to pick it up. > It'll get upgraded eventually, but because it's a whole OS upgrade it'll > probably be a month or two. Is there a bug for this in bugzilla I can vote for? > It only affects machines running Linux 2.6.8+ kernels on the client end > (which is why people are just now suddenly running into it). > > In the meantime, you can work around it by doing this as root: > > sysctl -w net.ipv4.tcp_default_win_scale=0 > > To make it permanent, you can add the following to your /etc/sysctl.conf > file: > > net.ipv4.tcp_default_win_scale=0 I'd heard of this, but its the first time to bite me in the butt. I guess I'll vnc into my Windows box to view bugzilla.org. Ugh. > The best writeup of the situation I've seen so far is at > http://lwn.net/Articles/92727/ if you're curious about the details. :) Thanks for that. LWN has the real dirt as usual. -- Physics is like sex. Sure, it may give some practical results, but that's not why we do it. -- Richard Feynman From chicks at chicks.net Sun Oct 24 22:44:44 2004 From: chicks at chicks.net (Christopher Hicks) Date: Sun, 24 Oct 2004 18:44:44 -0400 (EDT) Subject: Firefox not bring up bugzilla.org pages In-Reply-To: <417C2CF4.3000007@mozilla.org> References: <417C2CF4.3000007@mozilla.org> Message-ID: On Mon, 25 Oct 2004, Myk Melez wrote: > Dave'll know, though. Thanks for straightening me out so quickly guys. Now back to trying to get things done! (We ended up with a laptop unexpectedly a week ago and I've been using it to keep hacking while my wife sleeps. This keeps her happy since she has to get up at 6am and she sleeps better when I'm in bed and it keeps me happy because I've got more work than hours in the day. I'm more caught up than I've been in months. And yes its running Linux. Fedora Core 2 recognized everything including the NIC, touchpad, and sound for this laptop without a hitch. Too bad it doesn't have wireless, but that's going to get fixed RSN.) -- Physics is like sex. Sure, it may give some practical results, but that's not why we do it. -- Richard Feynman From gerv at mozilla.org Sun Oct 24 23:18:41 2004 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 25 Oct 2004 00:18:41 +0100 Subject: Doomed Reports? In-Reply-To: <20041022025528.GB30368@www.async.com.br> References: <20041019182437.GA3109@async.com.br> <4176F20C.9000007@mozilla.org> <20041021131542.GA2949@async.com.br> <4178237E.5020807@mozilla.org> <20041022025528.GB30368@www.async.com.br> Message-ID: <417C3851.7020102@mozilla.org> Christian Robottom Reis wrote: > Fair enough. But this means you *do* agree we need a number of pre-set > searches put together in the Reports page to allow people to actually > discover this kind of feature exists, right? I'm not quite sure what you are getting at. Which page, exactly? And how can one make it more obvious that this feature exists than a big link to it on the report summary page, with an explanation of what it does? Gerv From gerv at mozilla.org Mon Oct 25 09:16:36 2004 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 25 Oct 2004 10:16:36 +0100 Subject: Bug suggestions Message-ID: <417CC474.30202@mozilla.org> Guys, I'm about to go travelling for a month, as some of you may have read. I expect to get a fair amount of laptop time in, and am looking for suggestions for self-contained bugs to work on. I plan to have another run at fixing the email preferences system (I did it last Christmas, but the code didn't make it through review). That's bug 70,000-and-something. Please float any other ideas past this list :-) Gerv From bugreport at peshkin.net Mon Oct 25 12:02:44 2004 From: bugreport at peshkin.net (Joel Peshkin) Date: Mon, 25 Oct 2004 05:02:44 -0700 Subject: Bug suggestions In-Reply-To: <417CC474.30202@mozilla.org> References: <417CC474.30202@mozilla.org> Message-ID: <417CEB64.8060003@peshkin.net> Gervase Markham wrote: > Guys, > > > I plan to have another run at fixing the email preferences system (I > did it last Christmas, but the code didn't make it through review). > That's bug 70,000-and-something. Please float any other ideas past > this list :-) > > Gerv > - Component watching From kiko at async.com.br Mon Oct 25 13:27:53 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Mon, 25 Oct 2004 10:27:53 -0300 Subject: Doomed Reports? In-Reply-To: <417C3851.7020102@mozilla.org> References: <20041019182437.GA3109@async.com.br> <4176F20C.9000007@mozilla.org> <20041021131542.GA2949@async.com.br> <4178237E.5020807@mozilla.org> <20041022025528.GB30368@www.async.com.br> <417C3851.7020102@mozilla.org> Message-ID: <20041025132753.GA909@async.com.br> On Mon, Oct 25, 2004 at 12:18:41AM +0100, Gervase Markham wrote: > Christian Robottom Reis wrote: > >Fair enough. But this means you *do* agree we need a number of pre-set > >searches put together in the Reports page to allow people to actually > >discover this kind of feature exists, right? > > I'm not quite sure what you are getting at. Which page, exactly? And how > can one make it more obvious that this feature exists than a big link > to it on the report summary page, with an explanation of what it does? What I'm saying is that we had a one-click (well, few-clicks) way to get a list of bug counts per engineer. Today we need to use an interface which is more than a bit scary, guessing in the process what magical incantations are to be pronounced to obtain this result. I believe that most of the complexity in this task, however, is inherent, and apart from offering a step-based wizard to generate these reports, the only option I see to remove the initial barrier the UI presents is adding some links to common queries to report.cgi (that can also act as a gentle way to show off the really cool reporting we have to the end-user). My suggestion is therefore to remodel "Reporting and Charting Kitchen" into something that is more inductive -- suggesting concrete tasks the user can do instead of offering an array of options that can be confusingly similar (Old Charts? New Charts? Reports? What's the difference?). I think we've got a formidable reporting solution, but I suspect few people know it exists, and less actually manage to use it. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 From travis at SEDSystems.ca Mon Oct 25 16:13:07 2004 From: travis at SEDSystems.ca (Shane H. W. Travis) Date: Mon, 25 Oct 2004 10:13:07 -0600 (CST) Subject: Bug suggestions In-Reply-To: <417CC474.30202@mozilla.org> References: <417CC474.30202@mozilla.org> Message-ID: On Mon, 25 Oct 2004, Gervase Markham wrote: > I plan to have another run at fixing the email preferences system ... > That's bug 70,000-and-something. https://bugzilla.mozilla.org/show_bug.cgi?id=73665 (just in case anyone else wanted to find it) > Please float any other ideas past this list :-) Well, if you're going to be up to your metaphorical armpits in preferences, could you please take a look at: https://bugzilla.mozilla.org/show_bug.cgi?id=98123 please? It had quite a number of dependent bugs that all seem like they would greatly enhance user customisability of Bugzilla, but those can't go ahead properly until this one is solved. Also, this would dovetail nicely with what you're going to be doing *anyway*. I've already got a local patch for id=199048 that I'd be willing to up-rev to the latest version and post... but I had to hack up a one-off, one field 'Local Preferences Page' to make use of it. I'd rather there was a global, bugzilla-centric page I could use on which I could hang this. (I've got a local implementation of a fix for id=11368 as well that I could make public... and that one is also dependent on this bug.) Shane Travis | An efficient and a successful administration travis at sedsystems.ca | manifests itself equally in small as in Saskatoon, Saskatchewan | great matters. -- Winston Churchill From gerv at mozilla.org Mon Oct 25 16:51:00 2004 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 25 Oct 2004 17:51:00 +0100 Subject: Bug suggestions In-Reply-To: <417CEB64.8060003@peshkin.net> References: <417CC474.30202@mozilla.org> <417CEB64.8060003@peshkin.net> Message-ID: <417D2EF4.3080104@mozilla.org> Joel Peshkin wrote: > Component watching Yes :-). All those patches are tied together; I hope to rev all of them, assuming I can keep them separate. (Myk wants to do the email stuff first, so one big patch won't cut it.) Gerv From myk at mozilla.org Mon Oct 25 20:45:57 2004 From: myk at mozilla.org (Myk Melez) Date: Mon, 25 Oct 2004 22:45:57 +0200 Subject: Bug suggestions In-Reply-To: <417CC474.30202@mozilla.org> References: <417CC474.30202@mozilla.org> Message-ID: <417D6605.1050003@mozilla.org> Gervase Markham wrote: > I'm about to go travelling for a month, as some of you may have read. > I expect to get a fair amount of laptop time in, and am looking for > suggestions for self-contained bugs to work on. The line-wrapping bug could really use a fix: https://bugzilla.mozilla.org/show_bug.cgi?id=11901 -myk From dwilliss at microimages.com Mon Oct 25 21:09:47 2004 From: dwilliss at microimages.com (Dave Williss) Date: Mon, 25 Oct 2004 16:09:47 -0500 Subject: custom Bug IDs? Message-ID: <6a0401c4bad6$f6ecfab0$6e00000a@opus> We're considering converting our in-house error database to use Bugzilla. However we have one customization that we'd like to know if it's possible... Our problem IDs are formatted as a three-letter code (the initials of the person reporting the error) followed by a 4 digit sequence number. Is it possible to customize Bugzilla to produce error codes in this way? -- Dave Williss ------ Meddle not in the affairs of dragons, for you are crunchy and taste good with catsup From gerv at mozilla.org Mon Oct 25 21:17:00 2004 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 25 Oct 2004 22:17:00 +0100 Subject: custom Bug IDs? In-Reply-To: <6a0401c4bad6$f6ecfab0$6e00000a@opus> References: <6a0401c4bad6$f6ecfab0$6e00000a@opus> Message-ID: <417D6D4C.8030408@mozilla.org> Dave Williss wrote: > We're considering converting our in-house error database to use > Bugzilla. However we have one customization that we'd like to know if > it's possible... > > Our problem IDs are formatted as a three-letter code (the initials of > the person reporting the error) followed by a 4 digit sequence number. > Is it possible to customize Bugzilla to produce error codes in this way? Not internally. You could approximate it, though. For example, if it's just an in-house database, and people's email addresses are their initials (like at my company) then you could: - Use emailsuffix so that login names were initials - Wherever there's a bug number, print out the filer's login first (i.e. their initials) - Make Bug.pm and other code areas understand the new format - basically, throw away the letters. This would mean that you'd end up with sequence numbers starting at GRM1 rather than GRM0001, and that there would never be two bugs with the same sequence number, and sequence numbers would eventually have more than four digits, but it's fairly close. Gerv From justdave at bugzilla.org Mon Oct 25 21:33:47 2004 From: justdave at bugzilla.org (David Miller) Date: Mon, 25 Oct 2004 17:33:47 -0400 Subject: custom Bug IDs? In-Reply-To: <6a0401c4bad6$f6ecfab0$6e00000a@opus> References: <6a0401c4bad6$f6ecfab0$6e00000a@opus> Message-ID: <417D713B.4070308@bugzilla.org> Dave Williss wrote: > We're considering converting our in-house error database to use > Bugzilla. However we have one customization that we'd like to know if > it's possible... > > Our problem IDs are formatted as a three-letter code (the initials of > the person reporting the error) followed by a 4 digit sequence number. > Is it possible to customize Bugzilla to produce error codes in this way? There's an alias feature that lets you name bugs (as long as it starts with a letter, you can include numbers in it). aliases can be used interchangeably with the bug IDs almost everywhere you can put a bug ID. It probably wouldn't be too hard to hack post_bug.cgi to automatically assign an alias based on your criteria when a new bug is filed. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From gerv at mozilla.org Mon Oct 25 21:42:44 2004 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 25 Oct 2004 22:42:44 +0100 Subject: custom Bug IDs? In-Reply-To: <417D713B.4070308@bugzilla.org> References: <6a0401c4bad6$f6ecfab0$6e00000a@opus> <417D713B.4070308@bugzilla.org> Message-ID: <417D7354.5010208@mozilla.org> David Miller wrote: > There's an alias feature that lets you name bugs (as long as it starts > with a letter, you can include numbers in it). aliases can be used > interchangeably with the bug IDs almost everywhere you can put a bug ID. > It probably wouldn't be too hard to hack post_bug.cgi to automatically > assign an alias based on your criteria when a new bug is filed. Doh! Of course this is the right solution. Ignore what I said :-) You can even write code which mapped email addresses to initials if necessary, and made the numbers increment per-person, and always have four digits etc. Gerv From gerv at mozilla.org Mon Oct 25 22:45:05 2004 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 25 Oct 2004 23:45:05 +0100 Subject: Doomed Reports? In-Reply-To: <20041025132753.GA909@async.com.br> References: <20041019182437.GA3109@async.com.br> <4176F20C.9000007@mozilla.org> <20041021131542.GA2949@async.com.br> <4178237E.5020807@mozilla.org> <20041022025528.GB30368@www.async.com.br> <417C3851.7020102@mozilla.org> <20041025132753.GA909@async.com.br> Message-ID: <417D81F1.5050901@mozilla.org> Christian Robottom Reis wrote: > the only option I see to remove the initial barrier the UI > presents is adding some links to common queries to report.cgi (that can > also act as a gentle way to show off the really cool reporting we have > to the end-user). My suggestion is therefore to remodel "Reporting and > Charting Kitchen" into something that is more inductive -- suggesting > concrete tasks the user can do instead of offering an array of options > that can be confusingly similar (Old Charts? New Charts? Reports? What's > the difference?). I think we've got a formidable reporting solution, but > I suspect few people know it exists, and less actually manage to use it. I'll certainly buy that. We could have some sample reports or charts for each section. File a bug on me, and I'll do it while I'm away :-) Gerv From kiko at async.com.br Tue Oct 26 02:17:54 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Mon, 25 Oct 2004 23:17:54 -0300 Subject: Doomed Reports? In-Reply-To: <417D81F1.5050901@mozilla.org> References: <20041019182437.GA3109@async.com.br> <4176F20C.9000007@mozilla.org> <20041021131542.GA2949@async.com.br> <4178237E.5020807@mozilla.org> <20041022025528.GB30368@www.async.com.br> <417C3851.7020102@mozilla.org> <20041025132753.GA909@async.com.br> <417D81F1.5050901@mozilla.org> Message-ID: <20041026021754.GB24770@www.async.com.br> On Mon, Oct 25, 2004 at 11:45:05PM +0100, Gervase Markham wrote: > >My suggestion is therefore to remodel "Reporting and > >Charting Kitchen" into something that is more inductive -- suggesting > >concrete tasks the user can do instead of offering an array of options > > I'll certainly buy that. We could have some sample reports or charts for > each section. Cool. https://bugzilla.mozilla.org/show_bug.cgi?id=266062 Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 From myk at mozilla.org Tue Oct 26 03:45:57 2004 From: myk at mozilla.org (Myk Melez) Date: Tue, 26 Oct 2004 05:45:57 +0200 Subject: Bug suggestions In-Reply-To: <417D2EF4.3080104@mozilla.org> References: <417CC474.30202@mozilla.org> <417CEB64.8060003@peshkin.net> <417D2EF4.3080104@mozilla.org> Message-ID: <417DC875.8090606@mozilla.org> Gervase Markham wrote: > Joel Peshkin wrote: > >> Component watching > > > Yes :-). All those patches are tied together; I think component watching can actually be implemented much more simply without rewriting email preferences and filtering at all, as useful as those rewrites may be. Component watching would also be well served by inclusions and exclusions lists similar to those used for flag types (but with better worded UI), since such lists make specifying multiple components easier. I've attached a small, simple patch to the component watching bug 76794 with the backend changes for inclusions/exclusions-based component watching. The frontend changes are also relatively simple (trivial, in fact, once the inclusions/exclusions UI is factored out of the flag type code, as I've done in bug 261181, pending review): add inclusions/exclusions list controls to the email preferences page and list processing code to userprefs.cgi. -myk From vladd at bugzilla.org Tue Oct 26 12:33:14 2004 From: vladd at bugzilla.org (Vlad Dascalu) Date: Tue, 26 Oct 2004 15:33:14 +0300 (EEST) Subject: [market analysis] GForge 4.0 released, includes custom fields Message-ID: <4242.217.156.83.1.1098793994.squirrel@www.syndicomm.com> http://gforge.org/forum/forum.php?forum_id=150 GForge 4.0 is finally released at: http://gforge.org/frs/download.php/82/gforge-4.0.tar.bz2 The major changes include: Role-based access controls: Done RBAC unifies all the access information for a project into roles. Each member can be assigned a role, rather than forcing the admin to tediously check all the permissions each user has. Default roles for each project include Admin, Sr Developer, Jr Developer, Doc Writer, and Support Tech. All non-members of the project are controlled by the "Observer" role. (Tim Perdue) cvs-GForge integration (plugin): Done When committing to CVS, you can include Task and Bug IDs in the commit message. GForge then parses these ID's and links your changes into the database so you can see which files were changed to complete a task or fix a bug. (Francisco Gimeno) SCM Refactoring: Done GForge now uses plugins to provide SCM tool integration. We have full plugins for CVS and Subversion and a skeleton plugin for Clear Case. (Roland Mas, Christian Bayle) "Unlimited Fields" in tracker: Done The GForge tracker has the option of adding "unlimited" numbers of additional fields, like Radio Buttons, pop-up boxes, text fields and text areas, for each tracker. (Tony Pugliese, Tim Perdue) Reporting: Done Major cleanup and rewrite of statistics systems. Dozens of pretty graphs and charts in hundreds of combinations. Includes task manager time tracking and reporting. (Tim Perdue) WebDAV: Done The ability to control access to large numbers of DAV directories on a project-by-project basis. Used also to control Subversion-over-DAV. Subversion: Done Francisco Gimeno has updated his mod_auth_gforge module for Apache 2.0 so it works with Subversion. Forum<->email gateway: Done Tim Perdue rewrote Sung Kim's email gateway so the forums can now receive text comments in response to messages instead of forcing users to click a URL to respond. Tracker <-> Email gateway: You can respond to bugs and other tracker items via email, similar to the forum gateway mentioned above. Online Training: Done The GForge Group is offering self-guided online training for GForge 4.0, which covers most if not all features of GForge 4.0. Web Services: Done The GForge Tracker, Task Manager, User and Group API is exposed as a SOAP web service. This code should be considered raw. -- Vlad Dascalu Developer, Bugzilla Bug Tracking System From mkgnu at gmx.net Tue Oct 26 17:13:56 2004 From: mkgnu at gmx.net (Kristis Makris) Date: Tue, 26 Oct 2004 10:13:56 -0700 Subject: [ham] [market analysis] GForge 4.0 released, includes custom In-Reply-To: <4242.217.156.83.1.1098793994.squirrel@www.syndicomm.com> References: <4242.217.156.83.1.1098793994.squirrel@www.syndicomm.com> Message-ID: <1098810836.4862.100.camel@syd.mkgnu.net> > cvs-GForge integration (plugin): Done > When committing to CVS, you can include Task and Bug IDs in the commit > message. GForge then parses these ID's and links your changes into the > database so you can see which files were changed to complete a task or fix > a bug. (Francisco Gimeno) > > SCM Refactoring: Done > GForge now uses plugins to provide SCM tool integration. We have full > plugins for CVS and Subversion and a skeleton plugin for Clear Case. > (Roland Mas, Christian Bayle) Well there goes my evil plan... time to start harassing the GForge guys! From micklweiss at gmx.net Wed Oct 27 18:59:17 2004 From: micklweiss at gmx.net (Mick Weiss) Date: Wed, 27 Oct 2004 14:59:17 -0400 Subject: thanks Message-ID: <417FF005.1030602@gmx.net> I just looked at 2.17.6 (I hadn't used bugzilla in a while, so I'm not sure how new this is), I saw the "Find a Specific Bug". That was really needed. You have no idea how many people came to me all confused that they couldn't use bugzilla because it was too "complicated". That feature really kicks ass. :-) Thanks! - Mick (o> Web / software developer ( ) UNIX Systems Admin --- ~ www.mickweiss.com ~ From gerv at mozilla.org Wed Oct 27 22:56:01 2004 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 27 Oct 2004 23:56:01 +0100 Subject: [market analysis] GForge 4.0 released, includes custom fields In-Reply-To: <4242.217.156.83.1.1098793994.squirrel@www.syndicomm.com> References: <4242.217.156.83.1.1098793994.squirrel@www.syndicomm.com> Message-ID: <41802781.2020105@mozilla.org> Vlad Dascalu wrote: > http://gforge.org/forum/forum.php?forum_id=150 > > GForge 4.0 is finally released at: > > http://gforge.org/frs/download.php/82/gforge-4.0.tar.bz2 That's some pretty stiff competition. It's my view that in order to compete better, the two key areas for focus are our current look (which Kiko is looking at) and our installation process - too many people get caught up in dependency and module version problems, and Bundle::Bugzilla seems to fail more often than it succeeds. Gerv From stu at asyn.com Wed Oct 27 23:56:01 2004 From: stu at asyn.com (Stuart Donaldson) Date: Wed, 27 Oct 2004 16:56:01 -0700 Subject: [market analysis] GForge 4.0 released, includes custom fields In-Reply-To: <41802781.2020105@mozilla.org> References: <4242.217.156.83.1.1098793994.squirrel@www.syndicomm.com> <41802781.2020105@mozilla.org> Message-ID: <41803591.9090303@asyn.com> Gervase Markham wrote: > Vlad Dascalu wrote: > >> http://gforge.org/forum/forum.php?forum_id=150 >> >> GForge 4.0 is finally released at: >> >> http://gforge.org/frs/download.php/82/gforge-4.0.tar.bz2 > > > That's some pretty stiff competition. > > It's my view that in order to compete better, the two key areas for > focus are our current look (which Kiko is looking at) and our > installation process - too many people get caught up in dependency and > module version problems, and Bundle::Bugzilla seems to fail more often > than it succeeds. Well having been interested in gforge for some time, and having tried to install it once before, and then trying again yesterday and running into a bunch of problems, I would say Bugzilla is a hands-down winner on the installation front. Of course one of the reasons I tried to install it was all the features gforge provides, including custom fields. That being said, if they do the work to get the installation process down, it might just be stiffer competition. The other point I would say about Gerv's comments, is that the installation issue is something you have a pain with once, when you do the install. The custom fields issue is a pain every day. -Stuart- From travis at SEDSystems.ca Wed Oct 27 23:50:50 2004 From: travis at SEDSystems.ca (Shane H. W. Travis) Date: Wed, 27 Oct 2004 17:50:50 -0600 (CST) Subject: Calling long_list.cgi from within cgi hangs server Message-ID: I've got a local ISO requirement that we be able to archive bugs once a project is over. They don't have to be removed from the database, but they do have to be stored somewhere else in such a way that they can be read by someone without special software. (Having to re-install a specific version of Bugzilla qualifies as 'special software', so writing a mysqldump of the database, a tarball of the current bugzilla, and the binaries for MySql on a DVD just ain't gonna cut it. Sheesh - the unreasonableness of some people. :) For the bugs themselves, it's 'good enough' if they can be read by a standard browser... so it seemed to me that the output of long_list.cgi (including the local mods we've made to interleave comments with the output of show_activity based on timestamps) would be perfect, and I got them to agree on that too. So far, so good. I can use 'wget' to call long_list.cgi from the command-line with no problems at all. It gives me this sort of output: -------------------- /usr/bin/wget --output-document=/tmp/bug925.html http://fwk-svr.sedsystems.ca/bugzilla/long_list.cgi?buglist=925 --17:24:59-- http://fwk-svr.sedsystems.ca/bugzilla/long_list.cgi?buglist=925 => `/tmp/bug925.html' Resolving fwk-svr.sedsystems.ca... done. Connecting to fwk-svr.sedsystems.ca[192.107.131.54]:80... connected. HTTP request sent, awaiting response... 200 OK Length: 9,815 [text/html] 100%[====================================>] 9,815 9.36M/s ETA 00:00 17:25:01 (9.36 MB/s) - `/tmp/bug925.html' saved [9815/9815] -------------------- The output-document looks good -- looks exactly like it would if I pulled up the page within Bugzilla. That's exactly what I'm after. HOWEVER... If try the exact same command from within a perl script, the whole database hangs. Locked. Dead. Relevant code is: -------------------- my $command = "/usr/bin/wget --output-document=$outfile http://fwk-svr.sedsystems.ca/bugzilla/long_list.cgi?buglist=$id 1>/tmp/program.stdout 2>/tmp/program.stderr"; print (STDOUT "Command = $command

"); trick_taint($command); my $exit_status = system( $command ); print (STDOUT "Exit status 1 = $exit_status

"); -------------------- The output from the first print command looks identical to the command above. The command goes off and tries to execute... but then just never comes back. Furthermore, the database is hooped completely; I can't log into it, bugzilla stops working, etc. Apache is still running, and I can get into another database just fine, but this one is locked down tight. Output of the stderr file shows the following: -------------------- [root at fwk-svr]# cat /tmp/program.stderr [192.107.131.54]:80... connected. HTTP request sent, awaiting response... Read error (Connection timed out) in headers. Retrying. --17:15:12-- http://fwk-svr.sedsystems.ca/bugzilla/long_list.cgi?buglist=925 (try: 2) => `/tmp/bug925.html' Connecting to fwk-svr.sedsystems.ca[192.107.131.54]:80... connected. HTTP request sent, awaiting response... 500 Internal Server Error 17:20:34 ERROR 500: Internal Server Error. -------------------- I've fiddled with everything I can think of to get this to work, and it won't. Once I run the archive perl code, I'm screwed until I shudown mysqld and restart it again. (Screwed for this database anyway; other databases will still work.) I'm wondering if there's some Apache configuration I'm not aware of that I need, or if I'm going about this in entirely the wrong way, or there's a known MySQL bug... or something. Mostly, I'm hoping someone may have run across this or heard of it before, or can offer some suggestions... because I'm out of ideas. MySql = 3.32.54 Bugzilla = 2.16.7 Thanks. Shane Travis | An efficient and a successful administration travis at sedsystems.ca | manifests itself equally in small as in Saskatoon, Saskatchewan | great matters. -- Winston Churchill From dwilliss at microimages.com Fri Oct 29 14:16:57 2004 From: dwilliss at microimages.com (Dave Williss) Date: Fri, 29 Oct 2004 09:16:57 -0500 Subject: CC List Message-ID: <91ba01c4bdc1$f2c68210$6e00000a@opus> We've set up bugzilla on a private network (no access to the internet). We would like to be able to use the CC column to keep track of users who need to be contacted when an error is fixed, but we don't want bugzilla to try to email them itself, since the email can't get there. We just want our Tech Support to be able to keep track of them there and query based on that field. Is there a way to do that? Can I put them all into a group and somehow tell it to never send email to that group? Or do I have to find the bid of code that sends the email an comment it out? -- Dave Williss ------ Meddle not in the affairs of dragons, for you are crunchy and taste good with catsup From dwilliss at microimages.com Fri Oct 29 14:20:13 2004 From: dwilliss at microimages.com (Dave Williss) Date: Fri, 29 Oct 2004 09:20:13 -0500 Subject: Zarro Boogs? Message-ID: <91bd01c4bdc2$79828b00$6e00000a@opus> Were does the Zarro Boogs message come from? I'm told it looks "unprofessional" and I have to change it :-( -- Dave Williss ------ Meddle not in the affairs of dragons, for you are crunchy and taste good with catsup From kiko at async.com.br Fri Oct 29 14:27:44 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Fri, 29 Oct 2004 11:27:44 -0300 Subject: Zarro Boogs? In-Reply-To: <91bd01c4bdc2$79828b00$6e00000a@opus> References: <91bd01c4bdc2$79828b00$6e00000a@opus> Message-ID: <20041029142744.GA18898@www.async.com.br> On Fri, Oct 29, 2004 at 09:20:13AM -0500, Dave Williss wrote: > Were does the Zarro Boogs message come from? I'm told it looks > "unprofessional" and I have to change it :-( It's a FAQ, I believe; it has to do with the fact that no software ever is free of bugs (and your management knows that, right? ) Either tell people to lighten up or fix it in the template. Please don't suggest we make a terms.zarrobugs constant. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 From bugzilla at glob.com.au Fri Oct 29 14:42:03 2004 From: bugzilla at glob.com.au (byron) Date: Fri, 29 Oct 2004 22:42:03 +0800 (WST) Subject: Zarro Boogs? Message-ID: <20041029144203.60CBC4BC878@stutter.bur.st> > Either tell people to lighten up or fix it in the template. Please don't > suggest we make a terms.zarrobugs constant. it already is, terms.zeroSearchResults begin-base64 644 signature.gif R0lGODlhbQAHAIAAAABPo////ywAAAAAbQAHAAACfAxuGAnch+Bibkn7FL1p XgVl4Ig1jjlZRoqybgun2Cur5uOunq7u/Ipq7WIyIc7XG9JquEgumPzdlhTf h0O83kDJaXEm8mRHwXKJy5sac7qYOpT+gtv0n+0ujQOfdqh16caWt0foBViH N1PRMXimiLUGt3ElVimlgbllWAAAOw== ==== From justdave at bugzilla.org Fri Oct 29 15:26:13 2004 From: justdave at bugzilla.org (David Miller) Date: Fri, 29 Oct 2004 11:26:13 -0400 Subject: Zarro Boogs? In-Reply-To: <91bd01c4bdc2$79828b00$6e00000a@opus> References: <91bd01c4bdc2$79828b00$6e00000a@opus> Message-ID: <41826115.6010101@bugzilla.org> Dave Williss wrote: > Were does the Zarro Boogs message come from? I'm told it looks > "unprofessional" and I have to change it :-( templates/en/default/global/variables.none.tmpl that's the zeroSearchResults variable. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From preed at sigkill.com Fri Oct 29 15:54:54 2004 From: preed at sigkill.com (J. Paul Reed) Date: Fri, 29 Oct 2004 08:54:54 -0700 Subject: Zarro Boogs? In-Reply-To: <91bd01c4bdc2$79828b00$6e00000a@opus> References: <91bd01c4bdc2$79828b00$6e00000a@opus> Message-ID: <20041029155454.GA1467@sigkill.com> On 29 Oct 2004 at 09:20:13, Dave Williss arranged the bits on my disk to say: > Were does the Zarro Boogs message come from? I don't know if you are asking about the template or the history; you have an answer to the former. The term itself is... a choffman-ism, I believe; it conveys the idea that no software that ever ships has "zero bugs"; but, we make engineering tradeoffs about what we'll fix, what we'll work around, and what we'll ignore. Eventually we get to a state of code that can be released... and that state doesn't have "zero bugs," but "Zarro Boogs." This is, at least, the explanation I remember when I started working on BZ in 1998. Later, Paul ------------------------------------------------------------------------ J. Paul Reed -- 0xDF8708F8 || preed at sigkill.com || web.sigkill.com/preed Math, my dear boy, is nothing more than the lesbian sister of biology. -- Peter Griffin, Family Guy I use PGP; you should use PGP too... if only to piss off John Ashcroft From travis at SEDSystems.ca Fri Oct 29 15:53:49 2004 From: travis at SEDSystems.ca (Shane H. W. Travis) Date: Fri, 29 Oct 2004 09:53:49 -0600 (CST) Subject: CC List In-Reply-To: <91ba01c4bdc1$f2c68210$6e00000a@opus> References: <91ba01c4bdc1$f2c68210$6e00000a@opus> Message-ID: On Fri, 29 Oct 2004, Dave Williss wrote: > We've set up bugzilla on a private network (no access to the internet). > We would like to be able to use the CC column to keep track of users who > need to be contacted when an error is fixed, but we don't want bugzilla to > try to email them itself, since the email can't get there. We just want our > Tech Support to be able to keep track of them there and query based on that > field. Is it imperative that it be in the cc: field? And if so, why? It sounds like this is something that would fit really well on one of the existing text lines -- either URL or Status Whiteboard. If you don't use either of those fields (we don't, locally) then just edit the template for that field to read 'Notification on complete:' (or whatever), update your internal documentation (so you have a record of why the 'bug_file_loc' field now contains e-mails) and just start using it. Perhaps not quite as elegant, but a *whole* lot less work, and a lot easier to maintain over an upgrade (which is becoming increasingly important to me, as Bugzilla moves to more timely releases). (If it just *has* to be the cc: field or nothing, then sorry but I can't help you much... I try and stay away from that section as much as possible.) Shane Travis | An efficient and a successful administration travis at sedsystems.ca | manifests itself equally in small as in Saskatoon, Saskatchewan | great matters. -- Winston Churchill