From Nick.Barnes at pobox.com Fri Apr 1 13:55:46 2005 From: Nick.Barnes at pobox.com (Nick Barnes) Date: Fri, 01 Apr 2005 14:55:46 +0100 Subject: Stalled custom field development In-Reply-To: <424C6779.4030209@peshkin.net> from Joel Peshkin of "Thu, 31 Mar 2005 13:11:21 -0800" Message-ID: <8929.1112363746@thrush.ravenbrook.com> At 2005-03-31 21:11:21+0000, Joel Peshkin writes: > Christopher Hicks wrote: > > > On Wed, 30 Mar 2005, Joel Peshkin wrote: > > > >> Actually, it is not paralyzed at all unless someone is foolish enough > >> to try to do the whole thing in one huge patch that will never land. > > > > > > When somebody has an existing working implementation it doesn't seem > > at all foolish to wish that it could land. > > > The problem is that the existing implementation was incomplete and then > effectively abandoned when the data storage schema debate began. I think this may be at cross-purposes. Sean has an "existing implementation", which he was posting in parts to this list, for discussion, which led to the (restart of the) FAC/FAD schema debates. I imagine that Christopher Hicks is referring to Sean's implementation (certainly it's what I have been referring to in messages with a similar sentiment a couple of months ago). Whereas I assume you are referring to the patches on 91037. AFAIR that bug had good patches for 2.14.* and 2.16.*. It appears to have recently acquired a full patch for 2.18. As you point out, the right approach is to break 91037 down into a panoply of smaller bugs, as mkanat has started to do. But hardly any of these smaller bugs can get fixed until we have a decision on the underlying schema design. I favour Sean's design because he has a working deployed implementation of significant size. Within a week or two of getting a schema design decision, I expect we can get a patch landed for the totally basic first step towards custom fields (I outlined before that my idea for this first incremental step is a single plain-text field, applicable to all bugs, without any layout magic, and which can only be created or customized by hacking SQL directly). Nick B From bugreport at peshkin.net Fri Apr 1 14:35:41 2005 From: bugreport at peshkin.net (Joel Peshkin) Date: Fri, 01 Apr 2005 06:35:41 -0800 Subject: Stalled custom field development In-Reply-To: <8929.1112363746@thrush.ravenbrook.com> References: <8929.1112363746@thrush.ravenbrook.com> Message-ID: <424D5C3D.70501@peshkin.net> Nick Barnes wrote: >I think this may be at cross-purposes. Sean has an "existing >implementation", which he was posting in parts to this list, for >discussion, which led to the (restart of the) FAC/FAD schema debates. >I imagine that Christopher Hicks is referring to Sean's implementation >(certainly it's what I have been referring to in messages with a >similar sentiment a couple of months ago). > >Whereas I assume you are referring to the patches on 91037. AFAIR >that bug had good patches for 2.14.* and 2.16.*. It appears to have >recently acquired a full patch for 2.18. > > > While a patch for 2.18 is handy for the group of people using the patch in the unlanded state, the only path that works to land a patch is to do it against the tip of cvs and to do it in a manner that actually passes muster in terms of the implementation. For example, it must work with Search and not make a terrible mess of it. I have not seen a patch come for review that does that. Since I am one of the very few reviewers who does review monster patches and I assure you that I will review anything that touches Search or security, that does matter. Notice that I didn't say anything about FAC vs FAD. Personally, I am happy with either. >As you point out, the right approach is to break 91037 down into a >panoply of smaller bugs, as mkanat has started to do. But hardly any >of these smaller bugs can get fixed until we have a decision on the >underlying schema design. > That is where we disagree. Getting the code to "just work" with whatever fields are described by fielddefs is a very distinct item not blocked by the decision. > I favour Sean's design because he has a >working deployed implementation of significant size. > > > I'm happy with either one. What I don't want to have happen is that we go to all of the work of reviewing and testing a patch just to find out that myk cannot live with it because of performance concerns for bmo. That would keep it from landing. >Within a week or two of getting a schema design decision, I expect we >can get a patch landed for the totally basic first step towards custom >fields (I outlined before that my idea for this first incremental step >is a single plain-text field, applicable to all bugs, without any >layout magic, and which can only be created or customized by hacking >SQL directly). > > We almost agree here. The place I stand is that I think we should change the existing code to eliminate the hard-coded fieldlists first and then use that mechanism to add custom fields. The patches I have examined to date add a new mechanism that is 90% redundant with fielddefs and have a chunk of code after each of the hardcoded loops that then add in a special case for the custom fields. Redundant stuff is just a way to create additonal bugs. If you can accept that point, then the difference in our positions is that you want to immediately add the first new field (and need a schema decision to do that) and I want to have the first step involve no bug schema change. I would really like to have a customfields implementation land. mkanat and I will work on this as time permits. It won't take a week or two. It will probably take a few months if the interested paries quit complaining that justdave hasn't made a ruling on the schema and join in on the work. It will take more like 9-12 months in mkanat and I have to do these ourselves. -Joel From stu at asyn.com Fri Apr 1 14:54:10 2005 From: stu at asyn.com (Stuart Donaldson) Date: Fri, 01 Apr 2005 06:54:10 -0800 Subject: Stalled custom field development In-Reply-To: <8929.1112363746@thrush.ravenbrook.com> References: <8929.1112363746@thrush.ravenbrook.com> Message-ID: <424D6092.4030004@asyn.com> >>Actually, it is not paralyzed at all unless someone is foolish enough >>to try to do the whole thing in one huge patch that will never land. >> >> >When somebody has an existing working implementation it doesn't seem >at all foolish to wish that it could land. > > Here is a bit of an oversimplified view, but too much stagnation often calls for drastic action. Ya know if the proposal from Sean had landed several months back when he proposed it, you would have many many happy users of Bugzilla out there with a working custom fields implementation. Then even if you found the schema to be needing change, you could put all the work that is now being called for into Fielddefs and then change the schema later. The biggest downside is that it makes the upgrade script from the original custom fields schema a little more complex, but at least you would have custom fields, and happy users, and less squabbling, and Bugzilla development would gain some much needed respect. From bugreport at peshkin.net Fri Apr 1 16:00:24 2005 From: bugreport at peshkin.net (Joel Peshkin) Date: Fri, 01 Apr 2005 08:00:24 -0800 Subject: Stalled custom field development In-Reply-To: <424D6092.4030004@asyn.com> References: <8929.1112363746@thrush.ravenbrook.com> <424D6092.4030004@asyn.com> Message-ID: <424D7018.8050202@peshkin.net> Stuart Donaldson wrote: > > Ya know if the proposal from Sean had landed several months back when > he proposed it, you would have many many happy users of Bugzilla out > there with a working custom fields implementation. Unfortunately, nobody has ever submitted a patch for review in a state to land. That is the real issue. I am sure that there are many people who would love to have custom fields. What we need is someone to do the real work of implementing, testing, fixing, and reviewing the patches. So far, NOBODY has stepped up to the plate to do that. We can't land a "proposal" nor can we land a patch against 2.18. If we actually had a candidate to review, then we could establish if the patch makes a big mess or not. Speaking as someone who has landed multiple MAJOR changes successfully and as the person who has reviewed a huge number of the database independence code [Stuart - how much have you reviewed??], my advice is unchanged. Do not attempt to land a mega-patch when a step-by-step approach will work. Since it is almost as much work to review a patch as it is to write it, I am beginning to feel a lot like the little red hen here. If you want to help out, help out. Just whining about the feature not being done does not really help at all. -Joel From altlst at sonic.net Fri Apr 1 20:04:16 2005 From: altlst at sonic.net (Albert Ting) Date: Fri, 1 Apr 2005 12:04:16 -0800 Subject: arrays in FORM Message-ID: <16973.43328.853561.610756@gargle.gargle.HOWL> If I have something like below in a template: 1 2 3 4 Is there a way to get the data back as an array, something like: @{$::FORM{'choices'}} Best I can tell, FORM only holds strings. Thanks, Albert From jake at bugzilla.org Fri Apr 1 20:18:51 2005 From: jake at bugzilla.org (Jake) Date: Fri, 01 Apr 2005 15:18:51 -0500 Subject: arrays in FORM In-Reply-To: <16973.43328.853561.610756@gargle.gargle.HOWL> References: <16973.43328.853561.610756@gargle.gargle.HOWL> Message-ID: <424DACAB.8070907@bugzilla.org> You should be using the $cgi stuff right now in Bugzilla, though I'm not an expert at that to say for sure how to do it. As I recall, there's an MFORM variable that has arrays when there are multiple choices. Albert Ting wrote: >If I have something like below in a template: > > 1 > 2 > 3 > 4 > >Is there a way to get the data back as an array, something like: > > @{$::FORM{'choices'}} > >Best I can tell, FORM only holds strings. > >Thanks, >Albert >- >To view or change your list settings, click here: > > > From mkanat at bugzilla.org Fri Apr 1 00:05:56 2005 From: mkanat at bugzilla.org (Maxwell Kanat-Alexander) Date: Thu, 31 Mar 2005 16:05:56 -0800 Subject: Stalled custom field development In-Reply-To: References: <20050330084230.A5513C3DD@mail.schwag.org> <424B719B.2000709@letterboxes.org> <424B869B.2000301@peshkin.net> Message-ID: <1112313956.8915.6.camel@localhost.localdomain> On Thu, 2005-03-31 at 14:11 -0500, Christopher Hicks wrote: > The official process of small > patches seems to be sort of like the Hippocratic Oath for software. > While this is an admirable thought, part of the beauty of software is > being able to break it and fix what doesn't work. (1) That's what we did for 2.18, and look how long it took us. (2) I don't know if you've looked at the basics of Sean's patch, but it *replaces* Search.pm with a brand-new module. That's not an acceptable change for a single patch. :-) The best way to have bad code in Bugzilla that stays around for a long time is to check in large patches. We *can* have Custom Fields for 2.22, and I'm planning on it. We just need somebody to start now working on the blockers that I've posted, nearly all of which can be worked on now. -Max From mkanat at bugzilla.org Fri Apr 1 00:06:06 2005 From: mkanat at bugzilla.org (Maxwell Kanat-Alexander) Date: Thu, 31 Mar 2005 16:06:06 -0800 Subject: Stalled custom field development In-Reply-To: <424C6779.4030209@peshkin.net> References: <20050330084230.A5513C3DD@mail.schwag.org> <424B719B.2000709@letterboxes.org> <424B869B.2000301@peshkin.net> <424C6779.4030209@peshkin.net> Message-ID: <1112313967.8915.7.camel@localhost.localdomain> On Thu, 2005-03-31 at 13:11 -0800, Joel Peshkin wrote: > The team working on database-independence went through a similar > evolution. Same thing with MTAConfig, too. We debated it for four years, and then one day I split up the bug and we had Mail::Mailer support checked-in a week or two from then. -Max From justdave at bugzilla.org Fri Apr 1 20:34:58 2005 From: justdave at bugzilla.org (David Miller) Date: Fri, 01 Apr 2005 12:34:58 -0800 Subject: arrays in FORM In-Reply-To: <16973.43328.853561.610756@gargle.gargle.HOWL> References: <16973.43328.853561.610756@gargle.gargle.HOWL> Message-ID: <424DB072.7060804@bugzilla.org> Albert Ting wrote: > If I have something like below in a template: > > 1 > 2 > 3 > 4 > > Is there a way to get the data back as an array, something like: > > @{$::FORM{'choices'}} > > Best I can tell, FORM only holds strings. $::FORM is deprecated and getting removed (and will probably actually be gone in 2.20 if we get lucky). Don't use it unless you have an old enough version of Bugzilla that doesn't have Bugzilla->cgi available. If you have that old of a Bugzilla, then %FORM holds single strings, which anything that passed multiple values concatenated together. %MFORM contains arrays of all of the values for anything that passed multiple. If you have Bugzilla->cgi available, you can get multiple values with something like my @array = Bugzilla->cgi->param('paramname'); You can of course do: my $cgi = Bugzilla->cgi; first and then use $cgi if you want (if the file you're working in doesn't already do that). -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Foundation http://www.mozilla.org/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From altlst at sonic.net Fri Apr 1 22:23:27 2005 From: altlst at sonic.net (Albert Ting) Date: Fri, 1 Apr 2005 14:23:27 -0800 Subject: arrays in FORM In-Reply-To: <424DB072.7060804@bugzilla.org> References: <16973.43328.853561.610756@gargle.gargle.HOWL> <424DB072.7060804@bugzilla.org> Message-ID: <16973.51679.538258.436526@gargle.gargle.HOWL> Thanks for the tip. I've updated my patch accordingly. This is regarding feature #283695, where one can permanently highlight/mark individual bug comments. David Miller writes: > From: David Miller > To: developers at bugzilla.org > Subject: Re: arrays in FORM > Date: Fri, 01 Apr 2005 12:34:58 -0800 > > Albert Ting wrote: > > If I have something like below in a template: > > > > 1 > > 2 > > 3 > > 4 > > > > Is there a way to get the data back as an array, something like: > > > > @{$::FORM{'choices'}} > > > > Best I can tell, FORM only holds strings. > > $::FORM is deprecated and getting removed (and will probably actually be > gone in 2.20 if we get lucky). Don't use it unless you have an old > enough version of Bugzilla that doesn't have Bugzilla->cgi available. > > If you have that old of a Bugzilla, then %FORM holds single strings, > which anything that passed multiple values concatenated together. > %MFORM contains arrays of all of the values for anything that passed > multiple. > > If you have Bugzilla->cgi available, you can get multiple values with > something like > > my @array = Bugzilla->cgi->param('paramname'); > > You can of course do: > > my $cgi = Bugzilla->cgi; > > first and then use $cgi if you want (if the file you're working in > doesn't already do that). > From mkanat at bugzilla.org Sat Apr 2 08:34:46 2005 From: mkanat at bugzilla.org (Maxwell Kanat-Alexander) Date: Sat, 02 Apr 2005 00:34:46 -0800 Subject: Values of Custom Fields and Referential Integrity Message-ID: <1112430886.15080.16.camel@localhost.localdomain> Myk pointed out to me that if we have one table that contains all the values for each custom field, it will be impossible to have real referential integrity in the database backend from columns in the bugs table to the legal values for that column. So, at least for the field values, it could be a good idea to have the values placed into a structured set of tables, that have a standardized format and naming scheme. That is, one table per custom "select" field. Disclaimer: This implies no other position on how anything else for custom fields should be done. :-) I'll have some idea of what to do about that when I get there (or I'm sure somebody else will have an idea when they get there). -Max From gerv at mozilla.org Mon Apr 4 08:54:04 2005 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 04 Apr 2005 09:54:04 +0100 Subject: Should we remove ability to turn on user and bug deletion? Message-ID: <425100AC.2020900@mozilla.org> The newsgroups are filled with people who have turned on user and bug deletion, despite the warnings, and got into difficulty. I say we should remove the Params, and tell people it's not supported, until such time as someone implements it properly. What do you think? Gerv From LpSolit at gmail.com Mon Apr 4 09:25:58 2005 From: LpSolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Mon, 04 Apr 2005 11:25:58 +0200 Subject: Should we remove ability to turn on user and bug deletion? In-Reply-To: <425100AC.2020900@mozilla.org> References: <425100AC.2020900@mozilla.org> Message-ID: <42510826.10709@gmail.com> Gervase Markham a ?crit : > The newsgroups are filled with people who have turned on user and bug > deletion, despite the warnings, and got into difficulty. I say we should > remove the Params, and tell people it's not supported, until such time > as someone implements it properly. > > What do you think? I think that it will be correctly implemented in the very near future, see bugs 86328 and 288461. I have submitted a patch for each of these two bugs and now bug deletion is really clean. These patches are awaiting review but I think they could be checked in this week already. So please do not remove the bug deletion feature! Fr?d?ric (LpSolit) From gerv at mozilla.org Mon Apr 4 16:37:55 2005 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 04 Apr 2005 17:37:55 +0100 Subject: Should we remove ability to turn on user and bug deletion? In-Reply-To: <42510826.10709@gmail.com> References: <425100AC.2020900@mozilla.org> <42510826.10709@gmail.com> Message-ID: <42516D63.2020405@mozilla.org> Fr?d?ric Buclin wrote: > I think that it will be correctly implemented in the very near future, > see bugs 86328 and 288461. I have submitted a patch for each of these > two bugs and now bug deletion is really clean. These patches are > awaiting review but I think they could be checked in this week already. > > So please do not remove the bug deletion feature! Fair enough :-) Should we beef up the "you really don't want to do this" warning on editparams.cgi on the 2.18 branch? Gerv From wurblzap at gmail.com Mon Apr 4 17:04:38 2005 From: wurblzap at gmail.com (Marc Schumann) Date: Mon, 4 Apr 2005 19:04:38 +0200 Subject: Should we remove ability to turn on user and bug deletion? In-Reply-To: <425100AC.2020900@mozilla.org> References: <425100AC.2020900@mozilla.org> Message-ID: On Apr 4, 2005 10:54 AM, Gervase Markham wrote: > The newsgroups are filled with people who have turned on user and bug > deletion, despite the warnings, and got into difficulty. I say we should > remove the Params, and tell people it's not supported, until such time > as someone implements it properly. > > What do you think? User deletion has improved a lot with bug 119485. On user deletion, the admin is presented with individual, detailed warnings. Short of deleting bugs, related entities are deleted along with the user. Leaving the bugs undeleted will cause db inconsistency when overriding the corresponding warning. Maybe it's an idea to go for the never-inconsistencies way, but I don't think this warrants to make user deletion impossible. Marc -- http://wurblzap.net/ Bugzilla hosting and professional support From kevin.benton at amd.com Mon Apr 4 19:18:58 2005 From: kevin.benton at amd.com (Benton, Kevin) Date: Mon, 4 Apr 2005 12:18:58 -0700 Subject: Should we remove ability to turn on user and bug deletion? Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A42A09AC0@ssvlexmb2.amd.com> > -----Original Message----- > From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] > On Behalf Of Marc Schumann > Sent: Monday, April 04, 2005 11:05 AM > To: developers at bugzilla.org > Subject: Re: Should we remove ability to turn on user and bug deletion? > > On Apr 4, 2005 10:54 AM, Gervase Markham wrote: > > The newsgroups are filled with people who have turned on user and bug > > deletion, despite the warnings, and got into difficulty. I say we should > > remove the Params, and tell people it's not supported, until such time > > as someone implements it properly. > > > > What do you think? > > User deletion has improved a lot with bug 119485. On user deletion, > the admin is presented with individual, detailed warnings. Short of > deleting bugs, related entities are deleted along with the user. > Leaving the bugs undeleted will cause db inconsistency when overriding > the corresponding warning. Maybe it's an idea to go for the > never-inconsistencies way, but I don't think this warrants to make > user deletion impossible. As a Bugzilla Administrator, it seems like a lot of work at this point to perform deletions of users if that user has had much activity in the system at all. If the user is an assigned-to person, has commented on bugs, has created activity log entries, attachments, etc., there's a lot to deleting that user without creating referential problems. On the other hand, if we have a "deleted" flag, it would be relatively easy to handle clean-up because the user should no longer have access to the web or email interfaces, and there's no need to handle activity log entries in a special manner because they're still stored in the database. In the event a system admin decides they made a mistake, no data has been lost, they can simply turn the user back on. In my mind, a user flagged as deleted would no longer show up in user lists, hyperlinks to them would be disabled, and the only way to gain access to those users would be to request to include a listing of deleted users from the user administration menu, and of course, from MySQL directly. As a Bugzilla programmer, it makes a lot of sense to me to give the ability to "permanently and completely disable a user" without having to remove them from the DB. I believe it would be extremely rare when administrators would actually want to physically remove "old users" from the system short of running out of disk space or the user table gets "too big." In those cases, I think we need to come up with a way to set up a default user that all entries can be reassigned to in the event that a user deletion is required. If not a default user, then I feel we should give the person performing the deletion the opportunity to pick a person or assign the bugs back to the person doing the deletion. In those cases, a set of updates could be written to update all the user id foreign keys changing any instance of the user being deleted to the appropriate user id. By doing this, we haven't thrown out any historical information, and we can now completely remove the user from the system without breaking any references. It also makes querying the database relatively easy, giving the administrator immediate access to any bugs that need to be reassigned after the user has been removed. Another benefit of this auto-reassignment method is that it makes it easier to back-out any changes made by a real user deletion. All the changes made to bugs and other foreign keys containing that user's id can be reverted because the listing of those changes should be available in a query. --- Kevin Benton Perl/Bugzilla Developer Advanced Micro Devices The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. From Toomas.Toomsalu at PerSimplex.com Tue Apr 5 09:41:34 2005 From: Toomas.Toomsalu at PerSimplex.com (Toomas Toomsalu) Date: Tue, 5 Apr 2005 12:41:34 +0300 Subject: Should we remove ability to turn on user and bug deletion? Message-ID: My experience as administrator and developer of the enterprise business systems supports Kevin's point that a deletion record from interrelated database is complicated process that will create referential integrity problems. Instead of deletion of record (user, customer, work order) we introduced Active flag that can be turned off if there are related records (like bugs related to user in Bugzilla) If there is2 step deletion: -----Original Message----- From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] On Behalf Of Benton, Kevin Sent: Monday, April 04, 2005 10:19 PM To: developers at bugzilla.org Subject: Re: Should we remove ability to turn on user and bug deletion? > -----Original Message----- > From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] > On Behalf Of Marc Schumann > Sent: Monday, April 04, 2005 11:05 AM > To: developers at bugzilla.org > Subject: Re: Should we remove ability to turn on user and bug deletion? > > On Apr 4, 2005 10:54 AM, Gervase Markham wrote: > > The newsgroups are filled with people who have turned on user and bug > > deletion, despite the warnings, and got into difficulty. I say we should > > remove the Params, and tell people it's not supported, until such time > > as someone implements it properly. > > > > What do you think? > > User deletion has improved a lot with bug 119485. On user deletion, > the admin is presented with individual, detailed warnings. Short of > deleting bugs, related entities are deleted along with the user. > Leaving the bugs undeleted will cause db inconsistency when overriding > the corresponding warning. Maybe it's an idea to go for the > never-inconsistencies way, but I don't think this warrants to make > user deletion impossible. As a Bugzilla Administrator, it seems like a lot of work at this point to perform deletions of users if that user has had much activity in the system at all. If the user is an assigned-to person, has commented on bugs, has created activity log entries, attachments, etc., there's a lot to deleting that user without creating referential problems. On the other hand, if we have a "deleted" flag, it would be relatively easy to handle clean-up because the user should no longer have access to the web or email interfaces, and there's no need to handle activity log entries in a special manner because they're still stored in the database. In the event a system admin decides they made a mistake, no data has been lost, they can simply turn the user back on. In my mind, a user flagged as deleted would no longer show up in user lists, hyperlinks to them would be disabled, and the only way to gain access to those users would be to request to include a listing of deleted users from the user administration menu, and of course, from MySQL directly. As a Bugzilla programmer, it makes a lot of sense to me to give the ability to "permanently and completely disable a user" without having to remove them from the DB. I believe it would be extremely rare when administrators would actually want to physically remove "old users" from the system short of running out of disk space or the user table gets "too big." In those cases, I think we need to come up with a way to set up a default user that all entries can be reassigned to in the event that a user deletion is required. If not a default user, then I feel we should give the person performing the deletion the opportunity to pick a person or assign the bugs back to the person doing the deletion. In those cases, a set of updates could be written to update all the user id foreign keys changing any instance of the user being deleted to the appropriate user id. By doing this, we haven't thrown out any historical information, and we can now completely remove the user from the system without breaking any references. It also makes querying the database relatively easy, giving the administrator immediate access to any bugs that need to be reassigned after the user has been removed. Another benefit of this auto-reassignment method is that it makes it easier to back-out any changes made by a real user deletion. All the changes made to bugs and other foreign keys containing that user's id can be reverted because the listing of those changes should be available in a query. --- Kevin Benton Perl/Bugzilla Developer Advanced Micro Devices The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. - To view or change your list settings, click here: -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.benton at AMD.COM Tue Apr 5 15:45:40 2005 From: kevin.benton at AMD.COM (Benton, Kevin) Date: Tue, 5 Apr 2005 08:45:40 -0700 Subject: Should we remove ability to turn on user and bug deletion? Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A42A09B85@ssvlexmb2.amd.com> I should add that I do not see a user deletion flag as being the same as a user deleted flag. Users that are disabled are just that - disabled. No changes in the system need to be made for disabled users. Disabled users don't show up in drop-down lists, however, they can still own bugs (yuck). A company's security policy may require that a user is disabled while they're on vacation or some other kind of leave of absence. --- Kevin Benton Perl/Bugzilla Developer Advanced Micro Devices The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. > -----Original Message----- > From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] > On Behalf Of Benton, Kevin > Sent: Monday, April 04, 2005 1:19 PM > To: developers at bugzilla.org > Subject: Re: Should we remove ability to turn on user and bug deletion? > > > -----Original Message----- > > From: developers-owner at bugzilla.org > [mailto:developers-owner at bugzilla.org] > > On Behalf Of Marc Schumann > > Sent: Monday, April 04, 2005 11:05 AM > > To: developers at bugzilla.org > > Subject: Re: Should we remove ability to turn on user and bug > deletion? > > > > On Apr 4, 2005 10:54 AM, Gervase Markham wrote: > > > The newsgroups are filled with people who have turned on user and > bug > > > deletion, despite the warnings, and got into difficulty. I say we > should > > > remove the Params, and tell people it's not supported, until such > time > > > as someone implements it properly. > > > > > > What do you think? > > > > User deletion has improved a lot with bug 119485. On user deletion, > > the admin is presented with individual, detailed warnings. Short of > > deleting bugs, related entities are deleted along with the user. > > Leaving the bugs undeleted will cause db inconsistency when overriding > > the corresponding warning. Maybe it's an idea to go for the > > never-inconsistencies way, but I don't think this warrants to make > > user deletion impossible. > > As a Bugzilla Administrator, it seems like a lot of work at this point > to perform deletions of users if that user has had much activity in the > system at all. If the user is an assigned-to person, has commented on > bugs, has created activity log entries, attachments, etc., there's a lot > to deleting that user without creating referential problems. On the > other hand, if we have a "deleted" flag, it would be relatively easy to > handle clean-up because the user should no longer have access to the web > or email interfaces, and there's no need to handle activity log entries > in a special manner because they're still stored in the database. In > the event a system admin decides they made a mistake, no data has been > lost, they can simply turn the user back on. In my mind, a user flagged > as deleted would no longer show up in user lists, hyperlinks to them > would be disabled, and the only way to gain access to those users would > be to request to include a listing of deleted users from the user > administration menu, and of course, from MySQL directly. > > As a Bugzilla programmer, it makes a lot of sense to me to give the > ability to "permanently and completely disable a user" without having to > remove them from the DB. I believe it would be extremely rare when > administrators would actually want to physically remove "old users" from > the system short of running out of disk space or the user table gets > "too big." In those cases, I think we need to come up with a way to set > up a default user that all entries can be reassigned to in the event > that a user deletion is required. If not a default user, then I feel we > should give the person performing the deletion the opportunity to pick a > person or assign the bugs back to the person doing the deletion. In > those cases, a set of updates could be written to update all the user id > foreign keys changing any instance of the user being deleted to the > appropriate user id. By doing this, we haven't thrown out any > historical information, and we can now completely remove the user from > the system without breaking any references. It also makes querying the > database relatively easy, giving the administrator immediate access to > any bugs that need to be reassigned after the user has been removed. > > Another benefit of this auto-reassignment method is that it makes it > easier to back-out any changes made by a real user deletion. All the > changes made to bugs and other foreign keys containing that user's id > can be reverted because the listing of those changes should be available > in a query. > > --- > Kevin Benton > Perl/Bugzilla Developer > Advanced Micro Devices > > The opinions stated in this communication do not necessarily reflect the > view of Advanced Micro Devices and have not been reviewed by management. > This communication may contain sensitive and/or confidential and/or > proprietary information. Distribution of such information is strictly > prohibited without prior consent of Advanced Micro Devices. This > communication is for the intended recipient(s) only. If you have > received this communication in error, please notify the sender, then > destroy any remaining copies of this communication. > > > > - > To view or change your list settings, click here: > From dwilliss at microimages.com Tue Apr 5 15:52:35 2005 From: dwilliss at microimages.com (Dave Williss) Date: Tue, 5 Apr 2005 10:52:35 -0500 Subject: Should we remove ability to turn on user and bug deletion? References: <425100AC.2020900@mozilla.org> <42510826.10709@gmail.com> <42516D63.2020405@mozilla.org> Message-ID: <2ad201c539f7$7cadd6c0$4b00000a@opus2> ----- Original Message ----- From: "Gervase Markham" To: Sent: Monday, April 04, 2005 11:37 AM Subject: Re: Should we remove ability to turn on user and bug deletion? > Fr?d?ric Buclin wrote: >> I think that it will be correctly implemented in the very near future, >> see bugs 86328 and 288461. I have submitted a patch for each of these two >> bugs and now bug deletion is really clean. These patches are awaiting >> review but I think they could be checked in this week already. >> >> So please do not remove the bug deletion feature! > > Fair enough :-) > > Should we beef up the "you really don't want to do this" warning on > editparams.cgi on the 2.18 branch? > Deleting bugs should be OK, given proper warnings and if bugzilla can resolve dependency lists. We occasionally want to delete bugs which are duplicates (rather than just marking them as such). The occasional silly bug needs to be deleted from time to time too. I once had a couple high-priority bugs that I couldn't get to because another programmer who's help I required was too busy on a higher priority task. I logged those bugs as depending on a new bug who's subject was something like "Steve is too busy working on ... to help me". Steve was amused but the head programmer was not :-) Deleting users is, IMHO, a Bad Thing. We have users in our bugzilla database who were "former users" long before we converted everything over to bugzilla. The system records who logged that error and we want to keep that history. For users who left after implementing bugzilla, we want to keep all their comments, attachments, etc. What we WOULD like is an easy way to disable a user that would reassign anything that they're assigned, disable their email notifications, etc. I wrote a custom script to do this when we had a programmer quit a couple months ago. It reassigned all his Assigned To items back to the default assignee or the component and any items for which he as the QA contact went back to the default QA contact for the component. From altlst at sonic.net Tue Apr 5 17:28:30 2005 From: altlst at sonic.net (Albert Ting) Date: Tue, 5 Apr 2005 10:28:30 -0700 Subject: Should we remove ability to turn on user and bug deletion? In-Reply-To: <2ad201c539f7$7cadd6c0$4b00000a@opus2> References: <425100AC.2020900@mozilla.org> <42510826.10709@gmail.com> <42516D63.2020405@mozilla.org> <2ad201c539f7$7cadd6c0$4b00000a@opus2> Message-ID: <16978.51902.651153.689249@gargle.gargle.HOWL> > Deleting users is, IMHO, a Bad Thing. We have users in our bugzilla > database who were "former users" long before we converted everything > over to bugzilla. The system records who logged that error and we > want to keep that history. For users who left after implementing > bugzilla, we want to keep all their comments, attachments, etc. I have had to use the "delete users" feature quite a bit this past month. Or rather, I'd would love to see a "merge user" feature, combined with maybe an "user alias" feature. My company got merged and they're busily migration all the old email addresses to the new format. So I currently have 3 email addresses, all funneled into a single account. A lot of the employees got confused and ended up creating 3 bugzilla accounts. I had to disable new account creation, merge the 3 accounts into a single userid, and update all the sql tables accordingly. And since the 3 email addresses will be around for a while, I plan to create a lookup table to find the one email address bugzilla recognizes. This will be required to get bugzilla_email_append.pl working cleanly. From bugreport at peshkin.net Tue Apr 5 17:40:41 2005 From: bugreport at peshkin.net (Joel Peshkin) Date: Tue, 05 Apr 2005 10:40:41 -0700 Subject: Should we remove ability to turn on user and bug deletion? In-Reply-To: <16978.51902.651153.689249@gargle.gargle.HOWL> References: <425100AC.2020900@mozilla.org> <42510826.10709@gmail.com> <42516D63.2020405@mozilla.org> <2ad201c539f7$7cadd6c0$4b00000a@opus2> <16978.51902.651153.689249@gargle.gargle.HOWL> Message-ID: <4252CD99.5080107@peshkin.net> Albert Ting wrote: >I have had to use the "delete users" feature quite a bit this past month. >Or rather, I'd would love to see a "merge user" feature, combined with >maybe an "user alias" feature. >shkin.net> > > We certainly should ... https://bugzilla.mozilla.org/show_bug.cgi?id=188264 From wurblzap at gmail.com Tue Apr 5 17:49:10 2005 From: wurblzap at gmail.com (Marc Schumann) Date: Tue, 5 Apr 2005 19:49:10 +0200 Subject: Should we remove ability to turn on user and bug deletion? In-Reply-To: <4252CD99.5080107@peshkin.net> References: <425100AC.2020900@mozilla.org> <42510826.10709@gmail.com> <42516D63.2020405@mozilla.org> <2ad201c539f7$7cadd6c0$4b00000a@opus2> <16978.51902.651153.689249@gargle.gargle.HOWL> <4252CD99.5080107@peshkin.net> Message-ID: A "merge user" feature would certainly reduce my need for user deletion considerably. Otherwise, I'm all for allowing user deletion, but making sure only accounts completely unrelated to other db entities may be deleted. Marc -- http://wurblzap.net/ Bugzilla hosting and professional support From justdave at bugzilla.org Tue Apr 5 20:12:03 2005 From: justdave at bugzilla.org (David Miller) Date: Tue, 05 Apr 2005 16:12:03 -0400 Subject: Should we remove ability to turn on user and bug deletion? In-Reply-To: <4252CD99.5080107@peshkin.net> References: <425100AC.2020900@mozilla.org> <42510826.10709@gmail.com> <42516D63.2020405@mozilla.org> <2ad201c539f7$7cadd6c0$4b00000a@opus2> <16978.51902.651153.689249@gargle.gargle.HOWL> <4252CD99.5080107@peshkin.net> Message-ID: <4252F113.3060600@bugzilla.org> Joel Peshkin wrote: > Albert Ting wrote: > >> I have had to use the "delete users" feature quite a bit this past month. >> Or rather, I'd would love to see a "merge user" feature, combined with >> maybe an "user alias" feature. >> > We certainly should ... > https://bugzilla.mozilla.org/show_bug.cgi?id=188264 Note that there is a working script attached to that bug which does just that. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Foundation http://www.mozilla.org/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From justdave at bugzilla.org Tue Apr 5 20:31:54 2005 From: justdave at bugzilla.org (David Miller) Date: Tue, 05 Apr 2005 16:31:54 -0400 Subject: Docbook Wiki In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A42A09648@ssvlexmb2.amd.com> References: <6F7DA19D05F3CF40B890C7CA2DB13A42A09648@ssvlexmb2.amd.com> Message-ID: <4252F5BA.9030501@bugzilla.org> Benton, Kevin wrote: > FYI all ? I just found this link - > http://freshmeat.net/projects/doc-book/ - it?s Docbook Wiki. > Considering the recent discussion, it may be something worth looking into. Hmm, most intriguing. It's even CVS-backed. Wonder if I can shoehorn it onto our existing repository? I've got a copy unpacked on Landfill already, I'll play with it a bit. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Foundation http://www.mozilla.org/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From mkanat at bugzilla.org Wed Apr 6 01:01:42 2005 From: mkanat at bugzilla.org (Maxwell Kanat-Alexander) Date: Tue, 05 Apr 2005 18:01:42 -0700 Subject: Warning for CVS Users: Next Checksetup May Be Long Message-ID: <1112749302.6815.17.camel@localhost.localdomain> If you are using the current CVS tip of Bugzilla, you should know that your next checksetup run may be much longer than normal. I've checked-in some code into Bugzilla that renames all the indexes in the database, to conform to our new database-independent Schema standards. Unfortunately, the only way to rename an index in MySQL is to drop it and re-create it. So this will be re-creating all the indexes in your database. If the checksetup run will take longer than five minutes (at an estimate), you are given the chance to abort before the renaming begins, so that you can schedule the checksetup run at a better time if you'd like. I currently estimate that it will take about 5 minutes for each 15,000 bugs in your database. -Max From justdave at bugzilla.org Wed Apr 6 01:22:09 2005 From: justdave at bugzilla.org (David Miller) Date: Tue, 05 Apr 2005 21:22:09 -0400 Subject: E-mail notification of new attachments In-Reply-To: <424463F7.5060108@mozilla.org> References: <20050325191728.A1D0BBC77@mail.schwag.org> <424463F7.5060108@mozilla.org> Message-ID: <425339C1.5080304@bugzilla.org> Gervase Markham wrote: > Sean McAfee wrote: > >> if ($difftext eq "" && $newcomments eq "") { return; } >> >> How this condition gets met, though, is proving difficult to >> determine. So, >> I'm punting to the list and hoping someone more familiar with the BugMail >> guts can explain what's happening more quickly. > > > Having just rewritten them in bug 73665, I'm fairly familiar with them > :-) $difftext is the text to go in mails containing the differences in > the bug. Attachment fields aren't included. $newcomments are the new > comments. So both of these will be empty for your change. In Bugzilla as-shipped, creating an attachment adds a comment to the bug. This satifies the "are there new comments?" check and mail is sent. The only way you'd be getting bounced out on that is if you modified Bugzilla to not add that comment when an attachment is added. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Foundation http://www.mozilla.org/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From mkanat at bugzilla.org Wed Apr 6 02:23:31 2005 From: mkanat at bugzilla.org (Maxwell Kanat-Alexander) Date: Tue, 05 Apr 2005 19:23:31 -0700 Subject: Updates to the Checksetup Testing Script Message-ID: <1112754211.6815.22.camel@localhost.localdomain> The test-checksetup tinderbox script has some updates, as of today. It will now check the schema it creates at the end of every checksetup run, and compare it to the tip schema to make sure that it is exactly identical. If it's not identical, it will print out the differences as a slightly mangled diff. I think that there is still one error in certain types of upgrades (related to Schema), so the checksetup tinderbox will probably burn on the next run. There are also some differences where some tables will have PACK_KEYS in MySQL and some tables won't. Do we actually care about that schema difference? -Max From bugreport at peshkin.net Thu Apr 7 17:37:21 2005 From: bugreport at peshkin.net (Joel Peshkin) Date: Thu, 07 Apr 2005 10:37:21 -0700 Subject: Landfill now has mysql3, mysql4.1, and mysql5 Message-ID: <42556FD1.9070109@peshkin.net> All: In addition to the "default" mysql 3.23, landfill now has mysql4.1 and mysql5 and will soon have myslq4.0 To use these, use the same credentials you previously used but specify the appropriate sockets... $db_sock = '/opt/mysql4.1/var/mysql.sock'; $db_sock = '/opt/mysql5/var/mysql.sock'; mysql -S /opt/mysql4.1/var/mysql.sock -uwhatever -p mysql -S /opt/mysql5/var/mysql.sock -uwhatever -p For the time being, the utilities on landfill are only really aware of the default installation. These are, of course, experimental and mysql5 is a beta. -Joel From mkanat at bugzilla.org Thu Apr 7 18:24:20 2005 From: mkanat at bugzilla.org (Maxwell Kanat-Alexander) Date: Thu, 07 Apr 2005 11:24:20 -0700 Subject: New Reviewers List, Live On bugzilla.org Message-ID: <1112898260.6805.6.camel@localhost.localdomain> Hey there. If you are a contributor to Bugzilla, you'll want to note our new, expanded Reviewers List on bugzilla.org! It lists every single file in Bugzilla, and then who to ask for review on your patch depending on what file you've modified the most. It also contains instructions on how to become a reviewer, if you want to help out! :-) You can see it at: http://www.bugzilla.org/docs/reviewer-list.html It's also linked from the "Developer Resources" page: http://www.bugzilla.org/developers/ And finally, I've made some small updates to the Contributor's Guide, to make it clearer what the whole review process is all about, and how you can get review on a patch that you submit: http://www.bugzilla.org/docs/contributor.html This is part of an ongoing effort to make it easier for people to contribute to Bugzilla. If you have any suggestions in that area, please let me know! -Max From jpyeron at pdinc.us Thu Apr 7 22:13:25 2005 From: jpyeron at pdinc.us (Jason Pyeron) Date: Thu, 7 Apr 2005 18:13:25 -0400 (EDT) Subject: New Reviewers List, Live On bugzilla.org In-Reply-To: <1112898260.6805.6.camel@localhost.localdomain> References: <1112898260.6805.6.camel@localhost.localdomain> Message-ID: very nice. is there a way to restrict access to those logged into b.m.o? also in section Documentation "For reviews on documentation, make sure that you request them from documentation at bugzilla.bugs." is "documentation at bugzilla.bugs" a "special" alias? On Thu, 7 Apr 2005, Maxwell Kanat-Alexander wrote: > Hey there. If you are a contributor to Bugzilla, you'll want to note > our new, expanded Reviewers List on bugzilla.org! It lists every single > file in Bugzilla, and then who to ask for review on your patch depending > on what file you've modified the most. > > It also contains instructions on how to become a reviewer, if you want > to help out! :-) > > You can see it at: > > http://www.bugzilla.org/docs/reviewer-list.html > > It's also linked from the "Developer Resources" page: > > http://www.bugzilla.org/developers/ > > And finally, I've made some small updates to the Contributor's Guide, > to make it clearer what the whole review process is all about, and how > you can get review on a patch that you submit: > > http://www.bugzilla.org/docs/contributor.html > > This is part of an ongoing effort to make it easier for people to > contribute to Bugzilla. If you have any suggestions in that area, please > let me know! > > -Max > > - > To view or change your list settings, click here: > > -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Partner & Sr. Manager 7 West 24th Street #100 - - +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 mkanat at bugzilla.org Thu Apr 7 22:37:57 2005 From: mkanat at bugzilla.org (Maxwell Kanat-Alexander) Date: Thu, 07 Apr 2005 15:37:57 -0700 Subject: New Reviewers List, Live On bugzilla.org In-Reply-To: References: <1112898260.6805.6.camel@localhost.localdomain> Message-ID: <1112913477.6463.11.camel@localhost.localdomain> On Thu, 2005-04-07 at 18:13 -0400, Jason Pyeron wrote: > very nice. > > is there a way to restrict access to those logged into b.m.o? Not really necessary. > is "documentation at bugzilla.bugs" a "special" alias? If by "special," you mean "it's not a real person, and it represents more than one person," then yes. -Max From jpyeron at pdinc.us Fri Apr 8 01:02:36 2005 From: jpyeron at pdinc.us (Jason Pyeron) Date: Thu, 7 Apr 2005 21:02:36 -0400 (EDT) Subject: New Reviewers List, Live On bugzilla.org In-Reply-To: <1112913477.6463.11.camel@localhost.localdomain> References: <1112898260.6805.6.camel@localhost.localdomain> <1112913477.6463.11.camel@localhost.localdomain> Message-ID: On Thu, 7 Apr 2005, Maxwell Kanat-Alexander wrote: > On Thu, 2005-04-07 at 18:13 -0400, Jason Pyeron wrote: > >> is "documentation at bugzilla.bugs" a "special" alias? > > If by "special," you mean "it's not a real person, and it represents > more than one person," then yes. bugzilla.bugs does not appear to be a valid domain... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Partner & Sr. Manager 7 West 24th Street #100 - - +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 justdave at bugzilla.org Fri Apr 8 01:19:41 2005 From: justdave at bugzilla.org (David Miller) Date: Thu, 07 Apr 2005 21:19:41 -0400 Subject: New Reviewers List, Live On bugzilla.org In-Reply-To: References: <1112898260.6805.6.camel@localhost.localdomain> <1112913477.6463.11.camel@localhost.localdomain> Message-ID: <4255DC2D.8070802@bugzilla.org> Jason Pyeron wrote: > On Thu, 7 Apr 2005, Maxwell Kanat-Alexander wrote: > >> On Thu, 2005-04-07 at 18:13 -0400, Jason Pyeron wrote: >> >>> is "documentation at bugzilla.bugs" a "special" alias? >> >> >> If by "special," you mean "it's not a real person, and it represents >> more than one person," then yes. > > bugzilla.bugs does not appear to be a valid domain... Which is why we're using it. bugzilla.mozilla.org is hacked to disabled all mail to @*.bugs, so we use it for "role" accounts that multiple people watch. The part where the * is usually gets replaced by the product name, and the component goes in front. (Poor man's component watching until we have a real way to do it, really) -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Foundation http://www.mozilla.org/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From mkanat at bugzilla.org Fri Apr 8 01:19:38 2005 From: mkanat at bugzilla.org (Maxwell Kanat-Alexander) Date: Thu, 07 Apr 2005 18:19:38 -0700 Subject: New Reviewers List, Live On bugzilla.org In-Reply-To: References: <1112898260.6805.6.camel@localhost.localdomain> <1112913477.6463.11.camel@localhost.localdomain> Message-ID: <1112923178.6247.2.camel@localhost.localdomain> On Thu, 2005-04-07 at 21:02 -0400, Jason Pyeron wrote: > > If by "special," you mean "it's not a real person, and it represents > > more than one person," then yes. > > bugzilla.bugs does not appear to be a valid domain... See above. ("It's not a real person...") -Max From timeless at myrealbox.com Fri Apr 8 04:00:51 2005 From: timeless at myrealbox.com (timeless) Date: Thu, 07 Apr 2005 21:00:51 -0700 Subject: New Reviewers List, Live On bugzilla.org In-Reply-To: References: <1112898260.6805.6.camel@localhost.localdomain> <1112913477.6463.11.camel@localhost.localdomain> Message-ID: <425601F3.1080205@myrealbox.com> Jason Pyeron wrote: > bugzilla.bugs does not appear to be a valid domain... it like most things is a relative domain. we don't specify relative to what, but pretend it's relative to mozilla.org, so bugzilla.bugs.mozilla.org, that there happen to be no mail servers or dns servers answering to that is an implementation detail. people will watch the bugzilla account, so any bugmail that could be sent to that account could also be sent to the people who watch it. but it does not accept email, neither from the outside world nor from bugzilla. From mkanat at bugzilla.org Fri Apr 8 05:21:49 2005 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 07 Apr 2005 22:21:49 -0700 Subject: If You Change Checksetup, Please Let Me Know Message-ID: <1112937710.6247.4.camel@localhost.localdomain> Hey developers. If you modify checksetup in the next week, could you CC me on the bug or ask me for review on the patch? I'm working on a patch for bug 285722 right now, and it touches most of checksetup, so I'll need to be very aware of any changes made between now and the checkin of the patch. -Max From gerv at mozilla.org Sat Apr 9 19:33:38 2005 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 09 Apr 2005 20:33:38 +0100 Subject: Blank resolution causing problems Message-ID: <42582E12.4020407@mozilla.org> Developers, The use of the value "" for "no resolution" is causing problems in charting. The charting code is pretty generic (it has to be, to cope with arbitrary charts) but if this value is to be used in labels, it needs special-casing everywhere. For some of the problems using "" causes, see: https://bugzilla.mozilla.org/show_bug.cgi?id=289697 https://bugzilla.mozilla.org/show_bug.cgi?id=289694 https://bugzilla.mozilla.org/show_bug.cgi?id=289691 This fairly old line from query.cgi also tells its own story: push @::legal_resolution, "---"; # Oy, what a hack. This is needed to allow it to distinguish between "specifically, there is no resolution" and "I don't want to specify any restrictions on the value of the resolution". Would it be reasonable to update Bugzilla to use a string like "[None]" to represent no resolution? Or is there another, better solution to this problem? (Using "NULL" in the database instead of "" may make database purists happier, but doesn't solve this problem as far as I can see.) Gerv From vladd at bugzilla.org Sun Apr 10 04:20:43 2005 From: vladd at bugzilla.org (Vlad Dascalu) Date: Sun, 10 Apr 2005 07:20:43 +0300 Subject: Blank resolution causing problems In-Reply-To: <42582E12.4020407@mozilla.org> References: <42582E12.4020407@mozilla.org> Message-ID: <4258A99B.9080505@bugzilla.org> Gervase Markham wrote: > (Using "NULL" in the database instead of "" may make database purists > happier, but doesn't solve this problem as far as I can see.) It would solve the issue of having (in the future :) ) custom resolutions and one named "---" or "[None]", and then having confused users all over the place. To begin with :) Vlad. From vladd at bugzilla.org Sun Apr 10 04:23:56 2005 From: vladd at bugzilla.org (Vlad Dascalu) Date: Sun, 10 Apr 2005 07:23:56 +0300 Subject: Blank resolution causing problems In-Reply-To: <42582E12.4020407@mozilla.org> References: <42582E12.4020407@mozilla.org> Message-ID: <4258AA5C.4090908@bugzilla.org> So, besides the DB NULL thing, which is a back-end issue, I think we need to stop passing "---" or any other hard-coded value to query.cgi. We could have something like: query.cgi?resolution_value=specified&resolution_name=FIXED or query.cgi?resolution_value=any to solve a large part of these problems. Vlad. Gervase Markham wrote: > Developers, > > The use of the value "" for "no resolution" is causing problems in > charting. The charting code is pretty generic (it has to be, to cope > with arbitrary charts) but if this value is to be used in labels, it > needs special-casing everywhere. > > For some of the problems using "" causes, see: > https://bugzilla.mozilla.org/show_bug.cgi?id=289697 > https://bugzilla.mozilla.org/show_bug.cgi?id=289694 > https://bugzilla.mozilla.org/show_bug.cgi?id=289691 > > This fairly old line from query.cgi also tells its own story: > > push @::legal_resolution, "---"; # Oy, what a hack. > > This is needed to allow it to distinguish between "specifically, there > is no resolution" and "I don't want to specify any restrictions on the > value of the resolution". > > Would it be reasonable to update Bugzilla to use a string like > "[None]" to represent no resolution? Or is there another, better > solution to this problem? (Using "NULL" in the database instead of "" > may make database purists happier, but doesn't solve this problem as > far as I can see.) > > Gerv > - > To view or change your list settings, click here: > > > From mkanat at bugzilla.org Sun Apr 10 06:21:50 2005 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sat, 09 Apr 2005 23:21:50 -0700 Subject: Blank resolution causing problems In-Reply-To: <42582E12.4020407@mozilla.org> References: <42582E12.4020407@mozilla.org> Message-ID: <1113114110.11348.2.camel@localhost.localdomain> On Sat, 2005-04-09 at 20:33 +0100, Gervase Markham wrote: > Or is there another, better solution to this > problem? (Using "NULL" in the database instead of "" may make database > purists happier, but doesn't solve this problem as far as I can see.) Using NULL makes it considerably easier to special-case this when necessary, and it also makes it easier to catch when we fail, because DBI will return "undef" for a NULL field. I was planning to make that change eventually anyway, after 2.20 is unfrozen. -Max From gerv at mozilla.org Sun Apr 10 15:29:53 2005 From: gerv at mozilla.org (Gervase Markham) Date: Sun, 10 Apr 2005 16:29:53 +0100 Subject: Blank resolution causing problems In-Reply-To: <1113114110.11348.2.camel@localhost.localdomain> References: <42582E12.4020407@mozilla.org> <1113114110.11348.2.camel@localhost.localdomain> Message-ID: <42594671.7000903@mozilla.org> Max Kanat-Alexander wrote: > Using NULL makes it considerably easier to special-case this when > necessary But I'd much rather it wasn't necessary to special-case it at all. It also doesn't solve the "no resolution restriction specified" vs "specifically, no resolution" problem in URLs. Why can't we have a string signifying no resolution? Gerv From gerv at mozilla.org Sun Apr 10 15:31:03 2005 From: gerv at mozilla.org (Gervase Markham) Date: Sun, 10 Apr 2005 16:31:03 +0100 Subject: Blank resolution causing problems In-Reply-To: <4258A99B.9080505@bugzilla.org> References: <42582E12.4020407@mozilla.org> <4258A99B.9080505@bugzilla.org> Message-ID: <425946B7.4040805@mozilla.org> Vlad Dascalu wrote: > It would solve the issue of having (in the future :) ) custom > resolutions and one named "---" or "[None]", and then having confused > users all over the place. To begin with :) If that's really a problem (which I don't think it would be), we could disallow these resolutions at creation time. We shouldn't let this minor concern affect the decision. Gerv From gerv at mozilla.org Sun Apr 10 15:33:59 2005 From: gerv at mozilla.org (Gervase Markham) Date: Sun, 10 Apr 2005 16:33:59 +0100 Subject: Blank resolution causing problems In-Reply-To: <4258AA5C.4090908@bugzilla.org> References: <42582E12.4020407@mozilla.org> <4258AA5C.4090908@bugzilla.org> Message-ID: <42594767.6090102@mozilla.org> Vlad Dascalu wrote: > We could have something like: > > query.cgi?resolution_value=specified&resolution_name=FIXED > > or > > query.cgi?resolution_value=any > > to solve a large part of these problems. Unfortunately, this is a backwardly-incompatible change to the CGI interface of query.cgi, breaking stored queries (which we might be able to fix) and bookmarks and external scripts (which we can't). It also means that we'd need two parameters like this for any value for which "nothing" was an acceptable specific value, and that seems nasty to me. I'd say a better solution was to have a reserved value which always meant "specifically none" for any field for which that's a legal value. It could be "---", "[None]" or anything else. I don't mind too much. Gerv From mkanat at bugzilla.org Sun Apr 10 23:29:35 2005 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sun, 10 Apr 2005 16:29:35 -0700 Subject: Blank resolution causing problems In-Reply-To: <42594671.7000903@mozilla.org> References: <42582E12.4020407@mozilla.org> <1113114110.11348.2.camel@localhost.localdomain> <42594671.7000903@mozilla.org> Message-ID: <1113175775.6226.5.camel@localhost.localdomain> On Sun, 2005-04-10 at 16:29 +0100, Gervase Markham wrote: > But I'd much rather it wasn't necessary to special-case it at all. It > also doesn't solve the "no resolution restriction specified" vs > "specifically, no resolution" problem in URLs. We already have that problem solved in the current Bugzilla UI. If it's not easy to re-use that code, then that's a problem that should be resolved. > Why can't we have a string signifying no resolution? We already have that; the empty string. Apparently it didn't work very well in your situation. Similarly, any other string wouldn't work well in somebody else's situation. -Max From Nick.Barnes at pobox.com Mon Apr 11 10:02:22 2005 From: Nick.Barnes at pobox.com (Nick Barnes) Date: Mon, 11 Apr 2005 11:02:22 +0100 Subject: Blank resolution causing problems In-Reply-To: <42582E12.4020407@mozilla.org> from Gervase Markham of "Sat, 09 Apr 2005 20:33:38 +0100" Message-ID: <45765.1113213742@thrush.ravenbrook.com> At 2005-04-09 19:33:38+0000, Gervase Markham writes: > Developers, > > The use of the value "" for "no resolution" is causing problems in > charting. The charting code is pretty generic (it has to be, to cope > with arbitrary charts) but if this value is to be used in labels, it > needs special-casing everywhere. > > For some of the problems using "" causes, see: > https://bugzilla.mozilla.org/show_bug.cgi?id=289697 > https://bugzilla.mozilla.org/show_bug.cgi?id=289694 > https://bugzilla.mozilla.org/show_bug.cgi?id=289691 I don't understand. Why is the special string "" more difficult to handle than the special string "[None]" (or "Sproink!" or "42")? Is it just because "" has a magic truth value in Perl? Nick B From gerv at mozilla.org Mon Apr 11 12:24:16 2005 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 11 Apr 2005 13:24:16 +0100 Subject: Blank resolution causing problems In-Reply-To: <45765.1113213742@thrush.ravenbrook.com> References: <45765.1113213742@thrush.ravenbrook.com> Message-ID: <425A6C70.30006@mozilla.org> Nick Barnes wrote: > I don't understand. Why is the special string "" more difficult to > handle than the special string "[None]" (or "Sproink!" or "42")? Two reasons: 1) The way TT, GD and URLs treat blank values There's various different aspects to this problem, but none of them do exactly the right thing. 2) The fact that "" is not a useful label for a line on a graph representing "no resolution", whereas "[None]" (or even "---", if it's used elsewhere in the UI) is. Gerv From kiko at async.com.br Mon Apr 11 13:23:04 2005 From: kiko at async.com.br (Christian Robottom Reis) Date: Mon, 11 Apr 2005 10:23:04 -0300 Subject: Blank resolution causing problems In-Reply-To: <4258A99B.9080505@bugzilla.org> References: <42582E12.4020407@mozilla.org> <4258A99B.9080505@bugzilla.org> Message-ID: <20050411132304.GV8709@www.async.com.br> On Sun, Apr 10, 2005 at 07:20:43AM +0300, Vlad Dascalu wrote: > Gervase Markham wrote: > > >(Using "NULL" in the database instead of "" may make database purists > >happier, but doesn't solve this problem as far as I can see.) > > It would solve the issue of having (in the future :) ) custom > resolutions and one named "---" or "[None]", and then having confused > users all over the place. To begin with :) Yeah, using strings to indicate cases with special semantics depresses me somewhat, because it's one more codepath that needs to be special-cased everywhere the name is created/changed.. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 From freitag at suse.de Mon Apr 11 16:06:47 2005 From: freitag at suse.de (Klaas Freitag) Date: Mon, 11 Apr 2005 18:06:47 +0200 Subject: Patch: Buglist sort Message-ID: <200504111806.47846.freitag@suse.de> Hi, I attached a patch to bug #267859 https://bugzilla.mozilla.org/show_bug.cgi?id=267859 that fixes the buglists sorting. It indicates the sort direction of the list by a little arrow next to the column header and allows toggling of the sort direction by clicking on the header. Moreover this patch fixes the problem described in bug #228053 Maybe you might want to accept the patch. Regards, Klaas -- Klaas Freitag Novell - SUSE Brand - Internal Tools From gerv at mozilla.org Mon Apr 11 21:21:45 2005 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 11 Apr 2005 22:21:45 +0100 Subject: Blank resolution causing problems In-Reply-To: <1113175775.6226.5.camel@localhost.localdomain> References: <42582E12.4020407@mozilla.org> <1113114110.11348.2.camel@localhost.localdomain> <42594671.7000903@mozilla.org> <1113175775.6226.5.camel@localhost.localdomain> Message-ID: <425AEA69.4000505@mozilla.org> Max Kanat-Alexander wrote: > On Sun, 2005-04-10 at 16:29 +0100, Gervase Markham wrote: > >>But I'd much rather it wasn't necessary to special-case it at all. It >>also doesn't solve the "no resolution restriction specified" vs >>"specifically, no resolution" problem in URLs. > > We already have that problem solved in the current Bugzilla UI. If it's > not easy to re-use that code, then that's a problem that should be > resolved. Well, the problem is solved in some places and not others. The very nature of the current solution is that it's context-specific hacks - it can't be reused. That's the issue I'm trying to address, by changing to something which does not require such hacks. >>Why can't we have a string signifying no resolution? > > We already have that; the empty string. Apparently it didn't work very > well in your situation. Similarly, any other string wouldn't work well > in somebody else's situation. Could you be specific about what additional problems you think changing from "" to e.g. "---" or "[None]" would cause? Gerv From mkanat at bugzilla.org Tue Apr 12 01:32:53 2005 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 11 Apr 2005 18:32:53 -0700 Subject: Message every time you run checksetup Message-ID: <1113269573.6292.0.camel@localhost.localdomain> For the next week or so, you'll get a message that a field was updated every time you run checksetup. This is expected. Hopefully within the week we should check in some code that fixes this, but the code that's producing the message was a prerequisite to the code that will fix the message. :-) -Max From Kamal.Ahmed at esecurity.net Tue Apr 12 01:55:06 2005 From: Kamal.Ahmed at esecurity.net (Kamal Ahmed) Date: Mon, 11 Apr 2005 21:55:06 -0400 Subject: Upgrading Bugzilla from 2.17.1 to 2.18 Message-ID: <8CCCBAE86A028440A752E30C3410AEF6036680@va-ex03.esecurity.net> Hi, Sorry for posting on this forum, but i was not getting any response from perforce or bugzilla users mailing lists: How do i upgrade bugzilla, Since as per bugzilla upgrade using patches: bash$ cd /var/www/html/bugzilla bash$ wget ftp://ftp.mozilla.org/pub/mozilla.org/webtools/ Output omitted bash$ gunzip bugzilla-2.16.1-to-2.16.2.diff.gz bash$ patch -p1 < bugzilla-2.16.1-to-2.16.2.diff patching file checksetup.pl patching file collectstats.pl patching file globals.pl i do not see 2.17.1-to-2.18 Also concidering MAJOR Customizations were made by previous bugzilla admin, How can i make sure that the changes are preserved. Thanks, -Kamal. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rpello at balicamp.com Tue Apr 12 02:42:58 2005 From: rpello at balicamp.com (Ray Mike Troy Pello) Date: Tue, 12 Apr 2005 09:42:58 +0700 Subject: Blank resolution causing problems In-Reply-To: <20050411132304.GV8709@www.async.com.br> References: <20050411132304.GV8709@www.async.com.br> Message-ID: <425B35B2.8070107@balicamp.com> All, I have had similar problems with the "" and "---" strings. I have put the status "UNRESOLVED". This happens when you create a new bug. Subsequently, the status should be unresolved when clearing the resolution and changed the default value on the resolution field to have "UNRESOLVED" Also added the checksetup.pl checking so when you run checksetup it wouldn't change the default values on the tables. Several tweakings are made also on query and report so the status would be shown. I hope this can help with these problems. Thx Ray Pello Christian Robottom Reis wrote: >On Sun, Apr 10, 2005 at 07:20:43AM +0300, Vlad Dascalu wrote: > > >>Gervase Markham wrote: >> >> >> >>>(Using "NULL" in the database instead of "" may make database purists >>> >>> > > > >>>happier, but doesn't solve this problem as far as I can see.) >>> >>> >>It would solve the issue of having (in the future :) ) custom >>resolutions and one named "---" or "[None]", and then having confused >>users all over the place. To begin with :) >> >> > >Yeah, using strings to indicate cases with special semantics depresses >me somewhat, because it's one more codepath that needs to be >special-cased everywhere the name is created/changed.. > >Take care, >-- >Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 >2331 >- >To view or change your list settings, click here: > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stu at asyn.com Tue Apr 12 15:56:19 2005 From: stu at asyn.com (Stuart Donaldson) Date: Tue, 12 Apr 2005 08:56:19 -0700 Subject: current roadmap on Bugzilla? Message-ID: <425BEFA3.4040206@asyn.com> What is the current freeze status and roadmap for Bugzilla? And also, is there a changelog for 2.19.2? or do I need to generate that from CVS? Thanks... -Stuart- From justdave at bugzilla.org Tue Apr 12 17:13:02 2005 From: justdave at bugzilla.org (David Miller) Date: Tue, 12 Apr 2005 13:13:02 -0400 Subject: current roadmap on Bugzilla? In-Reply-To: <425BEFA3.4040206@asyn.com> References: <425BEFA3.4040206@asyn.com> Message-ID: <425C019E.6060902@bugzilla.org> Stuart Donaldson wrote: > What is the current freeze status and roadmap for Bugzilla? See http://www.bugzilla.org/status/roadmap.html (which is slightly outdated now, but not by much) and http://www.bugzilla.org/releases/2.20/ (which is more up to date) > And also, is there a changelog for 2.19.2? or do I need to generate > that from CVS? http://www.bugzilla.org/status/changes.html -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Foundation http://www.mozilla.org/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From mkanat at bugzilla.org Thu Apr 14 07:16:06 2005 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 14 Apr 2005 00:16:06 -0700 Subject: Checksetup Tinderbox State is Valid, Now Message-ID: <1113462966.6414.5.camel@localhost.localdomain> Hey developers. So, I've checked in a patch that should finally make the checksetup tinderbox green, now. So, from now on, if the checksetup tinderbox is "burning" or "test failed," that's really a failure. :-) -Max From mkanat at bugzilla.org Thu Apr 14 10:34:21 2005 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 14 Apr 2005 03:34:21 -0700 Subject: Vague Landfill Maintenance Window :-) Message-ID: <1113474861.7845.2.camel@localhost.localdomain> landfill.bugzilla.org will perhaps be down for 3 - 4 hours some time either today or tomorrow. It will probably be in the afternoon PDT (GMT-7). I know that's a pretty vague window of time, but hey -- it's landfill. :-) It's not exactly the world's most mission-critical server. :-) I'll be putting a new hard drive in it, and upgrading it to Fedora Core 3. -Max From mkanat at bugzilla.org Fri Apr 15 00:32:43 2005 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 14 Apr 2005 17:32:43 -0700 Subject: Checksetup may fail once on upgrade, if you're tracking CVS Message-ID: <1113525163.7931.2.camel@localhost.localdomain> If you've been tracking CVS very carefully, recently (that is, updating every day or every few days), when you upgrade soon you *may* notice the following error being printed by checksetup and it will die: Error reading ./data/params: Permission denied This has to do with some strange complexities of bugs that we fixed. Running checksetup again should fix this. If you *haven't* been tracking CVS closely, and you upgrade to a recent CVS build and you get this error, please let me know. -Max From PCampbell at ourvacationstore.com Mon Apr 18 20:01:04 2005 From: PCampbell at ourvacationstore.com (Patrick Campbell) Date: Mon, 18 Apr 2005 13:01:04 -0700 Subject: Help restoring db? Message-ID: <202DB470B8484B469E8B4302E44A71390CA26DA6@mail.ourvacationstore.com> This may not be the right forum for this so if it is I apologize - I have backed a bugzilla database using: mysqldump -u root -p bugs > bugzilla.20050418 and am trying to import it on a new mysql server using mysql -u root -p bugs < bugzilla.20050418 I'm getting ERROR at line 84: Line 84 is all garbled text... Working with 3.23.58 ... Any thoughts? -- Patrick Campbell OurVacationStore.com Website Administrator Tel. 602.896.4729 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pushpa at emids.com Wed Apr 20 13:12:16 2005 From: pushpa at emids.com (Pushpa) Date: Wed, 20 Apr 2005 18:42:16 +0530 Subject: Query Message-ID: Hi All, Could anyone of you tell me how to create a new field in Bugzilla. For Example: I need to create a filed "Defect Cause" and have a drop down of 2-3 options. Any guidnace on the same is highly appreciated. Thanks. Regards, Pushpa. From gerv at mozilla.org Wed Apr 20 17:37:26 2005 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 20 Apr 2005 18:37:26 +0100 Subject: Query In-Reply-To: References: Message-ID: <42669356.4000401@mozilla.org> Pushpa wrote: > Hi All, > > Could anyone of you tell me how to create a new field in Bugzilla. http://www.gerv.net/hacking/custom-fields.html Gerv From chrismcc at pricegrabber.com Wed Apr 20 20:48:36 2005 From: chrismcc at pricegrabber.com (Christopher McCrory) Date: Wed, 20 Apr 2005 13:48:36 -0700 Subject: Help restoring db? In-Reply-To: <202DB470B8484B469E8B4302E44A71390CA26DA6@mail.ourvacationstore.com> References: <202DB470B8484B469E8B4302E44A71390CA26DA6@mail.ourvacationstore.com> Message-ID: <1114030116.7364.19.camel@wednesday.pricegrabber.com> On Mon, 2005-04-18 at 13:01 -0700, Patrick Campbell wrote: > This may not be the right forum for this so if it is I apologize - I > have backed a bugzilla database using: > > mysqldump -u root -p bugs > bugzilla.20050418 and am trying to import > it on > a new mysql server using > You might try: mysqldump --opt -u root -p bugs > bugzilla.20050418.sql yes? > mysql -u root -p bugs < bugzilla.20050418 > > I'm getting > ERROR at line 84: > > Line 84 is all garbled text... > > Working with 3.23.58 ... Any thoughts? > > > -- > Patrick Campbell > OurVacationStore.com > Website Administrator > Tel. 602.896.4729 > -- Christopher McCrory "The^W One of the guys that keeps the servers running" chrismcc at pricegrabber.com http://www.pricegrabber.com Let's face it, there's no Hollow Earth, no robots, and no 'mute rays.' And even if there were, waxed paper is no defense. I tried it. Only tinfoil works. From justdave at bugzilla.org Wed Apr 20 22:25:24 2005 From: justdave at bugzilla.org (David Miller) Date: Wed, 20 Apr 2005 18:25:24 -0400 Subject: Upgrading Bugzilla from 2.17.1 to 2.18 In-Reply-To: <8CCCBAE86A028440A752E30C3410AEF6036680@va-ex03.esecurity.net> References: <8CCCBAE86A028440A752E30C3410AEF6036680@va-ex03.esecurity.net> Message-ID: <4266D6D4.7050202@bugzilla.org> Kamal Ahmed wrote: > Sorry for posting on this forum, but i was not getting any response from > perforce or bugzilla users mailing lists: You got at least two replies on the Bugzilla users list (mozilla-webtools), and you've even additionally participated in the thread there since it started, so I know you've seen them. That is the correct place for the discussion. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Foundation http://www.mozilla.org/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From john.fisher at znyx.com Thu Apr 21 17:52:43 2005 From: john.fisher at znyx.com (john fisher) Date: Thu, 21 Apr 2005 10:52:43 -0700 Subject: Help restoring db? In-Reply-To: <202DB470B8484B469E8B4302E44A71390CA26DA6@mail.ourvacationstore.com> References: <202DB470B8484B469E8B4302E44A71390CA26DA6@mail.ourvacationstore.com> Message-ID: <1114105963.10285.478.camel@johnf.znyx.com> You can always hand edit the dump file, if its not too large to handle. Its just a script. Since this should work, I suspect a db problem. Also ask at MySql. On Mon, 2005-04-18 at 13:01 -0700, Patrick Campbell wrote: > mysql -u root -p bugs < bugzilla.20050418 > > I'm getting > ERROR at line 84: -- John Fisher at Znyx Networks Santa Barbara office From myk at mozilla.org Thu Apr 21 23:53:26 2005 From: myk at mozilla.org (Myk Melez) Date: Thu, 21 Apr 2005 16:53:26 -0700 Subject: The State of 2.20 Blockers Message-ID: <42683CF6.5080108@mozilla.org> With permission from Dave, I've unblockered a bunch of 2.20 blockers, following the criteria laid out by Dave in IRC: "If it's not a regression from 2.18 and it's not a critical problem with something that's already landed, let's push it off." If you disagree with one of my decisions, re-request blocking2.20, and Dave will take another look at it. Note that you can still land fixes into 2.20 which are not 2.20 blockers; we'll still take other low-risk, high-reward polish fixes, even though they won't block the release. Note also that we've switched to a time-based release cycle. That means we're going to ship 2.20 when it's time to do so (i.e. now, or as soon as possible thereafter), not when it has all the fixes and new features we want for it. We know this means shipping with bugs we don't want. We hope and intend for the benefits of regular releases to outweigh that downside. There are now 15 2.20 blockers . Also, I've labeled the low-risk, high-reward polish fixes I'd like to see make it into 2.20 with the "[wanted for 2.20]" status whiteboard tag. Please prioritize these bugs in your development and review time so we can quickly ship a great 2.20. -myk -------------- next part -------------- An HTML attachment was scrubbed... URL: From justdave at bugzilla.org Mon Apr 25 05:10:00 2005 From: justdave at bugzilla.org (David Miller) Date: Mon, 25 Apr 2005 01:10:00 -0400 Subject: [Fwd: talks/slides, random stuff] Message-ID: <426C7BA8.8000104@bugzilla.org> Good stuff in here. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Foundation http://www.mozilla.org/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ -------------- next part -------------- An embedded message was scrubbed... From: Luis Villa Subject: talks/slides, random stuff Date: Sun, 24 Apr 2005 23:41:47 +1000 Size: 4516 URL: From luis.villa at gmail.com Mon Apr 25 08:40:51 2005 From: luis.villa at gmail.com (Luis Villa) Date: Mon, 25 Apr 2005 18:40:51 +1000 Subject: [Fwd: talks/slides, random stuff] In-Reply-To: <426C7BA8.8000104@bugzilla.org> References: <426C7BA8.8000104@bugzilla.org> Message-ID: <2cb10c44050425014037ca539f@mail.gmail.com> On 4/25/05, David Miller wrote: > Good stuff in here. I wasn't sure if it was appropriate for this list, hope people appreciate it here. Luis > ---------- Forwarded message ---------- > From: Luis Villa > To: mozilla-webtools at mozilla.org > Date: Sun, 24 Apr 2005 23:41:47 +1000 > Subject: talks/slides, random stuff > Hey, all- couple quick things: > > * I just gave a talk on 'why everyone needs a bugmaster' at > Linux.conf.au 2005 in Canberra, Australia, and have posted slides and > a short-ish paper at http://tieguy.org/talks/. Feedback for whenever I > next give a talk is appreciated. > > * I'd like to coalesce my three bugzilla talks/papers (bugzilla for > open source developers, why everyone needs bugzilla, why everyone > needs a bugmaster) into a bugzilla best practices guide at some point. > I know there was at one point discussion of such a thing, but I'm not > sure it ever happened- anyone else know? > > * I blogged a start of an attack on cross-bugzilla stats gathering here: > > http://tieguy.org/blog/index.cgi/353 > > If anyone has things to add, suggestions for other interesting > suggestions I could dig up, whatever, I'd appreciate it. > > Anyway, greetings from Down Under- > Luis > > _______________________________________________ > mozilla-webtools mailing list > mozilla-webtools at mozilla.org > http://mail.mozilla.org/listinfo/mozilla-webtools > > > - > To view or change your list settings, click here: > > > > From chicks at chicks.net Mon Apr 25 14:32:22 2005 From: chicks at chicks.net (Christopher Hicks) Date: Mon, 25 Apr 2005 10:32:22 -0400 (EDT) Subject: [Fwd: talks/slides, random stuff] In-Reply-To: <426C7BA8.8000104@bugzilla.org> References: <426C7BA8.8000104@bugzilla.org> Message-ID: On Mon, 25 Apr 2005, David Miller wrote: > Good stuff in here. Agreed. We need to start a donations drive for Luis' bandwidth. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) From Kamal.Ahmed at esecurity.net Mon Apr 25 18:12:15 2005 From: Kamal.Ahmed at esecurity.net (Kamal Ahmed) Date: Mon, 25 Apr 2005 14:12:15 -0400 Subject: Upgrading Bugzilla from 2.17.1 to 2.18 Message-ID: <8CCCBAE86A028440A752E30C3410AEF6175C42@va-ex03.esecurity.net> Sorry Dave, it was in desperation that I sought this help. By the way, please look at http://software.hixie.ch/applications/bugzilla3/ Are we developing Bugzilla 3 ? Thanks, -Kamal. -----Original Message----- From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] On Behalf Of David Miller Sent: Wednesday, April 20, 2005 6:25 PM To: developers at bugzilla.org Subject: Re: Upgrading Bugzilla from 2.17.1 to 2.18 Kamal Ahmed wrote: > Sorry for posting on this forum, but i was not getting any response > from > perforce or bugzilla users mailing lists: You got at least two replies on the Bugzilla users list (mozilla-webtools), and you've even additionally participated in the thread there since it started, so I know you've seen them. That is the correct place for the discussion. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Foundation http://www.mozilla.org/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ - To view or change your list settings, click here: From justdave at bugzilla.org Mon Apr 25 20:31:06 2005 From: justdave at bugzilla.org (David Miller) Date: Mon, 25 Apr 2005 16:31:06 -0400 Subject: Upgrading Bugzilla from 2.17.1 to 2.18 In-Reply-To: <8CCCBAE86A028440A752E30C3410AEF6175C42@va-ex03.esecurity.net> References: <8CCCBAE86A028440A752E30C3410AEF6175C42@va-ex03.esecurity.net> Message-ID: <426D538A.80202@bugzilla.org> Kamal Ahmed wrote: > Sorry Dave, it was in desperation that I sought this help. No worries, it happens :) > By the way, please look at > http://software.hixie.ch/applications/bugzilla3/ > Are we developing Bugzilla 3 ? Hixie dropped that project a few years ago. It was a little bit too ambitious, and the 2.x codebase has achieved a number of his goals already anyway in an incremental fashion. The current 2.x codebase will likely become 3.0 in the next year or so. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Foundation http://www.mozilla.org/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From mkanat at bugzilla.org Mon Apr 25 19:18:53 2005 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 25 Apr 2005 12:18:53 -0700 Subject: Bugzilla3 In-Reply-To: <8CCCBAE86A028440A752E30C3410AEF6175C42@va-ex03.esecurity.net> References: <8CCCBAE86A028440A752E30C3410AEF6175C42@va-ex03.esecurity.net> Message-ID: <1114456733.11951.3.camel@localhost.localdomain> On Mon, 2005-04-25 at 14:12 -0400, Kamal Ahmed wrote: > Are we developing Bugzilla 3 ? No, not in that form. Most of the features proposed for Bugzilla3 have already been implemented in the normal Bugzilla development process. We are, however, considering calling version 2.22 version 3.0, if we have both custom fields and mod_perl support in it, which I think we might (though I can't promise anything). -Max -- http://www.everythingsolved.com/ Everything Solved: Experts at Bugzilla... and everything else, too. From Tomas.Kopal at altap.cz Wed Apr 27 11:00:31 2005 From: Tomas.Kopal at altap.cz (Tomas Kopal) Date: Wed, 27 Apr 2005 20:30:31 +0930 Subject: I will be offline from Monday Message-ID: <426F70CF.206@altap.cz> Hi all, as some of you already know, I am leaving Australia and moving back to Europe next week. That means I will be off-line starting this Monday. We plan to do a bit of travelling, so I will not be available till September. I will do my best to finish all my bugs before then, but keep on mind that assigning me new ones or asking me for reviews will not be very practical in the coming months :-). I am eager to see what will bugzilla look like in September :-). Tomas From mkanat at bugzilla.org Wed Apr 27 11:19:30 2005 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 27 Apr 2005 04:19:30 -0700 Subject: PostgreSQL Support Ready For Testing Message-ID: <1114600770.8830.9.camel@localhost.localdomain> Hello! As of today's CVS version, Bugzilla's PostgreSQL support is ready for beta testing. There are still some known bugs -- see the blockers on bug 98304 for details. If you encounter any bugs while using Bugzilla on PostgreSQL, please report them to bugzilla.mozilla.org and make them block bug 98304. Also CC me on them. The steps for setting up a Bugzilla installation on PostgreSQL are very simple: (0) Connect to the template1 database in PostgreSQL as a PostgreSQL superuser. (That's usually the "postgres" user.) (1) Create a 'bugs' user: CREATE USER bugs PASSWORD 'password' CREATEDB; (2) Make sure that your pg_hba.conf allows md5 login from the local machine, from the 'bugs' user: host all bugs 127.0.0.1 255.255.255.255 md5 (3) Make sure that your postgresql.conf allows TCP/IP connections from the local machine: tcpip_socket = true (4) Stop PostgreSQL, and then start it again. (5) Set up Bugzilla normally, editing localconfig and so forth per the instructions in the Bugzilla Guide. Have fun! And of course, if anybody needs consulting support for their PostgreSQL Bugzilla... I'm always available. :-D -Max -- http://www.everythingsolved.com/ Everything Solved: Experts at Bugzilla... and everything else, too. From mkanat at bugzilla.org Wed Apr 27 11:23:43 2005 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 27 Apr 2005 04:23:43 -0700 Subject: PostgreSQL Support Ready For Testing In-Reply-To: <1114600770.8830.9.camel@localhost.localdomain> References: <1114600770.8830.9.camel@localhost.localdomain> Message-ID: <1114601023.8830.11.camel@localhost.localdomain> On Wed, 2005-04-27 at 04:19 -0700, Max Kanat-Alexander wrote: > Hello! As of today's CVS version, Bugzilla's PostgreSQL support is > ready for beta testing. Oh, and one other thing I forgot to mention -- PostgreSQL support currently requires perl's DBD::Pg version 1.31 be installed, although checksetup will not yet tell you that. -Max -- http://www.everythingsolved.com/ Everything Solved: Experts at Bugzilla... and everything else, too. From mkanat at bugzilla.org Wed Apr 27 15:23:42 2005 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 27 Apr 2005 08:23:42 -0700 Subject: PostgreSQL Testing Installation on Landfill Message-ID: <1114615423.8830.15.camel@localhost.localdomain> For those of you who don't want to install a PostgreSQL copy of Bugzilla locally, but still would like to experiment with one or help us test it out can try out our new landfill installation, bugzilla-tip-pg. It will be updated to the latest code every hour, just like bugzilla-tip is. You can see it at: http://landfill.bugzilla.org/bugzilla-tip/ Right now the first thing I've noticed is that show_bug is completely broken... :-) Help us find other bugs that we haven't found yet! :-) -Max -- http://www.everythingsolved.com/ Everything Solved: Experts at Bugzilla... and everything else, too. From mkanat at bugzilla.org Wed Apr 27 15:29:50 2005 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 27 Apr 2005 08:29:50 -0700 Subject: (FIXED URL) Re: PostgreSQL Testing Installation on Landfill In-Reply-To: <1114615423.8830.15.camel@localhost.localdomain> References: <1114615423.8830.15.camel@localhost.localdomain> Message-ID: <1114615790.8830.16.camel@localhost.localdomain> On Wed, 2005-04-27 at 08:23 -0700, Max Kanat-Alexander wrote: > http://landfill.bugzilla.org/bugzilla-tip/ That's actually: http://landfill.bugzilla.org/bugzilla-tip-pg/ -Max -- http://www.everythingsolved.com/ Everything Solved: Experts at Bugzilla... and everything else, too. From jon at jellybob.co.uk Sat Apr 30 20:06:15 2005 From: jon at jellybob.co.uk (Jon Wood) Date: Sat, 30 Apr 2005 21:06:15 +0100 Subject: UI Simplification Message-ID: <1114891575.8764.6.camel@localhost.localdomain> Hey, I don't know if this has come up in the past or not, being a newbie to Bugzilla - especially on the admin side. I've been making some changes to the template set, to make Bugzilla more useful for the Jaws[1] project, and try to improve the experience for people who just want to report a bug, and get out of there :P Would people be interested in merging some of these changes into the main release, or is it better left as a local modification? I'm willing to take the time to do the merge myself. The biggest changes have been made to the bug reporting page at the moment, where I have shifted half of the inputs down to a section labelled "Developer Settings", explaining to users that they probably don't need to worry about those ones. You can see a screen shot[2] of it online - I'll upload some more to my site[3] as I progress. The custom Jaws bits are all done in the header and footer, so they obviously wouldn't be merged in :P Jon Wood [1] http://www.jaws-project.com/ [2] http://www.jellybob.co.uk/data/phoo/2005_04_30/Bugzilla.png [3] http://www.jellybob.co.uk/ From mkanat at bugzilla.org Sat Apr 30 20:27:11 2005 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sat, 30 Apr 2005 13:27:11 -0700 Subject: UI Simplification In-Reply-To: <1114891575.8764.6.camel@localhost.localdomain> References: <1114891575.8764.6.camel@localhost.localdomain> Message-ID: <1114892831.10167.1.camel@localhost.localdomain> On Sat, 2005-04-30 at 21:06 +0100, Jon Wood wrote: > Would people be interested in merging some of these changes into the > main release, Yes! :-) Do read the Contributor's Guide on the bugzilla.org web site. There's a link from the "Developer Resources" page. > You can see a screen shot[2] of it online That looks great. :-) I think that's actually a very clever modification. -Max -- http://www.everythingsolved.com/ Everything Solved: Experts at Bugzilla... and everything else, too.