From mkanat at kerio.com Tue Mar 1 21:22:50 2005 From: mkanat at kerio.com (Max Kanat-Alexander) Date: Tue, 01 Mar 2005 13:22:50 -0800 Subject: Checksetup function changes Message-ID: <1109712170.20187.2.camel@localhost.localdomain> Hey. I've just checked-in bug 277617. It moves all of the GetFieldDef functions and stuff like that from checksetup.pl into Bugzilla::DB. Unfortunately, this probably means that if you have a patch that touched checksetup, it's been bit-rotted. It's very easy to fix, though. If you had a GetFieldDef, it's just $dbh->bz_get_field_def now. Same for the other functions like TableExists and so forth. See https://bugzilla.mozilla.org/show_bug.cgi?id=277617 for details. -Max -- Max Kanat-Alexander Technical Support Manager, USA 2350 Mission College Blvd., Suite 400 Santa Clara, CA 95054 Phone: (408) 496-4500 Fax: (408) 496-6902 http://www.kerio.com/support.html From mkgnu at gmx.net Wed Mar 2 02:12:06 2005 From: mkgnu at gmx.net (Kristis Makris) Date: Tue, 01 Mar 2005 19:12:06 -0700 Subject: [ham] SCM Bug In-Reply-To: References: <1109215092.2019.64.camel@syd.mkgnu.net> Message-ID: <1109729526.2019.207.camel@syd.mkgnu.net> Alexandre, perhaps you'd like to get some input from the Bugzilla developers. They may be interested in your work. On Thu, 2005-02-24 at 00:37 -0300, Alexandre Michetti Manduca wrote: > We want to use SCM Bug to make possible to make checkins from > Bugzilla. > So the user will select a patch for example, and Bugzilla will call a > script or something to do a checkin, and them the SCM Bug will put the > log > message on the bug. I can explaim the idea better if you want... From mkanat at kerio.com Wed Mar 2 09:29:52 2005 From: mkanat at kerio.com (Maxwell Kanat-Alexander) Date: Wed, 02 Mar 2005 01:29:52 -0800 Subject: The State of 2.20 Message-ID: <1109755793.9361.3.camel@max.localdomain> So, our planned freeze date for 2.20 is still at March 15th, last time I talked to Dave. Here is a report that lists all the bugs targeted for 2.20, their current Assignee, and their severity: http://tinyurl.com/7yalc If you have a bug assigned to you that is targeted for 2.20, and it's not going to make it in for 2.20, could you move it out to another milestone? If you have no real plans to work on the bug before Bugzilla 2.24, move it out to Future, and re-assign it to the component owner (or nobody at bugzilla.org, if the component owner is a real person). -Max -- Max Kanat-Alexander Technical Support Manager, USA Kerio Technologies, Inc. 2350 Mission College Blvd., Suite 400 Santa Clara, CA 95054 Phone: (408) 496-4500 Fax: (408) 496-6902 http://www.kerio.com/support.html From katsumi at gmail.com Wed Mar 2 15:44:31 2005 From: katsumi at gmail.com (katsumi liquer) Date: Wed, 2 Mar 2005 10:44:31 -0500 Subject: Resolutions Message-ID: <70dbf54d05030207442d3a3877@mail.gmail.com> First of all, my apologies on asking this question -- I can tell by looking over past messages both here and elsewhere, it has been a question that's been asked a lot (and probably a bothersome one) -- but I am asking it because I have not been able to find either a clear answer or a very recent answer, so here goes: What is the recommended path with Bugzilla if you need to have custom resolution types? Originally we had been running a version 2.18 installation, and had tried to follow some instructions which described modifying the checksetup.pl script to adjust some parameters as described in this post: http://groups-beta.google.com/group/netscape.public.mozilla.webtools/browse_thread/thread/cc4054915640c755/52bb78b3fe6f2165?q=resolution+bugzilla&_done=%2Fgroup%2Fnetscape.public.mozilla.webtools%2Fsearch%3Fgroup%3Dnetscape.public.mozilla.webtools%26q%3Dresolution+bugzilla%26qt_g%3D1%26searchnow%3DSearch+this+group%26&_doneTitle=Back+to+Search&&d#52bb78b3fe6f2165 but I did not have success. After I made the changes and then re-ran checksetup.pl and tired to run any queries, it would give me a long error about an invalid mysql query with the word 'isbless' in it. I am wondering, if I desire to add custom types, should I run 2.18 or 2.19.2? Is their a different method for both versions? Is their a plan to have it as a feature in an up-coming release? If the best thing to do is follow those instructions above, then I will try it again, I just wanted to get some current opinions and guidance. Secondly, thank you for a very excellent piece of software!! Thank you very much, katsu From dwilliss at microimages.com Wed Mar 2 16:07:32 2005 From: dwilliss at microimages.com (Dave Williss) Date: Wed, 2 Mar 2005 10:07:32 -0600 Subject: The State of 2.20 References: <1109755793.9361.3.camel@max.localdomain> Message-ID: <6bf301c51f41$f0e25ff0$4b00000a@opus2> The tinyurl link doesn't work for me. I can see tinyurl.com, but the link below must be redirecting to a bad place. ----- Original Message ----- From: "Maxwell Kanat-Alexander" To: Sent: Wednesday, March 02, 2005 3:29 AM Subject: The State of 2.20 > So, our planned freeze date for 2.20 is still at March 15th, last time > I talked to Dave. > > Here is a report that lists all the bugs targeted for 2.20, their > current Assignee, and their severity: > > http://tinyurl.com/7yalc > > If you have a bug assigned to you that is targeted for 2.20, and it's > not going to make it in for 2.20, could you move it out to another > milestone? > > If you have no real plans to work on the bug before Bugzilla 2.24, move > it out to Future, and re-assign it to the component owner (or > nobody at bugzilla.org, if the component owner is a real person). > > -Max > -- > Max Kanat-Alexander > Technical Support Manager, USA > Kerio Technologies, Inc. > 2350 Mission College Blvd., Suite 400 > Santa Clara, CA 95054 > Phone: (408) 496-4500 > Fax: (408) 496-6902 > http://www.kerio.com/support.html > > > - > To view or change your list settings, click here: > From travis at SEDSystems.ca Wed Mar 2 16:20:12 2005 From: travis at SEDSystems.ca (Shane H. W. Travis) Date: Wed, 2 Mar 2005 10:20:12 -0600 (CST) Subject: The State of 2.20 In-Reply-To: <6bf301c51f41$f0e25ff0$4b00000a@opus2> References: <1109755793.9361.3.camel@max.localdomain> <6bf301c51f41$f0e25ff0$4b00000a@opus2> Message-ID: On Wed, 2 Mar 2005, Dave Williss wrote: > The tinyurl link doesn't work for me. I can see tinyurl.com, but the link > below must be redirecting to a bad place. That happened to me a lot the last time Max put up a tinyurl link (for 2.18 blockers) but everyone else said it worked for them. This one, just FYI, was working fine for me as of about 10 minutes ago. Shane H.W. Travis | The greatest of all mistakes is to do nothing travis at sedsystems.ca | because you can only do a little. Saskatoon, Saskatchewan | Do what you can. -- Sydney Smith From bugzilla at glob.com.au Wed Mar 2 16:22:42 2005 From: bugzilla at glob.com.au (byron) Date: Thu, 3 Mar 2005 00:22:42 +0800 (WST) Subject: The State of 2.20 Message-ID: <20050302162242.CAAB04BC026@sweep.bur.st> > > http://tinyurl.com/7yalc > > The tinyurl link doesn't work for me. I can see tinyurl.com, but the link > below must be redirecting to a bad place. works for me. the *long* url is.. https://bugzilla.mozilla.org/report.cgi?x_axis_field=bug_severity&y_axis_field =assigned_to&z_axis_field=&query_format=report-table&short_desc_type=allwordss ubstr&short_desc=&product=Bugzilla&target_milestone=Bugzilla+2.20&long_desc_ty pe=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_ whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywo rds=&resolution=---&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned _to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=exact&email2=&bugidtype= include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&format=table&a ction=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= begin-base64 644 signature.gif R0lGODlhbQAHAIAAAABPo////ywAAAAAbQAHAAACfAxuGAnch+Bibkn7FL1p XgVl4Ig1jjlZRoqybgun2Cur5uOunq7u/Ipq7WIyIc7XG9JquEgumPzdlhTf h0O83kDJaXEm8mRHwXKJy5sac7qYOpT+gtv0n+0ujQOfdqh16caWt0foBViH N1PRMXimiLUGt3ElVimlgbllWAAAOw== ==== From jake at bugzilla.org Wed Mar 2 18:03:56 2005 From: jake at bugzilla.org (Jake) Date: Wed, 02 Mar 2005 13:03:56 -0500 Subject: The State of 2.20 In-Reply-To: <1109755793.9361.3.camel@max.localdomain> References: <1109755793.9361.3.camel@max.localdomain> Message-ID: <4226000C.5060508@bugzilla.org> And, for the curious, here's a list of 19 bugs that are targeted for 2.20 and waiting on review :) https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc=&product=Bugzilla&target_milestone=Bugzilla+2.20&resolution=---&cmdtype=doit&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=review%3F Maxwell Kanat-Alexander wrote: > So, our planned freeze date for 2.20 is still at March 15th, last time >I talked to Dave. > > Here is a report that lists all the bugs targeted for 2.20, their >current Assignee, and their severity: > > http://tinyurl.com/7yalc > > If you have a bug assigned to you that is targeted for 2.20, and it's >not going to make it in for 2.20, could you move it out to another >milestone? > > If you have no real plans to work on the bug before Bugzilla 2.24, move >it out to Future, and re-assign it to the component owner (or >nobody at bugzilla.org, if the component owner is a real person). > > -Max > > From Guillaume.Rousse at inria.fr Wed Mar 2 20:21:00 2005 From: Guillaume.Rousse at inria.fr (Guillaume Rousse) Date: Wed, 02 Mar 2005 21:21:00 +0100 Subject: The State of 2.20 In-Reply-To: <1109755793.9361.3.camel@max.localdomain> References: <1109755793.9361.3.camel@max.localdomain> Message-ID: <4226202C.8000000@inria.fr> Maxwell Kanat-Alexander wrote: > So, our planned freeze date for 2.20 is still at March 15th, last time > I talked to Dave. > > Here is a report that lists all the bugs targeted for 2.20, their > current Assignee, and their severity: > > http://tinyurl.com/7yalc A newbie question: how are enhancements reviewed and included once submitted ? Am I supposed to wait for some developper to volonteer and assign it to himself ? -- The younger the better -- Murphy's Laws on Sex n?22 From mkanat at kerio.com Wed Mar 2 20:34:44 2005 From: mkanat at kerio.com (Max Kanat-Alexander) Date: Wed, 02 Mar 2005 12:34:44 -0800 Subject: The State of 2.20 In-Reply-To: <4226202C.8000000@inria.fr> References: <1109755793.9361.3.camel@max.localdomain> <4226202C.8000000@inria.fr> Message-ID: <1109795684.28562.3.camel@localhost.localdomain> On Wed, 2005-03-02 at 21:21 +0100, Guillaume Rousse wrote: > A newbie question: how are enhancements reviewed and included once > submitted? http://www.bugzilla.org/docs/contributor.html > Am I supposed to wait for some developper to volonteer and > assign it to himself ? You can ask a specific developer to review it, if you want, or you can set the "review?" flag and wait for somebody to pick it up. The first way is better, if you know the developers and which one would be good. -Max -- Max Kanat-Alexander Technical Support Manager, USA Kerio Technologies, Inc. 2350 Mission College Blvd., Suite 400 Santa Clara, CA 95054 Phone: (408) 496-4500 Fax: (408) 496-6902 http://www.kerio.com/support.html From Guillaume.Rousse at inria.fr Wed Mar 2 21:17:00 2005 From: Guillaume.Rousse at inria.fr (Guillaume Rousse) Date: Wed, 02 Mar 2005 22:17:00 +0100 Subject: The State of 2.20 In-Reply-To: <1109795684.28562.3.camel@localhost.localdomain> References: <1109755793.9361.3.camel@max.localdomain> <4226202C.8000000@inria.fr> <1109795684.28562.3.camel@localhost.localdomain> Message-ID: <42262D4C.2080908@inria.fr> Max Kanat-Alexander wrote: >>Am I supposed to wait for some developper to volonteer and >>assign it to himself ? > > > You can ask a specific developer to review it, if you want, or you can > set the "review?" flag and wait for somebody to pick it up. The first > way is better, if you know the developers and which one would be good. Done, thanks. -- Shouldn't there be a shorter word for "monosyllabic"? -- Why Why Why n?17 From paulspencer at mindspring.com Wed Mar 2 23:22:02 2005 From: paulspencer at mindspring.com (Paul Spencer) Date: Wed, 02 Mar 2005 18:22:02 -0500 Subject: The State of 2.20 In-Reply-To: <1109755793.9361.3.camel@max.localdomain> References: <1109755793.9361.3.camel@max.localdomain> Message-ID: <42264A9A.4040102@mindspring.com> I do not know if this is on the bug list, but the "Bar" graph does not display. It appears as a broken link. If you click "Thinner" then you get a "Sorry, but 2000 x 2000 is the maximum size for a chart." error. Paul Spencer Maxwell Kanat-Alexander wrote: > So, our planned freeze date for 2.20 is still at March 15th, last time > I talked to Dave. > > Here is a report that lists all the bugs targeted for 2.20, their > current Assignee, and their severity: > > http://tinyurl.com/7yalc > > If you have a bug assigned to you that is targeted for 2.20, and it's > not going to make it in for 2.20, could you move it out to another > milestone? > > If you have no real plans to work on the bug before Bugzilla 2.24, move > it out to Future, and re-assign it to the component owner (or > nobody at bugzilla.org, if the component owner is a real person). > > -Max From mkanat at kerio.com Wed Mar 2 23:27:17 2005 From: mkanat at kerio.com (Max Kanat-Alexander) Date: Wed, 02 Mar 2005 15:27:17 -0800 Subject: Some Chart Bug (WAS Re: The State of 2.20) In-Reply-To: <42264A9A.4040102@mindspring.com> References: <1109755793.9361.3.camel@max.localdomain> <42264A9A.4040102@mindspring.com> Message-ID: <1109806037.29495.8.camel@localhost.localdomain> On Wed, 2005-03-02 at 18:22 -0500, Paul Spencer wrote: > I do not know if this is on the bug list, but the "Bar" graph does not > display. It appears as a broken link. If you click "Thinner" then you > get a "Sorry, but 2000 x 2000 is the maximum size for a chart." error. If it's a reproduceable bug, you can file it in Bugzilla. If it's already filed, you can CC gerv at mozilla.org on it and ask him if he thinks it needs fixing for 2.20. -Max From sundeep.kmr at wipro.com Wed Mar 2 06:21:32 2005 From: sundeep.kmr at wipro.com (sundeep.kmr at wipro.com) Date: Wed, 2 Mar 2005 11:51:32 +0530 Subject: regarding date display Message-ID: <201834AAB8BE6246A45166DFD66A3A0103B7C2@blr-m2-msg.wipro.com> An embedded message was scrubbed... From: Subject: regarding date display Date: Wed, 2 Mar 2005 11:51:32 +0530 Size: 5612 URL: -------------- next part -------------- Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or Mailadmin at wipro.com immediately and destroy all copies of this message and any attachments. From paulo.casanova at link.pt Thu Mar 3 15:04:14 2005 From: paulo.casanova at link.pt (Paulo Casanova) Date: Thu, 03 Mar 2005 15:04:14 +0000 Subject: regarding date display In-Reply-To: <201834AAB8BE6246A45166DFD66A3A0103B7C2@blr-m2-msg.wipro.com> References: <201834AAB8BE6246A45166DFD66A3A0103B7C2@blr-m2-msg.wipro.com> Message-ID: <4227276E.2040307@link.pt> Don't know if I got it correctly. You have created a customized field and want it to have today's date filled in when the page displays? Paulo sundeep.kmr at wipro.com wrote: >hi developers, > >I'm unable to display the todays date in enter_bug.cgi in my customized field. >I know to display date in a normal ".cgi" files. >please help out.. > >thanks, >sundeep > > >------------------------------------------------------------------------ > > > >Confidentiality Notice > >The information contained in this electronic message and any attachments to this message are intended >for the exclusive use of the addressee(s) and may contain confidential or privileged information. If >you are not the intended recipient, please notify the sender at Wipro or Mailadmin at wipro.com immediately >and destroy all copies of this message and any attachments. > >------------------------------------------------------------------------ > >- >To view or change your list settings, click here: > > > From sundeep.kmr at wipro.com Fri Mar 4 09:58:48 2005 From: sundeep.kmr at wipro.com (sundeep.kmr at wipro.com) Date: Fri, 4 Mar 2005 15:28:48 +0530 Subject: regarding date display Message-ID: <201834AAB8BE6246A45166DFD66A3A0103B7CA@blr-m2-msg.wipro.com> An embedded message was scrubbed... From: Subject: RE: regarding date display Date: Fri, 4 Mar 2005 15:28:48 +0530 Size: 4682 URL: -------------- next part -------------- Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or Mailadmin at wipro.com immediately and destroy all copies of this message and any attachments. From paulo.casanova at link.pt Fri Mar 4 18:54:24 2005 From: paulo.casanova at link.pt (Paulo Casanova) Date: Fri, 04 Mar 2005 18:54:24 +0000 Subject: regarding date display In-Reply-To: <201834AAB8BE6246A45166DFD66A3A0103B7CA@blr-m2-msg.wipro.com> References: <201834AAB8BE6246A45166DFD66A3A0103B7CA@blr-m2-msg.wipro.com> Message-ID: <4228AEE0.9090602@link.pt> OK, so you've got a custom field and have created a new field in the bug entry template, right? You have a few choices here, but I'll put the first two that come to my mind :) 1. You generate the default date in the CGI that generates your page (enter_bug.cgi, I'll assume) and place in your template. Say you'll have today's date in variable $mydate. Place a line with $vars->{'today_date'} = $mydate; near the other $vars->xxx declarations In the template, just use the variable: This is only useful if, for some reason, you might want to change the default date dynamically. 2. You fill in the text field directly in the template (probably the easiest): There are probably 1m ways to get the current date in an unimaginable bunch of formats but I guess you're problem is not getting the date. You can just call in any function between [% %] in the templates. The function gets evaluated and its result is placed in the template. I'm assuming your field is editable but if it's not, just ignore the <> stuff :) like:

My text in the enter bug page
Here is todays's date: [% my_date %]

Hope it helps, Paulo From myk at mozilla.org Sat Mar 5 02:12:11 2005 From: myk at mozilla.org (Myk Melez) Date: Fri, 04 Mar 2005 18:12:11 -0800 Subject: UI hackathon proposal Message-ID: <4229157B.7010305@mozilla.org> I'd like to accelerate improvements to the Bugzilla user interface with weekly UI hackathons over the next couple of months. Each hackathon would be a day-long intensive hacking session in which a team of designer-developers would collaborate via the Internet on a series of fixes to the UI for a specific Bugzilla component. Fixes will still be iterative (one bug per issue, one fix per bug), but we'll develop them in parallel to the extent possible, and at the end of each day, if all goes well, we'll have made significant changes. We'll review previous proposals and work in bugs and CVS branches before embarking upon changes, and I'll be around for the entire session to approve proposals, parcel out work, and review fixes. For the first five hackathons I want to tackle the home, search, search results, and show bug pages and the site navigation (not necessarily in that order). Later sessions will tackle other pages and parts of the app. The idea is to significantly improve our UI via targeted intensive hacking sessions while retaining our iterative development process. Doing this work in the compressed timescale of a hackathon presents many challenges, but I hope it also unleashes a great deal of creative and productive energy and will ultimately be successful. I'd like to get started in a couple of weeks and hold one hackathon per week on the same weekday every week (Friday?) from about 9am-6pm PST (GMT-08:00) until the five components mentioned above have all been hacked, targeting this work to the Bugzilla 2.22 release. Thoughts? -myk From bugreport at peshkin.net Sat Mar 5 02:50:48 2005 From: bugreport at peshkin.net (Joel Peshkin) Date: Fri, 04 Mar 2005 18:50:48 -0800 Subject: UI hackathon proposal In-Reply-To: <4229157B.7010305@mozilla.org> References: <4229157B.7010305@mozilla.org> Message-ID: <42291E88.8010106@peshkin.net> Myk Melez wrote: > I'd like to accelerate improvements to the Bugzilla user interface > with weekly UI hackathons over the next couple of months. Each > hackathon would be a day-long intensive hacking session in which a > team of designer-developers would collaborate via the Internet on a > series of fixes to the UI for a specific Bugzilla component. > > Fixes will still be iterative (one bug per issue, one fix per bug), > but we'll develop them in parallel to the extent possible, and at the > end of each day, if all goes well, we'll have made significant > changes. We'll review previous proposals and work in bugs and CVS > branches before embarking upon changes, and I'll be around for the > entire session to approve proposals, parcel out work, and review fixes. Are you suggesting making changes that are essentially limited to the template code or do you expect to be making deeper changes? -Joel From gerv at mozilla.org Sat Mar 5 17:11:57 2005 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 05 Mar 2005 17:11:57 +0000 Subject: UI for editing chart categories Message-ID: <4229E85D.2020608@mozilla.org> We can't do another release without a way of doing this. Please could people read: https://bugzilla.mozilla.org/show_bug.cgi?id=276230 (it's not very long) and add their views as to how this should work? Gerv From gerv at mozilla.org Sat Mar 5 17:17:21 2005 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 05 Mar 2005 17:17:21 +0000 Subject: Admin pages and JavaScript Message-ID: <4229E9A1.30209@mozilla.org> I think we should allow admin pages (but not user pages) to require JavaScript if it improves the user experience. I'm sure we've discussed this before, so this time I've opened a bug for the discussion. That way, we can find it in six months time. https://bugzilla.mozilla.org/show_bug.cgi?id=284901 Please read the bug, and chip in with your view. Gerv From gerv at mozilla.org Sat Mar 5 20:22:16 2005 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 05 Mar 2005 20:22:16 +0000 Subject: UI hackathon proposal In-Reply-To: <4229157B.7010305@mozilla.org> References: <4229157B.7010305@mozilla.org> Message-ID: <422A14F8.90006@mozilla.org> Myk Melez wrote: > Thoughts? Let's go. :-) Gerv From gerv at mozilla.org Sat Mar 5 20:50:41 2005 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 05 Mar 2005 20:50:41 +0000 Subject: Possible new class of bugs Message-ID: <422A1BA1.7000403@mozilla.org> TT treats hash keys beginning with "_" or "." as private, and templates can't access them: http://www.stonehenge.com/merlyn/LinuxMag/col61.html This caused https://bugzilla.mozilla.org/show_bug.cgi?id=284650 Anyone with a moment to spare could perhaps start defining lots of things (products, components etc.) that begin with those two chars and see what breaks... Gerv From bugreport at peshkin.net Sat Mar 5 22:58:00 2005 From: bugreport at peshkin.net (Joel Peshkin) Date: Sat, 05 Mar 2005 14:58:00 -0800 Subject: Possible new class of bugs In-Reply-To: <422A1BA1.7000403@mozilla.org> References: <422A1BA1.7000403@mozilla.org> Message-ID: <422A3978.7030902@peshkin.net> Gervase Markham wrote: > TT treats hash keys beginning with "_" or "." as private, and > templates can't access them: > > > Anyone with a moment to spare could perhaps start defining lots of > things (products, components etc.) that begin with those two chars and > see what breaks... Perhaps we should just validate products and components so thay have to start with [A-Za-z0-9] ?? From mkanat at kerio.com Mon Mar 7 09:32:25 2005 From: mkanat at kerio.com (Max Kanat-Alexander) Date: Mon, 07 Mar 2005 01:32:25 -0800 Subject: The Interesting Installation Integer Problem Message-ID: <1110187945.4046.24.camel@localhost.localdomain> I've come across an interesting theoretical problem, today, when thinking about our new cross-platform installation. Basically, here's the problem: We have a new Bugzilla::DB::Schema module coming, which is almost complete. (See ). It maps "generic" types to database-specific types. It's very cool. We, the developers, cannot really know how any given database will map a "generic" type to a database-specific type. There's just no way at this point to predict that for every database that we might implement. For example, for the PostgreSQL patch, all integers will probably be the same size, namely, "integer." Now, guess how checksetup works? It checks to see if fields have changed their definition! So let's say that we changed a field from a "small integer" to a "large integer," and then we wanted to trigger a change based on that. On MySQL, the triggered change code would run fine. On PostgreSQL, the triggered change would never run, because a "small integer" and a "large integer" are the SAME SIZE. Now, what if we had a database system where all variable-length text fields had the same underlying implementation? That is, where varchar == tinytext == mediumtext, etc. We couldn't trigger a change on moving something from varchar to text. Thankfully, this is not an urgent issue. We currently have no other databases besides MySQL to upgrade. Even when we implement PostgreSQL support, we will only have to truly upgrade starting with 2.22, although our first 2.21 release may also have some requirements in that area. I think we have a few choices that I can think of that will be entirely future-proof: (1) Store a version number somewhere in the database. When we upgrade, read that version number and run the correct upgrade code. Problem: This makes running checksetup against a CVS tree very risky, where before that was no problem. (2) Store the entire current schema itself in the database. That way we'll always know what the "generic" type of a field is SUPPOSED to be, even if it's not possible to read out that information. Problem: That's a somewhat-decent amount of work. Really, to keep our current functionality, I think that #2 is probably the best solution at this point. With Bugzilla::DB::Schema, this is somewhat easier. In fact, the easiest way would just be to store a Data::Dumper->Dump of the generic {schema} hash inside of Bugzilla::DB::Schema. However, that requires that the internal data structures of Bugzilla::DB::Schema either: (1) Always stay the same. (2) Always provide backwards-compatibility. Storing the schema in the database will also make my life in implementing cross-db installation a LOT easier. Right now, in order to get the definition of a table column in a cross-database fashion, I have to do a lot of hocus-pocus with DBI. Now, any advice on how we can best accomplish all of this in a fully maintainable and future proof way is very welcome. :-) I think the structures of Bugzilla::DB::Schema (the next version, not quite this version) should be fine. We'll have to implement a serialize() and deserialize() function, and when we serialize the data, we MUST store along with it the version of the schema that's being stored. I think that we should use a special DB::Schema version, as opposed to the Bugzilla version itself, since we care about when the Schema internal format changes, not when Bugzilla itself changes. -Max From kevin.benton at amd.com Mon Mar 7 14:38:13 2005 From: kevin.benton at amd.com (Kevin Benton) Date: Mon, 7 Mar 2005 07:38:13 -0700 Subject: Possible new class of bugs In-Reply-To: <422A3978.7030902@peshkin.net> Message-ID: <20050307143813.3B8961FE6@ldcmail.amd.com> I don't like that idea because it prevents me from using _xyz as a p/c name, something I do currently without any issues. One challenge I run into as a result, however, is the sorting is inconsistent for p/c's starting with _ - sometimes it shows up first, sometimes last. My hope is they would show up last. Just a thought... --- 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 Joel Peshkin > Sent: Saturday, March 05, 2005 3:58 PM > To: developers at bugzilla.org > Subject: Re: Possible new class of bugs > > Gervase Markham wrote: > > > TT treats hash keys beginning with "_" or "." as private, and > > templates can't access them: > > > > > > Anyone with a moment to spare could perhaps start defining lots of > > things (products, components etc.) that begin with those two chars and > > see what breaks... > > > Perhaps we should just validate products and components so thay have to > start with [A-Za-z0-9] ?? > > - > To view or change your list settings, click here: > From Nick.Barnes at pobox.com Mon Mar 7 14:45:21 2005 From: Nick.Barnes at pobox.com (Nick Barnes) Date: Mon, 07 Mar 2005 14:45:21 +0000 Subject: The Interesting Installation Integer Problem In-Reply-To: <1110187945.4046.24.camel@localhost.localdomain> from Max Kanat-Alexander of "Mon, 07 Mar 2005 01:32:25 -0800" Message-ID: <18820.1110206721@thrush.ravenbrook.com> At 2005-03-07 09:32:25+0000, Max Kanat-Alexander writes: > I've come across an interesting theoretical problem, today, when > thinking about our new cross-platform installation. > > Basically, here's the problem: > > We have a new Bugzilla::DB::Schema module coming, which is almost > complete. (See > ). It maps > "generic" types to database-specific types. It's very cool. Hey, that *is* cool. Any chance of extending it to custom field type names? Immediate benefit: you can say (for instance) "bugs_activity.bug_id is a bug ID", and the module will do the right thing (i.e. {TYPE => 'INT3', NOTNULL => 1}, right now, or something else, consistently everywhere, if that type ever changes). Subsequent benefit: smarter databases can say "a bug ID has to be a FOREIGN KEY bugs.bug_id", and that's a one-time change in this schema management code. Nick B From paulo.casanova at link.pt Mon Mar 7 18:38:26 2005 From: paulo.casanova at link.pt (Paulo Casanova) Date: Mon, 07 Mar 2005 18:38:26 +0000 Subject: The Interesting Installation Integer Problem In-Reply-To: <1110187945.4046.24.camel@localhost.localdomain> References: <1110187945.4046.24.camel@localhost.localdomain> Message-ID: <422C9FA2.9030408@link.pt> Max Kanat-Alexander wrote: > Now, what if we had a database system where all variable-length text >fields had the same underlying implementation? That is, where varchar == >tinytext == mediumtext, etc. We couldn't trigger a change on moving >something from varchar to text. > > And why would that be a problem? If all datatypes are equal, no change is needed in the underlying database... I don't get it... > (2) Store the entire current schema itself in the database. That way >we'll always know what the "generic" type of a field is SUPPOSED to be, >even if it's not possible to read out that information. > Problem: That's a somewhat-decent amount of work. > > Sounds fine. However, PLEASE, keep it manageable for people with custom hacks. Say, the checksetup script could complain about unknown tables and unknown fields but would not change them. As a rule of thum, I'd say checksetup should not drop any fields or tables unless we really know what we're doing (checksetup specific code?) You know, dropping stuff in a database is kinda dangerous :) Paulo From paulo.casanova at link.pt Mon Mar 7 18:54:59 2005 From: paulo.casanova at link.pt (Paulo Casanova) Date: Mon, 07 Mar 2005 18:54:59 +0000 Subject: regarding date display In-Reply-To: <201834AAB8BE6246A45166DFD66A3A0103B7D7@blr-m2-msg.wipro.com> References: <201834AAB8BE6246A45166DFD66A3A0103B7D7@blr-m2-msg.wipro.com> Message-ID: <422CA383.3070305@link.pt> Well, from perl documentation (man perlfunc) I got the following: exec LIST exec PROGRAM LIST The "exec" function executes a system command and never returns-- use "system" instead of "exec" if you want it to return. It fails and returns false only if the command does not exist and it is executed directly instead of via your sys- tem's command shell (see below). So I'm intrigued how your code works :) Moving along, why not using Date::Format (or some other module?). Try this on you cgi: use Date::Format; @lt = localtime(time); $vars->{'mydateval'} = strftime("%d-%m-%y"); Paulo sundeep.kmr at wipro.com wrote: > hi paulo, > > > sorry to disturb 'u again.. > > My problem is:- > > Code in enter_bug.cgi:-- > > my $mydate = "date +%d-%m-%y"; > my $temp = exec($mydate); > $vars->{'mydateval'} = $temp; > > In Corresponding html code is:-- > > DATE:[% mydateval %] > > > but it's Displaying > > DATE: 0 > > I think its not executing the date command here. > > Thanking 'u > > thanks & regards, > Sundeep > > > > Confidentiality Notice > > The information contained in this electronic message and any > attachments to this message are intended > for the exclusive use of the addressee(s) and may contain confidential > or privileged information. If > you are not the intended recipient, please notify the sender at Wipro > or Mailadmin at wipro.com immediately > and destroy all copies of this message and any attachments. > From gerv at mozilla.org Mon Mar 7 20:28:46 2005 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 07 Mar 2005 20:28:46 +0000 Subject: The Interesting Installation Integer Problem In-Reply-To: <1110187945.4046.24.camel@localhost.localdomain> References: <1110187945.4046.24.camel@localhost.localdomain> Message-ID: <422CB97E.1050008@mozilla.org> Max Kanat-Alexander wrote: > We have a new Bugzilla::DB::Schema module coming, which is almost > complete. (See > ). It maps > "generic" types to database-specific types. It's very cool. I may be mistaken, but isn't this what the SQL standard does - i.e. define a set of types with names that all databases understand? > I think we have a few choices that I can think of that will be entirely > future-proof: > > (1) Store a version number somewhere in the database. When we upgrade, > read that version number and run the correct upgrade code. > Problem: This makes running checksetup against a CVS tree very risky, > where before that was no problem. I don't quite understand the risk here; could you elaborate? > (2) Store the entire current schema itself in the database. That way > we'll always know what the "generic" type of a field is SUPPOSED to be, > even if it's not possible to read out that information. > Problem: That's a somewhat-decent amount of work. It's also duplication of information. What if the two get out of sync? Gerv From gerv at mozilla.org Mon Mar 7 20:54:07 2005 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 07 Mar 2005 20:54:07 +0000 Subject: Possible new class of bugs In-Reply-To: <20050307143813.3B8961FE6@ldcmail.amd.com> References: <20050307143813.3B8961FE6@ldcmail.amd.com> Message-ID: <422CBF6F.7050300@mozilla.org> Kevin Benton wrote: > I don't like that idea because it prevents me from using _xyz as a p/c name, > something I do currently without any issues. In which case, we don't need to change anything for products and components... :-) Gerv From mkanat at kerio.com Mon Mar 7 21:40:30 2005 From: mkanat at kerio.com (Max Kanat-Alexander) Date: Mon, 07 Mar 2005 13:40:30 -0800 Subject: The Interesting Installation Integer Problem In-Reply-To: <422C9FA2.9030408@link.pt> References: <1110187945.4046.24.camel@localhost.localdomain> <422C9FA2.9030408@link.pt> Message-ID: <1110231630.6859.10.camel@localhost.localdomain> On Mon, 2005-03-07 at 18:38 +0000, Paulo Casanova wrote: > And why would that be a problem? If all datatypes are equal, no change > is needed in the underlying database... I don't get it... Because we trigger migration changes based on field changes. You have to sort of read checksetup a lot to fully understand, but basically we have certain "upgrade code" that needs to run that wouldn't run. > As a rule of thum, I'd say > checksetup should not drop any fields or tables unless we really know > what we're doing (checksetup specific code?) Yeah, don't worry -- checksetup will never drop fields unless it's specifically told to by us the Bugzilla developers. It *may* at some point print out warnings if your schema differs from the intended schema in any way, though. :-) -Max -- Max Kanat-Alexander Technical Support Manager, USA Kerio Technologies, Inc. 2350 Mission College Blvd., Suite 400 Santa Clara, CA 95054 Phone: (408) 496-4500 Fax: (408) 496-6902 http://www.kerio.com/support.html From mkanat at kerio.com Mon Mar 7 21:45:08 2005 From: mkanat at kerio.com (Max Kanat-Alexander) Date: Mon, 07 Mar 2005 13:45:08 -0800 Subject: The Interesting Installation Integer Problem In-Reply-To: <422CB97E.1050008@mozilla.org> References: <1110187945.4046.24.camel@localhost.localdomain> <422CB97E.1050008@mozilla.org> Message-ID: <1110231908.6859.15.camel@localhost.localdomain> On Mon, 2005-03-07 at 20:28 +0000, Gervase Markham wrote: > I may be mistaken, but isn't this what the SQL standard does - i.e. > define a set of types with names that all databases understand? I wish that all databases understood them. And that we could then get those exact field names back with DBI's type_info. Unfortunately, neither of those things are true. > It's also duplication of information. What if the two get out of sync? It's not a duplication of information, really -- the schema holds information that the database itself loses. The two won't get out-of-sync -- the "ChangeField" subs will only change the stored schema after a successful ALTER TABLE call. Since those things always happen atomically (we never call ALTER TABLE outside of a "ChangeField" call), there's almost no risk of them getting out-of- sync. -Max -- Max Kanat-Alexander Technical Support Manager, USA Kerio Technologies, Inc. 2350 Mission College Blvd., Suite 400 Santa Clara, CA 95054 Phone: (408) 496-4500 Fax: (408) 496-6902 http://www.kerio.com/support.html From myk at mozilla.org Mon Mar 7 22:22:26 2005 From: myk at mozilla.org (Myk Melez) Date: Mon, 07 Mar 2005 14:22:26 -0800 Subject: UI hackathon proposal In-Reply-To: <42291E88.8010106@peshkin.net> References: <4229157B.7010305@mozilla.org> <42291E88.8010106@peshkin.net> Message-ID: <422CD422.1040307@mozilla.org> Joel Peshkin wrote: > Are you suggesting making changes that are essentially limited to the > template code or do you expect to be making deeper changes? I'm suggesting making as many and as deep changes as are reasonable within the given time frame. Since the time frame is only about eight hours, it's unlikely that we'll be doing much beyond template fixes, but there are no a priori restrictions. If deeper code can get written and reviewed within that time frame (f.e. if it doesn't touch code others are hacking, so the author can spend time on it without holding others up), more power to it. -myk From gerv at mozilla.org Mon Mar 7 22:39:48 2005 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 07 Mar 2005 22:39:48 +0000 Subject: The Interesting Installation Integer Problem In-Reply-To: <1110231908.6859.15.camel@localhost.localdomain> References: <1110187945.4046.24.camel@localhost.localdomain> <422CB97E.1050008@mozilla.org> <1110231908.6859.15.camel@localhost.localdomain> Message-ID: <422CD834.60402@mozilla.org> Max Kanat-Alexander wrote: > On Mon, 2005-03-07 at 20:28 +0000, Gervase Markham wrote: > >>I may be mistaken, but isn't this what the SQL standard does - i.e. >>define a set of types with names that all databases understand? > > I wish that all databases understood them. And that we could then get > those exact field names back with DBI's type_info. Unfortunately, > neither of those things are true. I would have thought that the latter could be made true without too much effort by using our wrapper around DBI to look up a name in a table and convert it. And it seems odd that databases claim to support SQL and yet don't understand the defined data types... > The two won't get out-of-sync -- the "ChangeField" subs will only > change the stored schema after a successful ALTER TABLE call. Since > those things always happen atomically (we never call ALTER TABLE outside > of a "ChangeField" call), there's almost no risk of them getting out-of- > sync. Our code may be that scrupulous... but other people's might not. OK, so we could claim that people hacking the database are on their own and deserve what they get, but we haven't claimed that thusfar. Gerv From mkanat at kerio.com Mon Mar 7 22:54:53 2005 From: mkanat at kerio.com (Max Kanat-Alexander) Date: Mon, 07 Mar 2005 14:54:53 -0800 Subject: The Interesting Installation Integer Problem In-Reply-To: <422CD834.60402@mozilla.org> References: <1110187945.4046.24.camel@localhost.localdomain> <422CB97E.1050008@mozilla.org> <1110231908.6859.15.camel@localhost.localdomain> <422CD834.60402@mozilla.org> Message-ID: <1110236093.6859.21.camel@localhost.localdomain> On Mon, 2005-03-07 at 22:39 +0000, Gervase Markham wrote: > I would have thought that the latter could be made true without too much > effort by using our wrapper around DBI to look up a name in a table and > convert it. It's been the most intense effort of my Bugzilla career, actually. I've been working on it for a week already. > And it seems odd that databases claim to support SQL and yet don't > understand the defined data types... Yes. Feel free to talk to the MySQL folks about why their database has hundreds of legacy customers whose lives would break into tiny bits if the database started suddenly strictly supporting ANSI SQL. :-) And, of course, we still support MySQL 3, which is a deprecated system. (Believe me, I've run into MANY other interesting problems that have not been discussed in the list, but just silently worked-around in Bugzilla or during my development cycle.) > Our code may be that scrupulous... but other people's might not. OK, so > we could claim that people hacking the database are on their own and > deserve what they get, but we haven't claimed that thusfar. Our code would never affect other people who hack the database. Their schema would live separately from our schema. We're only concerned about updating the tables, which is the same as what we've always done. The new method would not affect people who hack the database themselves. At the least, it wouldn't change anything from how checksetup currently interacts with those users. -Max -- Max Kanat-Alexander Technical Support Manager, USA Kerio Technologies, Inc. 2350 Mission College Blvd., Suite 400 Santa Clara, CA 95054 Phone: (408) 496-4500 Fax: (408) 496-6902 http://www.kerio.com/support.html From timeless at myrealbox.com Mon Mar 7 22:59:12 2005 From: timeless at myrealbox.com (timeless) Date: Mon, 07 Mar 2005 14:59:12 -0800 Subject: UI hackathon proposal In-Reply-To: <4229157B.7010305@mozilla.org> References: <4229157B.7010305@mozilla.org> Message-ID: <422CDCC0.90703@myrealbox.com> Myk Melez wrote: > I'd like to get started in a couple of weeks and hold one hackathon per > week on the same weekday every week (Friday?) from about 9am-6pm PST > (GMT-08:00) until the five components mentioned above have all been > hacked, targeting this work to the Bugzilla 2.22 release. hrm. fridays suck for me, because i turn into a pumpkin (~4pm). thursdays are much better, i have a tendency to stay up late. it's probably best for me to be around at the beginning to poke people w/ problems at the beginning (i love filing small bugs) and help at the end (reviews or small patches for missed items). From gerv at mozilla.org Mon Mar 7 23:58:33 2005 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 07 Mar 2005 23:58:33 +0000 Subject: UI hackathon proposal In-Reply-To: <422CDCC0.90703@myrealbox.com> References: <4229157B.7010305@mozilla.org> <422CDCC0.90703@myrealbox.com> Message-ID: <422CEAA9.2050005@mozilla.org> timeless wrote: > hrm. fridays suck for me, because i turn into a pumpkin (~4pm). Fridays are good for me; I can stay up late (my time) without worrying about work the following day. Gerv From jake at bugzilla.org Tue Mar 8 17:04:20 2005 From: jake at bugzilla.org (Jake) Date: Tue, 08 Mar 2005 12:04:20 -0500 Subject: The State of 2.20 In-Reply-To: <4226000C.5060508@bugzilla.org> References: <1109755793.9361.3.camel@max.localdomain> <4226000C.5060508@bugzilla.org> Message-ID: <422DDB14.80407@bugzilla.org> The list now has 21 waiting for reviews.... https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc=&product=Bugzilla&target_milestone=Bugzilla+2.20&resolution=---&cmdtype=doit&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=review%3F Shameless plug: I'd like to get mine reviewed if anybody has an opportunity. It is a simple patch :) https://bugzilla.mozilla.org/show_bug.cgi?id=83044 Jake wrote: > And, for the curious, here's a list of 19 bugs that are targeted for > 2.20 and waiting on review :) > > https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc=&product=Bugzilla&target_milestone=Bugzilla+2.20&resolution=---&cmdtype=doit&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=review%3F > > > Maxwell Kanat-Alexander wrote: > >> So, our planned freeze date for 2.20 is still at March 15th, last >> time >> I talked to Dave. >> >> Here is a report that lists all the bugs targeted for 2.20, their >> current Assignee, and their severity: >> >> http://tinyurl.com/7yalc >> >> If you have a bug assigned to you that is targeted for 2.20, and >> it's >> not going to make it in for 2.20, could you move it out to another >> milestone? >> >> If you have no real plans to work on the bug before Bugzilla >> 2.24, move >> it out to Future, and re-assign it to the component owner (or >> nobody at bugzilla.org, if the component owner is a real person). >> >> -Max >> >> > > - > To view or change your list settings, click here: > From mkanat at kerio.com Wed Mar 9 00:05:22 2005 From: mkanat at kerio.com (Max Kanat-Alexander) Date: Tue, 08 Mar 2005 16:05:22 -0800 Subject: Bug.pm Speed-Up Message-ID: <1110326722.5326.3.camel@localhost.localdomain> Hey! I've checked-in bug 282145, now: https://bugzilla.mozilla.org/show_bug.cgi?id=282145 This means that Bugzilla::Bug should be fast enough for "everyday" use, now. In general, try to create a Bugzilla::Bug from now on instead of querying the Bug tables directly. The only time that we don't want to yet do this yet is in buglist.cgi. (But that's OK, because that's Search.pm, anyhow, which is completely separate.) -Max From rpello at balicamp.com Tue Mar 8 12:19:40 2005 From: rpello at balicamp.com (Ray Mike Troy Pello) Date: Tue, 08 Mar 2005 19:19:40 +0700 Subject: Customization Message-ID: <422D985C.3050000@balicamp.com> Hullo, I am just wondering. If I have a question on customizing bugzilla for my company's needs should I ask here or on the IRC channel? thx Ray Pello From mkanat at kerio.com Wed Mar 9 00:21:43 2005 From: mkanat at kerio.com (Max Kanat-Alexander) Date: Tue, 08 Mar 2005 16:21:43 -0800 Subject: Customization In-Reply-To: <422D985C.3050000@balicamp.com> References: <422D985C.3050000@balicamp.com> Message-ID: <1110327704.5326.5.camel@localhost.localdomain> On Tue, 2005-03-08 at 19:19 +0700, Ray Mike Troy Pello wrote: > I am just wondering. If I have a question on customizing bugzilla for my > company's needs should I ask here or on the IRC channel? The IRC channel or on mozilla-webtools. See http://www.bugzilla.org/support/ Thank you for asking. :-) -Max From sundeep.kmr at wipro.com Mon Mar 7 11:44:38 2005 From: sundeep.kmr at wipro.com (sundeep.kmr at wipro.com) Date: Mon, 7 Mar 2005 17:14:38 +0530 Subject: regarding date display Message-ID: <201834AAB8BE6246A45166DFD66A3A0103B7D7@blr-m2-msg.wipro.com> An embedded message was scrubbed... From: Subject: RE: regarding date display Date: Mon, 7 Mar 2005 17:14:38 +0530 Size: 5050 URL: -------------- next part -------------- Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or Mailadmin at wipro.com immediately and destroy all copies of this message and any attachments. From n at ironport.com Wed Mar 9 01:49:15 2005 From: n at ironport.com (Nagendra Mishr) Date: Tue, 08 Mar 2005 17:49:15 -0800 Subject: Schema diagram and DHTML libraries In-Reply-To: <201834AAB8BE6246A45166DFD66A3A0103B7D7@blr-m2-msg.wipro.com> References: <201834AAB8BE6246A45166DFD66A3A0103B7D7@blr-m2-msg.wipro.com> Message-ID: <422E561B.2020107@ironport.com> Hi all, I did not notice a schema diagram in the cvs area. I have developed one for 2.18 and can provide it if you guys feel it would be useful. Also, I noticed that there is a need for to link the GD libraries to enable graphing. I wanted to share with you all my javascript and server side libraries for graphing pie, bar and line graphs in DHTML which removes the need to install these perl libraries. Let me know if there is interest and I can provide them. Nagendra From justdave at bugzilla.org Wed Mar 9 03:24:44 2005 From: justdave at bugzilla.org (David Miller) Date: Tue, 08 Mar 2005 22:24:44 -0500 Subject: Schema diagram and DHTML libraries In-Reply-To: <422E561B.2020107@ironport.com> References: <201834AAB8BE6246A45166DFD66A3A0103B7D7@blr-m2-msg.wipro.com> <422E561B.2020107@ironport.com> Message-ID: <422E6C7C.2070804@bugzilla.org> Nagendra Mishr wrote: > Hi all, I did not notice a schema diagram in the cvs area. I have > developed one for 2.18 and can provide it if you guys feel it would be > useful. We have one already, I thought. It's in the docs in the chapter about the schema :) Check in the docs/images directory. > Also, I noticed that there is a need for to link the GD libraries to > enable graphing. I wanted to share with you all my javascript and > server side libraries for graphing pie, bar and line graphs in DHTML > which removes the need to install these perl libraries. Let me know if > there is interest and I can provide them. That might be useful for some folks. We have a rule about making things work without javascript whenever possible, though. (Javascript is freely used to enhance the experience, but should never be depended on in order for something to work) -- 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 travis at SEDSystems.ca Wed Mar 9 03:44:21 2005 From: travis at SEDSystems.ca (Shane H. W. Travis) Date: Tue, 8 Mar 2005 21:44:21 -0600 (CST) Subject: Schema diagram and DHTML libraries In-Reply-To: <422E6C7C.2070804@bugzilla.org> References: <201834AAB8BE6246A45166DFD66A3A0103B7D7@blr-m2-msg.wipro.com> <422E561B.2020107@ironport.com> <422E6C7C.2070804@bugzilla.org> Message-ID: On Tue, 8 Mar 2005, David Miller wrote: > Nagendra Mishr wrote: > > > Hi all, I did not notice a schema diagram in the cvs area. I have > > developed one for 2.18 and can provide it if you guys feel it would be > > useful. > > We have one already, I thought. It's in the docs in the chapter about > the schema :) Check in the docs/images directory. We have one for 2.16. I haven't ever gotten around to making one for 2.18. If Nagendra's fits the bill, I'm not too proud to use hers instead of mine. :) https://bugzilla.mozilla.org/show_bug.cgi?id=275155 is the 2.18 schema bug. Shane H.W. Travis | The greatest of all mistakes is to do nothing travis at sedsystems.ca | because you can only do a little. Saskatoon, Saskatchewan | Do what you can. -- Sydney Smith From jremillardshop at letterboxes.org Wed Mar 9 04:54:21 2005 From: jremillardshop at letterboxes.org (Jason Remillard) Date: Tue, 08 Mar 2005 23:54:21 -0500 Subject: new problem with -Taint with CVS latest Message-ID: <422E817D.809@letterboxes.org> Hi, I have been having a problem with the latest (the tip of main branch) CVS version of bugzilla. When I hit index.cgi I get the following. Bugzilla has suffered an internal error. Please save this page and send it to jpr at clover with details of what you were doing at the time this message appeared. URL: http://clover/bugzilla/index.cgi Template->process() failed twice. First error: Insecure dependency in rename while running with -T switch at /usr/local/lib/perl/5.6.1/Template/Document.pm line 287. Second error: Insecure dependency in rename while running with -T switch at /usr/local/lib/perl/5.6.1/Template/Document.pm line 287. This was working ok last week. One of the check in over the past week or so has caused this problem. I was able to reproduce this on a clean checkout, so I don't think it is caused by any local changes. I am running a debain stable box. Template toolkit 2.08, perl version 5.6.1. The line in Document.pm looks like it is attempting to copy a compiled template back into the bugzilla directory. I ran checksetup.pl after I updated, so I don't know why it is even attempting to do this. Any Idea's? Thanks Jason. From bugzilla at glob.com.au Wed Mar 9 05:54:06 2005 From: bugzilla at glob.com.au (byron) Date: Wed, 9 Mar 2005 13:54:06 +0800 (WST) Subject: new problem with -Taint with CVS latest Message-ID: <20050309055406.CA2684BC791@sweep.bur.st> > I have been having a problem with the latest (the tip of main branch) > CVS version of bugzilla. When I hit index.cgi I get the following. > > Template->process() failed twice. > First error: Insecure dependency in rename while running with -T switch > at /usr/local/lib/perl/5.6.1/Template/Document.pm line 287. > Second error: Insecure dependency in rename while running with -T switch > at /usr/local/lib/perl/5.6.1/Template/Document.pm line 287. > > This was working ok last week. One of the check in over the past week or > so has caused this problem. I was able to reproduce this on a clean > checkout, so I don't think it is caused by any local changes. I am > running a debain stable box. Template toolkit 2.08, perl version 5.6.1. i'm running cvs tip, no taint issues (debian and windows). begin-base64 644 signature.gif R0lGODlhbQAHAIAAAABPo////ywAAAAAbQAHAAACfAxuGAnch+Bibkn7FL1p XgVl4Ig1jjlZRoqybgun2Cur5uOunq7u/Ipq7WIyIc7XG9JquEgumPzdlhTf h0O83kDJaXEm8mRHwXKJy5sac7qYOpT+gtv0n+0ujQOfdqh16caWt0foBViH N1PRMXimiLUGt3ElVimlgbllWAAAOw== ==== From mkanat at kerio.com Wed Mar 9 05:57:17 2005 From: mkanat at kerio.com (Max Kanat-Alexander) Date: Tue, 08 Mar 2005 21:57:17 -0800 Subject: The New Bugzilla::DB::Schema Message-ID: <1110347837.5326.12.camel@localhost.localdomain> OK, so thanks to Ed Sabol, we have a new way of storing our database tables and columns. In the past, you'd go into checksetup, and you'd modify the %tables hash with your new table and column definition. Now, instead, you modify the contents of the variable Bugzilla::DB::Schema::ABSTRACT_SCHEMA. The format is described in the Schema module itself, and it's fairly straightforward. If you have any trouble, just look at all the tables that currently exist. You don't need to know *anything* else about Bugzilla::DB::Schema, unless you're a Bugzilla::DB hacker. You still add upgrade code to checksetup in the same fashion that you always have, with the bz_add_field, bz_change_field_def, etc. statements above the last --TABLE-- statement. Those functions will change later, but they are not changing now. If you have any questions, you can probably catch me in IRC to ask. -Max From justdave at bugzilla.org Wed Mar 9 06:04:45 2005 From: justdave at bugzilla.org (David Miller) Date: Wed, 09 Mar 2005 01:04:45 -0500 Subject: Migrating templates to UTF-8? In-Reply-To: <421DB31A.4020700@myrealbox.com> References: <421CD72C.2070606@bugzilla.org> <421DB31A.4020700@myrealbox.com> Message-ID: <422E91FD.8080406@bugzilla.org> timeless wrote: > David Miller wrote: > >> I'm not sure offhand what CVS would do, I think it just treats it as >> 8-bit data, and probably slightly sloppily if it matches something >> that looks like an RCS keyword. I'm cross-posting this to the >> developers list as I don't think the localizers list has that big of >> an audience (and was really only intended for distributing >> template-related security information to the template authors prior to >> security releases). >> >> We do have UTF-8 data in CVS currently, both in the Bugzilla source >> code for contributors' names, as well as in the website source, and >> haven't run into any problems with it, but we might just be lucky. > > > http://www.devguy.com/fp/cfgmgmt/cvs/ > > Unicode Files > > UNICODE files must be marked BINARY; otherwise, CVS will corrupt them. If they contain something that looks like an RCS keyword. Marking them as binary means we lose the capability of running cvs diff on them, as well, which in most cases is a worse tradeoff. Time for a new SCM? :) (yeah, we're working on it) -- 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 n at ironport.com Wed Mar 9 17:15:41 2005 From: n at ironport.com (Nagendra Mishr) Date: Wed, 09 Mar 2005 09:15:41 -0800 Subject: Schema diagram and DHTML libraries In-Reply-To: <422E6C7C.2070804@bugzilla.org> References: <201834AAB8BE6246A45166DFD66A3A0103B7D7@blr-m2-msg.wipro.com> <422E561B.2020107@ironport.com> <422E6C7C.2070804@bugzilla.org> Message-ID: <422F2F3D.7060105@ironport.com> Dave, Since this only uses DHTML for the display, the code can be in either javascript or on serverside perl. The only thing is that you don't need to link the GD libraries.. (NOTE: graphinc capabilities are limited to fixed colors, line graphs, and bar graphs. no gradients, shading, etc...) Nagendra > That might be useful for some folks. We have a rule about making > things work without javascript whenever possible, though. (Javascript > is freely used to enhance the experience, but should never be depended > on in order for something to work) > From kevin.benton at amd.com Wed Mar 9 20:18:36 2005 From: kevin.benton at amd.com (Kevin Benton) Date: Wed, 9 Mar 2005 13:18:36 -0700 Subject: "Bugzilla is Down" after doing Edit Parameters? In-Reply-To: Message-ID: <20050309201836.538871FF3@ldcmail.amd.com> >From my perspective, this is problematic and should be changed to require a specific message such as "TURN OFF BUGZILLA" in the text box - otherwise, it should leave Bugzilla up/running. Any accidental keystroke in that field would shut Bugzilla down and it may take an administrator a significant amount of effort, as it did for Joseph, to figure out how to fix it the first time it happens to him/her. Something else we could/should do is any time there is something in a field like that one or the user disable field, we should ask the person making the change to confirm they really want the promised result, especially for something as significant as disabling the entire Bugzilla installation. Joseph - you may want to look at the Bugzilla Bug database on the link at http://www.bugzilla.org/ to see if a bug has been filed for just this very thing and if not, go ahead and file one. --- 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: mozilla-webtools-admin at mozilla.org [mailto:mozilla-webtools-admin at mozilla.org] On Behalf Of Jay Glanville Sent: Wednesday, March 09, 2005 12:35 PM To: Kershner, Joseph; mozilla-webtools at mozilla.org Subject: RE: "Bugzilla is Down" after doing Edit Parameters? Go back to the edit parameters page (for me, this is something like http://localhost/bugzilla/editparams.cgi) and look at the shutdownhtml parameter. If ANYTHING exists in this field, then bugzilla will say it's disabled. Remove the contents of this field. JDG PS: I'm assuming your using 2.18 or something very similar. _____ From: mozilla-webtools-admin at mozilla.org [mailto:mozilla-webtools-admin at mozilla.org] On Behalf Of Kershner, Joseph Sent: Wednesday, March 09, 2005 2:30 PM To: mozilla-webtools at mozilla.org Subject: "Bugzilla is Down" after doing Edit Parameters? I logged into my Bugzilla 2.18 and went to the Edit Parameters screen, where I made some changes/updates. I clicked the button to save my changes and there was a note (I think) saying that Bugzilla would be shut down to make the changes... Now when I go to my Bugzilla Start page, I am shown a page that says "Bugzilla is Down" and it shows the message I modified from the Edit Parameters screen. I didn't think Bugzilla itself ran any services/daemons. I restarted MySQL, then restarted Apache, and finally I rebooted my Linux box entirely. I still get the same "Bugzilla is Down" message. How in the f*&%$# do I 'restart' Bugzilla? Any help is appreciated. Thank you in advance, Joseph Kershner Senior Business Analyst, Renaissance Solutions Fidelity Integrated Financial Solutions Birmingham, AL (p) 205-408-4650, ext-1399 www.fidelityifs.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkanat at kerio.com Wed Mar 9 21:19:55 2005 From: mkanat at kerio.com (Max Kanat-Alexander) Date: Wed, 09 Mar 2005 13:19:55 -0800 Subject: "Bugzilla is Down" after doing Edit Parameters? In-Reply-To: <20050309201836.538871FF3@ldcmail.amd.com> References: <20050309201836.538871FF3@ldcmail.amd.com> Message-ID: <1110403195.10252.3.camel@localhost.localdomain> The solution here is to make "shutdown" into a radio button, and add a box below it for a message that admins can present for why Bugzilla is shut down. -Max -- Max Kanat-Alexander Technical Support Manager, USA Kerio Technologies, Inc. 2350 Mission College Blvd., Suite 400 Santa Clara, CA 95054 Phone: (408) 496-4500 Fax: (408) 496-6902 http://www.kerio.com/support.html From justdave at bugzilla.org Wed Mar 9 21:46:23 2005 From: justdave at bugzilla.org (David Miller) Date: Wed, 09 Mar 2005 16:46:23 -0500 Subject: "Bugzilla is Down" after doing Edit Parameters? In-Reply-To: <1110403195.10252.3.camel@localhost.localdomain> References: <20050309201836.538871FF3@ldcmail.amd.com> <1110403195.10252.3.camel@localhost.localdomain> Message-ID: <422F6EAF.6090002@bugzilla.org> Max Kanat-Alexander wrote: > The solution here is to make "shutdown" into a radio button, and add a > box below it for a message that admins can present for why Bugzilla is > shut down. Yeah, I agree wholeheartedly here. We should do the same with the disabledtext on user accounts, too. Both of those changes would make the SQL a lot simpler for determining if the system is shut down, too, in a cross-DB world. Some databases aren't the greatest at detecting empty strings. :) -- 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 bugreport at peshkin.net Thu Mar 10 00:02:37 2005 From: bugreport at peshkin.net (Joel Peshkin) Date: Wed, 09 Mar 2005 16:02:37 -0800 Subject: "Bugzilla is Down" after doing Edit Parameters? In-Reply-To: <422F6EAF.6090002@bugzilla.org> References: <20050309201836.538871FF3@ldcmail.amd.com> <1110403195.10252.3.camel@localhost.localdomain> <422F6EAF.6090002@bugzilla.org> Message-ID: <422F8E9D.6090200@peshkin.net> David Miller wrote: > Max Kanat-Alexander wrote: > >> The solution here is to make "shutdown" into a radio button, and >> add a >> box below it for a message that admins can present for why Bugzilla is >> shut down. > > > Yeah, I agree wholeheartedly here. We should do the same with the > disabledtext on user accounts, too. Both of those changes would make > the SQL a lot simpler for determining if the system is shut down, too, > in a cross-DB world. Some databases aren't the greatest at detecting > empty strings. :) > Actually, while we are at it.... It would be nice if it were possible to do a "partial" shutdown where only a certain group of users has Bugzilla access and others see it as shutdown. From mkanat at kerio.com Thu Mar 10 00:28:43 2005 From: mkanat at kerio.com (Max Kanat-Alexander) Date: Wed, 09 Mar 2005 16:28:43 -0800 Subject: "Bugzilla is Down" after doing Edit Parameters? In-Reply-To: <422F8E9D.6090200@peshkin.net> References: <20050309201836.538871FF3@ldcmail.amd.com> <1110403195.10252.3.camel@localhost.localdomain> <422F6EAF.6090002@bugzilla.org> <422F8E9D.6090200@peshkin.net> Message-ID: <1110414523.10973.6.camel@localhost.localdomain> On Wed, 2005-03-09 at 16:02 -0800, Joel Peshkin wrote: > It would be nice if it were possible to do a "partial" shutdown where > only a certain group of users has Bugzilla access and others see it as > shutdown. *mkanat clears his throat* "I really think that should be a separate bug." :-D -Max From Tomas.Kopal at altap.cz Thu Mar 10 10:19:13 2005 From: Tomas.Kopal at altap.cz (Tomas Kopal) Date: Thu, 10 Mar 2005 20:49:13 +1030 Subject: "Bugzilla is Down" after doing Edit Parameters? In-Reply-To: <422F6EAF.6090002@bugzilla.org> References: <20050309201836.538871FF3@ldcmail.amd.com> <1110403195.10252.3.camel@localhost.localdomain> <422F6EAF.6090002@bugzilla.org> Message-ID: <42301F21.8000000@altap.cz> And what about also adding some instructions (maybe even link) how to "restart" or re-enable bugzilla on the shutdown page? Tomas On 03/10/05 08:16, David Miller wrote: > Max Kanat-Alexander wrote: > >> The solution here is to make "shutdown" into a radio button, and >> add a >> box below it for a message that admins can present for why Bugzilla is >> shut down. > > > Yeah, I agree wholeheartedly here. We should do the same with the > disabledtext on user accounts, too. Both of those changes would make > the SQL a lot simpler for determining if the system is shut down, too, > in a cross-DB world. Some databases aren't the greatest at detecting > empty strings. :) > From ghendricks at novell.com Thu Mar 10 19:50:05 2005 From: ghendricks at novell.com (Greg Hendricks) Date: Thu, 10 Mar 2005 12:50:05 -0700 Subject: UI hackathon proposal In-Reply-To: <4229157B.7010305@mozilla.org> References: <4229157B.7010305@mozilla.org> Message-ID: <200503101250.06163.ghendricks@novell.com> On Friday 04 March 2005 19:12, Myk Melez wrote: > I'd like to get started in a couple of weeks and hold one hackathon per > week on the same weekday every week (Friday?) from about 9am-6pm PST > (GMT-08:00) until the five components mentioned above have all been > hacked, targeting this work to the Bugzilla 2.22 release. Fridays are good for me. Count me in. From gerv at mozilla.org Thu Mar 10 22:11:58 2005 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 10 Mar 2005 22:11:58 +0000 Subject: The New Bugzilla::DB::Schema In-Reply-To: <1110347837.5326.12.camel@localhost.localdomain> References: <1110347837.5326.12.camel@localhost.localdomain> Message-ID: <4230C62E.4080809@mozilla.org> Max Kanat-Alexander wrote: > In the past, you'd go into checksetup, and you'd modify the %tables > hash with your new table and column definition. > > Now, instead, you modify the contents of the variable > Bugzilla::DB::Schema::ABSTRACT_SCHEMA. Is there any chance of more of a heads-up about this sort of change, given that it automatically obsoletes every patch which modifies the schema? I spent a few hours last night updating the patch on bug 73665 so you can review it, and instead you appear to have checked something in which breaks it... I would laugh, but given that I'm now on the 10th iteration of the patch, the joke is wearing a little thin. So I'm just smiling :-). Please a) could we have a bit more warning about patch-breaking patches, and b) could you review my patch? :-) Gerv From travis at SEDSystems.ca Thu Mar 10 22:32:14 2005 From: travis at SEDSystems.ca (Shane H. W. Travis) Date: Thu, 10 Mar 2005 16:32:14 -0600 (CST) Subject: The New Bugzilla::DB::Schema In-Reply-To: <4230C62E.4080809@mozilla.org> References: <1110347837.5326.12.camel@localhost.localdomain> <4230C62E.4080809@mozilla.org> Message-ID: On Thu, 10 Mar 2005, Gervase Markham wrote: > Is there any chance of more of a heads-up about this sort of change, > given that it automatically obsoletes every patch which modifies the > schema? ... > Please a) could we have a bit more warning about patch-breaking patches, Honest question: why? I understand that it's frustrating when someone else's patch invalidates yours and you have to go back and fix the bitrot *again*. (This change also broke my patch on bug 98123, causing me to have to update the patch to v7 so I know where you're coming from. But as I said... even if one knew it was coming, what good would it do? *Someone* has to do the work of making the code in patch A play nice with the code in patch B wherever they conflict. It's just as frustrating for the Patch A author when someone checks in yet another !@$%# patch that they have to adapt and move. So as I said, I'm wondering... what good would it do to have more advance notice? Mental preparation -- steeling oneself to the fact that one's patch isn't going to land *this* time either? Incentive to work faster so your patch lands first, this forcing the other guy do the work instead of you? I really don't know, and I'm curious. Shane H.W. Travis | The greatest of all mistakes is to do nothing travis at sedsystems.ca | because you can only do a little. Saskatoon, Saskatchewan | Do what you can. -- Sydney Smith From mkanat at kerio.com Thu Mar 10 22:37:12 2005 From: mkanat at kerio.com (Max Kanat-Alexander) Date: Thu, 10 Mar 2005 14:37:12 -0800 Subject: The New Bugzilla::DB::Schema In-Reply-To: <4230C62E.4080809@mozilla.org> References: <1110347837.5326.12.camel@localhost.localdomain> <4230C62E.4080809@mozilla.org> Message-ID: <1110494232.14464.8.camel@localhost.localdomain> On Thu, 2005-03-10 at 22:11 +0000, Gervase Markham wrote: > Is there any chance of more of a heads-up about this sort of change, > given that it automatically obsoletes every patch which modifies the > schema? Yeah, sorry. I'd mentioned it in IRC a few times, but I'll try to give advance warning in the future. At the moment it's a bit hard -- I'm posting between 5 - 10 patches a day for PostgreSQL support, and I tend to have no idea when things will go in. I could have warned you five months ago about the Schema, but it would have been way too far in advance. And of course I didn't write it, so I had no idea when the patches were coming. I did review it, but I had no idea when I would give it r+, and then when it would get a+. Next time, though, I'll try to send out warnings about large changes at the time that I give them r+. > b) could you review my patch? :-) I will. At the moment, I'm slightly worried that it will conflict with my work on bug 278455 (which I'm planning on getting to for 2.22), and that I'll have to re-write it all anyhow. -Max From gerv at mozilla.org Thu Mar 10 23:29:30 2005 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 10 Mar 2005 23:29:30 +0000 Subject: Admin pages may now require JS. Message-ID: <4230D85A.9080406@mozilla.org> The results of https://bugzilla.mozilla.org/show_bug.cgi?id=284901 are in: admin pages may now require JS to function correctly. In deference to scripting requirements, the submitted URL params should be simple, and ideally all the data should be present in the original page in case someone wants to parse it using an external script which doesn't have a JS engine. Gerv From gerv at mozilla.org Thu Mar 10 23:52:06 2005 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 10 Mar 2005 23:52:06 +0000 Subject: The New Bugzilla::DB::Schema In-Reply-To: <1110494232.14464.8.camel@localhost.localdomain> References: <1110347837.5326.12.camel@localhost.localdomain> <4230C62E.4080809@mozilla.org> <1110494232.14464.8.camel@localhost.localdomain> Message-ID: <4230DDA6.1030906@mozilla.org> Max Kanat-Alexander wrote: > > Yeah, sorry. I'd mentioned it in IRC a few times, but I'll try to give > advance warning in the future. Thanks :-) >>b) could you review my patch? :-) > > I will. At the moment, I'm slightly worried that it will conflict with > my work on bug 278455 (which I'm planning on getting to for 2.22), and > that I'll have to re-write it all anyhow. Come on, dude - after 1.5 years, and being bumped by multiple other patches, surely I get first go this time? :-) Gerv From gerv at mozilla.org Thu Mar 10 23:54:55 2005 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 10 Mar 2005 23:54:55 +0000 Subject: The New Bugzilla::DB::Schema In-Reply-To: References: <1110347837.5326.12.camel@localhost.localdomain> <4230C62E.4080809@mozilla.org> Message-ID: <4230DE4F.2020209@mozilla.org> Shane H. W. Travis wrote: > *Someone* has to do the work of making the code in patch A play nice with > the code in patch B wherever they conflict. It's just as frustrating for the > Patch A author when someone checks in yet another !@$%# patch that they have > to adapt and move. Hmm... This is why Mozilla used to have a branch landing tool, so people could queue up and know whose code they had to merge and what order they were in. Perhaps something like that would be good? Currently, it's a case of "whoever has most time to get on IRC and find a reviewer get there first", which seems a bit unfair for those of us who have to spend time saving the world[0] as well as writing Bugzilla code. ;-) Gerv [0] http://weblogs.mozillazine.org/gerv/archives/007556.html From travis at SEDSystems.ca Fri Mar 11 06:30:17 2005 From: travis at SEDSystems.ca (Shane H. W. Travis) Date: Fri, 11 Mar 2005 00:30:17 -0600 (CST) Subject: The New Bugzilla::DB::Schema In-Reply-To: <4230DE4F.2020209@mozilla.org> References: <1110347837.5326.12.camel@localhost.localdomain> <4230C62E.4080809@mozilla.org> <4230DE4F.2020209@mozilla.org> Message-ID: On Thu, 10 Mar 2005, Gervase Markham wrote: > Shane H. W. Travis wrote: > > *Someone* has to do the work of making the code in patch A play nice with > > the code in patch B wherever they conflict. > > Hmm... This is why Mozilla used to have a branch landing tool, so people > could queue up and know whose code they had to merge and what order they > were in. Perhaps something like that would be good? Could be... but I don't understand how it would help in your situation. If Patch A was in the queue first, but Patch B -- which was behind it in the queue, and touched the same code -- was ready to land, would Patch B be held up until Developer A got his all polished up? Also, at what point does one get to put one's patch 'into the queue' so that nobody else is allowed to break something that this patch touches? - Once you've ASSIGNED the bug to yourself - Once you've got a patch ready - Once you've got an r+ - Once you've got an a+ #1 is ridiculous; people take bugs all the time, and sometimes don't work on them for years. #2 isn't quite as ridiculous, but sometimes there's a loooong time between when that first patch comes down, and then the last one is ready to land. (What did you say, 1.5 years already in your case?) Also, the last patch sometimes bears little resemblance to the first. #3 and #4 seem reasonable, but are already pretty much in line with current practices, which I infer you don't like. ("Currently, it's a case of 'whoever has most time to get on IRC and find a reviewer get there first'...") Furthermore, having a queue doesn't stop conflicts; someone still has to merge Patch A into Patch B -- or the other way around -- only now it depends on who gets into the queue first rather than who lands first. I don't see how this presents any benefit; it just seems to add another layer of complexity (and perhaps frustration) to the process. For those who don't hang on IRC and therefore haven't heard my statistics, this has been the most fertile period in Bugzilla's development history *ever*. Developers have landed fixes on almost three *hundred* bugs in the first 70 days of this calendar year; that's more than half as many as were fixed in all of 2004 (575), and almost as many as were fixed in 2003 (371). We'll probably surpass the latter total before March is out. So... yes; patches sure can bitrot fast these days. That's damnably frustrating when it's one's own patch that one is re-writing, no doubt about it. In the grand scheme of things, though, it's an impressive tribute to just how strong and healthy the development team is right now. Shane H.W. Travis | The greatest of all mistakes is to do nothing travis at sedsystems.ca | because you can only do a little. Saskatoon, Saskatchewan | Do what you can. -- Sydney Smith From mkanat at kerio.com Fri Mar 11 09:27:01 2005 From: mkanat at kerio.com (Max Kanat-Alexander) Date: Fri, 11 Mar 2005 01:27:01 -0800 Subject: Future Checksetup Changes (First Heads-Up Attempt :-)) Message-ID: <1110533221.14464.26.camel@localhost.localdomain> Very soon, important checksetup functions will be changing. I hope that this happens before the freeze. It's bug 285111, for anybody who's interested. They are not just changing names, they are changing functionality. Instead of taking/returning a string for a column type, they take/return a hash in the style of the column/index definitions in Bugzilla::DB::Schema. That's the only real functional change. Here is a table of functions that you should use instead of old functions, for new patches: Old New --- --- No Parameter Changes $dbh->bz_get_field_def $dbh->bz_column_info $dbh->bz_get_index_def $dbh->bz_index_info $dbh->bz_rename_field $dbh->bz_rename_column Parameter Changes $dbh->bz_add_field $dbh->bz_add_column $dbh->bz_change_field_type $dbh->bz_alter_column $dbh->bz_drop_field $dbh->bz_drop_column I'm not going to re-implement bz_drop_table_indexes until somebody actually needs it. -Max From etzwane at schwag.org Fri Mar 11 15:03:26 2005 From: etzwane at schwag.org (Sean McAfee) Date: Fri, 11 Mar 2005 10:03:26 -0500 Subject: Custom Fields stuff In-Reply-To: <41FD7EE4.5050508@bugzilla.org> Message-ID: <20050311150326.6EEADBC77@mail.schwag.org> David Miller wrote: >Just a quick note to let everyone know (in case you didn't already know >through other channels) that I was offline most of last week, and the >custom fields related threads seem to have exploded while I was gone. >The size of that explosion can only mean there's debate going on (and >I've heard that there is from other folks, too), and there's probably >something I need to settle. That said, I'm now faced with a huge amount >of reading to get caught up. If you all could give me a day or two yet >to get caught up before you all explode on each other, I'd appreciate >it. Then I'll chime in and let you know where I stand on this. I don't mean to be pushy, but is this going to happen anytime soon? --Sean From gerv at mozilla.org Sat Mar 12 19:44:49 2005 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 12 Mar 2005 19:44:49 +0000 Subject: The New Bugzilla::DB::Schema In-Reply-To: References: <1110347837.5326.12.camel@localhost.localdomain> <4230C62E.4080809@mozilla.org> <4230DE4F.2020209@mozilla.org> Message-ID: <423346B1.2070108@mozilla.org> Shane H. W. Travis wrote: > #2 isn't quite as ridiculous, but sometimes there's a loooong time between > when that first patch comes down, and then the last one is ready to land. > (What did you say, 1.5 years already in your case?) Also, the last patch > sometimes bears little resemblance to the first. I think it should be possible, once you've got a reviewer lined up, to say "Fred and I are working on this patch which is really sensitive in BugMail.pm. Can people hold off checking in there for a week or two?" (That is true of my patch, BTW, everyone :-) > So... yes; patches sure can bitrot fast these days. That's damnably > frustrating when it's one's own patch that one is re-writing, no doubt about > it. In the grand scheme of things, though, it's an impressive tribute to > just how strong and healthy the development team is right now. True enough; I'm just asking that the hyperactive developers share the love around a bit, rather than repeatedly leaving people eating their dust as they speed off into the sunset ;-) Gerv From gerv at mozilla.org Sat Mar 12 20:08:49 2005 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 12 Mar 2005 20:08:49 +0000 Subject: Future Checksetup Changes (First Heads-Up Attempt :-)) In-Reply-To: <1110533221.14464.26.camel@localhost.localdomain> References: <1110533221.14464.26.camel@localhost.localdomain> Message-ID: <42334C51.7080503@mozilla.org> Max Kanat-Alexander wrote: > Very soon, important checksetup functions will be changing. I hope that > this happens before the freeze. It's bug 285111, for anybody who's > interested. Thank you for the heads-up. :-) I hope you'll be able to review my patch before you do this. ;-) Gerv From gerv at mozilla.org Sat Mar 12 20:14:18 2005 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 12 Mar 2005 20:14:18 +0000 Subject: [Fwd: Re: Bugsilla users] Message-ID: <42334D9A.6090407@mozilla.org> FYI - feedback from a guy who emailed me to say he was using Bugzilla, and then emailed three hours later to tell me to take him off the list as he was now using Mantis. Gerv -------- Original Message -------- Subject: Re: Bugsilla users Date: Sat, 12 Mar 2005 22:09:13 +0200 From: Mikhail Barashkov To: Gervase Markham References: <4231E979.3070908 at handydev.com> <4232DEF9.2030609 at mozilla.org> <4232FF33.5000408 at handydev.com> <42332D5F.1010709 at mozilla.org> > Do you have any more specific feedback on the features you found > Bugzilla didn't have? > > Gerv > Gerv, it's just the UI. It's terrible. I don't have other words. I'm just very surprised that the same team that created Firefox created Bugzilla. Hope you will improve it in the feature and I'll get back, because I like the overall mozilla* style. Mikhail From justdave at bugzilla.org Sat Mar 12 20:43:37 2005 From: justdave at bugzilla.org (David Miller) Date: Sat, 12 Mar 2005 15:43:37 -0500 Subject: Session Inactivity timeout In-Reply-To: <20050207154250.5B7091FB1@ldcmail.amd.com> References: <20050207154250.5B7091FB1@ldcmail.amd.com> Message-ID: <42335479.3070006@bugzilla.org> Kevin Benton wrote: > Gerv answered you on Saturday. There is no session timeout. That's actually not true. Your session times out in 30 days. And that is configurable via the params in newer versions of Bugzilla to determine if you want it to be until that 30 days is up or until the user quits their browser. -- 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 sundeep.kmr at wipro.com Mon Mar 14 12:47:22 2005 From: sundeep.kmr at wipro.com (sundeep.kmr at wipro.com) Date: Mon, 14 Mar 2005 18:17:22 +0530 Subject: Regarding generation of reports.... Message-ID: <201834AAB8BE6246A45166DFD66A3A0103B7F7@blr-m2-msg.wipro.com> hi developers, Sorry for asking this question. if anybody can help..plz do it? I have customized Bugzilla-2.19.1 for my requierments & added some new fields. and i want these fields also should be there in all reports(graphical,tabular). what should be done for this? plz Help me out Thanks & Regards Sundeep Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or Mailadmin at wipro.com immediately and destroy all copies of this message and any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From myk at mozilla.org Tue Mar 15 02:30:06 2005 From: myk at mozilla.org (Myk Melez) Date: Mon, 14 Mar 2005 18:30:06 -0800 Subject: UI hackathon proposal In-Reply-To: <4229157B.7010305@mozilla.org> References: <4229157B.7010305@mozilla.org> Message-ID: <423648AE.8020902@mozilla.org> Myk Melez wrote: > I'd like to accelerate improvements to the Bugzilla user interface > with weekly UI hackathons over the next couple of months. Based on responses I've received so far, it looks like Friday's the best day for these. The trunk closes tomorrow and stays that way until 2.20rc1 gets released in a couple of weeks. We'll hold the first hackathon the first Friday after it opens back up (barring unforeseen scheduling conflicts). In the meantime, we have to pick a component to tackle first: home, search, search results, show bug, or the site navigation. I'd like to start with a simpler page to make the process easier while we're working it out, perhaps search, which has already received heavy UI optimization. Suggestions welcome. -myk From myk at mozilla.org Tue Mar 15 02:39:42 2005 From: myk at mozilla.org (Myk Melez) Date: Mon, 14 Mar 2005 18:39:42 -0800 Subject: [Fwd: Re: Bugsilla users] In-Reply-To: <42334D9A.6090407@mozilla.org> References: <42334D9A.6090407@mozilla.org> Message-ID: <42364AEE.7070603@mozilla.org> Mikhail, I'm the UI module owner for Bugzilla, responsible for all aspects of Bugzilla's user interface, and Gerv shared with me your email below in which you called Bugzilla's UI terrible. I want Bugzilla to have the best UI of any bug tracker on the planet, so if you have specific problems with Bugzilla's usability or appearance, then please let me know what they are so that I can make sure they get tracked and resolved. Regards, Myk Melez Gervase Markham wrote: > -------- Original Message -------- > Subject: Re: Bugsilla users > Date: Sat, 12 Mar 2005 22:09:13 +0200 > From: Mikhail Barashkov > To: Gervase Markham > References: <4231E979.3070908 at handydev.com> > <4232DEF9.2030609 at mozilla.org> <4232FF33.5000408 at handydev.com> > <42332D5F.1010709 at mozilla.org> > > >> Do you have any more specific feedback on the features you found >> Bugzilla didn't have? >> >> Gerv >> > Gerv, it's just the UI. It's terrible. I don't have other words. I'm > just very surprised that the same team that created Firefox created > Bugzilla. > Hope you will improve it in the feature and I'll get back, because I > like the overall mozilla* style. > Mikhail > > - > To view or change your list settings, click here: > > From bugzilla at glob.com.au Tue Mar 15 02:44:13 2005 From: bugzilla at glob.com.au (byron) Date: Tue, 15 Mar 2005 10:44:13 +0800 (WST) Subject: UI hackathon proposal Message-ID: <20050315024413.0D7EC4BC12B@sweep.bur.st> > In the meantime, we have to pick a component to tackle first: home, > search, search results, show bug, or the site navigation. I'd like to > start with a simpler page to make the process easier while we're working > it out, perhaps search, which has already received heavy UI > optimization. Suggestions welcome. i wouldn't pitch search as a simple page :) site navigation gets my vote. begin-base64 644 signature.gif R0lGODlhbQAHAIAAAABPo////ywAAAAAbQAHAAACfAxuGAnch+Bibkn7FL1p XgVl4Ig1jjlZRoqybgun2Cur5uOunq7u/Ipq7WIyIc7XG9JquEgumPzdlhTf h0O83kDJaXEm8mRHwXKJy5sac7qYOpT+gtv0n+0ujQOfdqh16caWt0foBViH N1PRMXimiLUGt3ElVimlgbllWAAAOw== ==== From mkanat at kerio.com Tue Mar 15 03:07:46 2005 From: mkanat at kerio.com (Maxwell Kanat-Alexander) Date: Mon, 14 Mar 2005 19:07:46 -0800 Subject: UI hackathon proposal In-Reply-To: <423648AE.8020902@mozilla.org> References: <4229157B.7010305@mozilla.org> <423648AE.8020902@mozilla.org> Message-ID: <1110856066.9190.0.camel@max.localdomain> On Mon, 2005-03-14 at 18:30 -0800, Myk Melez wrote: > In the meantime, we have to pick a component to tackle first: home, > search, search results, show bug, or the site navigation. I'd like to > start with a simpler page to make the process easier while we're working > it out, perhaps search, which has already received heavy UI > optimization. Suggestions welcome. I think it's not the simplest page, but the primary page that needs better UI is show_bug, no doubt about it. Probably a second or third one to tackle. -Max -- Max Kanat-Alexander Technical Support Manager, USA Kerio Technologies, Inc. 2350 Mission College Blvd., Suite 400 Santa Clara, CA 95054 Phone: (408) 496-4500 Fax: (408) 496-6902 http://www.kerio.com/support.html From justdave at bugzilla.org Tue Mar 15 03:15:03 2005 From: justdave at bugzilla.org (David Miller) Date: Mon, 14 Mar 2005 22:15:03 -0500 Subject: 2.20 Feature Freeze and 2.18.1/2.19.3 release Message-ID: <42365337.9090301@bugzilla.org> As many of you may remember, we freeze for version 2.20 tomorrow. Here's the plan. I'm probably going to wait to enforce the freeze until late in the day because several people seem to have major projects pending that are this[]close to landing, and would be very painful to suddenly put those on hold for 2 or 3 weeks. But nonetheless, freeze starts sometime tomorrow. I'd like to release 2.18.1 and 2.19.3 this coming weekend. To make that happen requires a bunch of volunteers to help out with website updates, release notes, and getting a status update ready to go and so forth. I'd like Max Kanat to coordinate that, so get with him if you want to help. The blocking2.20 flag has returned. If you know of any bugs that you think should be considered to be release blockers, please request that flag. I expect the release of 2.19.3 to generate a lot of new blocking2.20 bugs. We'll create the 2.20 branch, release 2.20rc1, and reopen the trunk as soon as we get all the blocking2.20+ bugs dealt with. hopefully that'll be within a few weeks. -- 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 kerio.com Tue Mar 15 03:48:22 2005 From: mkanat at kerio.com (Maxwell Kanat-Alexander) Date: Mon, 14 Mar 2005 19:48:22 -0800 Subject: Checksetup can Create A PostgreSQL Database Message-ID: <1110858502.9631.7.camel@max.localdomain> Hey developers. So, as of a few days ago, checksetup can now successfully complete an initial run on PostgreSQL. This means that it can create all the database tables, and set up the initial product. So, if you'd like to help test PostgreSQL support, you may. HOWEVER, BE WARNED: YOU CANNOT UPGRADE FROM THIS VERSION ON POSTGRESQL. So DO NOT USE POSTGRESQL IN A PRODUCTION ENVIRONMENT. In order to upgrade your PostgreSQL database from this version, I can ABSOLUTELY promise you that you will have to DROP THE DATABASE. In fact, if you're going to track CVS development with the database, I'd recommend dropping it every few days and re-creating it, just to stay in sync. Before you file any bugs against PostgreSQL support, please look over the already-filed open blockers that we know about: If you file a new bug about PostgreSQL support, please make it block bug 98304, and CC myself and Tomas.Kopal. If you have any questions about PostgreSQL support, you can ask me in IRC (if I'm around). -Max -- Max Kanat-Alexander Technical Support Manager, USA Kerio Technologies, Inc. 2350 Mission College Blvd., Suite 400 Santa Clara, CA 95054 Phone: (408) 496-4500 Fax: (408) 496-6902 http://www.kerio.com/support.html From ghendricks at novell.com Tue Mar 15 16:14:53 2005 From: ghendricks at novell.com (Greg Hendricks) Date: Tue, 15 Mar 2005 09:14:53 -0700 Subject: UI hackathon proposal In-Reply-To: <1110856066.9190.0.camel@max.localdomain> References: <4229157B.7010305@mozilla.org> <423648AE.8020902@mozilla.org> <1110856066.9190.0.camel@max.localdomain> Message-ID: <200503150914.53160.ghendricks@novell.com> On Monday 14 March 2005 20:07, Maxwell Kanat-Alexander wrote: > On Mon, 2005-03-14 at 18:30 -0800, Myk Melez wrote: > > In the meantime, we have to pick a component to tackle first: home, > > search, search results, show bug, or the site navigation. I'd like to > > start with a simpler page to make the process easier while we're working > > it out, perhaps search, which has already received heavy UI > > optimization. Suggestions welcome. > > I think it's not the simplest page, but the primary page that needs > better UI is show_bug, no doubt about it. > > Probably a second or third one to tackle. Agreed, both the advanced search and show_bug pages are probably the most critical. Of course we are going to need to have some direction to go on these. When do we plan on having this discussion? (or has it been going on somewhere that I am not aware of? ) I have some suggestions which are pretty much summed up by looking at how we have changed the layout at bugzilla.novell.com (of course I am a bit partial to that system myself ;-) In all honesty though I would like to know what people think and get the discussion flowing a little. It might be a good idea to set up a bugzillaUI channel in IRC while we are doing the hackathon so as not to choke the regular channel. Just a suggestion. -- Greg From stu at asyn.com Tue Mar 15 16:27:22 2005 From: stu at asyn.com (Stuart Donaldson) Date: Tue, 15 Mar 2005 08:27:22 -0800 Subject: Custom Fields stuff In-Reply-To: <20050311150326.6EEADBC77@mail.schwag.org> References: <20050311150326.6EEADBC77@mail.schwag.org> Message-ID: <42370CEA.2090006@asyn.com> Sean McAfee wrote: >David Miller wrote: > > >>Just a quick note to let everyone know (in case you didn't already know >>through other channels) that I was offline most of last week, and the >>custom fields related threads seem to have exploded while I was gone. >>The size of that explosion can only mean there's debate going on (and >>I've heard that there is from other folks, too), and there's probably >>something I need to settle. That said, I'm now faced with a huge amount >>of reading to get caught up. If you all could give me a day or two yet >>to get caught up before you all explode on each other, I'd appreciate >>it. Then I'll chime in and let you know where I stand on this. >> >> > >I don't mean to be pushy, but is this going to happen anytime soon? > > > Also, not wanting to be pushy, but I have noticed someone else working on bug https://bugzilla.mozilla.org/show_bug.cgi?id=91037 If guidance and wisdom is about to be shared on this topic, I am sure that the recent contributors to the bug would appreciate seeing such guidance before they go down yet another private path at implementing custom fields. From myk at mozilla.org Tue Mar 15 17:36:24 2005 From: myk at mozilla.org (Myk Melez) Date: Tue, 15 Mar 2005 09:36:24 -0800 Subject: UI hackathon proposal In-Reply-To: <200503150914.53160.ghendricks@novell.com> References: <4229157B.7010305@mozilla.org> <423648AE.8020902@mozilla.org> <1110856066.9190.0.camel@max.localdomain> <200503150914.53160.ghendricks@novell.com> Message-ID: <42371D18.7000107@mozilla.org> Greg Hendricks wrote: >Of course we are going to need to have some direction to go on these. When do >we plan on having this discussion? (or has it been going on somewhere that I >am not aware of? ) > We'll spend time during the UI hackathon going over previous proposals and work in bugs, this mailing list, and CVS branches and making decisions on what to tackle. If you have ideas you want the hackathoners to consider, the best thing to do is file bugs on them in the UI component. File one bug per suggestion, making each one as specific and discrete as possible. Then interested folks can review and discuss them before the hackathon. >It might be a good idea to set up a bugzillaUI channel in IRC while we are >doing the hackathon so as not to choke the regular channel. > > Great idea. Let's do that. -myk From mkanat at kerio.com Tue Mar 15 18:39:22 2005 From: mkanat at kerio.com (Maxwell Kanat-Alexander) Date: Tue, 15 Mar 2005 10:39:22 -0800 Subject: Release Tracking Message-ID: <1110911962.6169.7.camel@max.localdomain> I've filed a bug for general Release Tracking, for the upcoming and all future releases. If you'd like to be kept informed about the Bugzilla release process, CC yourself on this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=286269 Please do not add any comments to the bug. -Max From sundeep.kmr at wipro.com Wed Mar 16 13:14:28 2005 From: sundeep.kmr at wipro.com (sundeep.kmr at wipro.com) Date: Wed, 16 Mar 2005 18:44:28 +0530 Subject: FW: Regarding generation of reports.... Message-ID: <201834AAB8BE6246A45166DFD66A3A0103B801@blr-m2-msg.wipro.com> hi developers, Sorry for asking this question. if anybody can help..plz do it? I have customized Bugzilla-2.19.1 for my requierments & added some new fields. and i want these fields also should be there in all reports(graphical,tabular). what should be done for this? plz Help me out Thanks & Regards Sundeep Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or Mailadmin at wipro.com immediately and destroy all copies of this message and any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerv at mozilla.org Wed Mar 16 23:12:43 2005 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 16 Mar 2005 23:12:43 +0000 Subject: FW: Regarding generation of reports.... In-Reply-To: <201834AAB8BE6246A45166DFD66A3A0103B801@blr-m2-msg.wipro.com> References: <201834AAB8BE6246A45166DFD66A3A0103B801@blr-m2-msg.wipro.com> Message-ID: <4238BD6B.6010001@mozilla.org> sundeep.kmr at wipro.com wrote: > Sorry for asking this question. > if anybody can help..plz do it? > > I have customized Bugzilla-2.19.1 for my requierments & added some new > fields. > > and i want these fields also should be there in all > reports(graphical,tabular). > > what should be done for this? You need to contact whoever it was who supplied the patch to customise the fields. Gerv From gerv at mozilla.org Wed Mar 16 23:21:00 2005 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 16 Mar 2005 23:21:00 +0000 Subject: Splitting IRC into two? Message-ID: <4238BF5C.2020603@mozilla.org> Does anyone think it would be a good idea to split #mozwebtools into two - a chat/discussion version, and a "bugzilla monitoring" one where all the bug change notifications (and immediate discussion of them) went. Most people would be in both; I just think it would be nice to have the two information streams on separate screens. Currently it's hard to mentally disentangle them. Gerv From lpsolit at gmail.com Wed Mar 16 23:33:30 2005 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Thu, 17 Mar 2005 00:33:30 +0100 Subject: Splitting IRC into two? In-Reply-To: <4238BF5C.2020603@mozilla.org> References: <4238BF5C.2020603@mozilla.org> Message-ID: <4238C24A.30003@gmail.com> Gervase Markham wrote: > Does anyone think it would be a good idea to split #mozwebtools into two > - a chat/discussion version, and a "bugzilla monitoring" one where all > the bug change notifications (and immediate discussion of them) went. I prefer having a single screen for both... LpSolit From jake at bugzilla.org Wed Mar 16 23:34:47 2005 From: jake at bugzilla.org (Jake) Date: Wed, 16 Mar 2005 18:34:47 -0500 Subject: Splitting IRC into two? In-Reply-To: <4238BF5C.2020603@mozilla.org> References: <4238BF5C.2020603@mozilla.org> Message-ID: <4238C297.6040809@bugzilla.org> I personally find it easier to have everything in one window. I have a tendency to not switch tabs in my IRC client so I often miss things in #bmo because I'm too busy glancing at #mozwebtools every now and then. But that's just my personal preference. Gervase Markham wrote: > Does anyone think it would be a good idea to split #mozwebtools into two > - a chat/discussion version, and a "bugzilla monitoring" one where all > the bug change notifications (and immediate discussion of them) went. > > Most people would be in both; I just think it would be nice to have the > two information streams on separate screens. Currently it's hard to > mentally disentangle them. > > Gerv > - > To view or change your list settings, click here: > From bugreport at peshkin.net Wed Mar 16 23:36:12 2005 From: bugreport at peshkin.net (Joel Peshkin) Date: Wed, 16 Mar 2005 15:36:12 -0800 Subject: Splitting IRC into two? In-Reply-To: <4238BF5C.2020603@mozilla.org> References: <4238BF5C.2020603@mozilla.org> Message-ID: <4238C2EC.9050204@peshkin.net> Gervase Markham wrote: > Does anyone think it would be a good idea to split #mozwebtools into two > - a chat/discussion version, and a "bugzilla monitoring" one where all > the bug change notifications (and immediate discussion of them) went. > > Most people would be in both; I just think it would be nice to have the > two information streams on separate screens. Currently it's hard to > mentally disentangle them. I find having the notifications interleaved with the conversations helpful. Can any of the popular client help people seperate them from a single stream? -Joel From mkanat at kerio.com Thu Mar 17 00:06:44 2005 From: mkanat at kerio.com (Maxwell Kanat-Alexander) Date: Wed, 16 Mar 2005 16:06:44 -0800 Subject: Splitting IRC into two? In-Reply-To: <4238BF5C.2020603@mozilla.org> References: <4238BF5C.2020603@mozilla.org> Message-ID: <1111018004.7250.4.camel@localhost.localdomain> On Wed, 2005-03-16 at 23:21 +0000, Gervase Markham wrote: > Most people would be in both; I just think it would be nice to have the > two information streams on separate screens. Currently it's hard to > mentally disentangle them. I do prefer having the notices in the same channel as the discussion. Perhaps ssdbot/bzbot could be modified to add a ******* to the beginning of announcements to make it easier to disentangle them from normal conversation. -Max -- Max Kanat-Alexander Technical Support Manager, USA Kerio Technologies, Inc. 2350 Mission College Blvd., Suite 400 Santa Clara, CA 95054 Phone: (408) 496-4500 Fax: (408) 496-6902 http://www.kerio.com/support.html From kevin.benton at AMD.COM Thu Mar 17 00:12:12 2005 From: kevin.benton at AMD.COM (Benton, Kevin) Date: Wed, 16 Mar 2005 16:12:12 -0800 Subject: Splitting IRC into two? Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4278FEFE@ssvlexmb2.amd.com> That, or we could modify the bot to PM everyone on the chan with the updates. --- 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 Maxwell Kanat-Alexander > Sent: Wednesday, March 16, 2005 5:07 PM > To: developers at bugzilla.org > Subject: Re: Splitting IRC into two? > > On Wed, 2005-03-16 at 23:21 +0000, Gervase Markham wrote: > > Most people would be in both; I just think it would be nice to have the > > two information streams on separate screens. Currently it's hard to > > mentally disentangle them. > > I do prefer having the notices in the same channel as the > discussion. > Perhaps ssdbot/bzbot could be modified to add a ******* to the beginning > of announcements to make it easier to disentangle them from normal > conversation. > > -Max > -- > Max Kanat-Alexander > Technical Support Manager, USA > Kerio Technologies, Inc. > 2350 Mission College Blvd., Suite 400 > Santa Clara, CA 95054 > Phone: (408) 496-4500 > Fax: (408) 496-6902 > http://www.kerio.com/support.html > > > - > To view or change your list settings, click here: > From mkanat at kerio.com Thu Mar 17 05:02:58 2005 From: mkanat at kerio.com (Maxwell Kanat-Alexander) Date: Wed, 16 Mar 2005 21:02:58 -0800 Subject: Let's release some 2.18.1! Message-ID: <1111035778.11232.2.camel@localhost.localdomain> Hey hey! So, we want to release 2.18.1 this weekend! But... there are some blockers! Here's the list: http://tinyurl.com/4y7c3 If one of those is assigned to you, and you will be able to work on it before the weekend, make sure that you set the bug to ASSIGNED and get the code out! Otherwise, re-assign it to the component owner (if the component owner is a .bugs owner) or to nobody at bugzilla.org. If you'd like to help tackle any one of those bugs, it would be very much appreciated! :-) -Max From travis at SEDSystems.ca Thu Mar 17 17:07:45 2005 From: travis at SEDSystems.ca (Shane H. W. Travis) Date: Thu, 17 Mar 2005 11:07:45 -0600 (CST) Subject: Splitting IRC into two? In-Reply-To: <4238C24A.30003@gmail.com> References: <4238BF5C.2020603@mozilla.org> <4238C24A.30003@gmail.com> Message-ID: On Thu, 17 Mar 2005, [ISO-8859-1] Fr?d?ric Buclin wrote: > I prefer having a single screen for both... I'm in the same category; I like having it all in one screen. Having said that, I agree that it can be annoying, especially when people are being inconsiderate of existing conversations. (I find it very annoying when someone asks repeated questions 'ssdbot XXXX YYYY bugs' when people are trying to talk.) There must be better ways to be doing it. I am not an IRC guru so I don't know what they're called, but I've seen messages displayed in such a way that only I can see them (they usually have brown text on mIRC, if that helps) when I ask a bot a question in other IRC channels, but it's put in the same screen and not a private message. Could something like this be done for the answers to 'ssdbot ___ ___ bugs' questions? Perhaps it could even be done for normal checkin messages, so as to provide a way to visually differentiate between conversation and bot-messages. One drawback is that such text may not go into the permanent log... but is that a big issue? Shane H.W. Travis | The greatest of all mistakes is to do nothing travis at sedsystems.ca | because you can only do a little. Saskatoon, Saskatchewan | Do what you can. -- Sydney Smith From gerv at mozilla.org Thu Mar 17 18:02:45 2005 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 17 Mar 2005 18:02:45 +0000 Subject: Splitting IRC into two? In-Reply-To: <4238C297.6040809@bugzilla.org> References: <4238BF5C.2020603@mozilla.org> <4238C297.6040809@bugzilla.org> Message-ID: <4239C645.8050706@mozilla.org> Jake and lots of other people wrote: > I personally find it easier to have everything in one window. Looks like it's just me, then. Fair enough. :-) Gerv From jake at bugzilla.org Thu Mar 17 18:30:57 2005 From: jake at bugzilla.org (Jake) Date: Thu, 17 Mar 2005 13:30:57 -0500 Subject: Splitting IRC into two? In-Reply-To: References: <4238BF5C.2020603@mozilla.org> <4238C24A.30003@gmail.com> Message-ID: <4239CCE1.4030706@bugzilla.org> Shane H. W. Travis wrote: >Having said that, I agree that it can be annoying, especially when people >are being inconsiderate of existing conversations. (I find it very annoying >when someone asks repeated questions 'ssdbot XXXX YYYY bugs' when people are >trying to talk.) There must be better ways to be doing it. > > IIRC, ssdbot will accept queries such as that in a private /msg and return the results in private, it's just that most people don't think to do it that way. >I am not an IRC guru so I don't know what they're called, but I've seen >messages displayed in such a way that only I can see them (they usually have >brown text on mIRC, if that helps) when I ask a bot a question in other IRC >channels, but it's put in the same screen and not a private message. > I think that's a /notify type command. The bot probably could be modified to do that for certain types of questions. >Could >something like this be done for the answers to 'ssdbot ___ ___ bugs' >questions? Perhaps it could even be done for normal checkin messages, so as >to provide a way to visually differentiate between conversation and >bot-messages. > > I kinda like having the checkin messages and bug notifications (bzbot) as well as responses to bug ### type statements appear in the chat window. I can see some advantage (other than simply having bot in the name) to differentiate these messages. From myk at mozilla.org Thu Mar 17 20:05:19 2005 From: myk at mozilla.org (Myk Melez) Date: Thu, 17 Mar 2005 12:05:19 -0800 Subject: Splitting IRC into two? In-Reply-To: <4239C645.8050706@mozilla.org> References: <4238BF5C.2020603@mozilla.org> <4238C297.6040809@bugzilla.org> <4239C645.8050706@mozilla.org> Message-ID: <4239E2FF.7080704@mozilla.org> Gervase Markham wrote: > Looks like it's just me, then. Fair enough. :-) I'm with you, actually. But apparently we're the only ones. -myk From myk at mozilla.org Thu Mar 17 21:01:59 2005 From: myk at mozilla.org (Myk Melez) Date: Thu, 17 Mar 2005 13:01:59 -0800 Subject: making review/bug filing optional for some docs changes Message-ID: <4239F047.7050002@mozilla.org> Dave, I suggest we make review and bug filing optional for some docs changes made by a group of trusted docs writers. Although waiving these steps means more bugs, it also means more docs improvements, and I think the benefits outweigh the costs for a set of docs writers with known good skills. Instead of rehashing all the arguments, please find below most of the IRC discussion on the subject. -myk myk i can never remember; does docs hacking require review? Tru Yes LpSolit myk, yes, review requested but approval is not myk hmm, i thought there were some laxer review requirements for docs LpSolit Tru, yes travis [11:51] hmm, i thought there were some laxer review requirements for docs <== It *is* more lax. The intent is to ensure that things are syntactically and grammatically correct, and that they are not missing any obvious information ... not that they are 100% complete and accurate in all things. travis Basically, anything is better than nothing as far as documentation goes. The review is to ensure that we follow proper English grammar and structure, and that things are organized at least reasonably well. It is also a second pair of eyes and a second head full of knowledge, which might find cross-connections of which the original author was unawares... and it's easier to fix these things before checkin than after. You don't request a documentation review of a specific person, though; you request it of the component owner. People who can do reviews are watching that owner, and that queue. (the component owner is documentation at bugzilla.bugs -- a fake account set up just for this purpose.) travis Yes, the Developer Docs need an update on this procedure; that's one of the developments in the queue. :) Tru nods. Travis - is there a bug up for that? myk travis: it may be easier to fix code issues before checkin, but docs issues would be just as fixable after checkin as before if review were not required travis LpSolit: documentation bugs do not require approval just review once they have been reviewed, they can be checked in to the tree. Tru Myk - I think that requiring review is appropriate. Tru Myk - the reason being - if we dump poor documentation on our users, it's going to very negatively impact their view of the software. travis myk: you're probably right, and back in the days where only Jake was doing documentation work, he wouldn't bother asking for anyone for review because there was nobody toa sk to ask* myk Tru: perhaps it would make sense to designate a group of Bugzilla hackers whose linguistic skills we trust and not require review for that group f.e. the set of docs reviewers Jake And when Jake came back to it in Iraq he was still in the habit of not requesting review and that had a tendency to annoy travis :) travis myk: I'd like to think that I'm in that group (of those whose linguistic skills can be trusted), and I approve of having someone else look over my patches before they go in. I don't know everything by any means, and often there have been technical corrections that made the whole thing better. Jake Docs review is a lot like proof reading before you turn in your English paper myk travis: that's ok; i'm not suggesting that you can't get review or that it's never useful travis nods at Jake. Tru While I may want to consider myself part of that group, I would rather not have that responsibility on my shoulders. If I make a mistake and I update, then I don't get to share the blame. If I make a mistake and a reviewer misses it too, then we both get to share blame. travis In fact, it's like having someone *else* proofread your English paper, which is the best way to do it. Tru nods at travis and jake. myk travis: i'm just suggesting that it would be beneficial to not require review in some cases Tru: i'm part of that group, and i do want that responsibility Tru So - if nobody reviews your update but the update (unintentionally) leads users astray, who will know about it besides you? myk i don't care about blame, i care about improving docs; and i have good english skills, but i don't have a lot of time; going through thebug->review->checkin cycle for fixes like the one i just made to using.xml is way too much work for a change of that magnitude travis myk: we had an email discussion like this about six months ago -- Vlad, Jake, Dave and I -- which is when this current policy was formed. I'm not averse to reopening the discussion for the purposes of very small fixes -- on the order of what you were doing today -- but IMHO anything larger than that *needs* a second pair of eyes. myk Tru: everyone, the moment someone reports the error travis myk: Would you still be willing to make a bug and a patch? Or are you looking at just hacking the docs directly with no public record? myk travis: i'm suggesting hacking the docs directly with the CVS public record travis (I'm wondering if you're just trying to skip the review phase, or the whole bug creation/patch creation/patch uploading/bug closing phase) myk travis: i'm suggesting that a group of hackers be able to skip all those phases for a set of changes Tru Myk - I guess where I'm coming from - I depend heavily on the docs being accurate. If they're not or they mislead, then I wind up wasting my time as a user. If a lot of users are doing the same thing, then how much time is wasted? Is it more wasted time to utilize the process or more wasted time for users to be lead astray? myk travis: obviously there are some changes large enough to require review, but i think the hackers we trust to make changes without review can also be trusted to decide when it's necessary Tru: i think it's more wasted time for the users, because busy hackers like me aren't going to update the docs nearly as much if we have to go through a more cumbersome process to do so travis myk: by the same token, are you not a Trusted Code Hacker? By that same logic, should we not just say, "Myk knows what he's doing as far as the UI goes, and he can just hack the UI code with only the CVS as public record?" If not -- and this is an honest question, not sarcasm -- what do you perceive as the difference between the two? myk travis: code bugs break the app for other hackers, who have to stop working until the bustage gets fixed; errors in documentation do not generally stop docs hackers from working on them travis: so code bugs are more serious Tru myk: If the review adds more time to getting the documentation update into CVS, how does that prevent you from continuing what you're doing? myk Tru: it's the whole process that takes more time myk travis: but as a matter of fact i do think that we could beneficially waive the review requirement for some kinds of hacking Tru myk: What's preventing you from making updates to your Bugzilla installation and following the process for the rest of us? travis Tru: ethics myk Tru: i don't have a Bugzilla installation; i'm hacking on Bugzilla Tru myk: That's a problem from my perspective because those of us who do can be negatively impacted from an error in an update regardless of the size. myk Tru: i don't understand; what's a problem from your perspective? Tru It's also one reason why I'm writing a Pre-Release Testing Guide to cover all of Bugzilla. The problem from my perspective is not following the process to prevent human error. myk Tru: sure, not requiring review will sometimes result in errors with negative impact to others travis myk: I do understand where you're coming from. Having to follow any procedure is always a PITA, and slows things down. I would be willing to entertain discussion about 'trusted docs hackers' not needing a review, but relying completely on CVS for tracking is not something I'm personally comfortable with. Tru How many times have each of us made mistakes on even little things that caused problems? I'd raise my hand more times than I can count. It's not that we can't make changes without making mistakes, it's that we do make mistakes and sometimes we don't catch them till they're a problem. myk Tru: not requiring two reviews, which is what we do now, also has that problem myk Tru: in fact, i just reviewed and checked in some docs code today only to find i missed a problem Tru: but we don't require two reviews because the benefit in reduced errors isn't worth the effort Tru: my suggestion is that not requiring one review gives us more benefit than it costs us in some cases Tru See? That's the whole point I was trying to make - even reviewers make mistakes, but at least the reviewer (you) looked at it and had an opportunity to catch a problem. travis myk: it's a matter of perspective. I hear you saying that even one review on docs isn't 'worth the effort'. I recognize that you feel that way, but I don't feel the same way. Tru myk: having been a production operations manager, I completely agree with travis that not reviewing under 'certain' circumstances leads to a greater potential for problems and abuse of process that was put in place to protect us from ourselves. Process does add time initially but if it saves us from releasing buggy updates, then it saves us time and reputation. myk travis: sure, i understand. i would just suggest that it's probably because we're different, and different processes would be optimal for us, and we should be more flexible in applying processes to different hackers to make the best use of their capabilities and potential myk Tru: sure it does, but it also has greater potential for solutions and better docs LpSolit travis, could you check this patch in? Tru myk: Maybe we should just agree to disagree on this. Please don't get me wrong - I'm not picking on you. I have two responsibilities in my job - writing Bugzilla code and administering an active Bugzilla. As an administrator, I want to be sure I'm only using well-tested code. myk Tru: i think the additional problems from not reviewing some docs would be compensated for many times over by the additional docs and doc improvements such a policy would open the door for Tru myk: If you don't want to wait for review, that's fine with me. File your bug and patch, then feel free to move on. :) myk Tru: i can't do that at the moment, since that would be breaking the rules travis myk: that way also lies resentment, however. Based on discussion on the developers@ list, I would bet that Gerv would think that he deserves Trusted Docs Hacker status. Based on the response to his suggestions, others do not. myk: *file* the bug and move on, not *fix* the bug. myk Tru: but i'd like more than that anyway; i want to not have to file bugs on some fixes Tru I don't think anyone deserves that status because we're all human. myk Tru: it works pretty well in the Mozilla community travis myk: I know nothing about the Mozilla community, so I can't comment. Are you talking docs only, or everything? myk travis: perhaps; but we can't not make decisions because some people will resent them; it's our responsibility as project managers to make the hard decisions about who gets such privileges and others (like to become a reviewer) myk travis: i'm talking docs mostly, where bugs don't need to be filed and/or changes don't need review in a number of cases; but there are also some places where review is waived for code as well, and i believe bugs don't need to be filed for some really minor code fixes Tru myk: As I see it, that's a really slippery slope. If we give approval for certain kinds of updates, what's to prevent someone from abusing that power to make updates beyond the scope of the authorization? travis myk: okay, well, you're definitely talking about a change to How Things Are Done At Bugzilla... so it's worth bringing up on the developers@ list if you feel strongly about it... or maybe, better yet, use reviewers@ (now that it's a discussion list). I'm fairly confident that you'll receive some support from some corners, based on past posting history, and the discussion itself is probably worth having. I doubt anything is going to be settled in IRC, though. Just my feeling. myk Tru: the same things preventing them from doing it now, given that most Bugzilla privileges aren't restricted programmatically: tight feedback loops myk travis: ok, i'll do so Tru myk - I think you are one of the people that if we were going to do something like that for, I would be in favor of you having that capability. The problem is, I'm not against you having the ability, I'm against the entire concept of making updates to Bugzilla that aren't in the DB for someone to search on. I also feel that having a reviewer review means that someone else can act as a check/balance to make sure the update is taking Bugzilla in the travis "I'm not against you having the ability, I'm against the entire concept of making updates to Bugzilla that aren't in the DB for someone to search on." <-- this says it well for me also. myk travis, Tru: but they are in the db; they're in CVS and in bonsai -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerv at mozilla.org Fri Mar 18 00:12:58 2005 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 18 Mar 2005 00:12:58 +0000 Subject: making review/bug filing optional for some docs changes In-Reply-To: <4239F047.7050002@mozilla.org> References: <4239F047.7050002@mozilla.org> Message-ID: <423A1D0A.5010809@mozilla.org> Myk Melez wrote: > travis: myk: that way also lies > resentment, however. Based on discussion on the developers@ list, I > would bet that Gerv would think that he deserves Trusted Docs Hacker > status. Based on the response to his suggestions, others do not. Which suggestions have I made which have been so badly received that they mark me out as someone not to be trusted to update docs without review? I seem to remember making a suggestion almost exactly like Myk's - that people (specifically me, but it could have been anyone) be allowed to do documentation whackage without review. If this suggestion makes me unsuitable to be a TDH, while Myk's doesn't, I'd appreciate someone explaining the difference. :-) Gerv From travis at SEDSystems.ca Fri Mar 18 00:26:22 2005 From: travis at SEDSystems.ca (Shane H. W. Travis) Date: Thu, 17 Mar 2005 18:26:22 -0600 (CST) Subject: making review/bug filing optional for some docs changes In-Reply-To: <423A1D0A.5010809@mozilla.org> References: <4239F047.7050002@mozilla.org> <423A1D0A.5010809@mozilla.org> Message-ID: On Fri, 18 Mar 2005, Gervase Markham wrote: > Myk Melez wrote: > > travis: myk: that way also lies > > resentment, however. Based on discussion on the developers@ list, I > > would bet that Gerv would think that he deserves Trusted Docs Hacker > > status. Based on the response to his suggestions, others do not. > > Which suggestions have I made which have been so badly received that > they mark me out as someone not to be trusted to update docs without review? /me sighs Myk asked my permission before he put this log up, specifically because of this comment. I asked him if he thought that it would cause controversy and detract from the main point he was making, and he said that he did not think it would. I wasn't sure, but I said to go ahead. I wish his hopes had been right, and not my fears. > I seem to remember making a suggestion almost exactly like Myk's - that > people (specifically me, but it could have been anyone) be allowed to do > documentation whackage without review. ... and how was it received? Memory says that it was not looked on as a favourable idea. I know that my reasons for opposition were philosophical and not personal (as they are this time with Myk's proposal) but my recollection is that some specific personal points came up during the discussion, which was the basis of the above comment. If my memory is faulty, I apologize. Myk is trying to ask if the concept of Trusted Docs Hacker (or Trusted Code Hacker) is a good idea at all. My opinion is that it is not. Most of my objections are included in the log itself, and I'll restate them again when I have time to do so. I wanted to get this written quickly in the hopes of preventing things from getting off the original topic. Shane H.W. Travis | The greatest of all mistakes is to do nothing travis at sedsystems.ca | because you can only do a little. Saskatoon, Saskatchewan | Do what you can. -- Sydney Smith From gerv at mozilla.org Fri Mar 18 00:35:35 2005 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 18 Mar 2005 00:35:35 +0000 Subject: making review/bug filing optional for some docs changes In-Reply-To: References: <4239F047.7050002@mozilla.org> <423A1D0A.5010809@mozilla.org> Message-ID: <423A2257.6040406@mozilla.org> Shane H. W. Travis wrote: > Myk asked my permission before he put this log up, specifically because of > this comment. I asked him if he thought that it would cause controversy and > detract from the main point he was making, and he said that he did not think > it would. I wasn't sure, but I said to go ahead. > > I wish his hopes had been right, and not my fears. I don't mean to cause controversy, but surely you expected me to ask about it? It gives the impression that you and others think that if some people are trusted to update the docs without review, then I shouldn't be one of those people. I think it's reasonable to ask why. >>I seem to remember making a suggestion almost exactly like Myk's - that >>people (specifically me, but it could have been anyone) be allowed to do >>documentation whackage without review. > > ... and how was it received? Badly. :-) > Memory says that it was not looked on as a > favourable idea. I know that my reasons for opposition were philosophical > and not personal (as they are this time with Myk's proposal) but my > recollection is that some specific personal points came up during the > discussion, which was the basis of the above comment. If my memory is > faulty, I apologize. I don't remember any specific personal points. I had a discussion with Dave about some confusion over a previous docs update I did, but I can't remember him ever asserting that the *content* I added was bad, just the way I added it. And that's precisely what my proposal intended to clarify. But mayve I've misremembered too. Gerv From bugreport at peshkin.net Fri Mar 18 02:21:49 2005 From: bugreport at peshkin.net (Joel Peshkin) Date: Thu, 17 Mar 2005 18:21:49 -0800 Subject: making review/bug filing optional for some docs changes In-Reply-To: <4239F047.7050002@mozilla.org> References: <4239F047.7050002@mozilla.org> Message-ID: <423A3B3D.2050704@peshkin.net> Myk Melez wrote: > Dave, > > I suggest we make review and bug filing optional for some docs changes > made by a group of trusted docs writers. Although waiving these steps > means more bugs, it also means more docs improvements, and I think the > benefits outweigh the costs for a set of docs writers with known good > skills. Instead of rehashing all the arguments, please find below > most of the IRC discussion on the subject. > > -myk > This sounds like a good idea, so long as there is some guidance given to that group. In the same breath, I would like to see a clarification of the rules for docs changes. Is it safe to say that a doc change by anyone needs ONLY a single review, no approval, and can be checked in? From teemu.mannermaa at etlicon.com Fri Mar 18 02:46:17 2005 From: teemu.mannermaa at etlicon.com (Teemu Mannermaa) Date: Fri, 18 Mar 2005 04:46:17 +0200 Subject: Splitting IRC into two? In-Reply-To: <4238BF5C.2020603@mozilla.org> References: <4238BF5C.2020603@mozilla.org> Message-ID: <423A40F9.10703@etlicon.com> Gervase Markham wrote: > Does anyone think it would be a good idea to split #mozwebtools into two > - a chat/discussion version, and a "bugzilla monitoring" one where all > the bug change notifications (and immediate discussion of them) went. I have configured my IRC client to color bot messages in different color so they stand out quite nicely currently. Still, when I stopped to think about this separation issue, I decided it would be a good idea. Why? Well, I have a habit of scrolling IRC backlog from top to bottom and clicking on the URLs of various changed bugs to see what is going on. Now, if there is a lot of discussion in between I keep getting distracted between discussions by interesting people (also colored differently) and bot announcements. If there would only be a channel where only bots announce stuff.. :) -- Teemu Mannermaa System Specialist "Anything is possible. It's all about probabilities." From justdave at bugzilla.org Fri Mar 18 03:30:38 2005 From: justdave at bugzilla.org (David Miller) Date: Thu, 17 Mar 2005 22:30:38 -0500 Subject: making review/bug filing optional for some docs changes In-Reply-To: <423A3B3D.2050704@peshkin.net> References: <4239F047.7050002@mozilla.org> <423A3B3D.2050704@peshkin.net> Message-ID: <423A4B5E.7010804@bugzilla.org> Joel Peshkin wrote: >> I suggest we make review and bug filing optional for some docs changes >> made by a group of trusted docs writers. Although waiving these steps >> means more bugs, it also means more docs improvements, and I think the >> benefits outweigh the costs for a set of docs writers with known good >> skills. Instead of rehashing all the arguments, please find below >> most of the IRC discussion on the subject. > > This sounds like a good idea, so long as there is some guidance given to > that group. In the same breath, I would like to see a clarification of > the rules for docs changes. Is it safe to say that a doc change by > anyone needs ONLY a single review, no approval, and can be checked in? The existing policy for docs checkin was agreed on by the group of people who were actively working on docs at the time when that policy was last discussed. At the time that was Shane, Vlad, and Jake. If the circle of people who are actively maintaining docs is widening, then perhaps it needs to be revisited so we can come to some policy that the folks involved can agree to again. The main reason such a policy was created is that we went for a long time without a "documentation czar", which we had previously had for a long time prior to that (first Matt Barnson, then Jake). At the point Jake came back, he'd been out of the loop too long to just jump into that role again when there were other people that had been doing it without him. I believe back when Jake was officially in charge of docs we were doing approvals on docs, and he was the one granting them. Personally I'm not against having trusted folks making small changes in the docs. Making wide sweeping changes or changing the content (rather than just the presentation) of the docs are things that should certainly continue to require review though. -- 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 luis.villa at gmail.com Fri Mar 18 12:53:00 2005 From: luis.villa at gmail.com (Luis Villa) Date: Fri, 18 Mar 2005 07:53:00 -0500 Subject: docs in a wiki [was Re: making review/bug filing optional for some docs changes] In-Reply-To: <423A2257.6040406@mozilla.org> References: <4239F047.7050002@mozilla.org> <423A1D0A.5010809@mozilla.org> <423A2257.6040406@mozilla.org> Message-ID: <2cb10c4405031804539b80498@mail.gmail.com> Slightly OT from the developing flame war :) Why not put all the docs in a wiki, leave it open, make sure someone is at least trying to review the (probably low traffic) commits /after they happen/, and just have a script to pull docs off the wiki and into the tarball for the release? Hula is using this approach: http://www.hula-project.org/Hula_Server and so far by all accounts it is working well for them. Luis On Fri, 18 Mar 2005 00:35:35 +0000, Gervase Markham wrote: > Shane H. W. Travis wrote: > > Myk asked my permission before he put this log up, specifically because of > > this comment. I asked him if he thought that it would cause controversy and > > detract from the main point he was making, and he said that he did not think > > it would. I wasn't sure, but I said to go ahead. > > > > I wish his hopes had been right, and not my fears. > > I don't mean to cause controversy, but surely you expected me to ask > about it? It gives the impression that you and others think that if some > people are trusted to update the docs without review, then I shouldn't > be one of those people. I think it's reasonable to ask why. > > >>I seem to remember making a suggestion almost exactly like Myk's - that > >>people (specifically me, but it could have been anyone) be allowed to do > >>documentation whackage without review. > > > > ... and how was it received? > > Badly. :-) > > > Memory says that it was not looked on as a > > favourable idea. I know that my reasons for opposition were philosophical > > and not personal (as they are this time with Myk's proposal) but my > > recollection is that some specific personal points came up during the > > discussion, which was the basis of the above comment. If my memory is > > faulty, I apologize. > > I don't remember any specific personal points. I had a discussion with > Dave about some confusion over a previous docs update I did, but I can't > remember him ever asserting that the *content* I added was bad, just the > way I added it. And that's precisely what my proposal intended to > clarify. But mayve I've misremembered too. > > Gerv > - > To view or change your list settings, click here: > > From kevin.benton at amd.com Fri Mar 18 16:53:56 2005 From: kevin.benton at amd.com (Benton, Kevin) Date: Fri, 18 Mar 2005 08:53:56 -0800 Subject: making review/bug filing optional for some docs changes Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4279008A@ssvlexmb2.amd.com> > Myk Melez wrote: > > > Dave, > > > > I suggest we make review and bug filing optional for some docs changes > > made by a group of trusted docs writers. Although waiving these steps > > means more bugs, it also means more docs improvements, and I think the > > benefits outweigh the costs for a set of docs writers with known good > > skills. Instead of rehashing all the arguments, please find below > > most of the IRC discussion on the subject. > > > > -myk > > > This sounds like a good idea, so long as there is some guidance given to > that group. In the same breath, I would like to see a clarification of > the rules for docs changes. Is it safe to say that a doc change by > anyone needs ONLY a single review, no approval, and can be checked in? Part of our discussion revolved around the concern that no matter how updates are made, whether we still need accountability or not and should updates still be logged in Bugzilla. From my perspective, my answer would be in the affirmative for these issues - we do need accountability, that logging updates in Bugzilla should be a requirement not only so people can see what's been done without having to use CVS, but also in case something needs to be reverted, the place to track it should (IMNSHO) always be in Bugzilla. If we don't track it there, we're likely to make the same mistake again. Because we're maintaining enterprise-level software (and we advertise it that way), we need to handle it as an enterprise-level entity would. In my experience at that level, to ensure high quality, any time a change is put in place that could impact a customer, a release process needs to be followed. Because documentation is viewed by our "customers," I feel it should be kept inside the release process. This prevents human error from leaking out. Note I didn't say eliminate human error. It's possible that a reviewer could miss something. On the other hand, if we don't follow the release process, we can not benefit from catching problems before they're released. Therefore, with documentation being such a high-visibility part of our product, I would suggest that no matter who is making the documentation update, that it follow a release process. Whether that involves just one or two reviewers is not the issue with me. I think one reviewer on documentation is a fair balance giving us the greatest flexibility to move quickly but still have a check/balance for doc updates. If someone is in a rush to get a doc update done, the review process doesn't keep that person from making the update on their local system, submitting the patch, then go on with life. When the review comes up, the reviewer can check the code in. If it's a really small change, the review should go very quickly and easily. It would also make those changes the kind of thing newly CVS authorized people could flex their wings a little bit while the potential impact to Bugzilla should be minimal. It also educates new people to the review process. So, if someone misspells a word that gets published, a new reviewer could look at the correction, check it, then review+ it with minimal effort. I know that one developer we were talking with doesn't have a Bugzilla installation local to their system. What environment do they test updates in? How do we keep those updates from leaking into production? I'm not against the concept at all, I just want to know that updates are getting tested and there is no way for anyone except developers to see an update until it's checked in. --- 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 justdave at bugzilla.org Fri Mar 18 17:26:48 2005 From: justdave at bugzilla.org (David Miller) Date: Fri, 18 Mar 2005 12:26:48 -0500 Subject: docs in a wiki [was Re: making review/bug filing optional for In-Reply-To: <2cb10c4405031804539b80498@mail.gmail.com> References: <4239F047.7050002@mozilla.org> <423A1D0A.5010809@mozilla.org> <423A2257.6040406@mozilla.org> <2cb10c4405031804539b80498@mail.gmail.com> Message-ID: <423B0F58.2000001@bugzilla.org> Luis Villa wrote: > Slightly OT from the developing flame war :) Why not put all the docs > in a wiki, leave it open, make sure someone is at least trying to > review the (probably low traffic) commits /after they happen/, and > just have a script to pull docs off the wiki and into the tarball for > the release? > > Hula is using this approach: > http://www.hula-project.org/Hula_Server > > and so far by all accounts it is working well for them. That's actually a pretty cool idea, except that as far as I know, wikis don't deal well with Docbook XML, and it would probably be non-trivial to convert it. We do actually have a wiki we can use already if we want it at http://wiki.mozilla.org/ . Would be easy enough to create a namespace for Bugzilla on there. -- 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 jpyeron at pdinc.us Fri Mar 18 17:52:37 2005 From: jpyeron at pdinc.us (Jason Pyeron) Date: Fri, 18 Mar 2005 12:52:37 -0500 (EST) Subject: making review/bug filing optional for some docs changes In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4279008A@ssvlexmb2.amd.com> References: <6F7DA19D05F3CF40B890C7CA2DB13A4279008A@ssvlexmb2.amd.com> Message-ID: On Fri, 18 Mar 2005, Benton, Kevin wrote: > > Because we're maintaining enterprise-level software (and we advertise it > that way), we need to handle it as an enterprise-level entity would. In > my experience at that level, to ensure high quality, any time a change > is put in place that could impact a customer, a release process needs to > be followed. Because documentation is viewed by our "customers," I feel > it should be kept inside the release process. This prevents human error > from leaking out. Note I didn't say eliminate human error. It's Our customers could not tolerate anything less. > possible that a reviewer could miss something. On the other hand, if we > don't follow the release process, we can not benefit from catching > problems before they're released. Therefore, with documentation being > such a high-visibility part of our product, I would suggest that no > matter who is making the documentation update, that it follow a release > process. Whether that involves just one or two reviewers is not the > issue with me. I think one reviewer on documentation is a fair balance > giving us the greatest flexibility to move quickly but still have a > check/balance for doc updates. > How about a new enter bug template just for doc updates? Version, patch, summary, and an optional explanation. This will allow them to drop and go. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Partner & Sr. Manager #1 2739 Saint Paul Street - - +1 (410) 808-6646 (c) Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, purge the message from your system and notify the sender immediately. Any other use of the email by you is prohibited. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Partner & Sr. Manager #1 2739 Saint Paul Street - - +1 (410) 808-6646 (c) Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, purge the message from your system and notify the sender immediately. Any other use of the email by you is prohibited. From luis.villa at gmail.com Fri Mar 18 18:11:35 2005 From: luis.villa at gmail.com (Luis Villa) Date: Fri, 18 Mar 2005 13:11:35 -0500 Subject: docs in a wiki [was Re: making review/bug filing optional for In-Reply-To: <423B0F58.2000001@bugzilla.org> References: <4239F047.7050002@mozilla.org> <423A1D0A.5010809@mozilla.org> <423A2257.6040406@mozilla.org> <2cb10c4405031804539b80498@mail.gmail.com> <423B0F58.2000001@bugzilla.org> Message-ID: <2cb10c4405031810112673d005@mail.gmail.com> On Fri, 18 Mar 2005 12:26:48 -0500, David Miller wrote: > Luis Villa wrote: > > Slightly OT from the developing flame war :) Why not put all the docs > > in a wiki, leave it open, make sure someone is at least trying to > > review the (probably low traffic) commits /after they happen/, and > > just have a script to pull docs off the wiki and into the tarball for > > the release? > > > > Hula is using this approach: > > http://www.hula-project.org/Hula_Server > > > > and so far by all accounts it is working well for them. > > That's actually a pretty cool idea, except that as far as I know, wikis > don't deal well with Docbook XML, and it would probably be non-trivial > to convert it. I seem to recall that at least one of the bigger wikis can accept docbook. Not sure, though. Sadly, wiki.docbook.org is down, seems like they'd know ;) To keep pushing the boundaries, though- why do we use docbook? It's great for structured text. Do we actually use that (or, do we use it more than what the HTML markup would give us?) Does it give us translation benefits? Offhand, I can see an argument to be made that the flexibility and more collaborative nature of wiki would justify dumping docbook. Luis From n at ironport.com Fri Mar 18 18:18:11 2005 From: n at ironport.com (Nagendra Mishr) Date: Fri, 18 Mar 2005 10:18:11 -0800 Subject: making review/bug filing optional for some docs changes In-Reply-To: References: <6F7DA19D05F3CF40B890C7CA2DB13A4279008A@ssvlexmb2.amd.com> Message-ID: <423B1B63.7010300@ironport.com> I really like the way that the mysql docs are done. It shows the official doc and at the bottom, people can comment on their thoughts. At some point the comments are rolled up and included into the documentation. This has been very effective for me in understanding all the ins and outs of mysql. Nagendra From luis.villa at gmail.com Fri Mar 18 18:30:14 2005 From: luis.villa at gmail.com (Luis Villa) Date: Fri, 18 Mar 2005 13:30:14 -0500 Subject: making review/bug filing optional for some docs changes In-Reply-To: References: <6F7DA19D05F3CF40B890C7CA2DB13A4279008A@ssvlexmb2.amd.com> Message-ID: <2cb10c4405031810303810be5@mail.gmail.com> On Fri, 18 Mar 2005 12:52:37 -0500 (EST), Jason Pyeron wrote: > On Fri, 18 Mar 2005, Benton, Kevin wrote: > > > > > Because we're maintaining enterprise-level software (and we advertise it > > that way), we need to handle it as an enterprise-level entity would. In > > my experience at that level, to ensure high quality, any time a change > > is put in place that could impact a customer, a release process needs to > > be followed. Because documentation is viewed by our "customers," I feel > > it should be kept inside the release process. This prevents human error > > from leaking out. Note I didn't say eliminate human error. It's > > Our customers could not tolerate anything less. Wow. That sounds incredibly stiflingly unfun. Glad people are paid to work on this now... Luis From gerv at mozilla.org Fri Mar 18 18:32:26 2005 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 18 Mar 2005 18:32:26 +0000 Subject: making review/bug filing optional for some docs changes In-Reply-To: <423A4B5E.7010804@bugzilla.org> References: <4239F047.7050002@mozilla.org> <423A3B3D.2050704@peshkin.net> <423A4B5E.7010804@bugzilla.org> Message-ID: <423B1EBA.9010804@mozilla.org> David Miller wrote: > Personally I'm not against having trusted folks making small changes in > the docs. Making wide sweeping changes or changing the content (rather > than just the presentation) of the docs are things that should certainly > continue to require review though. But it's the wide, sweeping changes which are hard to review, because they tend to be done incrementally and patches tend to be very fragile. We don't have to have the same policy in all parts of the development cycle - after all, the code has an open period and a freeze period. How about something like: when the code is not frozen, people can update the docs without patch review. If they want to make structural changes, they need pre-implementation review of the _concept_ - so core docs people don't turn up one day to find the entire repository rearranged. Once the code is frozen, all docs patches have review and approval as normal. The idea is that this flexibility and fluidity means that the docs are generally in better shape on an ongoing basis, rather than being fixed up at the last minute - so there's much less _need_ for the big changes during a freeze period, because the docs at the start of the freeze are much closer to the final thing. So the review requirement during the freeze is not onerous either. Gerv From justdave at bugzilla.org Fri Mar 18 18:44:46 2005 From: justdave at bugzilla.org (David Miller) Date: Fri, 18 Mar 2005 13:44:46 -0500 Subject: docs in a wiki [was Re: making review/bug filing optional for In-Reply-To: <2cb10c4405031810112673d005@mail.gmail.com> References: <4239F047.7050002@mozilla.org> <423A1D0A.5010809@mozilla.org> <423A2257.6040406@mozilla.org> <2cb10c4405031804539b80498@mail.gmail.com> <423B0F58.2000001@bugzilla.org> <2cb10c4405031810112673d005@mail.gmail.com> Message-ID: <423B219E.9040709@bugzilla.org> Luis Villa wrote: > To keep pushing the boundaries, though- why do we use docbook? It's > great for structured text. Do we actually use that (or, do we use it > more than what the HTML markup would give us?) Does it give us > translation benefits? Offhand, I can see an argument to be made that > the flexibility and more collaborative nature of wiki would justify > dumping docbook. We use docbook because it lets us produce readable documentation in multiple formats. On the website, besides the HTML version, we also have plaintext and a PDF. And the PDF version is surprisingly popular. -- 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 kevin.benton at amd.com Fri Mar 18 19:31:44 2005 From: kevin.benton at amd.com (Benton, Kevin) Date: Fri, 18 Mar 2005 11:31:44 -0800 Subject: docs in a wiki [was Re: making review/bug filing optional Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A427900BF@ssvlexmb2.amd.com> > > To keep pushing the boundaries, though- why do we use docbook? It's > > great for structured text. Do we actually use that (or, do we use it > > more than what the HTML markup would give us?) Does it give us > > translation benefits? Offhand, I can see an argument to be made that > > the flexibility and more collaborative nature of wiki would justify > > dumping docbook. > > We use docbook because it lets us produce readable documentation in > multiple formats. On the website, besides the HTML version, we also > have plaintext and a PDF. And the PDF version is surprisingly popular. Interestingly enough, I've been working with CSS2 quite a bit lately and I *REALLY* like how it supports pagination through style sheets. One of the biggest complaints I've had with straight HTML (no CSS pagination) is the sense of where a page break belongs. If we can update our CSS to include page breaks (page-break-after, page-break-before, orphans, widows), I think a lot of that need will be minimized. Of course, it assumes that users have a CSS2 compatible browser. I've been book-writing most of my stuff lately using XHTML/CSS. I've put in a feature request for CSS3 Paged Media (since it's now at the recommendation / endorsement stage) to the Firefox team so I can define the entire printed page. For text-based media, lynx can produce the necessary output. I don't know if it's really time to say we should move to XHTML/CSS for our documentation, but it certainly is worth considering now that we can control page breaks in a way that makes sense. BTW - here's a portion of my "book" stylesheet for XHTML: body { background-color: #FFFFFF; } div.author { font-size: medium; text-align: center; color: #999999; font-weight: bold; margin-bottom: 200pt; } div.byauthor { font-size: medium; text-align: center; color: #999999; } div.chapter { font-size: x-large; font-weight: bold; text-align: justify; page-break-before: always; } div.chaptertitle { font-size: x-large; font-weight: bold; text-align: center; padding: 24pt; border-top: 1pt solid; border-bottom: 1pt solid; } div.copyright { font-size: small; text-align: center; color: #999999; margin-bottom: 36pt; } div.section { font-size: large; font-weight: bold; text-align: left; margin-top: 10pt; } div.subsection { font-size: medium; font-weight: bold; text-align: left; } div.subtitle { font-size: x-large; text-align: center; font-weight: bold; margin-bottom: 216pt; } div.title { font-size: xx-large; text-align: center; font-weight: bold; margin-top: 144pt; } p, ul, li { font-size: medium; font-weight: normal; text-align: justify; page-break-inside: avoid; orphans: 4; } table { font-size: medium; font-weight: normal; text-align: justify; page-break-inside: avoid; orphans: 8; } --- 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 travis at SEDSystems.ca Fri Mar 18 19:40:44 2005 From: travis at SEDSystems.ca (Shane H. W. Travis) Date: Fri, 18 Mar 2005 13:40:44 -0600 (CST) Subject: making review/bug filing optional for some docs changes In-Reply-To: <2cb10c4405031810303810be5@mail.gmail.com> References: <6F7DA19D05F3CF40B890C7CA2DB13A4279008A@ssvlexmb2.amd.com> <2cb10c4405031810303810be5@mail.gmail.com> Message-ID: On Fri, 18 Mar 2005, Luis Villa wrote: > Wow. That sounds incredibly stiflingly unfun. Glad people are paid to > work on this now... Nobody is getting paid, which means nobody can be forced to work on anything with the threat of the wage-stick hanging over their head. As such, to some degree, documentation has been abandoned by most people because it's 'un-fun', and not seen as a 'real' contribution. (Even Max once said to me, during a period when I was quite productive on the codebase, "Wow, you're going to catch up to me in real bugs fixed soon!" The implication being that documentation bugs aren't 'real bugs'...) That is, in part, what this discussion is about; lowering the bar so that documentation patches can get in more quickly/with less effort, so hopefully things stay more current. When Gerv brought up this topic before, he named about six things that needed doing on the documentation that could only be done in 'grand, sweeping changes', and that all he needed was a completely free hand and 12 solid hours of hacking to bring the documentation up to snuff. I disagreed with him on whether or not the process was broken, and asked him to file documentation bugs on any or all of the things he said that needed changing, as they all sounded valid. I welcomed his contributions, and invited his contribution on those issues, or any promised to make the review procedure as quick and painless as possible. To date, to the best of my knowledge, nothing has been done on that front; No bugs filed, no patches uploaded, nothing. This, then, is part of my problem. It seems like people are saying, "I'd be happy to contribute! I just love writing documentation... but you've got all these messy *procedures* in the way that are stopping me." The underlying message seems to be, "If I can't have complete and free access with nobody else restricting me, questioning me, or second-guessing me... then I just won't do anything at all." Were someone to try and take such an attitude to the codebase, the answer would be, "Sorry to hear that; there's the door. Don't let it hit you in the ass on the way out." Documentation is perceived as 'lesser', though, because one cannot 'break' it in the same way that one can break code; no amount of poor English, typographical errors, or factual inaccuracies will stop it from being The Documentation. The prevailing argument is that documentation could be fixed later... and I agree that it could, *if people notice that it needs fixing*. The people reading the docs are not, typically, people who are completely conversant with Bugzilla. They are the people who need help with Bugzilla. They are the ones who don't know how things work, and are seeking more information. How are they supposed to know if the docs are right or wrong? Those who do reviews, however, are (ostensibly) more aware of Bugzilla than your average user, and therefore will have a better chance of finding such things. I have University credentials as both an English Teacher and a computer programmer. I have contributed quite a few code improvements to Bugzilla. I have fixed more documentation bugs in the last six months than anyone else has in the last 30. If anyone was going to be awarded Trusted Docs Hacker status, I'd like to think that all of those things would put me on short list... and not only do I not want the honour, I don't think that the position should even exist. I agree with Dave that certain folks should be allowed to go in and fix typographical/presentational things, but I strongly believe that all content and structural changes should be reviewed by another human being who cares enough about documentation to want to be on the Documentation Review Team. Just because a girl isn't as popular, doesn't mean she should 'put out' more so people will be willing to be with her; just because documentation isn't perceived as a glamorous (or even, sometimes, valued) contribution doesn't mean we should relax the standards on it. All, of course, IMHO. Shane H.W. Travis | The greatest of all mistakes is to do nothing travis at sedsystems.ca | because you can only do a little. Saskatoon, Saskatchewan | Do what you can. -- Sydney Smith From tree at basistech.com Fri Mar 18 19:43:44 2005 From: tree at basistech.com (Tom Emerson) Date: Fri, 18 Mar 2005 14:43:44 -0500 Subject: docs in a wiki [was Re: making review/bug filing optional In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A427900BF@ssvlexmb2.amd.com> References: <6F7DA19D05F3CF40B890C7CA2DB13A427900BF@ssvlexmb2.amd.com> Message-ID: <16955.12144.972151.991606@tiphares.basistech.net> My biggest problem with documentation in X?HTML/CSS is that when printing tables end up looking like crap, getting split in the middle of a cell, etc. If CSS[23] addresses this, *and* browsers can support it, then perhaps it is worth looking at. But for generating documentation that looks good in print and on the screen, the choices are really DocBook or LaTeX (the Python documentation set being a primary example of the LaTeX aspect.) With that said, I like the idea of putting the docs into a Wiki. One feature that is nice about the PostgreSQL and MySQL documentation sets is that you can view them online with or without user comments: being able to include user feedback/clarification directly into the documentation can be very useful. -- Tom Emerson Basis Technology Corp. Software Architect http://www.basistech.com "Beware the lollipop of mediocrity: lick it once and you suck forever" From kevin.benton at amd.com Fri Mar 18 20:39:03 2005 From: kevin.benton at amd.com (Benton, Kevin) Date: Fri, 18 Mar 2005 12:39:03 -0800 Subject: docs in a wiki [was Re: making review/bug filing optional Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A427900D4@ssvlexmb2.amd.com> > My biggest problem with documentation in X?HTML/CSS is that when > printing tables end up looking like crap, getting split in the middle > of a cell, etc. If CSS[23] addresses this, *and* browsers can support > it, then perhaps it is worth looking at. But for generating > documentation that looks good in print and on the screen, the choices > are really DocBook or LaTeX (the Python documentation set being a > primary example of the LaTeX aspect.) I'm very glad to report that isn't an issue in XHTML/CSS if you use orphans and widows styles. :) The only real annoyance I've seen with it (printing) is not being able to control the header and footer that most browsers put on pages. That control won't be here till CSS 3 Paged Media. I still have to use my own software to create my index and TOC but that's really not that hard to do. --- 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. > With that said, I like the idea of putting the docs into a Wiki. One > feature that is nice about the PostgreSQL and MySQL documentation sets > is that you can view them online with or without user comments: being > able to include user feedback/clarification directly into the > documentation can be very useful. > > -- > Tom Emerson Basis Technology > Corp. > Software Architect > http://www.basistech.com > "Beware the lollipop of mediocrity: lick it once and you suck forever" > - > To view or change your list settings, click here: > From myk at mozilla.org Fri Mar 18 23:19:51 2005 From: myk at mozilla.org (Myk Melez) Date: Fri, 18 Mar 2005 15:19:51 -0800 Subject: docs in a wiki [was Re: making review/bug filing optional for In-Reply-To: <423B0F58.2000001@bugzilla.org> References: <4239F047.7050002@mozilla.org> <423A1D0A.5010809@mozilla.org> <423A2257.6040406@mozilla.org> <2cb10c4405031804539b80498@mail.gmail.com> <423B0F58.2000001@bugzilla.org> Message-ID: <423B6217.1020200@mozilla.org> David Miller wrote: > That's actually a pretty cool idea, except that as far as I know, > wikis don't deal well with Docbook XML, and it would probably be > non-trivial to convert it. It would be fairly easy to convert the Docbook XML to HTML and then put it into the wiki if the wiki supported HTML in addition to wiki formatting. > We do actually have a wiki we can use already if we want it at > http://wiki.mozilla.org/ . Would be easy enough to create a namespace > for Bugzilla on there. Sounds like a good idea. We can always give it a try and see if it results in better or worse documentation. -myk From bugreport at peshkin.net Fri Mar 18 23:45:31 2005 From: bugreport at peshkin.net (Joel Peshkin) Date: Fri, 18 Mar 2005 15:45:31 -0800 Subject: making review/bug filing optional for some docs changes In-Reply-To: <2cb10c4405031810303810be5@mail.gmail.com> References: <6F7DA19D05F3CF40B890C7CA2DB13A4279008A@ssvlexmb2.amd.com> <2cb10c4405031810303810be5@mail.gmail.com> Message-ID: <423B681B.5000309@peshkin.net> Luis Villa wrote: >>Our customers could not tolerate anything less. >> >> > Wow. That sounds incredibly stiflingly unfun. Glad people are paid to > >work on this now... > > Bugzilla customers are the people who find enough use for Bugzilla to either contribute or to hire people to contribute. It would be a bad idea not to take them seriously. The same professional standards apply regardless of the business model. From myk at mozilla.org Fri Mar 18 23:47:24 2005 From: myk at mozilla.org (Myk Melez) Date: Fri, 18 Mar 2005 15:47:24 -0800 Subject: making review/bug filing optional for some docs changes In-Reply-To: References: <6F7DA19D05F3CF40B890C7CA2DB13A4279008A@ssvlexmb2.amd.com> <2cb10c4405031810303810be5@mail.gmail.com> Message-ID: <423B688C.6050600@mozilla.org> Shane H. W. Travis wrote: >That is, in part, what this discussion is about; lowering the bar so that >documentation patches can get in more quickly/with less effort, so hopefully >things stay more current. > > For me, that's entirely what this is about: removing bug and review requirements for certain kinds of changes to make possible more and better documentation. Note that unlike Gerv's earlier proposal I'm suggesting we remove these requirements for small changes and additions, not large ones. >This, then, is part of my problem. It seems like people are saying, "I'd be >happy to contribute! I just love writing documentation... but you've got all >these messy *procedures* in the way that are stopping me." > That's not what I'm saying. I'm saying that I *don't* love writing documentation, but I do understand the importance of it, so I *am* happy to contribute, but I have limited time to do so, and if I spend time on process I won't have it to spend on documentation, which means I'll be able to contribute less documentation, and the value of the documentation I won't be able to contribute is much greater than the value of the improvements to it that going through the process will provide. >The underlying >message seems to be, "If I can't have complete and free access with nobody >else restricting me, questioning me, or second-guessing me... then I just >won't do anything at all." > > That's not it at all. I just think that for some kinds of changes such restrictions, questions, and second guesses are unnecessary and harmful. >The prevailing argument is that documentation could be fixed later... and I >agree that it could, *if people notice that it needs fixing*. The people >reading the docs are not, typically, people who are completely conversant >with Bugzilla. > That doesn't make them incapable of figuring out when the docs are wrong. After all, they may not know Bugzilla, but they're reading the docs specificly to apply its instruction to their copy of it. If the docs are wrong, they'll figure it out, because their Bugzilla won't do what the docs say it should. Of course, this doesn't obviate the need for us to minimize errors in the docs before we ship them to our users. But shipping errors in docs is not the end of the world, and we have to balance efforts to reduce the error count with their cost. In my mind, requiring one review for all changes and a bug for every fix, regardless of how large or controversial the change is or how good the documenter is at writing good docs, doesn't balance these costs and benefits well. >I have University credentials as both an English Teacher and a computer >programmer. I have contributed quite a few code improvements to Bugzilla. I >have fixed more documentation bugs in the last six months than anyone else >has in the last 30. If anyone was going to be awarded Trusted Docs Hacker >status, I'd like to think that all of those things would put me on short >list... and not only do I not want the honour, I don't think that the >position should even exist. > That's OK, you don't have to accept the position. I'm not suggesting that quality Bugzilla documenters should be forced to go without review, and I certainly don't think it should have anything to do with how much documentation you've contributed in the past. It should be awarded solely on the basis of known capability to write good docs, and anyone who gets it should be able to choose to have all changes go through review if they so desire. >Just because a girl isn't as popular, doesn't mean she should 'put out' >more so people will be willing to be with her; just because documentation >isn't perceived as a glamorous (or even, sometimes, valued) contribution >doesn't mean we should relax the standards on it. > > Sure, but glamour and value has nothing to do with it. I value docs, and I'm suggesting this change because I think it will make them better (higher quality, more comprehensive), relaxing the process, not our standards. -myk From luis.villa at gmail.com Sat Mar 19 00:10:19 2005 From: luis.villa at gmail.com (Luis Villa) Date: Fri, 18 Mar 2005 19:10:19 -0500 Subject: making review/bug filing optional for some docs changes In-Reply-To: <423B681B.5000309@peshkin.net> References: <6F7DA19D05F3CF40B890C7CA2DB13A4279008A@ssvlexmb2.amd.com> <2cb10c4405031810303810be5@mail.gmail.com> <423B681B.5000309@peshkin.net> Message-ID: <2cb10c44050318161033c095c8@mail.gmail.com> On Fri, 18 Mar 2005 15:45:31 -0800, Joel Peshkin wrote: > Luis Villa wrote: > > >>Our customers could not tolerate anything less. > >> > >> > > Wow. That sounds incredibly stiflingly unfun. Glad people are paid to > > > >work on this now... > > > > > > Bugzilla customers are the people who find enough use for Bugzilla to > either contribute or to hire people to contribute. It would be a bad > idea not to take them seriously. The same professional standards apply > regardless of the business model. I think there is a lot of evidence out there that you can produce effectively 'enterprise'[1]-quality software and documentation, and produce it a lot faster and a lot more fun, if you let go a bit and make it easier for motivated people to contribute. I'm not saying bugzilla should abandon attempts to make good software- I'm just saying that adopting strict, nearly traditional methods which discourage the participation of people who are interested but don't have tons of time is not the right way to get to professional quality software when you're not paying people.[2] If you guys want to create a rigid, painful process, that's fine, but there are a lot of people out there (like me) who'd like to give small amounts of quality work to bugzilla. Locking them out because of unfounded paranoia about the quality of their work, IMHO, is silly- instead, encourage them to contribute, figure out how to let them see results quickly (like wiki or the php documentation), and figure out how to do whatever quality control is necessary after the fact. I'd bet that in most cases it'll be a lot less QA work than you think, and a lot less than you currently do. Luis [1] I loathe that word. It implies that regular users don't need or deserve quality. [2] in many cases, it isn't the right way when you're paying people either, but that's a different rant for a different list ;) From myk at mozilla.org Sat Mar 19 01:14:18 2005 From: myk at mozilla.org (Myk Melez) Date: Fri, 18 Mar 2005 17:14:18 -0800 Subject: [Fwd: Re: [Fwd: Re: Bugsilla users]] Message-ID: <423B7CEA.7000408@mozilla.org> FWIW, I asked Mikhail for specifics, and this is the conversation we had. -------- Original Message -------- Subject: Re: [Fwd: Re: Bugsilla users] Date: Fri, 18 Mar 2005 11:36:37 +0200 From: Mikhail Barashkov To: Myk Melez References: <42334D9A.6090407 at mozilla.org> <42364AEE.7070603 at mozilla.org> <4236BF3D.5080207 at handydev.com> <423A26DB.80509 at mozilla.org> >> No out-of-the-box color coding for bug status. > > > We avoid too much use of color in Bugzilla because of the color blind > and also because we use background shading to distinguish between > rows. But you can implement color coding by status or severity with > simple CSS, since all rows are tagged with CSS classes denoting those > states. > See, I did not want very much to twick CSS files. I am not a web designer/develoepr, in fact. I wish I was able to tune UI from Preferences. That would be just fine. >> When you add a bug, you can't select a user to assign bug to from a >> drop-down list, you only can type in his e-mail (not even nickname). > > > This is a preference which is off by default, but you can turn it on > in editparams.cgi. It's called "usemenuforusers". Alternately, with > the "usermatchmode" param you can turn on user matching, which matches > what you type into a user field against user email addresses and names > (i.e. type "myk" and it gets replaced with "myk at mozilla.org", or you > get a list of matches if there are more than one, when you submit the > form). > Well, that's it, again. If it ever was in preferences, in a easy-to find place :) > I hope mantis works well for you. If you ever decide to give Bugzilla > a second look, let us know what gives you the headache, since there > are probably solutions to those problems. Well, it seems like you should just make some really beatiful CSS templates and allow to switch them in preferences; and add other options to preferences. Not all your users are committed to spend hours tuning up Bugzilla :) Wish you good luck, Mikhail Barashkov -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkanat at kerio.com Sat Mar 19 01:35:15 2005 From: mkanat at kerio.com (Maxwell Kanat-Alexander) Date: Fri, 18 Mar 2005 17:35:15 -0800 Subject: making review/bug filing optional for some docs changes In-Reply-To: <423B688C.6050600@mozilla.org> References: <6F7DA19D05F3CF40B890C7CA2DB13A4279008A@ssvlexmb2.amd.com> <2cb10c4405031810303810be5@mail.gmail.com> <423B688C.6050600@mozilla.org> Message-ID: <1111196115.6217.18.camel@localhost.localdomain> On Fri, 2005-03-18 at 15:47 -0800, Myk Melez wrote: > For me, that's entirely what this is about: removing bug and review > requirements for certain kinds of changes to make possible more and > better documentation. I haven't seen any problems manifest from the current way of doing things. I don't think there's any problem with docs review. Do you have any statistics or examples of an actual problem? I think we just need more people who *write* docs, and we're getting those slowly. -Max From mkanat at kerio.com Sat Mar 19 01:37:04 2005 From: mkanat at kerio.com (Maxwell Kanat-Alexander) Date: Fri, 18 Mar 2005 17:37:04 -0800 Subject: [Fwd: Re: [Fwd: Re: Bugsilla users]] In-Reply-To: <423B7CEA.7000408@mozilla.org> References: <423B7CEA.7000408@mozilla.org> Message-ID: <1111196224.6217.21.camel@localhost.localdomain> On Fri, 2005-03-18 at 17:14 -0800, Myk Melez wrote: > FWIW, I asked Mikhail for specifics, and this is the conversation we > had. I would agree with Mikhail that although accessibility is important, we don't have to penalize 95% of the users to make Bugzilla accessible to 5% of the users. However, we still ought to have some way for that 5% of users to use Bugzilla. Even a few colors can make Bugzilla remarkably easier to look at. -Max -- Max Kanat-Alexander Technical Support Manager, USA Kerio Technologies, Inc. 2350 Mission College Blvd., Suite 400 Santa Clara, CA 95054 Phone: (408) 496-4500 Fax: (408) 496-6902 http://www.kerio.com/support.html From justdave at bugzilla.org Sat Mar 19 02:01:48 2005 From: justdave at bugzilla.org (David Miller) Date: Fri, 18 Mar 2005 21:01:48 -0500 Subject: [Fwd: Re: [Fwd: Re: Bugsilla users]] In-Reply-To: <1111196224.6217.21.camel@localhost.localdomain> References: <423B7CEA.7000408@mozilla.org> <1111196224.6217.21.camel@localhost.localdomain> Message-ID: <423B880C.7020708@bugzilla.org> Maxwell Kanat-Alexander wrote: > I would agree with Mikhail that although accessibility is important, we > don't have to penalize 95% of the users to make Bugzilla accessible to > 5% of the users. > > However, we still ought to have some way for that 5% of users to use > Bugzilla. > > Even a few colors can make Bugzilla remarkably easier to look at. That's why alternative stylesheets were invented. :) Firefox gives you a handy popup menu in the corner to choose between them when the page lists them in the header (and I'm pretty sure Opera does, too). If they have javascript, you can even swap the stylesheet from a click on the page, too. -- 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 luis.villa at gmail.com Sat Mar 19 02:06:40 2005 From: luis.villa at gmail.com (Luis Villa) Date: Fri, 18 Mar 2005 21:06:40 -0500 Subject: making review/bug filing optional for some docs changes In-Reply-To: <1111196115.6217.18.camel@localhost.localdomain> References: <6F7DA19D05F3CF40B890C7CA2DB13A4279008A@ssvlexmb2.amd.com> <2cb10c4405031810303810be5@mail.gmail.com> <423B688C.6050600@mozilla.org> <1111196115.6217.18.camel@localhost.localdomain> Message-ID: <2cb10c440503181806491b33ac@mail.gmail.com> On Fri, 18 Mar 2005 17:35:15 -0800, Maxwell Kanat-Alexander wrote: > On Fri, 2005-03-18 at 15:47 -0800, Myk Melez wrote: > > For me, that's entirely what this is about: removing bug and review > > requirements for certain kinds of changes to make possible more and > > better documentation. > > I haven't seen any problems manifest from the current way of doing > things. > > I don't think there's any problem with docs review. > > Do you have any statistics or examples of an actual problem? > > I think we just need more people who *write* docs, and we're getting > those slowly. ^^^ That's the problem. Luis From myk at mozilla.org Sat Mar 19 02:24:13 2005 From: myk at mozilla.org (Myk Melez) Date: Fri, 18 Mar 2005 18:24:13 -0800 Subject: making review/bug filing optional for some docs changes In-Reply-To: <1111196115.6217.18.camel@localhost.localdomain> References: <6F7DA19D05F3CF40B890C7CA2DB13A4279008A@ssvlexmb2.amd.com> <2cb10c4405031810303810be5@mail.gmail.com> <423B688C.6050600@mozilla.org> <1111196115.6217.18.camel@localhost.localdomain> Message-ID: <423B8D4D.4010806@mozilla.org> Maxwell Kanat-Alexander wrote: > Do you have any statistics or examples of an actual problem? > > I only have anecdotal examples. Here's a docs fix I made a few days ago and which started me thinking about the issue: https://bugzilla.mozilla.org/show_bug.cgi?id=286265 Filing the bug and getting review took more time than making the change and checking it in, which is tremendously inefficient for patches like this with a high likelihood of being good as is (or at least good enough). > I think we just need more people who *write* docs, and we're getting >those slowly. > > We do need more people who write docs, but we also need to make the most of their time. -myk From myk at mozilla.org Sat Mar 19 02:28:55 2005 From: myk at mozilla.org (Myk Melez) Date: Fri, 18 Mar 2005 18:28:55 -0800 Subject: [Fwd: Re: [Fwd: Re: Bugsilla users]] In-Reply-To: <1111196224.6217.21.camel@localhost.localdomain> References: <423B7CEA.7000408@mozilla.org> <1111196224.6217.21.camel@localhost.localdomain> Message-ID: <423B8E67.8000509@mozilla.org> Maxwell Kanat-Alexander wrote: > I would agree with Mikhail that although accessibility is important, we >don't have to penalize 95% of the users to make Bugzilla accessible to >5% of the users. > > It's higher than that, but note that color blindness is only one reason we don't use color to differentiate between bug statuses by default. > However, we still ought to have some way for that 5% of users to use >Bugzilla. > > Even a few colors can make Bugzilla remarkably easier to look at. > > Agreed, which is why we alternate background colors in bug lists to differentiate between consecutive bug rows. I'm open to other uses of color, but I don't find mantis's implementation particularly compelling. -myk -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkanat at kerio.com Sat Mar 19 03:22:37 2005 From: mkanat at kerio.com (Maxwell Kanat-Alexander) Date: Fri, 18 Mar 2005 19:22:37 -0800 Subject: Review From the Wind Never Happens Message-ID: <1111202558.6217.35.camel@localhost.localdomain> Please look at and comment on bug 286822 and its current attachment: https://bugzilla.mozilla.org/show_bug.cgi?id=286822 -Max -- Max Kanat-Alexander Technical Support Manager, USA Kerio Technologies, Inc. 2350 Mission College Blvd., Suite 400 Santa Clara, CA 95054 Phone: (408) 496-4500 Fax: (408) 496-6902 http://www.kerio.com/support.html From mkanat at kerio.com Sat Mar 19 03:23:05 2005 From: mkanat at kerio.com (Maxwell Kanat-Alexander) Date: Fri, 18 Mar 2005 19:23:05 -0800 Subject: making review/bug filing optional for some docs changes In-Reply-To: <423B8D4D.4010806@mozilla.org> References: <6F7DA19D05F3CF40B890C7CA2DB13A4279008A@ssvlexmb2.amd.com> <2cb10c4405031810303810be5@mail.gmail.com> <423B688C.6050600@mozilla.org> <1111196115.6217.18.camel@localhost.localdomain> <423B8D4D.4010806@mozilla.org> Message-ID: <1111202586.6217.36.camel@localhost.localdomain> On Fri, 2005-03-18 at 18:24 -0800, Myk Melez wrote: > I only have anecdotal examples. Here's a docs fix I made a few days ago > and which started me thinking about the issue: > > https://bugzilla.mozilla.org/show_bug.cgi?id=286265 > > Filing the bug and getting review took more time than making the change > and checking it in, which is tremendously inefficient for patches like > this with a high likelihood of being good as is (or at least good enough). Yeah, looks like we just need more docs reviewers. :-) Or at least, perhaps a more coordinated way of quickly reviewing trivial changes. I do think that that change needed review, but the review should have been faster, because the change was obviously correct. I think that perhaps I have an idea for a solution to that: https://bugzilla.mozilla.org/show_bug.cgi?id=286822#c3 I wouldn't guarantee that all such changes would be obviously correct. :-) -Max From jake at bugzilla.org Sat Mar 19 18:33:09 2005 From: jake at bugzilla.org (Jake) Date: Sat, 19 Mar 2005 13:33:09 -0500 Subject: docs in a wiki [was Re: making review/bug filing optional for In-Reply-To: <423B0F58.2000001@bugzilla.org> References: <4239F047.7050002@mozilla.org> <423A1D0A.5010809@mozilla.org> <423A2257.6040406@mozilla.org> <2cb10c4405031804539b80498@mail.gmail.com> <423B0F58.2000001@bugzilla.org> Message-ID: <423C7065.8070406@bugzilla.org> David Miller wrote: > That's actually a pretty cool idea, except that as far as I know, > wikis don't deal well with Docbook XML, and it would probably be > non-trivial to convert it. > > We do actually have a wiki we can use already if we want it at > http://wiki.mozilla.org/ . Would be easy enough to create a namespace > for Bugzilla on there. Personally, I don't like the wiki concept. If you look at the original question and the arguments against it, a wiki actually compounds the problem, not solves it. That said, if the Dave decided that docs would be in a wiki I wouldn't block it. From engine at gmail.com Sat Mar 19 19:11:50 2005 From: engine at gmail.com (Jeff) Date: Sat, 19 Mar 2005 14:11:50 -0500 Subject: [Fwd: Re: [Fwd: Re: Bugsilla users]] In-Reply-To: <423B8E67.8000509@mozilla.org> References: <423B7CEA.7000408@mozilla.org> <1111196224.6217.21.camel@localhost.localdomain> <423B8E67.8000509@mozilla.org> Message-ID: <14943db3050319111124f0e387@mail.gmail.com> > > I would agree with Mikhail that although accessibility is important, we > > don't have to penalize 95% of the users to make Bugzilla accessible to 5% of > > the users. > > It's higher than that, but note that color blindness is only one > reason we don't use color to differentiate between bug statuses by default. Yeah, I believe the numbers for color blindness are 1 in 12, or 8%. And, I don't think colors are that useful for relaying information such as bug statuses, anyway. I remember learning somewhere that a study was done and that colors were unable to relay much more information other than grouping (all these red things are together, all these blue things are together). >From looking at Mantis' color scheme, one would have to be constantly negotaiting color meanigs in one's head, e.g. ("ok, pink is urgent, but brighter pink is higher priority, light blue is..."). I think it's butt, anyway. Whoops, not to push this thread away from the original topic anyway, of one user's feedback. From vladd at bugzilla.org Sat Mar 19 21:04:05 2005 From: vladd at bugzilla.org (Vlad Dascalu) Date: Sat, 19 Mar 2005 23:04:05 +0200 Subject: docs in a wiki [was Re: making review/bug filing optional for In-Reply-To: <423C7065.8070406@bugzilla.org> References: <4239F047.7050002@mozilla.org> <423A1D0A.5010809@mozilla.org> <423A2257.6040406@mozilla.org> <2cb10c4405031804539b80498@mail.gmail.com> <423B0F58.2000001@bugzilla.org> <423C7065.8070406@bugzilla.org> Message-ID: <423C93C5.50305@bugzilla.org> Jake wrote: > That said, if the Dave decided that docs would be in a wiki I wouldn't > block it. You wouldn't be able to "block" it in such a situation. Vlad (vladd). From mkanat at kerio.com Sun Mar 20 03:47:35 2005 From: mkanat at kerio.com (Max Kanat-Alexander) Date: Sat, 19 Mar 2005 19:47:35 -0800 Subject: Release Notes For 2.19.3 Message-ID: <1111290455.18166.3.camel@localhost.localdomain> I'm going to be working on the Release Notes for 2.19.3, pretty soon. Here is what will likely go into those release notes: http://tinyurl.com/5z376 If you know of anything that isn't in that list, but should be, please add a comment to bug 286273, and also add the "relnote" keyword to that bug. -Max From gerv at mozilla.org Sun Mar 20 14:12:43 2005 From: gerv at mozilla.org (Gervase Markham) Date: Sun, 20 Mar 2005 14:12:43 +0000 Subject: making review/bug filing optional for some docs changes In-Reply-To: References: <6F7DA19D05F3CF40B890C7CA2DB13A4279008A@ssvlexmb2.amd.com> <2cb10c4405031810303810be5@mail.gmail.com> Message-ID: <423D84DB.5050804@mozilla.org> Shane H. W. Travis wrote: > When Gerv brought up this topic before, he named about six things that > needed doing on the documentation that could only be done in 'grand, > sweeping changes', and that all he needed was a completely free hand and 12 > solid hours of hacking to bring the documentation up to snuff. I disagreed > with him on whether or not the process was broken, and asked him to file > documentation bugs on any or all of the things he said that needed changing, > as they all sounded valid. I welcomed his contributions, and invited his > contribution on those issues, or any promised to make the review procedure > as quick and painless as possible. > > To date, to the best of my knowledge, nothing has been done on that front; > No bugs filed, no patches uploaded, nothing. Nope. And, thinking about it, here's why. Doing the analysis to find out what needs fixing, and writing up some sort of proposal to explain it in detail, is simply an impossible task. Last time I did a big docs whackage, I spent 16 hours over two days cutting, pasting, moving, rereading, refining, eliminating - *editing*. I had no idea when I started about exactly what I'd be touching and where I'd end up, and couldn't have explained it - it was just fairly obvious that the docs were in various areas poorly organised, repetitive, unclear and redundant and they needed work. Here, as an example, is the diffs of the changes I made, just to the installation section. There is hardly a single line left untouched. http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=installation.xml&branch=&root=/cvsroot&subdir=mozilla/webtools/bugzilla/docs/xml&command=DIFF_FRAMESET&rev1=1.58&rev2=1.59 Here the page is before: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/webtools/bugzilla/docs/xml/installation.xml&rev=1.58 And here it is after: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/webtools/bugzilla/docs/xml/installation.xml&rev=1.59 Now, that section was, as a whole, absolutely definitely much, much better after I'd finished than before I started (if you disagree with that, shout - but I really don't expect anyone to). But before I started, could I have defined what I was going to do? Not except in terms so vague as to be useless. Once I'd finished, a couple of bugs got filed - "you changed this, and we don't like it". Cool - no problem. Let's change it back. That doesn't mean the entire procedure was broken, just as if you check in a code patch and it causes regressions, it doesn't mean the patch was a bad idea. Now, I'm not expecting to be allowed to do such a major change the day before a release. Which is why I suggested that such changes should be allowed while the tree is not frozen. Then, during the freeze period, we can read and review the documentation - which hopefully, is structurally sound by this point - and fix factual errors. > Were someone to try and take such an attitude to the codebase, the answer > would be, "Sorry to hear that; there's the door. Don't let it hit you in > the ass on the way out." Documentation is perceived as 'lesser', though, > because one cannot 'break' it in the same way that one can break code; no > amount of poor English, typographical errors, or factual inaccuracies will > stop it from being The Documentation. Documentation is not perceived as "lesser" - at least, not by me - it's perceived as _different_. Because you can't break it, and because people like working on it less, the procedure for achieving the highest quality documentation with the resources available is different from the procedure for achieving the highest-quality code. Gerv From gerv at mozilla.org Sun Mar 20 14:17:44 2005 From: gerv at mozilla.org (Gervase Markham) Date: Sun, 20 Mar 2005 14:17:44 +0000 Subject: docs in a wiki [was Re: making review/bug filing optional for In-Reply-To: <423B6217.1020200@mozilla.org> References: <4239F047.7050002@mozilla.org> <423A1D0A.5010809@mozilla.org> <423A2257.6040406@mozilla.org> <2cb10c4405031804539b80498@mail.gmail.com> <423B0F58.2000001@bugzilla.org> <423B6217.1020200@mozilla.org> Message-ID: <423D8608.8070606@mozilla.org> Myk Melez wrote: >> We do actually have a wiki we can use already if we want it at >> http://wiki.mozilla.org/ . Would be easy enough to create a namespace >> for Bugzilla on there. > > Sounds like a good idea. We can always give it a try and see if it > results in better or worse documentation. If it results in worse documentation, how do we change back? Having said that, if putting the docs in a Wiki lowers the barrier to change and makes people more comfortable with the idea of just going in and fixing stuff, I'm all for it. Gerv From travis at SEDSystems.ca Sun Mar 20 19:38:36 2005 From: travis at SEDSystems.ca (Shane H. W. Travis) Date: Sun, 20 Mar 2005 13:38:36 -0600 (CST) Subject: [Fwd: Re: [Fwd: Re: Bugsilla users]] In-Reply-To: <423B7CEA.7000408@mozilla.org> References: <423B7CEA.7000408@mozilla.org> Message-ID: On Fri, 18 Mar 2005, Myk Melez wrote: > >> No out-of-the-box color coding for bug status. > > > > > > We avoid too much use of color in Bugzilla because of the color blind > > and also because we use background shading to distinguish between > > rows. But you can implement color coding by status or severity with > > simple CSS, since all rows are tagged with CSS classes denoting those > > states. > > > See, I did not want very much to twick CSS files. I am not a web > designer/develoepr, in fact. > I wish I was able to tune UI from Preferences. That would be just fine. Just FTR, there is a bug open on this: https://bugzilla.mozilla.org/show_bug.cgi?id=36013 There was no way to make it user-customizable until recently when bug 98123 landed; now that it has, I forsee this getting done before 2.22 is ready to ship. > Well, it seems like you should just make some really beatiful CSS > templates and allow to switch them in preferences; Isn't this what 'skins' is? Shane H.W. Travis | The greatest of all mistakes is to do nothing travis at sedsystems.ca | because you can only do a little. Saskatoon, Saskatchewan | Do what you can. -- Sydney Smith From luis.villa at gmail.com Sun Mar 20 20:26:45 2005 From: luis.villa at gmail.com (Luis Villa) Date: Sun, 20 Mar 2005 15:26:45 -0500 Subject: docs in a wiki [was Re: making review/bug filing optional for In-Reply-To: <423D8608.8070606@mozilla.org> References: <4239F047.7050002@mozilla.org> <423A1D0A.5010809@mozilla.org> <423A2257.6040406@mozilla.org> <2cb10c4405031804539b80498@mail.gmail.com> <423B0F58.2000001@bugzilla.org> <423B6217.1020200@mozilla.org> <423D8608.8070606@mozilla.org> Message-ID: <2cb10c440503201226364d90d8@mail.gmail.com> On Sun, 20 Mar 2005 14:17:44 +0000, Gervase Markham wrote: > Myk Melez wrote: > >> We do actually have a wiki we can use already if we want it at > >> http://wiki.mozilla.org/ . Would be easy enough to create a namespace > >> for Bugzilla on there. > > > > Sounds like a good idea. We can always give it a try and see if it > > results in better or worse documentation. > > If it results in worse documentation, how do we change back? Wikis have revisions too :) Mediawiki's is particularly good. > Having said that, if putting the docs in a Wiki lowers the barrier to > change and makes people more comfortable with the idea of just going in > and fixing stuff, I'm all for it. This is certainly why I suggested it. Luis From travis at SEDSystems.ca Sun Mar 20 20:43:51 2005 From: travis at SEDSystems.ca (Shane H. W. Travis) Date: Sun, 20 Mar 2005 14:43:51 -0600 (CST) Subject: making review/bug filing optional for some docs changes In-Reply-To: <423D84DB.5050804@mozilla.org> References: <6F7DA19D05F3CF40B890C7CA2DB13A4279008A@ssvlexmb2.amd.com> <2cb10c4405031810303810be5@mail.gmail.com> <423D84DB.5050804@mozilla.org> Message-ID: On Sun, 20 Mar 2005, Gervase Markham wrote: > Shane H. W. Travis wrote: > > To date, to the best of my knowledge, nothing has been done on that front; > > No bugs filed, no patches uploaded, nothing. > > Nope. And, thinking about it, here's why. Doing the analysis to find out > what needs fixing, and writing up some sort of proposal to explain it in > detail, is simply an impossible task. No one (as far as I'm aware) is requiring that you give more detail *in advance* of working on a documentation reorg than you give when you work on a major piece of code architecture. All that is being asked is that you open a bug, and post your patch for review before it is committed to the trunk. Amount of extra work: 2 minutes to make the bug, 2 minutes to make the diff, two minutes to attach the diff. Heck, even if you didn't want to do the work yourself, you could have still opened the bugs; http://bugzilla.org/cgi-bin/mj_wwwusr?user=&passw=&list=developers&brief=on&func=archive-get-part&extra=200501/110 You named three things there that are worthy of documentation bugs. I asked you to open bugs against them so that they could be addressed -- if not by you, then by someone else. You already know the general outline of the issues you addressed there, or else you couldn't even have brought them up. Nobody asked for a road map or a highly detailed analysis... just an infodump on why you think it needs doing and maybe even one way to approach it. Is even that too much to ask? > Now, that section was, as a whole, absolutely definitely much, much > better after I'd finished than before I started (if you disagree with > that, shout - but I really don't expect anyone to). Fine, here's my shout. I like the 2.16 step-by-step Installation Instructions far better than what is currently in 2.18 or 2.20. They're easier for a rank beginner to understand, in that they provide a 'do this, then do this, then do this' format that can be easily followed. For more experienced people it's easier to find information about specific things on MySQL (for example) when the information is all are in one section, rather than split between Installation and Configuration. I often go back to the 2.16 docs rather than use the 2.18 ones, because I find it far more difficult to find what I need in the 2.18 docs. At some point, when I've got the time, I'd like to open a bug to re-write things and bring back the step-by-step process. Since you asked. Does that mean that nothing you did needed doing? Of course not. You fixed up a lot of stuff that needed fixing; I just didn't like the shape of the end result. Since it's already done, though, what's the point in discussing it *now*? > But before I started, could I have defined what I was going to do? Not > except in terms so vague as to be useless. I would assert that the whole process could have benefitted from some more structured goals; if you're not even sure what your endpoint is, how do you know if you're there yet? Bugs with one goal -- even when that goal is a huge one, like "update the entire FAQ" or "Add a troubleshooting guide" or "Amalgamate the windows documentation found everywhere into one location" provide a solid surface. They give guidance by which others can assess if one is doing it right or not, or if there are places where things have been missed/need inclusion. I assert that this is a good thing, and beneficial for the docs as a whole. > Once I'd finished, a couple of bugs got filed - "you changed this, and > we don't like it". Cool - no problem. Let's change it back. That doesn't > mean the entire procedure was broken, just as if you check in a code > patch and it causes regressions, it doesn't mean the patch was a bad idea. That code patch in your example had many people look at it to determine if it was a bad idea before it ever gets done. First of all, it's subject to general analysis on creation, then someone has to review it, then someone else has to approve it. Only then does it get checked in. As I understand it, the result of your 16 hour docs hackathon ended up with people being presented with a 'fait accompli'. Nobody even got a chance to say if they thought it was a good idea or not; you did it, and you checked it in. Voila! Note, however, that when you asked what people thought about doing the same thing for 2.18, the answer was a resounding 'no'. (Being willing to change things back does not make it any less of a 'fait accompli'. It was done, it was checked in, and nobody got to look at it BEFORE that happened is the point I'm raising.) In UI design, there are some big names in the field who say that 'computer mockups' -- even if there is absolutely no functional code behind them -- are a bad way to get user feedback on designs. The user will see the screen and be less willing to make suggestions because zie will be inherently unwilling to discard the effort already put forth to get the design to this point. Presented with the exact same design in a pencil-and-paper sketch, however, people are much more willing to suggest improvements, as they know that the effort required to get to this stage is orders of magnitude less. I submit that you ran into a similar case; people appreciated the work you HAD done, and didn't really want to undo/invalidate that work even if they thought that parts of it shouldn't have been done like that. > Now, I'm not expecting to be allowed to do such a major change the day > before a release. Then you've changed your expectations in the last two months. http://bugzilla.org/cgi-bin/mj_wwwusr?user=&passw=&list=developers&brief=on&func=archive-get-part&extra=200501/100 Factual note: it is actually *two* days before the 2.18 release that you wrote this, asking for carte blanche to re-write the docs as you saw fit. As such, you could probably claim victory on a technicality. This letter got more into the personal/historical and less into the meta-topic, but my belief is that documentation can benefit from design just as much -- if, perhaps, in different ways -- as code can. When Bugzilla started off, based on what I've seen/heard, there was little-to-no attempt at uniformity of style, or code integration, or code reuse... people just added things as they thought it needed adding. Now, despite there being a lot more people adding to the whole, there is a real effort to make things consistent, documented, and well-formed. It may be true that docs aren't in very good shape right now; one could easily compare them to the state of the code four or five years ago (which I recall reading someone describe as 'an abominable mess'). The code hasn't gotten prettier/better because we *relaxed* the restrictions on it, though, and just let people check in things whenever/wherever they wanted to... and I don't think going down that route would help the docs much either. Shane H.W. Travis | The greatest of all mistakes is to do nothing travis at sedsystems.ca | because you can only do a little. Saskatoon, Saskatchewan | Do what you can. -- Sydney Smith From Tomas.Kopal at altap.cz Mon Mar 21 06:43:25 2005 From: Tomas.Kopal at altap.cz (Tomas Kopal) Date: Mon, 21 Mar 2005 17:13:25 +1030 Subject: docs in a wiki [was Re: making review/bug filing optional for In-Reply-To: <423D8608.8070606@mozilla.org> References: <4239F047.7050002@mozilla.org> <423A1D0A.5010809@mozilla.org> <423A2257.6040406@mozilla.org> <2cb10c4405031804539b80498@mail.gmail.com> <423B0F58.2000001@bugzilla.org> <423B6217.1020200@mozilla.org> <423D8608.8070606@mozilla.org> Message-ID: <423E6D0D.7000308@altap.cz> Well, what about treating wiki as sort of "landfill" of documentation? Anyone can make an attempt to make the docs better, and some "reviewers" will be overlooking the changes. Approval from any of the reviewers would mean taking the changes from wiki and putting them back to the docbook sources, which will be the only "official" documentation. It would be necessary to find a way how to propagate these changes from wiki to docbook automatically, though. Tomas On 03/21/05 00:47, Gervase Markham wrote: > Myk Melez wrote: > >>> We do actually have a wiki we can use already if we want it at >>> http://wiki.mozilla.org/ . Would be easy enough to create a namespace >>> for Bugzilla on there. >> >> >> Sounds like a good idea. We can always give it a try and see if it >> results in better or worse documentation. > > > If it results in worse documentation, how do we change back? > > Having said that, if putting the docs in a Wiki lowers the barrier to > change and makes people more comfortable with the idea of just going in > and fixing stuff, I'm all for it. > > Gerv > - > To view or change your list settings, click here: > > From timeless at myrealbox.com Mon Mar 21 13:03:21 2005 From: timeless at myrealbox.com (timeless) Date: Mon, 21 Mar 2005 05:03:21 -0800 Subject: docs in a wiki [was Re: making review/bug filing optional for In-Reply-To: <423E6D0D.7000308@altap.cz> References: <4239F047.7050002@mozilla.org> <423A1D0A.5010809@mozilla.org> <423A2257.6040406@mozilla.org> <2cb10c4405031804539b80498@mail.gmail.com> <423B0F58.2000001@bugzilla.org> <423B6217.1020200@mozilla.org> <423D8608.8070606@mozilla.org> <423E6D0D.7000308@altap.cz> Message-ID: <423EC619.8000102@myrealbox.com> Tomas Kopal wrote: > Well, what about treating wiki as sort of "landfill" of documentation? or graveyard. i don't have much experience with wikis (or blogs), but what i have seen is that figuring out what's changed and worth looking at is non trivial, and not better than using bonsai on cvs or a decent query of bugzilla/bu.gmail. > Anyone can make an attempt to make the docs better, and some "reviewers" > will be overlooking the changes. these are the same reviewers who barely have time to review requests from the wind and write their own code/docs .... > Approval from any of the reviewers > would mean taking the changes from wiki and putting them back to the > docbook sources, which will be the only "official" documentation. lots of additional work.... > It would be necessary to find a way how to propagate these changes from > wiki to docbook automatically, though. sounds like a big problem waiting for someone to waste time on. From kevin.benton at amd.com Mon Mar 21 15:51:04 2005 From: kevin.benton at amd.com (Benton, Kevin) Date: Mon, 21 Mar 2005 07:51:04 -0800 Subject: making review/bug filing optional for some docs changes Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4279015D@ssvlexmb2.amd.com> I wouldn't mind being a docs reviewer. :) Granted, I may have things to learn before I could be really effective, but I wouldn't mind doing it. --- 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 Maxwell Kanat-Alexander > Sent: Friday, March 18, 2005 8:23 PM > To: developers at bugzilla.org > Subject: Re: making review/bug filing optional for some docs changes > > On Fri, 2005-03-18 at 18:24 -0800, Myk Melez wrote: > > I only have anecdotal examples. Here's a docs fix I made a few days ago > > and which started me thinking about the issue: > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=286265 > > > > Filing the bug and getting review took more time than making the change > > and checking it in, which is tremendously inefficient for patches like > > this with a high likelihood of being good as is (or at least good > enough). > > Yeah, looks like we just need more docs reviewers. :-) Or at least, > perhaps a more coordinated way of quickly reviewing trivial changes. > > I do think that that change needed review, but the review should > have > been faster, because the change was obviously correct. I think that > perhaps I have an idea for a solution to that: > https://bugzilla.mozilla.org/show_bug.cgi?id=286822#c3 > > I wouldn't guarantee that all such changes would be obviously > correct. :-) > > -Max > > > - > To view or change your list settings, click here: > From kevin.benton at amd.com Mon Mar 21 17:09:17 2005 From: kevin.benton at amd.com (Benton, Kevin) Date: Mon, 21 Mar 2005 09:09:17 -0800 Subject: making review/bug filing optional for some docs changes Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A42790174@ssvlexmb2.amd.com> > Shane H. W. Travis wrote: > > To date, to the best of my knowledge, nothing has been done on that > front; > > No bugs filed, no patches uploaded, nothing. > > Nope. And, thinking about it, here's why. Doing the analysis to find out > what needs fixing, and writing up some sort of proposal to explain it in > detail, is simply an impossible task. I don't see it as being an impossible task. I also don't think it needs to be highly detailed. I think it should be detailed enough for a reviewer to figure out general idea of what's being changed. I think the rest will be self-evident in the patch(es). > Last time I did a big docs whackage, I spent 16 hours over two days > cutting, pasting, moving, rereading, refining, eliminating - *editing*. > I had no idea when I started about exactly what I'd be touching and > where I'd end up, and couldn't have explained it - it was just fairly > obvious that the docs were in various areas poorly organised, > repetitive, unclear and redundant and they needed work. ... > Once I'd finished, a couple of bugs got filed - "you changed this, and > we don't like it". Cool - no problem. Let's change it back. That doesn't > mean the entire procedure was broken, just as if you check in a code > patch and it causes regressions, it doesn't mean the patch was a bad idea. In my mind, this is even more reason for review. If someone is doing "big docs whackage" as you call it, there ought to be a way to test the documentation to see what it will look like after all the "whackage" is applied but before it's released. Someone ought to read through the updated form to make sure it doesn't have issues that break the docs. > Documentation is not perceived as "lesser" - at least, not by me - it's > perceived as _different_. Because you can't break it, and because people > like working on it less, the procedure for achieving the highest quality > documentation with the resources available is different from the > procedure for achieving the highest-quality code. "because people like working on it less" - should be rewritten to say "because some people like working on it less". I'm one of those people who really enjoys doing docs and I am looking forward to continuing to aid in the improvement of BZ docs. As I see it, one of the big problems is how we often find that as developers, we often don't file documentation update requests until just before an official release rather than filing them in concert with our updates. I think it seems fair that any approval+ should have a bug filed for documentation against the changes made (when required), preferably with a review+ on those document updates. That way, we don't end up with 16-hour documentation code-a-thon's. When documentation structure needs to be changed, or large sections of the documentation need to be updated, I think it seems fair that bugs should be required. I'm actively creating a new Bugzilla document I'm calling the PRTG - Pre-Release Testing Guide that is being written completely from scratch. If it's accepted and put into Bugzilla documentation, each time an update is made that impacts pre-release testing, it will be the reviewer's and approver's responsibility to make sure that the PRTG updates are filed. If we let documentation like the PRTG slip, it will quickly become useless just like the Bugzilla Guide would if we ignored it. Does the creation of a PRTG make more work for all of us? Yes and no. It makes more work making sure we're up-to-snuff with our own documentation, but it also helps us make sure we're not releasing junk. It acts as a guide for developers, reviewers, administrators, and others. Does the benefit of having a PRTG outweigh the administrative cost of keeping it up-to-date? For me, it definitely does and I think the vast majority of others will find that to be the case as well. We disagree about your statement "because you can't break it". IMNSHO, one of three cases is always true when documentation and what's documented disagree. A) The documentation is broken, B) what's documented is broken, or C) both are broken. As I mentioned before, it's generally harder to re-learn something that's correct than it is to learn it right the first time. Back to the topic - I feel that a review of documentation updates before applying to CVS is necessary because 1) people are human and make mistakes, 2) having a reviewer review gives another human a chance to check over what is proposed, reducing the chance of publishing "stuff that's broken", and 3) two heads are usually better than one in this type of situation because the other person generally has a different perspective and can offer insight that the person requesting the update doesn't have. --- 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 jake at bugzilla.org Mon Mar 21 18:58:21 2005 From: jake at bugzilla.org (Jake) Date: Mon, 21 Mar 2005 13:58:21 -0500 Subject: docs in a wiki [was Re: making review/bug filing optional for In-Reply-To: <423C93C5.50305@bugzilla.org> References: <4239F047.7050002@mozilla.org> <423A1D0A.5010809@mozilla.org> <423A2257.6040406@mozilla.org> <2cb10c4405031804539b80498@mail.gmail.com> <423B0F58.2000001@bugzilla.org> <423C7065.8070406@bugzilla.org> <423C93C5.50305@bugzilla.org> Message-ID: <423F194D.8020205@bugzilla.org> Vlad Dascalu wrote: > Jake wrote: > >> That said, if the Dave decided that docs would be in a wiki I >> wouldn't block it. > > > You wouldn't be able to "block" it in such a situation. Block wasn't quite the right word, obviously. I meant something more along the lines of raise a fuss. From gerv at mozilla.org Mon Mar 21 22:56:10 2005 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 21 Mar 2005 22:56:10 +0000 Subject: docs in a wiki [was Re: making review/bug filing optional for In-Reply-To: <2cb10c440503201226364d90d8@mail.gmail.com> References: <4239F047.7050002@mozilla.org> <423A1D0A.5010809@mozilla.org> <423A2257.6040406@mozilla.org> <2cb10c4405031804539b80498@mail.gmail.com> <423B0F58.2000001@bugzilla.org> <423B6217.1020200@mozilla.org> <423D8608.8070606@mozilla.org> <2cb10c440503201226364d90d8@mail.gmail.com> Message-ID: <423F510A.1080303@mozilla.org> Luis Villa wrote: > On Sun, 20 Mar 2005 14:17:44 +0000, Gervase Markham wrote: >>If it results in worse documentation, how do we change back? > > Wikis have revisions too :) Mediawiki's is particularly good. Sorry for not being clear; I meant "how do we change back to DocBook"? Gerv From luis.villa at gmail.com Mon Mar 21 23:02:32 2005 From: luis.villa at gmail.com (Luis Villa) Date: Mon, 21 Mar 2005 18:02:32 -0500 Subject: docs in a wiki [was Re: making review/bug filing optional for In-Reply-To: <423F510A.1080303@mozilla.org> References: <4239F047.7050002@mozilla.org> <423A1D0A.5010809@mozilla.org> <423A2257.6040406@mozilla.org> <2cb10c4405031804539b80498@mail.gmail.com> <423B0F58.2000001@bugzilla.org> <423B6217.1020200@mozilla.org> <423D8608.8070606@mozilla.org> <2cb10c440503201226364d90d8@mail.gmail.com> <423F510A.1080303@mozilla.org> Message-ID: <2cb10c44050321150257488e3f@mail.gmail.com> On Mon, 21 Mar 2005 22:56:10 +0000, Gervase Markham wrote: > Luis Villa wrote: > > On Sun, 20 Mar 2005 14:17:44 +0000, Gervase Markham wrote: > >>If it results in worse documentation, how do we change back? > > > > Wikis have revisions too :) Mediawiki's is particularly good. > > Sorry for not being clear; I meant "how do we change back to DocBook"? If the wiki experiment failed, I'd think you'd want to go back to the last docbook-based version in CVS, no, instead of exporting back out of mediawiki? Luis From mkanat at kerio.com Mon Mar 21 23:35:47 2005 From: mkanat at kerio.com (Max Kanat-Alexander) Date: Mon, 21 Mar 2005 15:35:47 -0800 Subject: making review/bug filing optional for some docs changes In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4279015D@ssvlexmb2.amd.com> References: <6F7DA19D05F3CF40B890C7CA2DB13A4279015D@ssvlexmb2.amd.com> Message-ID: <1111448147.5488.18.camel@localhost.localdomain> On Mon, 2005-03-21 at 07:51 -0800, Benton, Kevin wrote: > I wouldn't mind being a docs reviewer. :) Granted, I may have things to > learn before I could be really effective, but I wouldn't mind doing it. Well, hey. :-) I think that the best way to become a docs reviewer is to start doing docs reviews. :-) Feel free to pull up the documentation at bugzilla.bugs request queue (using the My Requests screen) and do some informal reviews on waiting docs. :-) -Max -- Max Kanat-Alexander Technical Support Manager, USA Kerio Technologies, Inc. 2350 Mission College Blvd., Suite 400 Santa Clara, CA 95054 Phone: (408) 496-4500 Fax: (408) 496-6902 http://www.kerio.com/support.html From gerv at mozilla.org Tue Mar 22 12:11:46 2005 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 22 Mar 2005 12:11:46 +0000 Subject: IBM DeveloperWorks article on Bugzilla Message-ID: <42400B82.6040102@mozilla.org> IBM DeveloperWorks appears to have swallowed and regurgitated the installation guide: http://www-128.ibm.com/developerworks/linux/library/l-bugzilla.html?ca=dgr-lnxw04Bugzilla [While higher visibility is good, the article's clearly a derivative work of our docs. Do we care that they have violated the licence?] Gerv From Nick.Barnes at pobox.com Tue Mar 22 12:27:55 2005 From: Nick.Barnes at pobox.com (Nick Barnes) Date: Tue, 22 Mar 2005 12:27:55 +0000 Subject: IBM DeveloperWorks article on Bugzilla In-Reply-To: <42400B82.6040102@mozilla.org> from Gervase Markham of "Tue, 22 Mar 2005 12:11:46 +0000" Message-ID: <82625.1111494475@thrush.ravenbrook.com> At 2005-03-22 12:11:46+0000, Gervase Markham writes: > IBM DeveloperWorks appears to have swallowed and regurgitated the > installation guide: > http://www-128.ibm.com/developerworks/linux/library/l-bugzilla.html?ca=dgr-lnxw04Bugzilla > > [While higher visibility is good, the article's clearly a derivative > work of our docs. Do we care that they have violated the licence?] I care that it's way out of date. Despite being datelined 2005-03-18, it says: "The latest stable version of Bugzilla, 2.18rc3" In fact, this document is full of holes. And it doesn't even refer to the Guide in its Resources section. Nick B From etzwane at schwag.org Tue Mar 22 16:10:27 2005 From: etzwane at schwag.org (Sean McAfee) Date: Tue, 22 Mar 2005 11:10:27 -0500 Subject: Stalled custom field development Message-ID: <20050322161027.7E603BC77@mail.schwag.org> I really hate that I have to keep harping on this, but... Despite my best efforts, the custom fields discussion has stalled yet again. What is it going to take to make some real progress? There's a good chance I'll be losing my job next week, and it's hard to see myself maintaining an interest in the issue if there's not some degree of momentum going. (I may lose interest in any event, depending on the new demands on my time.) --Sean From gerv at mozilla.org Tue Mar 22 21:34:56 2005 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 22 Mar 2005 21:34:56 +0000 Subject: docs in a wiki [was Re: making review/bug filing optional for In-Reply-To: <423EC619.8000102@myrealbox.com> References: <4239F047.7050002@mozilla.org> <423A1D0A.5010809@mozilla.org> <423A2257.6040406@mozilla.org> <2cb10c4405031804539b80498@mail.gmail.com> <423B0F58.2000001@bugzilla.org> <423B6217.1020200@mozilla.org> <423D8608.8070606@mozilla.org> <423E6D0D.7000308@altap.cz> <423EC619.8000102@myrealbox.com> Message-ID: <42408F80.6080403@mozilla.org> timeless wrote: > or graveyard. i don't have much experience with wikis (or blogs), but > what i have seen is that figuring out what's changed and worth looking > at is non trivial, and not better than using bonsai on cvs or a decent > query of bugzilla/bu.gmail. That's certainly a concern. I too have seen many unnavigable spaghetti-wikis. >> Approval from any of the reviewers would mean taking the changes from >> wiki and putting them back to the docbook sources, which will be the >> only "official" documentation. > > lots of additional work.... Yes, this does seem like the worst of both worlds. Gerv From mkanat at kerio.com Wed Mar 23 02:19:39 2005 From: mkanat at kerio.com (Max Kanat-Alexander) Date: Tue, 22 Mar 2005 18:19:39 -0800 Subject: The New Reviewers List Message-ID: <1111544379.7616.2.camel@localhost.localdomain> Hey hey! So we have a fancy new Reviewers List By File, on bugzilla.org, now: http://www.bugzilla.org/docs/reviewer-list.html It's not linked from anywhere yet, but it will be, soon. At the moment, if you're a reviewer and you're not on that list somewhere, and you'd like to be, please let me know! We still have quite a few "unowned" files on that list. :-) If anybody else has any other suggestions, please let me know. :-) -Max From jremillardshop at letterboxes.org Wed Mar 23 02:59:21 2005 From: jremillardshop at letterboxes.org (Jason Remillard) Date: Tue, 22 Mar 2005 21:59:21 -0500 Subject: Stalled custom field development In-Reply-To: <20050322161027.7E603BC77@mail.schwag.org> References: <20050322161027.7E603BC77@mail.schwag.org> Message-ID: <4240DB89.50709@letterboxes.org> Hi, First, I assume that all of the work on this is here. https://bugzilla.mozilla.org/show_bug.cgi?id=91037 This bug has been open since 2001, 35+ patches, and 275 comments and No decision on the schema. Come on, it not that hard. Can you say.... Analysis Paralysis - http://c2.com/cgi-bin/wiki?AnalysisParalysis Design By Committee - http://c2.com/cgi-bin/wiki?DesignByCommittee or maybe even a little .... Not Invented Here - http://c2.com/cgi-bin/wiki?NotInventedHere The db schema question needs to be settled so this entire mess can move forward. I don't understand the fuss when you can buy a 64 bit cpu, 4 gigs of memory, and gig Ethernet for 3600 dollars. That is 13k of memory per bug on a db with 300,000 bugs. You can go to 8 Gigs for 4300 dollars. Second, Why are custom fields not on the road map? http://www.bugzilla.org/status/roadmap.html If this is never going to land, you guys should say that so you stop wasting peoples time. Dave (aka the Project Leader), you did a post on 1/30 promising to deal with this. I have looked through the archive and did not see your follow up. So I think it would be a huge step forward to decide on the following. 1. Road map? 2. Target release? 3. DB Schema? This stuff has been debated to death already. It is time for a decision. Thanks Jason. Sean McAfee wrote: > I really hate that I have to keep harping on this, but... > > Despite my best efforts, the custom fields discussion has stalled yet again. > What is it going to take to make some real progress? > > There's a good chance I'll be losing my job next week, and it's hard to see > myself maintaining an interest in the issue if there's not some degree of > momentum going. (I may lose interest in any event, depending on the new > demands on my time.) > > > --Sean > - > To view or change your list settings, click here: > From mkanat at kerio.com Wed Mar 23 03:45:29 2005 From: mkanat at kerio.com (Max Kanat-Alexander) Date: Tue, 22 Mar 2005 19:45:29 -0800 Subject: Stalled custom field development In-Reply-To: <20050322161027.7E603BC77@mail.schwag.org> References: <20050322161027.7E603BC77@mail.schwag.org> Message-ID: <1111549528.7989.6.camel@localhost.localdomain> On Tue, 2005-03-22 at 08:10, Sean McAfee wrote: > I really hate that I have to keep harping on this, but... > > Despite my best efforts, the custom fields discussion has stalled yet again. > What is it going to take to make some real progress? To be fair, had you broken your implementation down into separate bugs as I think I asked in a private email, I would have been doing review on it now. :-) Did you get my email? I never got a response. I have a lot of comments on the patch that you posted, but I'm not really able to give them review as part of the review process, because: (1) You posted the patch as a .tar.gz, which makes me unable to use Bugzilla's attachment-commenting feature. (2) The patch is too huge, and needs to be broken down into separate bugs. One bug for each step in comment 239 would probably be a good start. (3) The patch doesn't include the modifications to Bugzilla that would be necessary to make it active, so I can't see how the architecture works. (4) It seems to address many more features than the basic necessary implementation. And although that's great, incremental development tends to get us higher-quality code, particularly in an Open Source environment where we don't have a QA team and have to do intensive review on small changes to get high-quality code. -Max From mkanat at kerio.com Wed Mar 23 03:55:25 2005 From: mkanat at kerio.com (Max Kanat-Alexander) Date: Tue, 22 Mar 2005 19:55:25 -0800 Subject: Stalled custom field development In-Reply-To: <20050322161027.7E603BC77@mail.schwag.org> References: <20050322161027.7E603BC77@mail.schwag.org> Message-ID: <1111550124.7989.15.camel@localhost.localdomain> Thinking about it even more, here's what we'd want to do: (1) Add infrastructure necessary to "genericize" some of the current fields. I'll have to do some of this anyway for Generic Field Watching. We could start with rep_platform -- that'd probably be the easiest one, since it's not even used by all installations. (2) Move that one field into that generic framework, with the associated changes to the backend, with no changes to the UI. (3) Move the other enum fields into that generic framework, except status and resolution (which probably still need to be separate at this stage). (4) Add a framework to add similar fields. (5) Add a UI to add those fields. (6) Add other features (see comment 239 on the custom fields bug for what "other features" would be). This is probably the best way to go from what we have now in Bugzilla to custom fields. Step 1 could probably also be broken down a lot. I picture a Bugzilla::Field module and a lot of subclasses. I'd imagine that a structure similar to what we used for userprefs would work for a lot of that. In this case, that means FAD. I think that Dave is thinking about the schema stuff as we speak, by the way, FWIW. -Max From mkanat at kerio.com Wed Mar 23 04:02:20 2005 From: mkanat at kerio.com (Max Kanat-Alexander) Date: Tue, 22 Mar 2005 20:02:20 -0800 Subject: Stalled custom field development In-Reply-To: <1111550124.7989.15.camel@localhost.localdomain> References: <20050322161027.7E603BC77@mail.schwag.org> <1111550124.7989.15.camel@localhost.localdomain> Message-ID: <1111550540.7989.17.camel@localhost.localdomain> On Tue, 2005-03-22 at 19:55, Max Kanat-Alexander wrote: > I'd imagine that a structure similar to what we used for userprefs > would work for a lot of that. In this case, that means FAD. However, using FAC would allow us to keep our current Boolean Chart code, which is a big plus. FAD would require re-working the Boolean Charts. I'll let Dave decide about this, though. -Max From justdave at bugzilla.org Wed Mar 23 06:07:13 2005 From: justdave at bugzilla.org (David Miller) Date: Wed, 23 Mar 2005 01:07:13 -0500 Subject: Stalled custom field development In-Reply-To: <1111550540.7989.17.camel@localhost.localdomain> References: <20050322161027.7E603BC77@mail.schwag.org> <1111550124.7989.15.camel@localhost.localdomain> <1111550540.7989.17.camel@localhost.localdomain> Message-ID: <42410791.30300@bugzilla.org> Max Kanat-Alexander wrote: > On Tue, 2005-03-22 at 19:55, Max Kanat-Alexander wrote: > >> I'd imagine that a structure similar to what we used for userprefs >>would work for a lot of that. In this case, that means FAD. > > However, using FAC would allow us to keep our current Boolean Chart > code, which is a big plus. FAD would require re-working the Boolean > Charts. > > I'll let Dave decide about this, though. Yikes, and until that was pointed out, I was so close... I finally got through a bunch of reading up on what's been going on here. Max and I had a little discussion earlier tonight, also, and he's attempting to file bugs (most of them are filed already by now probably) to split up this monumental task into smaller pieces. Most of them beyond step 1 are easy to do once step 1 is done. Step 1 is a big one though, because it involves solving the above discussion. Max: can you explain to me why FAD requires reworking boolean charts? We already have fields that require table joins in order to check things from boolean charts, and if we know the field is in one of these custom field tables, then that join can be manufactured pretty easily, just like any of the others. $table = 'fieldname_chartnum'; push @tables, "INNER JOIN customfields $table ON bugs.bug_id = $table.bug_id AND $table.fieldname='fieldname'"; push @wherepart, "$table.value = $term"; That's psuedocode of course, don't trust my variable names. :) -- 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 kerio.com Wed Mar 23 08:12:53 2005 From: mkanat at kerio.com (Max Kanat-Alexander) Date: Wed, 23 Mar 2005 00:12:53 -0800 Subject: Stalled custom field development In-Reply-To: <42410791.30300@bugzilla.org> References: <20050322161027.7E603BC77@mail.schwag.org> <1111550124.7989.15.camel@localhost.localdomain> <1111550540.7989.17.camel@localhost.localdomain> <42410791.30300@bugzilla.org> Message-ID: <1111565573.8483.4.camel@localhost.localdomain> On Tue, 2005-03-22 at 22:07, David Miller wrote: > Max: can you explain to me why FAD requires reworking boolean charts? > We already have fields that require table joins in order to check things > from boolean charts, and if we know the field is in one of these custom > field tables, then that join can be manufactured pretty easily, just > like any of the others. Yes, but imagine that *all* of the fields are in the *same* table. :-) So that's only a minor re-working in that case, now that you've pointed that out. Joel would know more about this in general than I would, though. Of course, we'll have to deal with that situation anyhow, when we move all field values into the same table. So I suppose that's not even really an avoidable problem. I just figured that FAC was generally the Path of Least Code Change, when I started to think about how to make status_whiteboard into a custom field, or how to make any of our current